Code Beast

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?

The way WPF manages memory is a bit of a mystery. It all appears to be nicely garbage collected and everything, but I know there are unmanaged resources under there. How does it know when to garbage collect them?

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.

I’ve spent the evening going through some of the tutorials for the newly released Android SDK.  I won’t beat around the bush about my motivaion: I want money!  I’ve spent about two hours playing with it so far.   

My impressions so far are mixed.  The packaging is fairly nice - the eclipse plugin integrates things together well, including debugging in the emulator.  It’s a little rough around the edges but quite usable.   

I’m not altogether impressed with the code itself so far.  The xml layouts are quite verbose - I think I’ve written ‘android:layout_height=”wrap_content”‘ about 10 times in the past hour.  (Why did they choose such a long default namespace prefix for all the examples?  I’m using ‘a’. )   There’s nothing particularly novel about the way these are done.  Perhaps it’s the ‘it works on a phone’ part that’s cool?  Having never developed for these things, I don’t know.  /me is spoiled, undoubtedly.   

I also don’t yet understand why there are constants being used for so many things.  This code has serious public-static-final-int-itis.  Doesn’t java have strongly typed enums?  My java friends says that yes, it does, as of 1.5.  Perhaps this is based on an older compiler?  The attributes in the examples tell me otherwise.   

I do like the resource mechanism, as I currently see it.  Being able to access resources from the code in a strongly-typed way is a big win. (ala ResXCodeFileGen)  It feels like it’ll make for a good localization mechanism as well.  I would like to see better ide integration for this kind of thing.  Imagine thinking: “I need a new string resource for this”, hitting the hot key, filling out a little form, and having the string added with the key you specified and the reference already in place.   

This is all, of course, FWIW.  I’m sure my opinions will change as I learn more.  

I hereby banish the words ‘aggregation’ and ‘composition’ from all of software.

Am I allowed to do that?

Think about it. The last time you drew a UML diagram, did you use hollow diamonds or filled-in diamonds? If you used both, did anybody know what you meant? I’ll bet the answer is no. And if you used those words in conversation, there was probably a 10-minute discussion about what their meaning. This discussion happens EVERY time.

There’s a good reason for this - the distinction of aggregation vs. composition simply is not useful enough to stick in people’s brains. Some feel the need to use it because it’s part of the modeling tool they spent so much money on. Others like it because it makes them look smart.  But it’s not worth it. (nor is the modeling tool, IMHO)

So join the movement! Run sed -e ’s/(aggregation|composition)/association/g’ over all your documentation and emails! Get rid of those stupid diamonds and use arrows instead! Spend your time thinking about the problem you’re trying to solve instead of explaining useless concepts.

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?

If it’s worth doing, it’s worth overdoing!

The abuse context in this case is the IEnumerable interface and the new (in C# 2.0) ‘yield’ statement that goes with it. In case you don’t know, it’s a trick hot feature that lets you easily return a sequence of things without having to create a temporary object. I like to think of it as being ‘foreachable’. Typical uses of this simply iterate over a single list. I’m going to show you to traverse a tree.

By way of example, lets start with the tree structure we used in the last article:

class Node {
    Node[] children;
}

Let’s throw things up a little this time and look at the client code first. What I want to be able to do is traverse over the tree as transparently as possible. We got pretty close last time, but this method will be better:

void TestTraversal()
{
    Node root = GenerateTestTree();

    int nodeCount = 0;
    foreach(Node n in root.Traverse)
    {
        nodeCount++;
    }
}

This is my favorite kind of source code - it’s absolutely obvious what’s going on, with no indication of what needs to happen inside. Perhaps ‘Traverse’ could be a better name, though: ‘Nodes’, or something. But you get the idea.

To implement this, we’ll use an IEnumerable (foreach-able) property:

class Node {
    public Node[] children;

    public IEnumerable<Node> Traverse
    {
        get
        {
            foreach(Node child in children)
                foreach(Node n in child.Traverse)
                    yield return n;

            yield return this;
        }
    }
}

This is the meat, and it bears further study. The two nested loops are the recursive step, with a twist: they must re-yield each child’s result up to the caller. This is hard to grasp at first. It may help to note that a more sensible way of saying the same thing would be:

// THIS WON'T BUILD!!!
foreach(Node child in children)
    yield return child.Traverse;

That is, in fact, what I tried to write the first time I did this. But you can’t yield anything to an IEnumerable but its defined type. This is clearly a design flaw in the C# language. The workaround for this is to iterate over the child and re-yield each item.

I have mixed feelings about this technique. Between it and the delegate vistor technique I wrote about previously, it’s really hard to say what’s better. For applications where clarity of implementation is most important, I lean towards the delegate version. It’s easy to explain to anybody who understand function pointers, which is most people.

But for applications where a good API is the most important, I like the IEnumerable version (this one). It’s as clean as an API can possibly be, and it retains all the run-time benefist of the visitor pattern: it uses no temporary storage, and the user’s code is run once at every node instead of stringing all the calls together at the end.

The GoF visitor pattern is useful but awkward. The usual c++ or Java-y versions typically involve some kind of visitor interface which your visitor must subclass. Java somewhat mitigates this with anonymous classes, but not fully. In C#, if we’re clever with the use of delegates, we can make tasks like tree traversal look about as simple as iteration.

Let’s start with a simple tree class:

class Node {
    Node[] children;
}

We’ll implement a depth-first search using the visitor pattern. Using delegates, we can eliminate the need for an additional class:

class Node {
    public Node[] children;

    public delegate void VisitorDelegate(Node currentNode);
    public void Traverse(VisitorDelegate visitor)
    {
        foreach(Node n in children)
        {
            Traverse(n);
        }
        visitor(this);
    }
}

This is a pretty simple recursion, and really isn’t anything special. The way delegates are typically used, there is still an additional method required for the delegate to be called. But with C# 2.0, we have the opportunity to use anonymous delegates. This is where we can write some really slick code:

void TestTraversal()
{
    Node root = GenerateTestTree();

    int nodeCount = 0;
    root.Traverse(delegate(Node n)
    {
        nodeCount++;
    });
}

The really cool thing about this is that, since anonymous delegates can act as closures, our visitor can pull in the nodeCount from the surrounding environment. This makes for a very succinct version of the visitor pattern.

Technorati Tags: c#, programming

We frequently encounter APIs that take lists of objects as parameters. The code behind the API will likely want to know something about those objects. It might sort them or extract some metadata and then process them. It may return a list of the objects with additional data. The question at hand is: how should the API get the data it needs about those objects?

Presented below is an elegant solution which preserves separation of concerns.

In considering this problem, we’ll use a simple (read: contrived) example: a chart drawing API that needs an X and Y data point for each item in the chart. The client has a number of StockQuote objects it wishes to plot, defined as follows:

class StockQuote
{
    public float price;
    public DateTime date;
}

Suppose further that later on I want to be able to react to user interaction with the chart and obtain the relevant StockQuote object.

Simple Approach: Data Objects
A typical approach would be to define a data structure with the information in question. For example:

library:

class ChartPoint
{
    int objectId;
    public int x, y;
}

Chart CreateChart(List<ChartPoint> points);

client:

List<ChartPoint> points = new List<ChartPoint>();
foreach(StockQuote quote in quotes)
{
    points.add(new ChartPoint(quotes.IndexOf(quote),
        quote.date.DayOfYear,
        quote.price));
}

CreateChart(points);

This works, and is explicit, but is very wordy. It’s very easy to implement on the library side, of course. But I’ve got to create an intermediate list of this other type on the client side, which adds three lines of additional code on top of the call, plus an intermediate list. It also imposes this requirement that I have an Id to refer to my object, so I can know which one is which when later interacting with the chart. That’ll be another layer of lookup - this doesn’t feel right at all.

OO-Approach: Interfaces
Many would suggest the following method:

library:

interface IChartable
{
    public int X { get; }
    public int Y { get; }
}
Chart CreateChart(List<IChartable> points);

client:

class StockQuote : IChartable
{
    public float price;
    public DateTime date;

    public int X { get { ... } }
    public int Y { get { ... } }
}

ChartAPI.CreateChart(stockQuotes);

The actual invocation has improved, and I no longer need the Id field, since I’m passing in my objects directly. But now my class has to implement this ‘chartable’ interface that none of the rest of the code actually cares about. That doesn’t feel right either. We should be able to do better.

Generic Approach: Accessor Delegates
The question to ask is: what is the fundamental thing the library actually cares about? What is the core of the problem? The answer in this case is: for each object, what is the X value and what is the Y value? Or to phrase it differently: how I extract the values from the object in question? Lets provide that information directly.

library:

delegate int CoordinateAccessDelegate(object o);
Chart CreateChart(List<object> items,
    CoordinateAccessDelegate xAccess,
    CoordinateAccessDelegate yAccess);

client:

ChartAPI.CreateChart(quotes,
    delegate(StockQuote q) { return q.date.DayOfYear; },
    delegate(StockQuote q) { return q.date.price; } );

Since what we want is the way to access the X and Y data, we’ll give it exactly that: an access delegate. In this way, the chart library doesn’t particularly care about the format of the data I’m using, nor does the rest of my application care about the requirements of the chart library. And I avoid the painful copy step of the data-centric version.

A hidden benefit of this approach is revealed later, when the chart library needs to return to me information about some user interaction. It can do this now in my own terms, with my own objects, rather than by using some structure with an id field that I have to map to my object.

Some will have correctly observed by now that this is the same technique used to provide a sort comparator. This is exactly right! Understanding the technique and realizing it may be used elsewhere is the entire point.

Of course, this technique is not appropriate for all problems. If a large number of accessors are required, it probably shouldn’t be used. The goal is a literate API, one in which the invocation parameters represent the data that is actually required.

Technorati Tags: c#, <a programming

Apple today announced a lot of new things - a sexy computer, a spreadsheet, and a new version of iMovie. A complete rewrite, according to the reality distortion field. It’s got this cool feature where you scrub the mouse across a video and it updates according to where it is. They also have a neat way to decompose things by scene very quickly. Watching the demo video got me thinking: how would I go about doing that? Really, it’s an impressive technical feat, dealing with all that data so immediately.

And here’s the thing: I don’t think I could do it. Not because of any inability on my own part, but because I don’t have the tools. I think there are exactly two companies today with the technical ability to pull off something like that: Apple and Microsoft. They each have:
- An OS
- A video stack
- A DRM system
- A whole suite of applications (roughly 1:1 corresondence)
- An application development stack
- An IDE (or five)
- The source code for all of the above
- The people who wrote all of the above

Any reasonable idea I can come up with for doing the kind of thing done by the new iMovie involves changing the video stack. And since I can’t change the video stack, since I don’t work for Apple, I’m out of luck.

Apple and Microsoft clearly have an advantage by controlling the entire software vertical, but I contend that it makes applications such as this downright impossible. Microsoft in particular has a long history of releasing one API and writing their own applications using another.

Where is there hope for innovative apps? There’s one more vertical set of code I haven’t mentioned: open source. It’s not easy, but the tools are there to do what needs to be done. The only way to do any kind extensive innovation on a desktop app is by basing it on open source technologies. Apple and Microsoft simply cannot be fought on their own turf.

Technorati Tags: apple, opensource

I recently got a new workstation with lots of memory (3 GB) and a big disk (750 GB), and it has significantly improved my life. Here’s how:

1) Since we’ve got MSDN, I get Virtual PC for free. Not as cool as VMWare, which has neat ways to manage the changes to your VM, but still good enough for me.

2) I did a patched up XP install and save the VM definition + the disk (vhd and vmc files) in VMs/Base XP. I seem to remember having to hack up the .vmc file to have it use a relative path to the disk. The disk is named ‘disk.vhd’ to save me work.

3) Whenever I want to do something possibly invasive, like test a beta of Visual Studio or something else that I would be pretty stupid to do on my main dev box, I simple clone the directory, rename the files, and go from there. The copy takes about 5-10 minutes, depending on what else I’m doing at the time.

4) I’ve also got a ‘Base XP Dev’ image with my development environment all set up that I can use for extended debugging sessions without having to tie up my normal environment. Particularly useful when doing a long-running automated test on an old version, when there are outdated COM APIs (I know, I know).

I don’t think I’m ready to go full-on virtual yet. I tried that once, but the responsiveness of the VM just wasn’t where it needed to be. Immediate feedback is very important to me, since I tend to move pretty fast through systems that I know well. Maybe someday when I get a quad core box and the VM apps can spread across multiple cores, I’ll give it another try.

In summary: virtualization makes me happy.

Technorati Tags: programming, virtualization