The Third Bit

This, via Joey de Villa (whose blog is always full of interesting bits and pieces), is a good brief guide to improving your startup’s odds.

Uncategorized

Jon Erickson, the editor-in-chief of Doctor Dobb’s Journal, asked me to write a couple of paragraphs about a typical developer’s typical day. As usual, I went a little overboard; unusually, I veered toward the bright side.

It’s 9:30. You’ve caught up on email from the contractors in India, skimmed a dozen blog postings, and finished your first cup of coffee: time to get to work. Open Eclipse, and check your working copy against the repository. Hm… Maria and Sukhmeet have checked in changes to the charting module. Two clicks takes you to the web page that shows the results of the overnight build and smoke tests. Total coverage has dropped slightly, but the new functionality is being tested, so you update and recompile.

Next, you flip over to the bug tracking web page, and re-read the description that Bin in QA filed against the password strength checker. “Doesn’t recognize digits immediately following non-Latin characters.” OK, that’s probably a character encoding problem. You write a unit test, copy and paste the Chinese character passwords Bin used to find the problem, set a couple of breakpoints, and dive in.

By 11:00, you know that the problem is something to do with the LDAP server not reporting encodings correctly. You have to put it aside for a while, though, because there’s a 1:00 meeting to review the schedule estimates for the new biometrics module, and you want to get forty minutes on the exercise bike downstairs before then. You print the requirements doc, get a fresh cup of coffee, and settle in with your favorite red pen.

3:00. The meeting ran well over time, but the pizza was good, and several important decisions were made. The minutes won’t be up on the project web site for checking until the end of the day, so you have at least a couple of hours to track down that encoding issue. You’re interrupted twice: once by the intern with a question about environment variables in Ant, and one by a phone call from a field engineer in Calgary, whom you redirect to second-line support. Despite that, you’re able to figure out that the admin UI isn’t setting the domain object properties correctly. A one-line change, two new unit tests, and a three-line check-in comment later, it’s 4:30, and you have half an hour in which to catch up with Joel Spolsky, Jon Udell, and the fine folks at Artima before catching the train home.

Writing

This guide to Google services contains a lot of stuff I’d never heard of (and would never thought of myself). I wonder how many I can have students use in course assignments?

Uncategorized

Yet another 3D visualization of the web, this one inspired by the Sims.

See this post for a walkthrough. No idea how useful it is, but it’s real purty.

Uncategorized

I’m going to start this review with a disclaimer and an apology. The disclaimer is that the publisher of these two books also published my most recent one; the apology is that when Dave Thomas told me what Chad Fowler’s book was going to be called, my reaction was far more negative than it had any right to be.

Despite its title, My Job Went to India (And All I Got Was This Lousy Book) isn’t really about the perils of offshoring. It’s about what programmers can do to keep themselves employable in a rapidly changing world. Having worked for a consulting firm in India, Fowler knows that being able to code isn’t enough any more. If you want to be cost-effective, you have to be able to elicit requirements from customers and do high-level design. You have to be one jump ahead of the technology curve, keep your network of contacts fresh, and know enough about economics to understand the difference between “possible” and “profitable”. It’s all good advice, and Fowler presents it clearly and coherently.

So why was I initially so negative? Because the choice of title reminded me of a pamphlet I came across in a public library years ago. Written in the late 1950s, it was titled, “Will Your Daughter Marry a Negro?” Inside, it was actually a very liberal look at what desegregation would mean. If the front cover had reflected that, instead of trying to capitalize on the inflammatory rhetoric of the day, I would have felt very differently about it. Listening to the ever-louder chorus of protectionism in our industry (which used to take pride in creating a world without borders), I can’t help but wish that Fowler, or his publisher, had chosen something like “All You Really Own Is Your Career”. Despite that, this is a good book, and well worth reading.

A disclaimer, an apology, and a grudging admission that I might have backed the wrong horse… For those of you who haven’t been paying attention, Ruby on Rails is a lightweight framework for building three-tier MVC web applications. It combines an HTML templating framework with an object/relational mapping layer, and (crucially) a set of conventions about what things are called, and where things are stored. The end result is that you can create, test, and deploy fairly sophisticated web applications with just a few lines of code.

No, really, this time I mean it—Rails really does let you focus on what’s specific to your application, and leave all of the routine stuff to the framework. Elegant design is part of the reason; its reliance on a nimble scripting language instead of Java or C# is another.

“Elegance” and “nimbleness” are equally appropriate as descriptions of this book. It starts with a step-by-step tutorial that builds up a simple shopping site, then explains the things that make up Rails in depth. As with everything Thomas writes, the prose is transparent, the examples perfectly chosen, and the pacing exactly right. Other books on Rails are already on the market, but I doubt any will be able to match this one.

What? Oh yes, the grudging admission. As regular readers know, I’m a big fan of Python: having taught many languages to many people over many years, I think it strikes a better balance between readability and power than anything else invented to date. However, the Python community has a regretabble history of missing boats. Right now, for example, several Python-based frameworks are trying to be its answer to Rails. I don’t know enough about them to argue their relative strengths and weaknesses; what I know for sure is that the fact that there are many, instead of one, makes Python less credible as a “bet your business on it” language. Two years ago, I was confident that as Perl crumbled under the weight of its own complexity, Python would pick up the refugees. Now? Thanks to tools like Rails, and books like Thomas and Hansson’s, it looks like the future might well be shiny and red.

