dilithiumH3

I think you missed the point of a TL;DR. I have always treated TL;DR as an abstract to a paper. It kind of sets the stage and presents the conclusion in a concise way so that if one is still interested in the full content of the paper, they can read in depth. For example, if the title is interesting enough for me to get to the page/post. The TL;DR basically packages and refines the crux of the topic so that I can get the gist of the post.

Of course, it would be plain stupid to try to get involved in a discussion without actually getting into reasoning for the conclusion but then there is no solution to stupidity.

Coming from a person who has owned both. I can say for sure that it just doesn't matter. Some will say that the pro has more ports and is more of a power beast, but given all that let me ask you the following. 1. You are starting to program, consider yourself at least a few months out till you get into a world where you will start programming device drivers. 2. When was the last time you actually used a dvd drive? Everything is on the internet or wirelessly available.

Most of the work that I have done, ranging from device drivers to now, distributed systems, my macbook air sufficed. Programming has never 'required' me to have a retina display. If you asked the question with the context of media or photo editing, my answer would be different.

My setup is as follows: 1. Macbook air 11" (portability is the key) 2. Apple wireless keyboard and mouse 3. Apple 27" display connected via thunderbolt. (wired network). You may substitute with any other good monitor.

The desktop setup is just a plain must. Anyone who says 11" or 13" or even 15" is enough for working, has just never worked on a big screen long enough. It just increases your productivity by an order of magnitude. Imagine the time saved by having multiple windows/terminals and documentation right in front of you and not having to switch between the two.

So, to end it all. Get a decent compact machine that you can take with you, and use on the go. And get yourself a good desktop setup when you want to get serious stuff done. Also, the desktop setup (personally) focuses you into a simple and distraction free zone, allowing you to be more productive.

I personally use REST APIs (over HTTP/HTTPS) to surface all the backend capabilities. Then it doesn't matter how the frontend is developed.

In your case you would probably want to serve the content(resources) using REST. I am not particularly sure how this is done in Rails but it shouldn't be tough to have your objects serialized into json. You would then write AJAX code in your frontend/client code to interact with the backend via the API.

Biggest suggestion anyone can give you: Don't prematurely optimize. Period. Python/Django is a good starting point given the good community support. Start with a standard project structure, so that asking technical questions can be answered by anyone out there.

So something that worked for me when I was starting out was to reverse engineer an existing Opensource project or maybe even look at their buglist. IMO reading code and figuring out the intuition behind it is almost half the battle. You may also want to pick up some engineering/algorithms/computer science books to get the underlying (and almost universally) applicable concepts.

Coursera is a good place to start.

Last I heard, it was a re-skinned and simplified Ubuntu based os. This might have changed given the rise of android based os flavors in the market.

My company is willing to sponsor but given the length of time it takes, it's basically not in my favour. It can at times be a hassle and more like a burden.

I would be very interested in knowing more about what exactly his problems were. What APIs what he trying to use? I work on backend systems and build APIs or related systems everyday so getting a rant is not of much help. :( * Auth Tokens - needed. * Code samples - good place to get started. * Documentation - really, I am yet to see a good API without documentation. * Blog - Okay not always helpful but other times its a way to tell users about new features, downtimes, changes. * business development/relationship/ecosystem - not important but can be nice to have in case you get stuck or are building something that is more than just a crappy weekend hack.