July 2007 - Posts
If you are involved in software development, you are probably responsible for creating and presenting documents and web pages on a regular basis. If you only ever get enthusiastic reviews on the layout and design of the documents you present, you don't need to read any further; you should probably write your own book about design. However, if like me, you happen to get the occasional odd stare or constructive criticism about how your work looks, then you should be interested in this book spotlight.
The subject of this spotlight is Robin Williams', The Non-Designers Design Book, subtitled "Design and Typographic Principles for the Visual Novice". This book is not geared towards the Internet or even really electronic documents in particular, but instead to the basics of arranging and coordinating text on a page.
In the first part of the book, Williams lays out 4 principles of page layout: Contrast, Repetition, Alignment and Proximity. When Williams heartily acknowledges that she has just presented the CRAP principles, she sets an informal and warm tone that is a pleasant surprise for a book boasting a 50 page section on type. With helpful exercises and effective visual examples, Williams ends up making the 4 principles seem obvious.
In the second part of the book, Williams focuses on type, or as I might call them, fonts. My biggest takeaway from this section was her insistence on a designer being bold ("don't be a wimp") in her use of fonts. She recommends and illustrates with examples how it looks better to combine typefaces that are very different, not very similar, on the same page.
"The Non-Designers Design Book" is not a book you can absorb with just one read. However, after the first read you will be able to look at your own work and point out some specific reasons why that document looks right and that one doesn't. So if you've ever been frustrated when your presentation ends up obscuring your content, then I highly recommend picking up a copy of Robin Williams' book.
Due to some scheduling issues, I was only able to attend one session of the recent San Diego code camp. The one session that I went to was about the Dynamic Language Runtime (DLR). The DLR is a new piece of the .NET landscape that makes it easier for dynamic languages, such as Python, JavaScript and Ruby to access the .NET framework libraries and easier to call scripts in dynamic languages from C# or VB code.
According to the presenter, Steve Saxon, Microsoft got much of the initial inspiration for the DLR from the custom work they did implementing Iron Python, the .NET version of Python. By generalizing this code, Microsoft was able to create the framework that is the DLR and in fact the latest version of Iron Python was implemented using the DLR.
So what makes up the DLR? Steve went into some of the details and I took away the following two interesting points about its implementation:
- For code to run on the CLR, it needs to be converted to MSIL. To get dynamic code converted to MSIL, the individual language implementation needs to be able to convert the dynamic code into an Abstract Syntax Tree (AST). I don't know too much about specifics of AST's, but it is basically a tree structure that represents your program's execution flow. The DLR takes Abstract Syntax Trees and parses them into MSIL. So, if you have a language you want to run on the CLR and you can write a parser to convert it into an AST, the DLR will do the rest for you.
- When objects come from a dynamic language, they get wrapped in a CLR wrapper for access from the regular .NET languages. In effect, this wrapper ends up being a glorified function pointer table or hash. In order to deal with the possibility of methods and properties being added at runtime, the statically typed CLR uses a hash structure containing names and pointers to the named method. Calls to a hash are not evaluated until runtime, so you can in effect do an end run around the compiler's type checking.
All in all, the presentation was quite interesting, but perhaps more interesting than the DLR itself is what it enables. You may benefit from the DLR when writing JavaScript in Silverlight for example, without ever having to know how it works. If however, you are curious for more, check out Jim Hugunin's blog Thinking Dynamic for lots of posts about the DLR and Iron Python.
If there is such a thing as a legendary programming book, then the canonical example would be Kernighan and Ritchie's, The C Programming Language. I leaned on it heavily in college while learning C and I have yet to meet anyone who has done much C programming and does not swear by it. Which is perhaps just an indication that I need to meet more people, but rather than face that idea, I thought I'd try to determine what made this book a legend.
C Itself
If you've programmed in C and in almost any other language, you know that C is hard. C gives you amazing control over your program, with few boundaries over what you can and cannot do. C is deliberately not as abstracted as C#. Fewer boundaries and abstractions means that you can write unworkable code very easily in C. So a tutorial style book explaining some of the mystery is bound to be popular.
C is also everywhere. It could be changing now, but it has long been a staple of college programming courses, providing a continuously refreshing set of programming newbies looking for answers. Finally, C is compact. It is possible to cover a lot of it in a 274 page book; for C# and .NET, that might get you a good index.
1988
The 2nd edition of this book came out in 1988, so long (in computer time) before the massive collective programmers' brain dump that is the web. In other words, when this book was in its heyday, you couldn't just Google for an answer to your coding woes. Oftentimes K&R was the only and best reference around.
Brevity and Style
As I mentioned before K&R is less than 300 pages long, so you didn't need to buy a seat for it on the plane ride. In this case brevity was coupled with great content and good writing. I wouldn't call K&R a page turner, but for a programming text, it was pretty good. How many 800+ page programming tomes have you seen on your desk or someone else's and wondered why the back 400 or so pages looked so crisp?
Short and well written, focused on a topic prone to tutorials and lacking the competition of the web, K&R was able to vault to a position of prominence. So, if you want to write a legendary computer book, find a language that's tough and without much online reference material and of course, write well and concisely.* Pretty simple, right?
* An example of this approach is Programming Ruby. Before Ruby got so popular with Ruby on Rails, Programming Ruby capitalized on some good writing, lack of English language documentation and a quirky language to become a legend of Ruby programming. Maybe Programming Erlang is next?
I took advantage of one of the Dell deals recently to get myself a second desktop computer. After my experiences with various forms of Ubuntu and Linux through virtual machines I felt confident and ready to install Linux for myself on a real physical machine. Pride goes before the fall and after running through installs of Xubuntu, Kubuntu, Ubuntu and PC-BSD, I ended up back where I started: using Vista and virtual machines for anything I want to do in Linux.
Without getting into all the details, I made the following observations on my tour of popular desktop Linux variants.
64 bit versions are more trouble than they are worth:
Excited about my new AMD X2 processor, I initially went with Xubuntu 64 bit version. The install was easy and the OS itself ran great. However, the rest of the application landscape is not really ready for 64 bit. This is not a knock on Linux itself, since the same problems exist in the Windows world, but it was a hassle to discover that there were either not 64 bit versions of applications or the 64 bit versions were crippled in some way, such as Firefox 64 bit, which lacked almost any media plug in support.
Sometimes you can get too much help:
Between Synaptic, Add/Remove, Automatix and EasyUbuntu, and plain old apt-get, I found myself overloaded with options on how to install and remove applications from Ubuntu. Most of these did not play nice with each other and did not realize if you had installed an application using another manager, or if they did, would refuse to do anything with it. I ended up really missing the relative simplicity of the MSI style guided install on Windows. In fairness to PC-BSD, this did not seem to be a problem because it features the PBI format, a kind of Linux MSI.
Configuring fonts is no fun:
I'll freely admit to a strong, perhaps irrational bias towards Windows in one respect, I like the way that IE and Firefox render web pages, particularly how they display fonts. So, it really throws me off when I start up Firefox on Linux and pages just don't look right, even after installing the Windows fonts. At one point I was able to download a set of configuration files that helped, but they also changed all the system menus. I will claim ignorance here on how difficult this must be, but I really have no desire to learn the nuances of Linux font management just to get ESPN.com to look right. Again, PC-BSD (at least the VM) was configured much better out of the box in this respect.
I'm OK with a binary driver:
My new Dell has an Nvidia chip for its onboard video. The Ubuntu variants had an open source driver for it, but I could not get up to higher resolutions until I installed the binary/closed source driver from Nvidia. This was easy to do on Ubuntu, although I did have to go through a somewhat menacing "Restricted Drivers" dialog that warned me that I was installing something that was hard to support and could be broken by future changes. I know for some people it is very important that everything on their machine be totally "open"*, but for me, I'm not going to get myself stuck at low resolution so I can stick it to Nvidia.
Kubuntu is kluttered:
The worst part about my new Dell so far was removing all the crap ware that came with it. From AOL installs, to a trial edition of Norton, I can't be happy until my system is nice and clean of extras that I didn't ask for. Xubuntu and Ubuntu came with a pretty light load of pre-installed applications, whereas Kubuntu comes with an relative explosion of them, all somewhat irritatingly starting with "k". Hopefully this is appreciated by novice users because I just wanted to get rid of everything and build up from a clean slate. Also Kubuntu's many level of control panels allowed me to tweak almost anything, but made Windows' control panel structure seem clean by comparison.
Back to where I started.
Although PC-BSD uses KDE, which I just criticized for being a little cluttered, I was excited to install it after a good experience with the VM. Unfortunately, I was stymied by lack of support for my SATA II controller and Nvidia graphics problems. I tried 2 different versions of install CDs and a Live CD with no luck. For now, I will just use the VM.
So, I end up back where I started; Vista or XP for most things, with Linux VM's around if I need them. I gained some good experience along the way and discovered a great little utility EasyBCD, which allows you to easily configure (and restore!) the Vista boot loader, which is very useful when messing with Linux installs. I'm not sure if all the time and effort was really worth it, but it certainly cured me of my desire to OS chase, at least for a few months :)
* See Mark Pilgrim's blog, Dive Into Mark, and Gobuntu