edmundhuber
IMO, attacking all of "devops" (or "agile", or "cloud computing") at once is not productive, because it means so many things. So if you don't get specific, as others have said, it makes you seem like you just oppose new things.
For example with devops, a very rational concern is that if the infrastructure team shrinks or disappears, then there's no one on the hook for making things all work at the same time. If you leave it to the developers of each team to make their thing work, you are likely to have a continually broken development environment.
A good argument to oppose any change without a clear rationale for the change occurring is "if it ain't broke don't fix it." This, at least, leads to someone explaining why change is necessary, and then from there perhaps you can have a conversation.
Pay to play: for youth development, the player's family has to be fairly well off. This is pay for either an academy, or going to a D1 college team, paying for travel, etc etc
Limited coaching talent: not very many soccer coaches play or even watch soccer regularly. This leads to an emphasis on agility and strength rather than skills and strategy. Agility and strength work out pretty well if the team you're facing has the same focus, but if you're playing against a team that has drilled and nurtured intelligence it will end badly for you.
1) if the idea is to impart all of the kinetic energy needed to get into LEO at once, on the ground, then you are talking ~17,000 MPH worth of KE (though truly, more, because of loss to drag). There's a reason why max-q is an important consideration in the design of space vehicles. The space shuttle reaches max-q at 30K feet, where the density of air is 3x less than at sea level. How do you design your vehicle so that it doesn't turn into dust when it hits 1 ATM at 17,000+ MPH?
2) the centripetal force on the vehicle, prior to launch, will be enormous. So in addition to not deforming and/or burning up the moment the vehicle hits the air, the vehicle also needs to be built sturdily enough to not get crushed while being accelerated.
I read Bad Blood a few weekends ago. Holmes hoodwinked investors who wanted to believe that a fairy tale technology could exist, by never publishing or otherwise allowing outside scrutiny of their technology. How is this company different?
> For example, an eater might search for udon, but end up ordering soba. In this case, the eater may have been looking for something similar to udon, such as soba and ramen, instead of only being interested in udon. As humans, it might seem obvious; Udon and soba are somewhat similar, Chinese and Japanese are both Asian cuisines.
Aren't udon and soba both Japanese?
Here's one great thing about ItB that was not discussed in the article (probably for brevity!). When you're deciding what moves to take, the game will show you the effect of the move you're about to do. This is really handy because often your moves have knockback, or splash, etc so it's challenging to figure out on your own what exactly your move is going to do.
The not so great thing about ItB, visually, is that after a certain point in the game the grid just becomes too cluttered. This is because every enemy in the lategame has effects, splash, special moves, etc. It becomes difficult to parse visually. If the article had dissected a screenshot from the late game, they probably would not have come to the same conclusions as they did.
Suppose the code was "list.extend([1])" (Python). And the comment was "why didn't you just list.append(1)"? That would be a completely reasonable thing to say.
I think what I want to caution is that there is a middle ground that this article is ignoring. Yes, sometimes it is uncouth to just say "why didn't you just _". But it can also be important to have a little bit thicker skin, as sometimes you will get a comment that looks just like that, and there will be a good reason.
While it's true that not all opinion is fact (uh oh -- 5. sarcasm) there is nothing out of line in asking "Why didn’t you just do ___ here?" How you approach this question has a lot to do with your own perspective. If you are feeling defensive, it can seem like the code reviewer is calling you out. But if you have experienced people reviewing your code, this is a question that you will get a lot.
"Why didn’t you just do ___ here?" often simply means "I don't see why you couldn't have done it this simpler way, can you explain"? It's often for everyone's benefit that things are done in the simplest, most obvious way possible, and it's not productive to take offense at being asked to reconsider how you accomplished something.
It can be kinda hard to see if two neighboring entities are the same in a given band (kbs, mbs, gbs), because you're looking for the absence of a difference of a pixel or two. Maybe if they are the same and neighboring, join the two columns rather than have them spaced? That would visually instantly tell you that those two samples are the same.
It's not like the doctor is building a new space rocket every time they do an appendectomy, or designing something completely new. It's a procedure that is done thousands of times per day. But still, no one can tell you how much it will cost.
There's layers and layers of waste in American healthcare. No one seems to really want to take point in fixing it. Frankly, it seems like a hopeless situation that will only get worse.
So then you would have instant hot or cold water, instead of any mixing at all.
Here are some reasons why this is a dumb idea: * can't handle branching, * pipe networks have "welling points" where water will simply remain by gravity, and no pumping will get it out.
Has anyone tried something similar?
The ultrasonic puffs of air keep it suspended.
I think people have gotten lazier and they expect to be taught, rather than seeking out materials. Or perhaps the people wishing to learn, are not as interested in programming as they think they are.
That being said, yes, learning "cloud" is an enormous sink of time that requires some exposure to lots of different silos of information. Doesn't that make sense though? It's a complicated subject.
But maybe the "take home test" strategy is about identifying candidates that will sacrifice their free time for your company.
No matter how you look at it, it doesn't look good.
The problem is that savvy users will install additional plugins to block these Javascript programs from running, the same way that they use Adblock. Unsavvy users will just have a shorter battery life.
Another effort in this space is Brave, and Basic Attention Tokens (BAT). Instead of expending browser resources to mine, the idea is that people start using a special browser (Brave) that dispenses BATs to the websites you dwell the most on / get the most value out of. Then presumably the site that receives the BAT could exchange them for USD.
When we look at an application/resume from a bootcamp grad, it tends to only contain: "this is what I was doing before", "this is the bootcamp I went to and the projects we did there" (sometimes, these are cleverly formatted to appear as projects done after the bootcamp. We can generally see right through this, and it feels a little dishonest, but it is fine.)
What would make a bootcamp grad resume infinitely more attractive is if they demonstrated their enthusiasm by doing more projects. What it comes down to for me is: this person wants to have a job that many people go to a 4 year program for. Additionally, lots of those people who went to the 4 year programs had an inherent interest in the subject even before starting schooling. Bootcamp grads are heavily outclassed in general by these candidates, and an org is taking a risk (burden) by hiring a bootcamp grad.
So, it goes a long way for a bootcamp grad to 1) demonstrate that they're going to come in fighting and have a raw enthusiasm, 2) possibly tie in their previous employment (biotech? stats? very relevant.) These two things are going to be their strongest assets coming into the job. Not whatever they learned at bootcamp.
In one of these companies, SPA architecture was chosen because the backend was unacceptably slow. Instead of fixing that problem, we adopted more complexity by transitioning to SPA. When I left, the backend was still slow, and the SPA was breaking all the time. It felt like a waste of effort and I would never do an SPA by choice again.
Today, there are hundreds of programming languages competing for attention. It is in your interest to put an example front and center of why one should spend time looking into yet another programming language.