Clojure: Transparently using delayed values

Clojure has a nice ‘(delay)’ macro which will delay the computation of anything you like.

(def lazy-val (delay (+ 1 2)))
lazy-val  ;; #<Delay@57d4f95b: :pending>
@lazy-val ;; 3
lazy-val  ;; #<Delay@57d4f95b: 3>

But, as you see above, you need to deref it with @ in order to get at the value on the inside. There are cases where this is a pain. You may have a chunk of code which already operates on regular values, and you want to provide a lazily computed value to it. As long as you’re using protocols, you’re good: you can extend-protocol on top of the Delay type to provide a version which is lazily constructed upon calling any of the protocol methods.

(defprotocol MyProto
(do-it [this]))</code>

(defrecord Impl [a b]
MyProto
(do-it [_] (+ a b)))

(extend-protocol MyProto
clojure.lang.Delay
(do-it [this] (do-it @this)))

(def lazy-instance (delay (->Impl 1 2)))

(do-it lazy-instance) ;; 3

This could probably be done more concisely with a macro, but I’m happy with this for now.

Configuring msysgit for improved awesome

Git, as many of us know, is pretty great. And it works with great things like github and gerrit. I’ve been using it for work lately and like it very much. But the windows toolchain leaves something to be desired.

It turns out that the first rule of git on windows is don’t use cygwin git. I didn’t understand why this was until I started dealing with large repositories and doing a lot of waiting. git status took 15 seconds to run EVERY TIME. Luckily I figured it out and started using msysgit instead. msysgit is a pretty good port, but anybody who’s used a mac or any unix machine with a real terminal emulator will be immediately dismayed to find out that its shell runs inside the regular cmd.exe window. Which is crap.

This is how to make it not crap.

1. Configure the console
Did you know you can make cmd.exe not suck? I didn’t. It’s pretty easy.


The most important setting is “QuickEdit Mode”, which lets you select text directly without doing the brain-damaged menu selection thing. Then you can hit enter to copy it. The right mouse button pastes. Double click selects a word, just like you’d expect; this is really useful when dealing with git, since you can double click a commit hash and hit enter to quickly copy it, then right click to paste it to the command line.

The other settings I use and recommend are:

  • Font: Consolas 14pt
  • Window Size: Width=128
  • Window Position: “Let system position window” turned off, set to be the right half of my screen every time.
  • Colors: I use a light yellow background and dark foreground. This gives good contrast against the blue you see in so much colored output, unlike the default black background. BG=255,255,236, Text=0,0,0. You should configure your prompt first if you want to do this, so you don’t get stuck with invisible text.

2. Configure your prompt.
The default msysgit prompt settings are kind of crap. This is what I use in my ~/.bash_profile. NB: this is set up for a LIGHT background, so the text is BLACK. If you use this with the default colors, your text will be invisible.

function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}

function proml {
  local       BLACK="\[\033[0;30m\]"
  local        BLUE="\[\033[0;34m\]"
  local         RED="\[\033[0;31m\]"
  local   LIGHT_RED="\[\033[1;31m\]"
  local       GREEN="\[\033[0;32m\]"
  local LIGHT_GREEN="\[\033[1;32m\]"
  local       WHITE="\[\033[1;37m\]"
  local  LIGHT_GRAY="\[\033[0;37m\]"
  case $TERM in
    xterm*)
    TITLEBAR='\[\033]0;\w\007\]'
    ;;
    *)
    TITLEBAR=""
    ;;
  esac

PS1="${TITLEBAR}\
$BLACK\w$GREEN\$(parse_git_branch)\
$BLACK\$ "
PS2='> '
PS4='+ '
}
proml

You can easily adjust the colors to be how you like. Note that the last color here will override the text color you set in the prefs window; that confused me at first. Also make sure your profile file is executable (chmod +x ~/.bash_profile) and starts with #!/usr/bin/bash, if you’re having any troubles.

3. Configure git a little
This isn’t specific to windows, but it makes my git experience so much smoother. I found the ‘lg’ alias on the internet and forgot where. Sorry, guy who made this first.

[merge]
        tool = winmerge
[mergetool "winmerge"]
        cmd = 'C:/Program Files/WinMerge/WinMergeU.exe' \"$MERGED\"
[color]
        diff = auto
        status = auto
        branch = auto
