Programmer Musings

"Shortcomings" of the Web

I was reading The JavaScript Phrasebook on Safari and ran across one of my favorite pet peeves when people write about Web technologies.

Cookies are not a specific browser technology, but a mechanism in the client/server model to overcome one major shortcoming in the HTTP protocol. HTTP is stateless, which means that the protocol does not have a memory.

There are many people writing about web-based technologies that really appear not to understand the design of the web. Statelessness is not a shortcoming, it is a feature. Contrary to what these people apparently think, the designers of HTTP did not forget to include state in the protocol. Most client/server protocols before that point either kept state as part of the protocol or relied on a persistent connection for the session (which is just state at the TCP level). The default approach for HTTP would have been to do the same. The designers of HTTP explicitly chose not to keep state in the protocol.

One of the reasons that the web exploded was the fact that the HTTP protocol is stateless. The average web server does not need to retain connection information on every browser request that it receives. This made developing early web applications and specialized servers much easier. No need for storage to track browser sessions. No need to keep open connections or determine when to expire old sessions. No need for complexity that has nothing to do with serving individual pages to a browser.

Part of the genius of the minimal approach taken by HTTP is the fact that stateful applications can be built on top of it through mechanisms like cookies. (There were more approaches at the beginning. Cookies eventually won out.) The great thing is that systems that don't need stateful connections don't pay for them in complexity and bandwidth. For systems that need the extra state, the complexity and extra bandwidth is part of doing business.

HTTP is a relatively minimal protocol with mime-headers as an extension mechanism. This design decision has proven itself as being an extremely robust and stable protocol. The original version was implement sometime around 1990. RFC1945 described version 1.0 in 1996. Since that time, we have had one new version 1.1. This protocol has been stable for almost 20 years and underlies every request over the web.

Despite the success of this design, some people still find the need to point out shortcomings in a design they don't understand.

Because of all of this I remain amused when someone, who obviously doesn't understand the concept of a minimal design, refers to that design as falling short.

Review of The Productive Programmer

The Productive Programmer
Neal Ford
O'Reilly, 2008

When I found out about this book, I knew I had to read it. I have been a programmer for a long time and I'm always on the lookout for tips about how to become more productive. I expected a list of tricks that would make individual development tasks easier. This book does have some of those, although not as many as I expected.

The book is divided into two major parts. The first section, Mechanics, contains a number of useful tricks and tips organized in four major categories: Acceleration, Focus, Automation, and Canonicality. This organization is the first useful feature of the book.

Instead of just listing random tips, Ford spends a bit of time on what makes us productive and groups his tips accordingly. This approach not only gives specific tips, but also gives you a framework into which you can put your own tips. By reviewing the tips in a particular section and thinking about the tasks you do every day, you open up the possibility of spotting ways to make yourself more productive.

Although the book has a strong developer focus, many of the tips would be useful for any computer user that wants to be more productive. Much of Ford's advice flies in the face of the GUI/user friendly path taken by modern operating systems and programs. He makes a strong argument that a command line is more effective in the hands of someone who has learned to make use of it.

The second section, Practice, looks at higher-level practices that can make you more productive. In this section, Ford touches on Agile practices (TDD and YAGNI), good design, philosophy, meta-programming, and tools, among other things. In each case, he focuses on each practice in terms of productivity rather than methodology or dogma. This section will not teach you how to develop in an Agile fashion, but it does show how some practices make you more productive.

This section suggests some answers to the high-level questions we all struggle with:

* How do you make certain the code you write is the best it can be and solves the problem you need to solve?
* How do you avoid writing code that does not need to be written?
* How do you get the most out of your tools.

Many programmers will be familiar with many of the tips or, at least, the ideas behind them. Unless you have decades of experience on multiple kinds of systems, you will probably still find a few new items. At the very least, it may remind you of tricks you had forgotten.

I would definitely recommend this book to any programmer or computer power user. If you've only worked on Windows or always develop with a powerful IDE, prepare to have your beliefs challenged. If you have experience with the command line, this book still provides a lot of benefits in tools to improve the more GUI-based OSes, if you need to work there.