Infovark Underground » New

Review: Code

Dean — Wed, 10 Mar 2010 01:35:11 +0000

Sometimes it’s nice to go back to your roots. And sometimes, it’s nice to go back to the roots you never had.

As a computer science dropout, I’d never gotten the fundamentals presented to me in a coherent fashion. I’d picked up many of the connections between mathematics, logic, and electrical engineering from reading online, but it’s no substitute for having the progress of computer science laid out in a systematic way. Code: The Hidden Language of Computer Hardware and Software by Charles Petzold is the Computer Science 101 course I’d wish I’d had in college.

Code: The Hidden Language of Computer Hardware and Software

Code is a great trip through the fundamentals of computing. Starting from first principles the author takes you through the basic computer theory to the point where you could create your own computer. It’s a journey that begins with a simple light switch and ends with advent of the Internet.

Morse Code, combinatorial theory, the telegraph, logic circuits — are all parts of the story of the computer. It’s a story told without analogies, but in a straightforward building-block fashion. It describes the insights and intuitive leaps that lie behind the most important tool of our age.

At times, it can seem like computers and high-tech gadgets are magic. What reading a book like Code reminds us is that there’s no wizardry involved, just careful engineering.

A few things I learned

We were close to steampunk era computing. All the insights required to make simple calculators and computers were present in the late 19th century. Most of the equipment had been invented for the telegraph. But it took several decades more before the pieces came together, in a 1938 master’s thesis written by Claude Shannon while at MIT. (Shannon also coined the name used for the basic unit of digital information, the binary digit, or bit.)

The idea of separating code from data — something that every programmer gets beaten into them at the beginning — goes all the way back to the origin of computing. Even though it’s all binary numbers and logic gates at the hardware level, some of those numbers represent instructions and some represent data. Many of today’s higher-level languages are so far removed from the basic circuitry that you can (sometimes) treat them as one and the same.

It turns out the longstanding distinction between positive and negative numbers in most programming languages derives from electrical engineering. The circuitry needed to subtract two numbers can be greatly simplified if you accept a few constraints on the size of the number and apply some tricks for how they’re encoded. I’d assumed that the reason had to do with storage space alone, but it simplifies the electrical circuitry required as well.

I had no idea that assembly language was essentially machine language with human annotations and symbols. I thought that they were fundamentally different, somehow.

And speaking of assembly language, I now have an vague idea of what the disassembly code Visual Studio shows me during debugging means. By the time you’re finished with Code, you’ll have a basic understanding of it as well, and for how tedious it was to program. I’m glad to be working with today’s much more expressive programming languages.

Parting thoughts

Code was a great read, and ought to sit on every professional programmer’s bookshelf. Part Wired, part Make, part junior high science class, it’ll teach you the inner workings of the complicated and ubiquitous devices that run everything these days.

My only criticism of the book was that it wrapped up too quickly. The graphical user interface gets only a chapter, and events since the rise of the Internet barely half of one. I’d like to see another volume (or two!) covering in depth everything that’s happened since the Apple Macintosh.

But that’s really more of a compliment than a criticism.

Review: Framework Design Guidelines

Dean — Mon, 11 May 2009 03:38:11 +0000

Framework Design Guidelines

I’m almost embarrassed to admit that I really enjoyed Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams. I mean, it’s a book about coding standards.

Maybe I ought to get out more… but before I leave the glare of my monitor behind, I’ll type up my review.

Code is literature, not language

Computing languages, just like human languages, have grammar and syntax. There are correct ways to form sentences and paragraphs, with well-defined rules (and exceptions). Just like word processors can check spelling and verify basic sentence structure, most IDEs today can ensure your code will compile and run.

That doesn’t mean that your story or program is an easy or enjoyable read, though. Most newspapers have accumulated extensive guidelines for matters of style and substance, and most software companies have their own guides as well. If you’re writing as part of a team project, or writing programs intended to be used by other programmers, it’s important to make your code consistent, clear, and direct.

Just like many journalists keep a copy of The Associated Press Stylebook or the New York Times Manual of Style and Usage handy — even if they don’t actually work for the New York Times or the AP — lots of programmers keep a copy of Microsoft’s Framework Design Guidelines as reference.

Or they should. That’s probably my roots as a maintenance programmer showing.

Know your genre

Ideally, you’d want any code you write for other Windows programmers’ use to look as if it came from Microsoft itself. That is, you want it to feel like a natural extension of the .NET framework and not some third-party bolt-on with odd stylistic touches. You’d also like your code to use the full power and expressiveness of .NET, and not appear like some watered-down Java-esque port. (Far too many open source projects retain awkward Java-isms after being converted to .NET, in my opinion. NUnit is a notable exception.)

This helps your fellow programmers gain a better understanding of your code in less time. And it can also make your programming tasks easier, too. Just like design patterns can help you lay out your application architecture, programming guidelines can help you structure your code at the class or method level.

About the book

The Framework Design Guidelines covers a lot of ground in its 400 pages. It describes what conventions Microsoft uses when designing types, methods, and exceptions. It also describes the naming and design patterns that Microsoft uses in their public APIs. The topics are grouped by category and heavily cross referenced, making it easy to find your way around. The rationale of each guideline is explained, and the authors indicate the strength of each recommendation by marking it with the terms Do, Consider, Avoid or Do Not.