[alias]
        lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)&lt;%an&gt;%Creset' --abbrev-commit --date=relative
        anchor = tag -f anchor
        s = status

‘git lg’ will now give you a nice colored log summary. I use ‘git anchor’ frequently before trying out something I may mess up or want to quickly revert; it makes it easy to get back to where I was without having to inspect the reflog. And finally, I use ‘git status’ so much that I just abbreviate it to ‘git s’.

4. RTFM
There are incredible amounts of excellent information about git on the web. Read them. You can look at my bookmarks over at del.icio.us for a starting point if you want.

Although there are a number of windows guis around, in various states of incompletion, you’ll be much better off if you learn to use git from the command line. Yes, this means editing commit logs in vi, if you stick with the defaults. If you can’t do this already, you should learn how. The GUI tools, as they are today, simply hide too much important stuff from you. The real power in git is understanding how the commit graph works and how it changes when you do various operations; this is something that should in your face, not hidden away. At most, ‘git gui’ is acceptable for staging things for commit. ‘gitk’ is alright as well. But I haven’t yet seen any windows-specific guis that do a good job.

C# techniques: simulating stack unwinding and block syntax

One of my favorite things about C++ was its predictable stack unwinding.  This could be combined with anonymous scopes for some powerful techniques.  (I learned all about this from Steve) For example, I might want to hold onto a lock to something for a particular time.  I could simply make an object which allocates the lock in its constructor and releases it in its destructor.

// Anonymous scope for lock
{
ResourceLock lock;
//…
}

ResourceLock allocates the resource it its constructor. It lives on the stack until the local block is exited, whereupon its destructor is called and the lock is released.

The really great thing about this technique, especially for things like locks, is that it’s entirely exception safe. Can we do something similar in C#?

Method 1: IDisposable/using
The C# way of doing predictable allocation is IDisposable. And since we have a bit of syntax sugar in the ‘using’ block to make it exception safe, we may as well use it for this purpose.

class ResourceLock: IDisposable
{
public ResourceLock()
{
// allocate the lock
}

public Dispose()
{
// release the lock
}
}

// usage example
using(new ResourceLock())
{
// the lock is held here…
}
// … and released here

Hopefully the usage is pretty obvious. I like this method because the usage syntax is pretty good. In fact I don’t know of another method for things like locks. But there are other scenarios where you might want to do a bit more.

Method 2: Delegate passing
You’ll be familiar with this technique if you’ve ever used Ruby or Smalltalk. Those languages (and others) have native support for blocks. It’s not quite as nice in C# but still usable.

Let’s take the example of data binding. There are often cases where you need to do a batch of operations on a class which can throw change events. While it’s not strictly incorrect to throw an event after each operation, it can be a big performance problem. So we want disable change notification while the operations are in progress and throw a single change event when they’re done. Think of it as a kind of data-binding transaction.

We’ll implement the Transaction method using a Delegate parameter:

// A class which is observable in some way
class DataBindingClass
{
    public void Transaction(Action a)
    {
        try
        {
            SuspendChangeNotification();
            a();
        }
        finally
        {
            ResumeChangeNotification();
            NotifyObserversOfChange();
        }
    }
}

By passing an anonymous delegate to this method, we get an acceptable (but not great) syntax.

public void DoStuff(DataBindingClass db)
{
    db.Transaction(delegate() 
    {
        // do some stuff
    });
}

Don’t forget that you can pull in variables from the surrounding scope via closure. That’s really the only reason this technique is worth bothering with.

Method 3: IEnumerable/yield return/continuations
Okay, we’ve now stepped clearly into the realm of abuse. Please don’t do this in your code. But in the interest of completeness…

Since the yield return syntax is really a form of continuation, we can get the same general scoping effect with a little bit of creativity.

// A class which is observable in some way
class DataBindingClass
{
    public IEnumerable<int> Transaction()
    {
        try
        {
            SuspendChangeNotification();
            yield return 42;
        }
        finally
        {
            ResumeChangeNotification();
            NotifyObserversOfChange();
        }
    }
}

// usage example
public void DoStuff(DataBindingClass db)
{
    foreach(var i in db.Transaction())
    {
        // do some stuff
    }
}

As you can see, we abuse the ability of foreach to iterate over any IEnumerable to simulate a block syntax. In this case the block is only called once, so the loop only runs one time. The particular value we yield out Transaction() is completely arbitrary, as is the type. It’s only there to fool the loop into running.

