Top-tier devs just give you skill and experience; that in itself doesn't give you passion.
What you consider an act of desperation, DuckDuckGo sees as an act of passion and strong interest. If a skilled developer values his time more than his passion, perhaps that isn't a good fit for DuckDuckGo.
Desperate people can apply, but they must be able to prove they have the technical capacity to deliver too. Which means they need to meet the calibre of developers who are in high demand, which means perhaps they aren't desperate?
This process doesn't look much different to participating in an open source project in your own time, and then after your contributions have been assessed a decision/invitation extended to be part of the Core Team. Except that invitation is also an employment contract with a salary.
By having the app running on the server it can take advantage of being primed before the first request arrives. Primed in that the app is already running, and/or the data retrieved is cached and regularly refreshed.
Depending on the nature of the application, if it's largely not client personalised (a content site like Bustle, as opposed to a Gmail client), one instance of the app on the server can respond to multiple client requests in it's lifespan. So basically it's an already spun up ready to go instance of the app, or already processed, just needs to squirt the HTML buffer at a response object.
Really? I'd imagine most Ember projects are more like Gmail than Bustle (in the sense that they probably have at least login). If even a single byte of the payload changes, you're looking at O(n=users) instances and then you're potentially back at the problem of having the db hit happen before the first pixel on screen.
Additionally, progressive enhancement techniques almost always involve server-side rendering, which means you lose the benefits of client-side routing I describe in the post.
The goals of progressive enhancement are wonderful. My complaint has always been that previous techniques hamper developer productivity far too much to be realistic. With FastBoot, I'm hoping we can offer the benefits with far fewer costs.
I think this might be semantic quibbling at this point.
Yes, progressive enhancement and server-side rendered JS are similar. You can see the latter as a new version of the former. But it is implemented in such a way - a novel way - that it definitely deserves a term of its own.
It's not really useful for the conversation to lump it in with the traditional definition of progressive enhancement that's been done for years.
Even middle of the road efforts I tried a few years ago (such as sharing a templating language between client and server even when the implmentation language differs) was fraught with friction compared to this technique.
As far as I can tell, working in the AWS teams is perhaps the best software engineering place to be at Amazon (e.g. note Tim Bray's joining the Vancouver office.). The positivity from there I've seen echoed by other diverse sources, so unlikely to be just kool aid.
Everywhere else, stay away, unless it is something you have a very very strong passion for. (Perhaps the Games teams might be another AWS like atmosphere in the making, hard to say yet). Don't get bait-and-switched with AWS buzzwords, make sure it is AWS doing the hiring.
From my experience working for Amazon, they seem to grind engineers down, so they are regularly churning through a constant supply of graduates to keep employee numbers up. So a large chunk of engineering is new to 2 years.
Stack Ranking (the cross-over of staff between Amazon and Microsoft in Seattle means the same people drawing up employee performance processes. They may insist it isn't stack ranking, but looking at how the review process works is inescapable that the nastiness of stack ranking is present)
Edit: there are a handful of genuinely good engineering teams at Amazon, but their ability to make a positive impact is tainted by the volume of garbage that surrounds them.
Having been a Senior Engineering Manager in an Amazon business, I can confirm that the stack ranking process is the single worse treatment of employees I have ever experienced. Furthermore, it is not based on an honest and truthful assessment of individuals, but rather who is best at standing up in a room full of managers across one division and arguing that their developers are better than someone else's, even if they've never met or seen the output of the developers they are arguing against. In fact, I've even seen people judged on the _amount_ of commits they've made (not the quality) and the _amount_ of wiki edits they have published.
It was the single worst employment period of my life, resulting in depression and stress that was off any scale you'd care to mention. I cannot recommend enough that you avoid at all costs.
I learned a few languages in school: French, Afrikaans, Xhosa, South Sotho. Been learning Mandarin on my own over the past year (using Pimsleur).
The main difference is the tonal system, reading it it sounds easy, but training your ear to pick it up takes time. It's hard to follow an audio when you're not picking up the nuances of the tones in context.
The language structure is kinda logical, so far. I haven't reached tenses or multiple clauses yet.
I found some pronunciation similar to French, for me ren (Zh: people) is similar sounding to rien (Fr: nothing)
I'd be wary of touching any Yahoo API that isn't a core part of their business. Developer enthusiasm isn't enough considering how likely, when Yahoo run into difficulties, they'll just sunset APIs we're using.
I want to say the Search API is a good example of a core business proposition: there's a revenue stream there for the service, but the search results are probably from Bing, so although the Yahoo side looks like it has longevity, the reliance and licensing of search metadata from Microsoft is a dependency that ups the risk of using this API. I don't really trust Microsoft not to pull the carpet out from under us when they've collected a sufficient number of eyeballs to consider the second step of a bait and switch.
They've made it clear that they're in the business of being a media company, not a technology company. So I would say that the media-focussed products like Tumblr are probably more reliable bets, but it also means that they're more likely to pivot based on unpredictable trends, rather than focus on any specific technological capability.
I don't know how it works for outside developers, but I've discovered that they use it heavily for some of their own media projects including, for example, their video product Yahoo Screen. What that means for longevity is probably an open question.
YQL is one of my favorite Yahoo services, but I hesitate to use it in projects due to its unreliability / uncertain future. It would be great to have an open source clone that was deployable to Heroku or similar.
Oh, I wasn't actually the poster who saw it down for 48 hours. I guess it's more that since YQL is accessing a bunch of external services there's a good possibility that something else was going on. As a 3rd party service it's a bit harder to debug, but that's just the nature of things.
It doesn't need to be called "Markdown" to justify what they've invested their time in over the last few years. Changing to a non-Markdown name doesn't invalidate their 2-year effort of creating a spec, unit tests and implementation of a human-readable text format that can be rendered as HTML. A name change doesn't change the fundamental and substantial part of their work.
That's why they don't even need to call it Markdown. It can be a markdown derivative with a different name and it would still be as successful because they have the mindshare and the beginnings of a collaborative community.