Have You Met Your Dog, Patches? | Hacker News Reader

Have You Met Your Dog, Patches?

codinghorror.com

18 pointsbdfh4213 comments

Summary: Jeff read the Gamasutra article about bad coding practices. He then notes that "Apache" is a play on "a patchy", and that he recently refactored some StackOverflow code that had been patched in the past (code not provided).

Also, there is a picture of a dog.

Jeff Atwood's blog would be improved immensely if it was just pictures of dogs.

Back in the eighties, my mother had a job as a programmer on a maintenance contract. 'In order to reduce risk', the contract specified that bug fixes should change the minimum number of lines of code. Really.

I remember her bringing home a listing (remember listings?) and trying to figure out how to change some loop. It had already been 'fixed' a number of times using this methodology, so it was a mess of nested if statements. I suggested that it needed rewriting. (Although this was the right answer, I didn't actually have the programming experience to know this at the time). Unfortunately, she thought that was too large a change to be acceptable to the client.

Patches grow on our code because it's easier to patch than it is to figure out the paradigm-changing code simplification that will encompass all previous functionality plus the new thing we want to add. That's hard work!

I'm elbow-deep in patch remediation right now, and even though I'm not worried about breaking anything (I have good code coverage and a big automated test suite), it's still mentally draining to do it right.

Cf. Jeff's partner: http://www.joelonsoftware.com/articles/fog0000000069.html

That article is about not throwing away your whole codebase; in fact, he even talks about doing exactly what Jeff Atwood mentions:

These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code.

Joel, I'm sure, is not advocating never re-writing anything at all, and if you think that, sheesh, I'd hate to see the code you work on...

I was offering Joel's essay as context, not contradiction. I just thought it was worth comparing the two arguments, given that the authors work together on stackoverflow.

Still, even in your comment, you're suggesting that there are two arguments. I guess what I'm saying is that there aren't any arguments here at all.

His blathering might hold up a bit more if Apache wasn't such a kitchen-sink heap of shit that would have been end-of-lifed a long time ago if the ASF hadn't lost itself in SOAP, WS-*, and Java for a goddamn decade.

What web server do you use?

Whatever's most appropriate for the job! For dynamic content I use the HTTP abstraction native to the language I'm using (WSGI, Rack, Servlets, etc.), and a single-purpose HTTP server that supports it: twisted.web, cherrypy.wsgiserver, GAE, mongrel, etc. For production, separate HTTP servers (possibly in multiple layers) reverse-proxy the app servers: handling client interaction, caching, routing, dispatch, etc.

Apache's design is completely degenerate: you're encouraged to do all of these logically independent things in one process, even the app execution!

Years ago I used lighttpd and even hacked it's webdav implementation for using on localhost as an alternative to FUSE on OS X. I eventually realized that they made all the same design mistakes as Apache, they just had the courtesy to use epoll (the Apache MPMs are a cruel joke).

Would you consider Apache appropriate for the job for someone who doesn't want to have to try six different solutions to serve their webpages?

I hear what you're saying about it being monolithic, but I do think it has its place.

You generally don't need the reverse proxies in front until you're doing something sizable (or that fits into something of size). I haven't done a project that needed them in a while! You can just use a single app server capable of processing multiple requests -- twisted.web is a solid event-driven one.

If you just need to serve static pages nginx is perfect by itself. If you really need a monolithic swiss-army-knife, lighttpd is at least a pretty good implementation of a mediocre idea.

I really dislike a lot of things about Rails, but I will be eternally grateful for the way their community accidentally demonstrated to the world that the ASF's crap was not the alpha and the omega of webserving. At the time the only options that people thought viable were httpd and overarchitected babel towers (lots of Java crap, WS-*, Zope, etc.).

Reply on news.ycombinator.com