Shipping ordinary software on time is damned hard. Shipping great software in any time frame is extraordinary. Shipping great software on time is the rarest of earthly delights.
– Jim McCarthy, Dynamics of Software Development

I received my copy of Dynamics of Software Development by Jim McCarthy in the mail today, and this quote was just sitting there on the first page.

I’ve shipped great software on time and I’ve shipped ordinary software late. This inconsistency to a logic-driven mind is maddening. I think I’m fairly decent at writing code, but getting the whole process to a point of repeatable success from a business standpoint is what I’m in the dark on.

Though my computer science education was fantastic in teaching me about logic and theory, the nuts and bolts of software engineering is something I am lacking. There was a software engineering course offered but I opted for the programming language design course, instead. I don’t regret that decision–I love programming languages–but  in the world of waiting customers and deadlines that come much too quickly, I’m having to play catch up.

So for now, it’s time to hit the books.

Since SICP runs close to 600 printed pages and approximately 40 HTML files , I’d rather not read it in my browser and printing it on the home printer is not really an option. I decided that using Lulu might be a workable solution.

Lulu takes PDFs so step one was to convert the SICP website to one big PDF.

First, I used wget to mirror the site. Now that I had all the files, I wanted to clean them up a little. Every single page had the previous and next links at the bottom and this was obviously not needed when the pages are in physical form. I ran the following sed command to remove these lines:

sed -i "/\[Go to/d" *html

The next step was to convert the HTML to PDF. I used htmldoc for this particular task.  First, I put all the names of the HTML files in one text file, on one line, and in the correct order. I called this file “all_files.txt”. The htmldoc command I used to convert to PDF is the following:

htmldoc -f sicp.pdf --webpage --left .75in --right .75in `cat all_files.txt`

I then uploaded this file up to Lulu and designed my (very) simple cover. I made it clear on the back  cover text that I was printing this book under the rights granted by the aforementioned license and would receive no profit from this book with a link back to the original source. I’m not a lawyer so I hope that covers all bases.

Lulu has a convenient feature that will let you do a private printing. I could probably make  this book public, setting my profit to zero, and even though that would be covered under the license, it still feels strange to do.

I am very curious how this book will turn out. The Lulu process was actually fun and if this turns out well, I could see myself using the service again. Once I get the book, I’ll post my reviews of the service and possibly some pictures of the final product. Nonetheless, I’m excited to get a print version of this book for a much-reduced price.

Edited to add:
Here’s the download for the PDF: sicp.pdf

For my day job, I’m a PHP and Javascript developer, enjoying the latter more the former, and for personal scripts and side projects, I’ve been a Python guy for years.

I wanted something that was a departure from these more imperative languages which obviously lends itself to the functional languages. At the same time, I wanted something that wasn’t purely academic, but I could build real-world software with it that other people could easily use.

I’ve been fascinated with Lisp and its S-expressions and the idea of code being data and vice versa. At the same time the speedy, static-typed languages like OCaml and Haskell were very intriguing.

After playing with OCaml for a week or two and also working through the first few chapters of Real World Haskell and watching the entertaining Simon Peyton-Jones,  I enjoyed them, but I wasn’t infatuated with them. No magic spark, I guess you could say. I think it comes down to me being more inclined to the dynamically-typed languages which seems to cut down one more barrier between me and the implementation of my code.

So ruling out the OCaml and Haskell brand of typed, functional languages, I found myself working my way back to Lisp. Surveying the Lisp scene, I found myself confronted with quite a few choices of Lisp implementations. I decided to go with Clojure, as from my readings, it seems to be a nice Lisp, even coming from the older Lisp guys and you get the almost endless number of  libraries of Java, as well as  the speedy JVM that runs on all the major platforms. I’m sold.

I’ve played with SBCL going through bits and pieces of Practical Common Lisp and I really enjoy the expressiveness and the speed of going from the idea of what you want to do to actually seeing it run. Stuart Holloway (of nearby Chapel Hill) has written a series of blog posts porting pieces of the PCL code to Clojure which should serve as a nice introductions as well as the screencasts.

I’ll post updates on new discoveries I make, and any software I decide to work on.

I am a web developer by trade, and like any skilled worker, I am always looking for the best tools for the job. With my current job, I write PHP on top of a custom in-house CMS. Off the clock though, I work with Python and Django.

First off, I like the concept of a framework. With web development, 95% of the stuff you do is stuff you’ve done before and unavoidably will do again. A well-written framework alleviates a lot of this. Most of the tasks can be broken down to 2 steps: 1) Grab objects from database. 2) Show them. The visual design of a website is always the fun part to do after you get all the heavy lifting done. There are also things like form handling, user authentication, writing XML feeds, and caching that gets done over and over that frameworks are nice enough to say, “hey, I’ll take care of this boring, repetitive stuff and let you get on with creating something cool.”

As far as specific frameworks go, I’ve read quite a bit about Ruby on Rails and wrote some simple apps to test it out. One reason I didn’t grasp on to this one was that I didn’t know Ruby. Another reason is that deploying it seemed tricky and you trade speed of deployment for runtime speed. This is true for any interpreted language, but Ruby on Rails takes it to the extreme in both directions. Also it seems too opinionated at times stepping in the way of what I really wanted to do.

Another one I’ve gave more than a passing glance to is CakePHP. While there are several good ideas in there, and it does increase coding efficiency, it has one big, glaring black mark against and that is it is writting in PHP. PHP is a good language in the regards that it fairly powerful, runs everywhere, runs relatively fast, and everyone knows it, but it is an unattractive and inconsistent language. This link sums it up quite nicely.

Now onto my favorite: Django. When I first stumbled on this one earlier this year, I amazed by the simplicity of the framework and how it just made sense, from organizational and logical standpoints. There is a very strict model/view/controller demarcation (except Django calls the controller a view, and the view a template) which leaves little debate of what piece of code goes where, which in my opinion is a great thing. It also has lots of super handy things that are built in or are easily added, such as an auto-admin interface, unit and regression testing, modular apps, an easy-to-use templating language, great form handling, and user authentication.

Far and away my favorite features are the generic views. In my opinion, most of web development is grab an item or a list of items from the database and show them on a page, possibly paginating if there are a lot of them or maybe dividing them up by their publication dates. With generic views, Django takes almost all of this repetitiveness and abstracts it out so you can get on with making it look pretty or adding some cool new feature. Django brings back a lot of the joy of web development that sometimes gets lost in the grind or when writing that same hunk of logic for the hundredth time.

Not to be one to follow hype, I didn’t fully buy into Django until I built a full site with it. Meghan and I built a soon to be launched site for our upcoming wedding. We built it from the ground up (with Django, of course) in the span of about 3 hours. This time included everything from registering the domain to designing the site. It even has a working blog with a commenting system, and a full-featured admin tailored to my exact needs. Django made the easy things really easy and the hard or repetitive things actually fun to work with.