Magic Incantations for Installing asdf-install in Clozure Common Lisp

I'm on my way to bed, but I wanted to document this first.

1. Follow the instructions here: http://common-lisp.net/project/asdf-install/tutorial/setup.html
2. Skip the command "(asdf:operate 'asdf:compile-op :asdf-install)". It didn't run for me, but everything seems to work fine without it.

In my case, that means adding the following to my openmcl-init:

(require 'asdf)
(pushnew "/Users/matt/lib/asdf/" asdf:*central-registry* :test #'equal)
(asdf:operate 'asdf:load-op :asdf-install)

None of the other results in Google had it quite right, and they sent me on an hour long wild goose chase.

Saying stuff like "(asdf-install:install 'md5)" now works.

The Flattened Requirements Matrix

I have no idea if something like this exists in the project management literature (ick, project management), but it's a hack I'm in the processes of putting together because I'm sick of less organized projects spinning out of control.

Here's the scenario: I have a ton of new features I need to spec out and a developer who will be doing most of the coding. I also need to make sure it gets done "right". Of course we're using my definition of right here because I'm in charge (sorta)... YMMV.

I don't like long spec docs. And saying "make it do this" never works. The outcome is never the correct "this".

Instead, this is what I'm trying.

I have a Google doc and each feature is a heading. Under the heading I have a paragraph describing what the feature should do. Below that I have subsections titled "depends on" and "dependents". Each is a list of links to either more specific features or back to more general ones. I repeat until people stop asking questions with "obvious" answers... assuming they actually read it.

I call it the Flattened Requirements Traceability Matrix

Making Django's Built-in Auth Tests Pass

Image via Wikipedia

I added the built in auth framework to a relatively fresh Django project today, and upon running my tests, I got a large number of failures coming from auth. This problem does not appear to be fully documented so this is what I did.

First, notice that most of the errors are template missing errors. Fix these by

1. Installing the admin tool. Auth relies on some of its templates.
2. Stub out any other missing templates (ie. login, logout).

Next, the test cases will complain about missing text in your new templates. Just add in exactly what its asking for as plain text.

Finally, some of the password reset tests were complaining about getting redirect (301) codes instead of success (200) codes. This was an error on my part. They're looking for a link in the password reset email and GETting it. I wrapped the link in an HTML anchor, and the regex in the test was grabbing the closing HTML tag. Removing the HTML fixed that problem. Finally, I just had to add some missing text as above, and all the tests passed.

How to Compile OCMOCK_VALUE for the iPhone

If you're using OCMock to test your iPhone application and OCMOCK_VALUE gives you this error message:

error: syntax error before 'typeof'

Add this line to the top of your test case:

#define typeof __typeof__

What seems to be happening is that the ObjC compiler on the iPhone has renamed 'typeof' to '__typeof__'. The macro above will add the old version back in. Some Googleing seems to suggest that this is related to C99 compatibility.

Make money from open source? Umm, no.

Image by rigeneriamoci via FlickrOn Open Source:

Companies have long hoped to make money from this freely available software by charging customers for support and add-on features. Some have succeeded. Many others have failed or will falter, and their ranks may swell as the economy worsens. This will require many to adopt a new mindset, viewing open source more as a means than an end in itself.
- Open Source: The Model Is Broken

Umm... Duh.

Let's look at a couple of the premises of Open Source.

1. Open Source code is higher quality
2. Anyone can modify it
3. The more successful the software it, the larger the community.

Now, lets look at the business model.

1. Give software away for free
2. Charge for support
3. Charge for custom development
   

You're giving the software away for free so you can't charge for a license. Charging for support means that when something breaks or your clients need help, you help them in exchange for a yearly or monthly fee. Unfortunately, by making your product a successful open source project, you destroy the value of your support contracts (see 1 and 3 in the first list). You say you want to charge for customization like a consultant? See number 2 in the above list. That project is going to the lowest bidder. Also, good luck making that scale.

What sucks here is that I like open source. And to make something sustainable, you have to be able to make money off of it. I don't know how to do that. The original author might, but he just spent two pages not telling us.

Related articles by Zemanta

• Dave Neary: Jerry Maguire on the future of the free software industry
• Is 2009 the Breakout Year for Open Source?
• Open Source Isn't A Business Model... Just Like Free Isn't A Business Model

The Best Programming Books of 2008

Image by eMaringolo via FlickrThere's a thread over at Stack Overflow asking for the Best Programming Books in 2008. I think I'm missing out because I've only read one of them: Programming Collective Intelligence: Building Smart Web 2.0 Applications.

It can be hard to keep up with what's been going on in the world of programming so I appreciate these lists. They help keep me up to date.

These are the books that are on my reading list, but only one of them is from 2008.

1. Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series)
   


2. Real World Haskell
   


3. Smalltalk 80: The Language
   

Related articles by Zemanta

• Is Smalltalk Cool Again?
• Real World Haskell
• Stack Overflow: None of Us is as Dumb as All of Us

Unless you do something, listening is a waste of time

Image via WikipediaListening is hard. It's easier to ignore and rationalize. What's harder though is learning from those conversations and applying what you've learned. The real reason? People don't like change. It scares them.

Dave Winer's recent article - If you never listen you never learn - makes this point. He also offers an anecdote where they listened to one suggestion from one user "and company went from being in the brink of shutting down to gushing cash".

Yes, if you listen you can learn, but unless you're willing to do something about it, its a wasted effort.