Hacker Newsnew | comments | show | ask | jobs | submit | Isofarro's comments login

http://en.wikipedia.org/wiki/Software_design_pattern#History

-----


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.

-----


You're assuming the programmer is dispassionate in all things asides from Duck Duck Go work.

-----


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.

-----


So they are building a server-side app to deliver a usable first-load experience with HTML and CSS, while the JavaScript loads in and runs, and until the JavaScript runs, all the links work like normal anchors.

Sounds like Progressive enhancement [1].

[1] http://tomdale.net/2013/09/progressive-enhancement-is-dead/

-----


Typical "progressive enhancement" calls for creating HTML in templates that have no knowledge of the JavaScript, and then using JavaScript to attach behavior to that HTML.

The approach described in this blog post builds a JavaScript app from the get-go, and uses a server-side technique to extract standalone HTML from the JavaScript application.

The net effect is the same (you get HTML on the client before you executed the JavaScript), but the developer paradigm is sharply different.

Typical progressive enhancement techniques require you to carefully construct a version of your application that works without JavaScript, and then find ways to shim in and bring the page alive. The approach I'm working on provides the HTML as a by-product of running the application normally.

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.

-----


Tom, it's ok to backtrack here. You (and the rest of us) didn't know at the time that progressive enhancement could be possible without making development much more difficult.

-----


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.

-----


Progressive enhancement is not a technique, it's a goal. Server-side rendering is a method for achieving the goal.

-----


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.

-----


Playing devil's advocate:

PE techniques aren't documented (so far as I know) so it's up the developer to take the path they're most comfortable with.

FastBoot, I suspect, will dictate how I code my application/server side logic.

On the surface, it looks like the cost of FastBoot is higher.

The benefits are, I suspect, are higher though: single code base, reusable views, etc.

-----


Hah! I'm glad others have seen we've come full circle again :)

As a developer of isomorphic (there's another term to pick apart!) React apps, I'm thrilled Ember and others are reaching the same conclusions on why server-side rendering is crucial.

I'll still call it Progressive Enhancement, since a server-generated response is "enhanced" with client-side functionally that still functions for those with it disabled.

-----


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.

-----


Seconded.

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.

-----


If you're excluding search (and I think your reasoning is at least plausible), then what IS a core part of Yahoo's business?

-----


Yahoo is a holding company focused on large, category-leading sites in Asian markets. They also own a struggling portal in the US.

-----


Ha! Like the old joke that McDonald's is a real estate company that sells hamburgers.

-----


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.

-----


News and email

-----


Reorganizations?

-----


I thought yahoo were pretty good, hasn't YQL been running for donkeys? And YSlow. Or am I confusing it with another service. I'm sure I used it about 5 or 6 years ago.

-----


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 has been falling apart for years now. Sometimes it's down for me for over 48 hours.

-----


YQL shouldn't be down for so long. It's likely that the underlying data source/API you were trying to access was down or your API key/IP address was blocked for exceeding rate limits.

-----


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.

-----


YQL runs a huge amount of the internal infrastructure at Yahoo. I'm surprised you saw it down for 48 hours unless you were blacklisted for abuse.

There is an open source clone from eBay that isn't quite the same: http://ql.io

-----


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.

ql.io looks interesting, I'll check it out.

-----


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.

-----


""Github Flavored Markdown" is a thing, has been for a very long time. Not a peep from Gruber about it."

In the podcast John Gruber did with Marco Arment ( https://overcast.fm/podcasts/episode/344902019595#t=4527 ), John Gruber notes "Github Flavoured Markdown" is a good product name.

He also says that they should standardise using a different name.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: