So in the spirit of Release Early, Release Often: https://github.com/mullr/WordnetJapanActiveRecord

Have fun!

http://digitalartificer.com/TwitConc/

And if you want the source: http://github.com/mullr/TwitConc

If it’s broken for you, let me know how and I’ll try to fix it. I’ve tested on my mac only.

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)<%an>%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.

// 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.

Recall that the command pattern specifies an abstract “Command” type with an Exceute method. This is only needed in languages without first-class functions: C# gives us delegates, which are pretty much equivalent in this case.  So we’ll skip the custom class and just use them.

But the extended, more useful form of the pattern also has an UnExecute method, used for undo.  This lets you push the commands onto a stack after executing them.  Undo is then simply a matter of popping the most recent command off the stack and UnExecute()ing it.  The command instance retains enough state information to undo what it had previously done.

We can do all that through the clever application of closures.  I’ve chosen to implement the commands as static methods, but they could also be implemented as regular methods, even virtual if you’d like to be able to route around to different implementations. Here’s a fictitious example:

static class Commands
{
    public static Action HAlign(Item stationary, Item movable)
    {
        int oldX = movable.X;
        movable.X = stationary.X;

        return delegate()
        {
            movable.X = oldX;
        };
    }
}

Executing the command is just a method call, and enabling undo is as simple as pushing the returned Action (just a delegate with no parameters or return type) onto an undo stack. (Stack<Action> will do nicely) The returned delegate captures, via closure, all the state in needs for undo to work properly.

That’s it! There are a few small land-mines in the details of how closures work (especially w.r.t. non-local or iteration variables), but the general technique is very simple.

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.

It’s awesome.

Really, it’s just a fancy outline editor at its core.  I know there a lot more things that I haven’t learned about yet, but the surface is very useful.  I can mark things as todo/done, collapse subtrees, and easily move things around.  That’s about all I need, really.  And it works much better for me than the complex one because I can easily customize the view onto my data.  It’s just a tree in a text file, after all.  It also lets me easily morph the system into whatever I need it to be at the time, rather than being rigid.  I suppose that’s good for some people, but ad-hocish is good for me.

And plus it means I get to use emacs more.  Which makes me feel very l33t.

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?

This is especially important for my application, since I have to manage MANY photos on the screen at once. I’m pretty comfortable with the Dispose() idiom – I kind of like knowing where the memory is going when I’m using such large chunks. But with WPF it’s been a mystery.

Enter: .Net Reflector! Not that I would use such a thing. But supposing I did. (Incidentally, I think I owe Lutz Roeder several beers because of this program)

For those that don’t know, there’s a native code library called ‘milcore’ that WPF is built upon. It has a number of handle types. These are wrapped in .NET by subclasses of SafeMILHandle. This is where things become clear – each of these handle wrappers manually puts pressure on the garbage collector according to the estimated size of the object in question. It uses something called MemoryPresssure.Add() to do this.

Which, it turns out, is not actually a way to influence the garbage collector. It’s in PresentationCore.dll: MS.Internal.MemoryPressure. It uses a funny time/size based heuristic to manually call GC.Collect, which we all know and love. So, depending on what you’re doing with MIL Handles and how you’re doing it, WPF will force garbage collection when it feels like it.

Now, I don’t know a whole lot about garbage collectors, but… how can this possibly work? It seems fine in simple cases (allocate a whole ton of memory, null out your references, repeat). But doesn’t it break the useful heuristics that makes gc perform well? For the case of bitmaps especially, it seems that it’s important for GC to know that these are large objects that should be released as soon as possible. More bang for the buck there. (The large object heap comes to mind, but I think that’s to prevent heap fragmentation)

It’s interesting to observe that the base SafeHandle class *does* implement IDisposable. But the MIL handles themselves aren’t publicly accessible, so they can’t be directly used. But an adventurous/insane person might use reflection to pull the MIL Handle out, replace it with null at the source, type it as an IDisposable, and dispose it manually. I may resort to such measures if this memory pressure thing turns out to be as fishy as it smells.