24 items tagged “timbray”
I’m pretty convinced that the biggest single contributor to improved software in my lifetime wasn’t object-orientation or higher-level languages or functional programming or strong typing or MVC or anything else: It was the rise of testing culture.
When you’re pumping messages around the Internet between heterogeneous codebases built by people who don’t know each other, shit is gonna happen. That’s the whole basis of the Web: You can safely ignore an HTTP header or HTML tag you don’t understand, and nothing breaks. It’s great because it allows people to just try stuff out, and the useful stuff catches on while the bad ideas don’t break anything.
The Net is the greatest listening engine ever devised. These days anyone can choose, with its help, to be well-informed. You have to make the effort to figure out which key people are really on top of what you care about, so that you can start listening to them. Plus, you need to deploy some saved searches. Once you’ve done these things, then when you turn your computer on in the morning, it’ll tell you if anything’s happened that you need to know about.
What I’m writing here is the single most important take-away from my Sun years, and it fits in a sentence: The community of developers whose work you see on the Web, who probably don’t know what ADO or UML or JPA even stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise.
Developing for the iPhone at the moment is like picking up dimes in front of a bulldozer.
Ravelry. Tim Bray interviews Casey Forbes, the single engineer behind Ravelry, the knitting community that serves 10 million Rails requests a day using just seven physical servers, MySQL, Sphinx, memcached, nginx, haproxy, passenger and Tokyo Cabinet. # 3rd September 2009, 6:50 pm
I propose that the World Wide Web would serve well as a framework for structuring much of the academic Computer Science curriculum. A study of the theory and practice of the Web’s technologies would traverse many key areas of our discipline.
Test-Driven Heresy. Tim Bray advocates TDD for maintenance development, but argues that it may not be as useful during the exploratory, greenfield development phase of a project. # 24th June 2009, 11:03 am
Are we so deranged here in the twenty-first century that we’re going to re-enact, wide-eyed, the twin tragedies of the great desktop-suite lock-in and the great proprietary-SQL lock-in? You know, the ones where you give a platform vendor control over your IT budget? Gimme a break.
The strain due to the fact that most business desktops are locked into the Microsoft platform, at a time when both the Apple and GNU/Linux alternatives are qualitatively safer, better, and cheaper to operate, will start to become impossible to ignore.
Thai personal names (via) “Family names were allocated to families systematically and the use of family names is still controlled by the government. Any two people in Thailand with the same family name are related.” # 8th December 2007, 4:26 pm
Some Notes on Tim Bray’s Wide Finder Benchmark. Fredrik Lundh demonstrates some Python ninja techniques for parsing log files using multiple cores (and eventually memory mapping). # 7th October 2007, 1:06 am
The Rubinius Sprint. Sun are throwing a ton of resources at Ruby, because as Tim Bray says, “it’s not fast enough”. Imagine where they’d be if they’d invested this kind of support in Jython five years ago... # 21st September 2007, 11:32 pm
There are only two hard things in Computer Science: cache invalidation and naming things
If you write a spec, write a validator alongside. How much pain could have been spared with early versions of RSS if we’d had a common, agreed upon validator. In short, it’s the test suite that ultimately decides the spec.
People don’t recognize how important URIs are. The notion that you have a huge, world-scale, information space, and that everything in it has an name and they’re all just short strings that you can paint on the side of a bus; that’s a new thing and a good thing.
In the big picture, Twitter did exactly the right thing. They had a good idea and they buckled down and focused on delivering something as cool as possible as fast as possible, and it’s really hard, in early 2007, to beat Rails for that. When all of a sudden there were a few tens of thousands of people using it, then they went to work on the scaling.
Seems easy to me; if you want to serialize a data structure that’s not too text-heavy and all you want is for the receiver to get the same data structure with minimal effort, and you trust the other end to get the i18n right, JSON is hunky-dory.