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.



As things have been heating up at work lately, I’ve found myself returning to GTD as a way of keeping things more sane.  I thought that I’d look for a tool.  I tried a complicated one that modeled out the whole system, but I ended up with emacs org-mode.

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.

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?

Secrets of WPF Memory Allocation

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.

Android SDK: First Impressions

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.  

Aggregation + Composition = Headache

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.

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?