---

Chad Fowler: My Job Went to India (And All I Got Was This Lousy Book). Pragmatic Bookshelf, 2005, 0976694018, 232 pages.

Dave Thomas, David Heinemeier Hansson, and others: Agile Web Development with Rails. Pragmatic Bookshelf, 2005, 097669400X, 450 pages.

Books

I don’t know much about graphic design. In fact, I know almost nothing, and what little I know is probably wrong. I do, however, know about how to use modularity and abstraction to make software more robust and more maintainable. This is why Cederholm’s book, Bulletproof Web Design, appealed to me so directly. In it, Cederholm talks about how to implement web pages that will behave gracefully under pressure. One of the simplest examples is that you shouldn’t specify font sizes absolutely. Instead, use CSS to specify the factors by which your titles are larger than your main text, so that if someone with a visual disability wants things enlarged, everything will enlarge by the same amount.

Cederholm applies the same ideas to things like navigation tabs, flexible layouts that will survive browser resizing, and so on. In each case, he explains what the wrong thing to do is, why it’s wrong, and how to fix it. The full-color illustrations clarify the examples and bring them to life, making this an easy read (even for a presentationally-challenged geek like me).

Whittaker and Thompson’s How to Break Software Security is equally good, though its subject matter is very different. Like Whittaker’s earlier How to Break Software, it catalogs some of the nasty things that QA can do to programs to see if they’re ready to inflict on an unsuspecting world. This book, however, concentrates on security attacks, such as overflowing input buffers, trying counterintuitive paths through the workflow to see if any settings are inadvertenly left enabled, and using system monitoring tools to watch libraries load (so that you can try to replace them with your own).

The best part of this book for me was the first case study, which applied each attack to Windows Media Player. The other case studies weren’t as deep or as satisfying, but that’s a minor quibble: this book is full of useful ideas that most of us will be able to apply right away.

---

Dan Cederholm: Bulletproof Web Design. New Riders, 2005, 0321346939, 280 pages.

James A. Whittaker and Herbert H. Thompson: How to Break Software Security. Addison Wesley, 2004, 0321194330, 208 pages.

Books

A community is more than just a bunch of people. It’s a shared set of values, and rules for how to behave. By this standard, the open source community isn’t just what some programmers choose to do with their time, and why; it’s also how they do it.

Karl Fogel’s new book, Producing Open Source Software, is an excellent guide to that “how”. Every page offers practical advice; every point is made clearly and concisely, and clearly draws upon the author’s extensive personal experience. Want to know how to earn commit privileges on a project? It’s here. Do you and other project members have irreconcilable differences? Fogel explains when and how to fork, and what the pros and cons are. Want to get your project more attention? Want to take something closed, and open it up? It’s all here, and much more.

There aren’t many people who write as well as Brian Kernighan, and there haven’t been many books that can measure up to classics like Software Tools and The Unix Programming Environment. This “operator’s manual for open source projects” meets those exacting standards, and makes it look easy. It deserves five stars, and ought to be read by everyone who takes software development (open or not) seriously.

---

Karl Fogel: Producing Open Source Software. O’Reilly, 2005, 0596007590.

Books

The perfect gift for people who worry too much…

Uncategorized

Joel Spolsky has posted the reading list for his Software Management Training Program. Only four of the books are in the geek books portion of my reading list (which, BTW, will soon include Doar’s Practical Development Enviornments and Fogel’s Producing Open Source Software). One of the reasons my score is so low is that most of Spolsky’s list is business books, or computer company war stories — Accidental Empires is there, but surprisingly, neither West of Eden or The Plot to Get Bill Gates made it. And what is In Search of Stupidity doing on anyone’s “best of” list?

Uncategorized

The first four Doctor Dobb’s Journal articles about Google’s Summer of Code projects are now on the web:

• Apache Axis2 JMX Front
• CL-GODB: A Common Lisp GO Database Manipulation Library
• Wide Character Support in NetBSD Curses Library
• gjournal: FreeBSD GEOM Journaling Layer

There are more queued up behind them, so stay tuned.

Coincidentally, my latest book reviews have also gone up:

• 37signals, Matthew Linderman, and Jason Fried: Defensive Design for the Web (New Riders, 2004, 073571410X).
• Bryan Basham, Kathy Sierra, and Bert Bates: Head First Servlets & JSP (O’Reilly & Associates, 2004, 0596005407 ).
• Stuart Langridge: DHTML Utopia: Modern Web Design Using JavaScript & DOM (SitePoint, 2005, 0957921896).
• Ian Langworth and chromatic: Perl Testing: A Developer’s Notebook (O’Reilly, 2005, 0596100922).
• Jared Richardson and William Gwaltney Jr.: Ship It! A Practical Guide to Successful Software Projects (The Pragmatic Bookshelf, 2005, 0974514047).
• Barry J. Rosenberg: Spring Into Technical Writing for Engineers and Scientists (Addison-Wesley, 2005, 0131498630).

Sunny and 69 degrees in San Francisco…

Writing