DRM - Daniel’s Random Mutterings

Jacob Kaplan-Moss posted to his blog yesterday that the Django book (Pro Django. Web Development Done Right) is completed and is now going off to the printers. He writes: “It should start shipping to bookstores around the second week of December.”
This is great news! It’s great news for the Django platform — it’s a true sign of the maturity of the platform that Apress is publishing a book about it. It’s a strange effect, but in some way having one or more (good) books available gives a technology a certain degree of “manager-cred”, which could make more widespread adoption of Django in “enterprisey” settings easier. Also great news for novices to Django (especially if, like me, they prefer having an actual book which you can read in bed at night, etc.).
As a side note, I must admit that I had become so fed up with the regular “shipping delay” emails I got from Amazon about my preorder of the book (originally scheduled for March) that I canceled my preorder a couple of weeks ago. Once the book is actually available, though, I’ll be sure to order it. I really couldn’t have built the trogger.de platform in the short time it took my without the great framework that Django is and without the good documentation that was on the project’s Web site already.
I’m also pleased for Adrian and Jacob, as the initiators (instigators?) of the Django framework and project, as it appears they managed to get their book out of the door before other authors’ books on Django come out.
So, congratulations to Adrian and Jacob on finally completing the book. It’ll definitely be on my Christmas wish list and I’m looking forward to reading it.

I recently read through (most of) “Founders At Work” by Jessica Livingston. The book’s idea and premise is as simple as it is brilliant: Interview the founders of well-known startups, print the interviews, and - hopefully - give the reader some insight into the workings of an IT startup.

What I didn’t like

Let’s start with one small detail I didn’t like, and get that out of the way as quickly as possible.

For my liking (especially as a non-US reader), the book’s interviews could have done with a bit more editing. They feel as though they’ve been printed more or less directly from the transcript. And people simply don’t always speak in ways that are suitable for print. In general, the tone of the book is fine and it’s quite enjoyable to follow the interviews. The first time, though, that I read

“… and I was like ‘Yeah. Let’s do that’. And he was all like positive.”

(quote from memory), that just made me want to throw up - into the book - then close the bloody thing and put it away. I’m sorry; I know I’m probably being overly critical. Reading language like that just hurts my eyes.

What I liked about the book

This book gives all the aspiring startup founders a feel that the other guys, who succeeded in something you’re just starting out on, are just human, make some of the same mistakes and bad choices, have some of the same bad experiences but were able to pull it off and make it work. There isn’t a single interview in this book where you think the person just succeeded due to some large piece of sheer dumb luck.

Book Review: The Adsense Code - Joel Comm

I’ve just finished reading ” The AdSense Code“, by Joel Comm. Subtitle: “What Google never told you about making money with AdSense”. Was it worth it? Well… I’ve got mixed feelings about this book.

Joel’s goal is to explain how to make the most money out of Google AdSense advertising. He does this mostly by explaining how to “tweak” your ads so that they blend in with the page contents, how to position the ads on the page for optimal results and how to perform some search engine optimisazion (SEO) to make sure your site appears relevant to Google and attracts visitors. For Joel, visitors == people to click on ads.

(more…)

There - that got your attention, didn’t it?

Anyway, I finally managed to finish Paul Graham’s “Hackers and Painters“. After really enjoying the first two or three chapters (see my previous post), I found finishing this book quite a chore and on the whole found it quite a let-down. At the end, I’m not sure what I’ve learned. Except that Paul enjoys LISP. That’s what I found the most painful and booooooringgggg: Advanced LISP fanboy-hood (is that a word? If not, I’ve got copyright).

What totally threw me off was the repeated “Milchmädchenrechnung” (see here for explanation) of developer productivity and the huge gains possible by using LISP. Paul’s argument — condensed in order to make a point — is as follows: Due to syntactic brevity, the average LISP program is five to ten times as short as a Java program solving a similar problem. Hence, LISP programmers are five to ten times times as productive, giving any start-up using LISP an enormous competitive advantage over those using Java. He actually writes: ‘So the more powerful the language, the shorter the program. […] Code size is important, because the time it takes to write a program depends mostly on its length. If your program would be three times as long in another language, it will take three times as long to write […] If [your competitors developing in LISP] spent just three months developing something new, it would be five years before you had it too.’ (p. 192f)

I’m currently reading Paul Graham’s “Hackers & Painters” and I’m enjoying it a lot. What he has to say about hacking, and being a hacker, is like he’s “strumming my pain with his fingers; telling my life with his words.”

In the second chapter I already discovered a quote I agree wholeheartedly with, and which gave me a warm feeling reading it: “Programs should be written for people to read, and only incidentally for machines to execute.” (Harold and Sussmann, 1985). I can still vividly recall my horror when, in a conversation about a particularly hideous and convoluted piece of code he had thrown together, a colleague seriously told me “But of course performance is more important than comprehensibility!” — and he obviously really believed that. No, it is not! Never, ever, under any circumstances, is performance more important than comprehensibility (corollary: This applies to code that is to be used more than once or that is to be developed by more than one person — and this pretty much covers all of the coding we do every day.) If they ever make a Simpson’s episode about coding, Bart should be writing the above quote on the blackboard in the opening sequence.

Introduction

I recently attended a CSM (Certified Scrum Master) training course and was (still am) pretty convinced that Scrum is a very good approach to running your software development projects — making sure you meet (or exceed) your customer’s expectations, reacting to changing requirements, while at the same time allowing the development team to maintain focus and control. While preparing for this course, I read the two canonical Scrum texts: Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, and Agile Project Management with Scrum, by Ken Schwaber.

What is Scrum?

Scrum (not SCRUM — it’s not an acronym) is an agile development methodology. You might say that Scrum is XP’s (not so) ugly step-sister. Where XP focuses more on the actual programming side of things (pair programming, test-driven development, etc.), Scrum provides a light-weight methodology and framework for keeping your project on track.

By following an iterative, strictly time-boxed, project schedule a development team delivers project functionality (business value for the customer), making sure that the project owner is always aware of what the project is doing and where it’s going. A Scrum project delivers software in increasingly complete releases. Each iteration of the process (a ‘Sprint’, in Scrum lingo) must finish with a potentially shippable unit of increment. This unit of increment is presented to the customer (or a representative of the customer) in a Sprint review meeting, which serves as the basis for planning the next iteration. The importance of team communication is emphasized by the introduction of daily (!) meetings — the Daily Scrum. In the Daily Scrum, the entire team brings itself up-to-date. Each team member briefly presents his progress as well as any issues preventing him from achieving his goal.