In summary
C# gives us some reasonable tools here. I recommend method 2 (delegate passing) for most cases – it’s very flexible and the syntax is reasonable.

Two cool things (cappuccino, github)

Cool thing 1: Cappuccino.  I’m sure this is well known by most by now.  I’ve been playing with it in my copius free time and continue to be impressed.  I’m excited to be able to use Objective-C in the browser – I’ve always thought it was a nice language, despite my lack of experience with it.  In particular, dynamic message dispatch is a perfect fit for GUI programming.

Cool thing 2: github.  While playing with cappuccino, I thought I’d fix a few bugs.  So I made a github account and cloned the full repo.  The clone took about a half second.  Really.  The collaboration model on github just decimates all the commercial systems I’ve used, not to mention cvs and svn.  This is what sourceforge always should have been.

My Bookshelf

These are the books I have at work, which mostly reflect the various projects I’ve worked on over the years.  Some are useful, some are not.

General Books:

  1. Design Patterns, GoF: Recommended, but first read Head First Design Patterns.  These two books togther kicked my brain into being able to think critically about design decisions.
  2. The Pragmatic Programmer:  I like it, though I think it’s worth less now in the light of robust discussion of these topics on blogs.
  3. Peer Reviews In Software: Haven’t opened it.  Got it from a mandatory training class that didn’t impress me.
  4. Lean Software Development / Implementing Lean Software Development: Barely cracked them. Put on my desk by my boss, but I think this particular movement (in our organization, anyway) is going to pass before I need to care too much about it.
  5. Extreme Programming Explained: Barely cracked, though I bought it myself.  Once I started reading it, I realized I already learned the content on the web.

Technology-specific books:

  1.  The C++ Programming Lanuage: Essential if you’re using the language.
  2. Effective C++/More Effective C++/Effective STL: Also essential if you’re using the language.  Other books tell you how to write code, but these books tell you how to right GOOD code.
  3. Effective C#: Doesn’t live up to its namesake.  Perhaps there are fewer gotchas in C#?
  4. Java Performance Tuning: I got this for $5 and learned one or two things from it.  But I think it’s about Java 1.1, so it’s more than a little out of date.
  5. Interprocess Communication in Linux: useful when I needed it, but I no longer need it.
  6. Programming .Net components: This is a bit of a weird one.  I was hoping it would explain the mysterious System.ComponentModel namespace, but I never got into it enough to fully understand what’s going on.  I could probably learn a lot from this book if I got into it, but I’m not motivated to do it anymore.
  7. Java development with Ant: I like this one.  Useful whenever I need to do ant, which is more often than one might think.  And my copy is autographed!
  8. Applications=Code+Markup: Meh.  Not that impressed.  If you want a WPF book, get:
  9. Windows Presentation Foundation Unleashed: This is the one you want.  It’s smaller than the previous book, but it has better explanations about the things that matter.
  10. Debugging Microsoft .NET 2.0 Applications: This book has saved my ass on multiple occasions.  If you’re developing for .NET, you need to know how to use your debugging tools.

What does your bookshelf look like?  Are there any bacon-saving books you’d recommend?

Rules of the Source Tree

These are the fundamental rules I use when managing a source tree. To many these are a given, but others don’t know these things.

  1. There must be an automated build.
  2. If you break the build, fix it.
  3. Building the code must be trivial.
  4. The code should run from the source tree, with no installation steps required.
  5. Creating a new build machine be as easy as following the document you wrote saying how to do it.
  6. Things needed to build the code aside from the contents of the source tree must be minimal and well documented. Ideally, this is nothing more than your compiler and your build system.
  7. Source control is for source code. Checking in binaries is allowed only in the pursuit of #4, or when said binaries are a critical part of the software itself. Even then, tread carefully.
  8. If you can choose between a binary and textual representation for a source file, use text. Consider this when choosing your tools. (WiX good, InstallShield BAD)
  9. It must be trivial for developers to run the unit tests in the same way the automated build does.
  10. Be considerate. Think about your fellow developer.

My project is pretty good on this list, I think we’re at 7.5/10. I’ve had major headaches enforcing #7, to my great disappointment. And number 8 is a continuing struggle. We’ll get there, hopefully. The half point is from #10 – turns out it’s hard to create a culture of mindfulness out of nothing.

What’s the score on your project? Are you working any of these things?