Pick Your Battles

http://zef.me/4235/pick-your-battles?

by tanepiper • 14 years ago

98 20 14 years ago

zef.me

X-Istence• 14 years ago

The page is unfortunately not responding.

fideloper• 14 years ago

Google has it cached (Altho it's slow to load as well): http://webcache.googleusercontent.com/search?q=cache:YAoaA6A...

yareally• 14 years ago

It'll load much faster if you strip out resources that still load server side on it (like images).

http://webcache.googleusercontent.com/search?q=cache:YAoaA6A...

(just add strip=1 to the end of cache searches)

chmike• 14 years ago

The interface is bad on iPad. I can't zoom the text. It's stressing to read with so small text. Reading to the end, the back button makes you skip back through all the pages.

This guy is not doing what he says people should do. He uses the latest fancy web page UX where he should use a well proven UX but maybe boring. Do what he say not what he does.

RyanZAG• 14 years ago

That's what he is talking about though - he used node.js and redis on a production site when neither are close to production ready. Thanks to him though, both are improving rapidly and should be production ready before long, so kudos.

His whole article is about "woops, going with the latest tech wasn't such a good idea - here is what you can learn from this".

So yes, he is using the latest fancy web page UX and he has written an article about what he has learned. Next site he makes will probably be using well proven UX.

bonzoesc• 14 years ago

Wordpress handles load pretty badly without any caching enabled.

guylhem• 14 years ago

The google cache link is not working due to pictures. Correct text-only link : http://webcache.googleusercontent.com/search?q=cache:zef.me/...

Nice nugget from the article : "Facebook uses MySQL to keep most of its data, are you going to get bigger than them"

You could rephrase as that as Djisktra did "Premature optimization is the root of all evil"

First solve the problem then optimize, unless it gives you a special edge that'll bring money.

When I started doing "stuff" I wish I had read such an article. It would have saved me both good nights of sleep AND unneeded worries.

zacharyvoase• 14 years ago

It wasn't actually Dijkstra who said the bit about premature optimization; it was Donald Knuth.

mrviking• 14 years ago

Definitely smart to adopt software at the correct point in the hype cycle so other people solve core problems before you start using it: http://www.gartner.com/technology/research/methodologies/hyp...

It sucks to be the alpha tester. However, the SQL vs NoSQL debate is silly, because Facebook seems to be using both to scale.

A lot of content at Facebook seems to be served from a denormalized NoSQL storage and that is the useful takeaway insight. I do not know what I can learn from the fact that a team with some of the most talented SQL ops and developers can store some core data in SQL.

alephnil• 14 years ago

It forgets to mention that some technologies just dies after the "peak of inflated expectations" and never manage to turn the slope.

johngalt• 14 years ago

"At Cloud9, more often than not we predicted our bottlenecks wrong. Dead wrong."

I'd be a millionaire if I made a nickel every time someone guessed at a bottleneck rather than looked. If I wanted to expand my portfolio, I would add a nickel for every time this is said: 'we had our programmers working for 6months to improve performance' when performance issues could have been solved with a $10k SSD array in a week.

damian20002• 14 years ago

Throwing a $10k SSD at a problem is a boring solution. There's very little that can come between a developer and a chance to optimize some badly performing code. ;-)

damian20002• 14 years ago

Great article. The facebook example is very pertinent - they started with PHP and MySQL and only when the traffic came did they scale to using C++ (via a PHP to C++ translator). I'd be interested to hear what the writer would think of using Go on a new project ... a new language that has been called boring and yet does have some features that aren't really in use anywhere else (channels, slices, goroutines).

gbog• 14 years ago

there is a second order analysis on Facebook: how many of its employees who quit to create a startup did use php-mysql?

Kynlyn• 14 years ago

When I read articles like this, I always wonder if early-on there was someone in the room saying "Um..guys..maybe we should just pick something stable first?" and got shouted down as being a Luddite?

I've seen that countless times where exuberant "experts" hastily choose a new technology over the warnings of those who are a little more thoughtful in their technology choices. Usually the ignoring comes with a heavy dose of disdain and mocking of the person for not being "up to speed with the latest stuff".

Then when disaster strikes, they seem to have forgotten about how they were warned and write a blog post about how much smarter and more experienced they have now become.

Not suggesting that this the case here, but I have to wonder if Cloud9 didn't have at least one person saying "Whoa there sparky! Have anyone of you considered how we are ever going to query this stuff?", etc.

plinkplonk• 14 years ago

"If a new technology is going to give you the edge to push the competition out of the market, it’s a no brainer."

Superior technology (as distinct from new technology) almost always gives you an edge. The edge maybe a small one, but it exists, assuming other things are equal (quality of your devs, say). Isn't this the whole point of pg's "Beating the Averages" essay? [1]

But then, I guess you need some real hands on experience to distinguish superior tech from 'the latest buzzword' tech. For most apps, node.js is probably an example of the latter than the former. So the OP's point holds.

[1] http://www.paulgraham.com/avg.html

ntoshev• 14 years ago

Great advice, but I've heard it before. Any chance of an article describing what really happened for each of the problems listed, and how you solved it?

mgkimsal2• 14 years ago

Here's my theory. When I was learning programming early on, then later on with specific languages, almost all the problems I'd run in to were "solved problems" - I just didn't know the answers. With enough searching, testing, querying, asking, I'd generally find the 'right' way to do X, and move on.

I've grown more conservative over time, but other people tend to continue to operate with the idea that with enough searching/testing/querying, there will always be 'the' answer which will solve all their issues. Not picking on node specifically, but choosing that a year ago or so as the platform to write a production system in seems hopelessly naive. I suspect that some of the people involved had this unconscious idea that, with enough work, the 'right' answer would magically appear, and they'd move on to the next problem. Turns out that's not what happens when choosing bleeding edge tech, but I'm not sure it's a lesson everyone learns (and I suspect it's a maxim not everyone really cares about anyway).

mgkimsal2• 14 years ago

"We hired a few node.js core developers (actually, over time we ended up hiring 75% of the core node.js team) — they were incredibly helpful."

This sort of approach won't scale too well when 10 startup companies all need to hire the core node.js (or insert favorite trendy base tech of the day) team.

peripetylabs• 14 years ago

I've seen this in mathematical programming too. The most successful projects use old Fortran libraries: LAPACK, FFTPACK, etc. Python (SciPy) is popular, and great for prototyping, but I still write everything in C because although floating point is flawed, it's flawed in well-understood ways.

Pick Your Battles

Related Stories