4 ms·

Have You Met Your Dog, Patches?

18 points by bdfh42 17y ago

RyanMcGreal 17y ago
Cf. Jeff's partner: http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- Davertron 17y ago
  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...
  - RyanMcGreal 17y ago
    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.
    - Davertron 17y ago
      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.
wwalker3 17y ago
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.
ajb 17y ago
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.
- deleted 17y ago
  [deleted]
jcl 17y ago
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.
- DannoHung 17y ago
  Jeff Atwood's blog would be improved immensely if it was just pictures of dogs.
blasdel 17y ago
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.
- icey 17y ago
  What web server do you use?
  - blasdel 17y ago
    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).
    - icey 17y ago
      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.
      - blasdel 17y ago
        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.).

18 points by bdfh42 17y ago

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

Davertron 17y ago
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...
- RyanMcGreal 17y ago
  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.
  - Davertron 17y ago
    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.

wwalker3 17y ago

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.

ajb 17y ago

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.

deleted 17y ago
[deleted]

jcl 17y ago

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.

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

blasdel 17y ago

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.

icey 17y ago
What web server do you use?
- blasdel 17y ago
  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).
  - icey 17y ago
    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.
    - blasdel 17y ago
      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.).