But the best part of the book is the stories and comments given by members of the Microsoft team. These are sprinkled throughout the book and give insight into why the guideline exists. Some of these discuss lessons Microsoft learned the hard way, places in the .NET Framework where the rules are violated, and how real-world programmers feel about certain guidelines. You can get a flavor of these by checking out the Framework Design Guidelines section of Brad Abrams‘ blog.

If you find his posts interesting or helpful, you’ll feel the same way about the book. Highly recommended.

Review: Working Effectively with Legacy Code

Dean — Fri, 07 Nov 2008 17:29:00 +0000

Working Effectively with Legacy Code

I know what you’re thinking: “Infovark’s been around for barely a year! Surely you guys aren’t having to deal with legacy code already?” If you accept Michael Feather’s expansive definition of legacy code — code without unit tests — then yes, despite our best efforts, we have lots of legacy code.

But even if you don’t buy that definition, and even if you’re working on a completely greenfield application, chances are you’ll have a lot of code in your project that isn’t fully understood. Or perhaps isn’t fully understood by all members of the team. And it’s in dealing with this issue that Working Effectively with Legacy Code really shines.

What happens when you need to change code that isn’t fully understood? Are you making it better or worse? The author says that you can’t know the answer to this question without tests in place. Having documentation is nice, but unit testing provides measurable output.

The brass tacks

Unlike many programming books, this one is organized in a Q&A format. Once past the introduction — which you can skip if you already understand the importance of refactoring and test-driven development — you’ll find the chapters organized by topic. Here’s a sample of a few chapter headings:

It Takes Forever to Make a Change
I Can’t Run This Method in a Test Harness
Dependencies on Libraries are Killing Me
I Don’t Understand the Code Well Enough to Change It
This Class is Too Big and I Don’t Want It to Get Any Bigger

This is a great way to organize a highly technical book. Each chapter has a specific purpose. The author then spends the chapter discussing the ways you can get out of the jam and weighing the pros and cons of each.

You’ll find in-depth examples of each of the techniques used, but be prepared to shift between languages. To get the most out of the book, you’ll need to be comfortable scanning unfamiliar syntax.

As a bonus, the book contains an index of common refactoring patterns. Certain patterns make appearances in more than one chapter, and the index provides another place for the author to work through some real-world examples.

All in all, this is a practical field manual for a set of problems that occur too often out in the wild. I highly recommend it.

Review: The Pragmatic Programmer

Dean — Wed, 05 Nov 2008 15:46:54 +0000

The Pragmatic Programmer: From Journeyman to Master

You’ll find The Pragmatic Programmer: From Journeyman to Master on many software developers’ must-read books lists. After reading it from cover to cover, I’ve added it to my essential reading list as well.

It’s not a book for beginners, though. The subtitle of the book, “From Journeyman to Master” sums it up. The Pragmatic Programmer describes the skills, attributes, and attitudes that a mid-level programmer needs to become a professional developer.

Its purpose is to distill the wisdom gathered from a career in programming into about 70 tips. Each of these tips is explained and illustrated with examples that most programmers will find familiar.

The tips are not necessarily about writing code. The authors, Andrew Hunt and David Thomas, take a holistic approach to the craft of programming. They cover topics like communicating effectively, planning and scheduling, and building teams.

I’d read somewhere that you can judge the quality of a craftsman by the quality of his tools. The Pragmatic Programmer is a book I’d expect to see on any professional developer’s shelf.

Review: Restful Web Services

Dean — Thu, 10 Apr 2008 14:38:46 +0000

As we mentioned recently, we’re building the infovark server using the REST pattern. Since REST is more a loose set of guidelines than a strict series of rules, it’s hard for implementers to know where to begin.

OK, you could go to the source, chapter 5 of Roy Fielding’s dissertation. Or you could check out the somewhat academic discussions on the REST wiki, though there hasn’t been much activity lately. You can occasionally find good advice from the odd blog post, like the REST for the Rest of Us article at Open Garden. But ironically, there’s not a whole lot of material about implementing REST web services available on the web yet. (If you know of good links, leave a comment.)

RESTful Web Services

For the practical, gritty details of how it’s actually done, you’ll need the Restful Web Services book by Sam Ruby and Leonard Richardson. They describe the principles that inform REST-ian (RESTafarian?) design in detail, taking you step-by-step through two different sample applications. If you’re a Ruby programmer using Rails, you’ll find the book especially valuable, since that’s the language and framework in which most of the examples are done. For those of us using different technology, it’s the thought process behind the examples that is most illuminating.

This is because the key challenge of the REST paradigm is the fact that it can’t really be implemented on today’s web without some workarounds. REST will come into its own with HTML 5. The book steers an interesting course between how REST web services might be done in HTML 5 with how they must be done today. I think the authors get the balance right, but at times it can make for a frustrating read for someone wanting practical advice about building a REST service right now.

But that’s less a criticism of the book than of the openness of the REST concept itself. The occasional what-if digression the authors make is a small price to pay for the amount of sound guidance you get. The appendixes alone, which discuss things like which HTTP status codes and headers are worth implementing and which are worth forgetting, will save you far more time than you’ll lose in reading how great things will be when HTML forms finally support the PUT method.

Until that day comes, keep this book handy.