phyller

There are linting tools that you can and should add to your text editor of choice. Whenever I reference a variable in JS, if that variable is not assigned it highlights it as a possible error. If I define a variable or function and don't use it, that gets highlighted too. If my syntax is wrong, that gets highlighted. If my team had decided that we only want to use single quotes around strings, that gets highlighted. Even our build will complain and our tests will fail because we have incorporated linting into them. With ES6 there is no reason to have global variables anymore, so it is possible to confidently identify all these errors before the code is even run.

The language is constantly being improved while maintaining backwards compatibility. Finally it's ability to handle whatever kind of data you throw at it until you choose to check the data is a strength in an environment (web pages) where nothing is certain. You aren't sure about the data you will get from an API, from the user, you don't even know what kind of environment your code will be run in! The same code might run on the latest version of Chrome, a headless test environment, or some old version of Internet Explorer. And that is totally possible. It's all up to how you code it. And you have to get used to coding in this type of language. You can and should test your code as you go along, no need to wait to compile, you can see the results right away. Build your code to handle errors, because even if the code is perfect, the data you are working with will not be. And have lots of tests. Not only do they identify current errors in the code, but they allow you to make large changes with confidence that everything else is still working like it should.

While we all wish there was a standard few polished tools that did everything we needed and had good documentation and testing tools, I think the reality is that what we want to do and are capable of doing using javascript is evolving so fast that the perceived chaos is inevitable. So you have to choose, what are you trying to do and why?

I think if you are a professional, you should specialize. Make a choice and stick with whatever you choose, at least for a little while. You don't need to know everything. Maybe you don't need to know the front end at all. The whole "full stack engineer" idea is nice, but I'd rather have someone who specialized in the front end working on my site than someone who has tacked it on to a bevy of other skills and is just trying to hang on. If you are a professional web developer, then learn the tools you need, keep everything as updated as possible, and try to learn one other thing that is up and coming. Don't wait to let the updates and releases pile up before you upgrade, stay on top of it, read the blogs, update your code. But don't worry about knowing all the frameworks. If you are going to be working in React for a few years, it'll be worth the struggle with the current project you're working on. You don't need to know Angular, React, and Ember, just pick one. Learn another one when your job requires it, or mess around with it on the side.

If you are a professional web developer and have not kept up, and need to know the new hotness, I recommend Ember. They are always absorbing the best features of other frameworks (they now render the DOM like React does), have developed a pretty good update process that helps you transition, and have middling good documentation. They try to keep things simple. It seems a lot less fragmented than React.

If you need to build websites, but it isn't your only job, you don't need to know a javascript framework. JS frameworks are awesome and I love them, but for 90% of stuff you are almost just as good without them and for the other 10% you still don't need them. Learn Ruby on Rails. It's been around forever, has great documentation, has everything you need from start to finish, and if you want to dip your toes in a JS framework, you can put that on top of your Rails project no problem.

If you don't need to know this stuff for work and are just trying to keep up with the field, just keep in mind that everything you learn will be obsolete in 3 years. Hopefully you are enjoying the process, because you'll do it again soon.

It said one spacecraft was active, one was not, but it didn't explicitly say which was active? I was curious if they'll be able to reconnect with the Indian spacecraft.

I assume that the LRO is active, since they mentioned people that were still on the team, so they must have just been using it for target practice.

What advertising model are you suggesting? Perhaps it could be added to the Readme on the repo to help point advertisers in the right direction.

At first I thought this was a great idea, but then I thought about it more. I think this is the digital equivalent of an angry mob throwing bricks through windows. We aren't doing any good, just destroying the community we live in. What would it be like if all the content creators that are incentivized by ad revenue lost their revenue? And we lost their content? I don't like being placed into an artificial bubble of customized content by tracking services, but i don't think this is the solution.

I agree with the code test, the discussion and whiteboard I would say depends on the type of developer. The former member of my team that produced negative work did well with discussions and popular little whiteboard problems. Our normal policy has become to have applicants do a mini project that represents actual work that we are doing. So far it has worked flawlessly. This guy didn't have to do that because he was so experienced. He ended up creating over-complicated, very buggy code that took more time for us to review than it would have taken for someone else to write. And when we needed to make even minor changes to his code the fastest way to do it was to just delete it all and start from scratch, everything was so complicated and codependent.

He had an appearance of technical skill, was very well spoken, knew all the interview questions and answers, but had really bad judgment and somewhat poor logic when he had to come up with novel solutions. On the contrary, I taught myself and didn't have the CS background to do well in purely technical interviews. But I was given the practical challenge and crushed it. I knew what I needed to know for my job. Of course I had a lot to learn (and still do), but I was productive from the start, or so I have been told.

I guess there is nothing wrong with whiteboard tests, but I think a practical coding challenge where the applicant makes part of an application is much more valuable. You can see that they have basic coding ability, but also how they organize code and break down larger problems. Can they get the big picture right while making clean, maintainable code?

Bacteria can share DNA, there is a plasmid that sort of infects bacteria, and it causes bacteria to create connections with other bacteria. https://en.wikipedia.org/wiki/Plasmid It shares the plasmid DNA, but it also shares other DNA from that one bacteria to another. This allows bacteria to rapidly modify by mixing and matching DNA from other bacteria around them. Obviously bacteria that have traits that are beneficial are selected for. So some pathogenic bacteria that don't have this resistance will be killed by the antibiotic. Some nonpathogenic bacteria that have natural resistance will at some point share the relevant DNA with the pathogenic bacteria, which will then be selected for by the antibiotic, and then you have the new pathogenic antibiotic resistant strain. Or it could happen with some minor mutation, depending on how the antibiotic works, the article is deceptive in saying that resistance doesn't come from antibiotic use.