Say you have a webpage that uses a template engine and server-side code exclusively and you want to add a small little functionality that needs ajax to avoid a page reload, that is okay to use jQuery. If some other part of your application depends on that ajax to do something else now you are starting to get confusing code, keep doing it and you will be in the crazy zone really quick.

jQuery is being used more for creating custom UI components for DOM manipulation, these components are usually well (at least as well as the DOM allows) encapsulated so no jQuery leaks out of the component. Doing AJAX through jQuery these days is only acceptable in small stand-alone pieces of your application.

I agree, but just adding to the above:

Backbone is falling out of fashion, new stuff is not being built in it, but there are a lot of stuff that is not going to get ported to other frameworks anytime soon. Angular is currently hot but with angular2 getting popular it might not be such a good idea (while learning angular2 will not give get you any jobs, at least not yet). ReactJS and Ember are currently the best bets in my opinion.

Look you can learn the responsive part of bootstrap in one day, it is just some CSS classes you use, but you need to know at least one of the languages that compile to CSS, be it LESS, SASS or Stylus (SASS is more popular, but Stylus is supposedly the new best thing, LESS is simpler)

I would focus on learning NodeJS and/or a MVC front-end framework (backbone, angular, ember...), but there is this new framework that runs on top of Node called Meteor but no Node knowledge is required to use it. Meteor is supposedly the new best thing to use and it is a more complete solution (it is full stack, it covers the database, front-end and backend) so it might be easier to pick up, but the jobs for it right now are not as in demand because it is so new.

Also coffeescript it currently in demand, typescript (because of angular2) and ECMAJS6 will soon be as well. You usually don't need to know these, but it will look better in a CV because it means you care more about your code looking better.

Also, personally I like Gulp more than Grunt. If your aim is to find a job you need to know the basics of at least one so you do not sound like someone who uses their IDE compile button. Also it helps that you need to make a proper build process to get the LESS/SASS/Stylus/Coffeescript compiled.

Well, this implicit functionality is rather useful, that is why you see libraries like Apache IOUtils (like IOUtils.reafLine()) that bring some of that magic back. But the fact that you can go to the lower level is a good thing, I just wish the Java designers had these kind of utilities backed into the core of the language.

I think he means circular reference ( http://en.wikipedia.org/wiki/C... )

Probably not very soon, but you might start seeing it for people with knee problems in our lifetime.

To many people a glowing apple on the front would classify as a "compelling feature".

But honestly if they made a TV with a decent remote control (maybe touchscreen?) that alone would make me consider buying one (I have not owned any apple devices ever).

PuTTY also runs in linux, if you are doing a simple SSH access you can do it in any terminal easily, but PuTTY also does a lot of stuff that you need to be a command-line specialist to be able to do by hand. Plus it saves your configurations for later uses.

Personally I always do tunneling through PuTTY

But when I see years of experience in a job posting it usually is like this:

X years of experience in backend/functional programming/frontend/relational databases like (java/ruby/C#)/(clojure,erlang,scala)/(javascript,html,css)/(oracle,sql server,mysql). Bonus points if you have experience with Y technology.

Which is sensible, even though rust might be only a couple of years old when you want a senior dev you want one that has been dealing with these kinds of problems for many years, even if most of those years were not in the right language. So expect a rust ad to say:

10 years with a low-level programming language (Rust/C/C++/Assembly), bonus points if experienced with Rust.

Well if it ran Emacs it would be able to do anything anyone could possibly want.

Your documents will lose formating when the files are converted, if you want users to be able to download the files in any format you should just store the files in the way that the user uploaded them and convert directly. Create a metadata plain text version for search, maybe a visualization version so that the user be able to see the files inside your application, in this visualization version you should just use the easiest method.

Of course this depends heavily on your requirements.

The real problem are the clients, many only want the complete solution and they want to know exactly when it is going to be delivered and how much it is going to cost. I have seen way too many projects that had these kind requirements to be shoehorned into the agile methodology only to stupidly fail after some months.

If you project has to be done in 6 months and has to deliver everything that the client requested agile simply does not work.

But is it NP-Hard?

You are absolutely right about the complexity of the ecosystem, but from my experience every Java based platform eventually evolves such complexity (it is like a xml fetish)

So you are basically saying that hadoop will eventually fall in disuse but HDFS (Hadoop file system) will linger on with new platforms built on top of it? Or do you believe that the HDFS will also be replaced eventually?