July 31, 2006
I am alive, and I have stories
Just a note that I am alive. I am currently helping take care of my mother in Louisville. She’s doing fine after her second surgery, but she is in a lot of pain. She was freaked out about needing the second surgery. Not only was it demoralizing to come home for a week and then find out she needed another surgery, but she had an allergic reaction to the anesthetic used in her first surgery and almost didn’t wake up. (I’m sure that’s a bit inaccurate…I don’t claim to be medically literate. :))
And boy do I have stories to tell when I have time. 😉
At this point, I still plan on attending and blogging about SIGIR next week. More when I have time…
July 9, 2006
Soccer: It’s the Strategy, Stupid!
Everybody has a theory why “soccer” isn’t more popular in the United States. None is ever going to be proven right, but the one I’ve found most convincing attempts to explain both the popularity of soccer in the U.S., and the level of play of U.S. soccer players: the theory that U.S. soccer is too organized. And not in a good way.
If you’re like me, you grew up with organized youth league sports. Which means, in many respects, you never stood a chance at being any good at it. Young leagues are all about having fun, playing by the rules, giving everybody a shot, and fostering self-esteem. Laudable goals, but not really an environment that fosters playing at an elite level. The best kids I knew in any sport did not play youth league sports: they played pick-up with the freaky kids across town.
Soccer–that is, football–is, so they say, all about playing pick-up in the streets with the best kids in town, even if those kids don’t belong in your middle-class suburban neighborhood. Right off the bat, you see the dissimilarities. How can U.S. kids compete with that? How could U.S. kids grow up to be so passionate about a sport like that?
It’s not a perfect theory, but I’ve heard it a number of times, and I find it more convincing than other theories. The closest theory in my mind is that the rules of soccer just don’t lend themselves well to high-impact advertising.
But, watching the World Cup championship this year, a competing theory gelled in my head, which I haven’t yet poked many holes in. No, it’s not the theory of headbutts. It’s the theory that American sports spectators like high levels of strategy.
Every other sport that is popular in the U.S. has, at its core, a battle of shifting strategies.
In baseball, the pitcher and catcher have to strategize about every batter they face; in turn, the batter gets cues from his coach on whether to expect a pitch that’s hittable. When runners are on base, strategy is taken to another level.
In basketball, 80% of the trips down the court result in set plays, either called directly by the coach or by the point guard. These are plays that are practiced day-in and day-out. Defensive strategies might shift a half dozen times during the game, in response to who’s on the court, whether the offense is hot from a certain range, etc.
Golfers have a strategy for every hole, hockey teams seem to set up plays much like basketball players (I don’t know enough about ice hockey to know whether that’s really true), even tennis players get a chance to play mind-games when they serve. About the most notable exception is Beach Volleyball, but, well, who doesn’t want to watch Misty May and Kerri Walsh bend over in their bikinis?
Of course, you can’t take your obsession with strategizing too far. You wouldn’t want to be seen running around with a chess geek or anything. But bursts of athleticism + plenty of strategy + plenty of action = good spectating.
Okay, I’m really just talking out of my ass here, but that’s what spectator sports are really all about anyway. So nyah.
July 6, 2006
Web Development: Engineering Geeks vs Design Geeks; Small Teams vs Large
I usually resist the urge to blog something that appears on Slashdot, on the theory that it’s old news within fifteen minutes, and most any response can be found in the comments (which can be pretty good if you have the right filters). But IBM Developerworks recently published an article on Ruby and Seaside by Bruce Tate. Read it, then come back.
Maybe I’m dumb, but let’s summarize what you’ve just read:
- Ruby supports string interpolation, which has only been a hallmark of scripting languages for 20 years (and
eval()for, what, 15 years?) - Ruby can be embedded in Apache, “raising the bar” for CGI programming, like, um,
mod_python, and, um,mod_perl, and… - Embedding code inside HTML is a good thing
- Objects (that is, code artifacts) rendering themselves is even better
I’m sympathetic to the “Java is soooooo 90’s” crowd, which first latched onto Python, and now are big into Ruby. I like Python, and I really like many of the design choices by the Rails framework developers. (Chowhound, another recent CNET acquisition, recently relaunched using Ruby on Rails. I doubt they could’ve had such a quick turnaround in Java, and I’m really hoping to learn from their engineers when they re-emerge from the depths.)
Purely anecdotally, judging by some of the recurring healthy debates on my team, Java web development is lacking, and the plethora of competing frameworks tends to make things worse, not better (rule of thumb: the number of religiously held viewpoints grows exponentially with the number of competing frameworks; corollary: the number of affordable candidates who are genuinely experienced in your framework of choice and not just futzing with their resume’ decreases exponentially with the number of competing frameworks).
Bruce and many people in the Ruby (and, especially, Smalltalk) community are smart, hard-core engineering geeks. It’s no surprise that niche frameworks cater to smart, hard-core engineering geeks. But as soon as you separate the engineering geeks from the design/webdev geeks, you have a problem. (And, really, as soon as your team grows large enough, and enough work is being done simultaneously, you have a problem. Not to mention the overhead of context switching.)
I can be incredibly dumb/dense sometimes, so let’s discount me: design geeks are not dumb, they’re just familiar with different things than engineering geeks. The more you intermingle code and presentation, the more your team will spin its wheels. I’ve seen it happen. I’ve heard horror stories that make my team’s worst moments seem tame. Why on earth would you want to go back to a time before MVC was commonly implemented?
Through the years, I’ve developed a theory of medium-sized teams. Wanna hear it? I call it the co-dependency theory of web development. It runs like this: engineers (me included) like to be in control, so they build systems that they can easily modify on their own, however convoluted or difficult it may be for non-engineers or new hires. This causes other teams to always run to engineering when a change needs to be made. But that’s good, because engineers (me included) like to feel wanted: so we gladly modify the system on our own everytime a change needs to be made. And web developers/designers? They like it, too. Less work to do, less hassle (and engineers, after all, are not known for their, uh, our documentation skills). Who’s enabling whom in this scenario, I haven’t determined. When I do, you’ll have to buy my book to find out.
All kidding aside, let me summarize what you’ve just read, after you read what you had already read:
- web development frameworks are for more than engineering geeks; they should show the same separation of concerns that engineering geeks like in their own code: overhauling the presentation using the same features and data should not require any engineering work
- design geeks are smart. well, usually smarter than me, anyway
- I’m a co-dependent egomaniac…uh, that is to say, never trust an engineer who says “trust me, I’ll do it for you by morning”; read your Bible, especially the part about fishing
Your task, should you choose to accept it: publish a blog post purely by having Word objects render themselves to a page, using an XML configuration file to determine the order of words to publish. It’ll be easier than working with a large-ish team on a large-ish web site for more than two years if the code and presentation are intermingled.
Update ~10:35p: In case it’s not clear, Tate’s article, as published, comes across to me as representing a big step backward from modern web frameworks (Java or not). I am not dismissing the Ruby on Rails community, nor the Java community–least of all, my own team. I probably should have focused more on why advocacy articles like that one almost always fail to satisfy, but there is a real point that niche, engineering-geek-culture-driven frameworks tend to focus on rapid prototyping and small development shops, and practically assume engineering geeks should (or could!) do it all. (Note to self: don’t blog as a means of using up your nervous energies when you’re tired and want to go to bed.)
July 4, 2006
Web Frameworks, Underlying Technologies, and You
Ian Holsman asks What should your framework do for you? in response to a post by James Bennett on Django and AJAX.
Do I know how how to write javascript? yep. I also know SQL, and have writen webservers modules (although not much lately) but knowing how to do it doesn’t mean I should be doing it every time I want to develop an application if I don’t have to. Having me writing (and debugging) javascript is not a good use of my time. I should be spending my time doing more valuable things like creating job sites or content aggregators. If django had a fancy javascript layer those sites would be using it right now, instead of waiting for me to develop and integrate it.
While the context of that discussion is what, if any, toolkits the Django framework should tie into, the philosophy runs deeper. I think Ian hits it on the head: frameworks should simplify your life most of the time, but give you the flexibility you need in special cases.
Of course you have to expect that any engineer or web developer you hire understands what’s going on under the hood. Using an ORM toolkit doesn’t mean you can get by with not understanding SQL or how to optimize queries or how indexes are used. Using an abstract REST API doesn’t mean you can get by with not understanding HTTP.
In the base case, using a higher-level programming language doesn’t mean you can be effective without understanding what’s going on underneath, what the CPU sees, how your VM utilizes memory, and so on. But you rarely see people anymore arguing that programmers need to always be burdened with these details. (You used to see that argument, but it’s rare.)
A framework is an abstraction, which frees up the developer’s mind to concentrate on delivering (if not perfecting) the overall functionality of the application on time. Frameworks represent the commodification of certain development skills, which is good, because it means more can get done. But to be effective, you have to know the limits of your framework, and be able to circumvent the framework when necessary.
Which isn’t to say that frameworks aren’t without their risks. If you depend too heavily on a framework that ceases development, your entire company can freeze. (So don’t use proprietary frameworks!) If the technological landscape changes and your framework doesn’t keep up, or represents an “outmoded” way of approaching the problem, your basic skills (whether it’s SQL or Javascript or even HTML) might have softened too much to make the switch. Bad frameworks can even restrict you to less efficient solutions. But, on the whole, having fewer problems to deal with and less code to write is a good thing.
Back to James’ original reluctance, though:
[O]ffering built-in systems for automatically doing XMLHttpRequests and other effects would tie Django to a particular JavaScript toolkit, which I think would be an awful idea. Or else it would require us to maintain code in the framework for all of the popular JS toolkits, which would be an even worse idea.
All of that is true (except the “worse idea” is really the first). But that’s the responsibility you take on when you develop a framework. In
this case, if Django is a framework for developing web applications, then regardless of whatever level of Javascript knowledge web developers ought to have, the framework itself will need to provide hooks to make life simpler for everybody. Otherwise, it’s going to fail, because it will become less and less a web development framework, and the companies who use it will more and more get outclassed in user experience because their competitors are the ones spending less time writing and debugging Javascript to provide simple effects.
Better Software. Better Science. Better Sense. 