Author: Julian Birch

If you bind a grid to a large data set, you will inevitably create a control larger than is comfortable to show on the screen.  By default, if you have this the root view model in Caliburn Micro, you will end up with a window that is so large that it is hard to manipulate on the screen.  This is because, by default, the windows that CM creates are set to size to the control.  If you want to change this behaviour, you will need to change the SizeToContent property of the window to Manual.  To do this, you need to do the following:

First, you need a custom window manager.  If you’re using an IoC container, you can simply register an implementation of IWindowManager.  I recommend subclassing the default WindowManager class.  If not, you can simply override GetInstance in the Bootstrapper; this also has to advantage of suppressing annoying on-boot exceptions.

Secondly, override EnsureWindow (as of 1.1, it’s slightly different in 1.0) in the window manager.  You’ll note the window manager is aware of the view model it contains, which allows for more customized approaches depending on your requirements.  A final gotcha: whereas most of the code is found in the Silverlight implementation, WindowManager is completely different between WP7, WPF and Silverlight and is contained in different projects.

I spent a couple of hours banging my head against a wall over this.  Leiningen doesn’t respect the HTTP_PROXY environment variable as most Unix programs do.  I finally asked on the Clojure IRC channel and got the answer from manutter: leiningen, of course, uses maven for its dependency management.  Maven, in turn, doesn’t respect the environment variable.  Instead you need to configure a specific file in your ~/.m2 directory.

Hope this helps someone.

OK, this isn’t going to be a line-by-line code quality review.  Anyone who is interested can take a look (and will find the quality is excellent).  This is about my experiences so far using Caliburn Micro for relatively simple UIs.

First off, let me say that I’m unaware of any competitors to CM and, at the time of writing, I can’t imagine ever not using it unless I decide to build my own.  If I built my own, it would probably look quite like CM.

Convention Based Binding

This is the raison d’etre of CM, and it just works straight out of the box.  It’s a joy to use.  I did, however, find it quite difficult to figure out how to set up new conventions for things like SyncFusion graphs.  I imagine this is a problem quite a lot of people run into, and a fair number probably do what I did: just drop back down to normal binding declarations.  There’s nothing particularly wrong with this approach if you’ve only got a couple of instances, like I have, but I would have appreciated more guidance on it in the documentation.  I’d have loved to have seen more convention-based thinking in the event handlers.  For instance, is it really necessary for the developer to specify the parameters to the target function like $view, when you could simply introspect the target function to work out which parameters it needs.  (This is probably the first of many remarks that will elicit an extremely sensible “here’s why it doesn’t do that” response.)

The Event Aggregator

It’s interesting to look at the event aggregator from the point of view of a Retlang user.  Retlang is explicitly built to handle both straight concurrency and the synchronization with the UI.  Here’s the main differences:

• Caliburn Micro keeps Weak References to subscriber objects.  Retlang requires an explicit unsubscribe.
• Caliburn Micro requires subscriber objects to implement explicit interfaces, Retlang does not.
• The handling of events in Caliburn Micro is performed on the UI thread.  You can override this on a per-publish basis.  Retlang offers a wide variety of modes, and you can have different modes for the one published event.
• Caliburn Micro is oriented towards you creating one bus with all events sent on the same event aggregator.  Retlang Channels are strongly typed and you typically have a lot of channels.

This makes the two approaches so different it feels like they’re addressing different problems.  To a certain extent they are: CM’s use cases are simpler, and it’s easier to use CM for these cases.  However, if you need the power, there’s nothing stopping you using Retlang within a CM project and they play well together.

The main problem with the event aggregator is that it’s just slightly too simple for its own use cases.  Basically, this objection boils down to “actions aren’t events”

• You can’t kick off co-routines from events.  (You can kick off co-routines from anywhere using SequentialResult, but the effect isn’t pretty.)
• You can’t localize or bubble events.

Basically, although a nice piece of code, I don’t think publish and subscribe can be divorced from broader synchronization questions.  Which brings me to co-routines.

Co-routines

I’ve talked before about how impressed I was with this particular trick.  However, it’s worth examining the limitations of the approach: yield return is nice, but it’s limited to a single function.  If you want to achieve something more complex (and by more complex, I mean about 5 or 6 things need doing), you’re going to have to solve the composition problem yourself.  However, this is easier said than done.  As I’ve already mentioned, you can’t kick off co-routines from events.  However, even if your task is simpler than that, there are still problems:

Let’s take the following example of something you might want to do in response to a button press

• show busy indicator
• perform 4 DB accesses
• Hit a web service
• Hide the busy indicator
• Compute some data from the data we’ve obtained (I’m assuming the computation is fast)
• Set that to a local property

Truth is, the database accesses and the web service aren’t probably going to want to be executed in sequence.  The co-routine trick is useful for waiting until they’re all complete, but you’d like to be able to kick them off in parallel.  Really, you want functionality similar to async.js.  The co-routine trick basically replaces waterfall, but it doesn’t really address the other cases.  Sadly, implementing functionality such as “auto” in C# is probably impossible due to the nature of the type system.*

Then comes the question of what to do with the results.  The Build Your Own MVVM framework code suggests callbacks to process the “return values” of the queries, but that’s pretty ugly.  In practice you want something like futures.

Finally, there’s no batteries included in the IResult model.  There’s no IResult for running something on a threadpool, no IResult for wrapping an asychronous function pair.  It’s a nice trick, but it’s not a framework.

The weird thing is, there is a system that actually addresses these concerns: Reactive Extensions.  Now, I spent some time investigating it last year and found it over-complex and underdocumented, but it’s got parallel execution, it’s got execution in different sychronization contexts, it’s got built in support for asynchronous results.  It’s possible that Rx could bring genuine benefits to Caliburn Micro.

*Java has the same problem.

The Ugly

There are a number of things that, while they’re not exactly wrong, I don’t much like.  For one, who decided to call a class “Action”?  That’s just plain annoying for anyone who writes a lot of functions that take delegates.

More seriously, the problem with any convention-based system is “what happens when the conventions go wrong”?  Krzysztof has spent a long time trying to improve the diagnostics for Castle Windsor, and the same process is needed here.  In fairness to CM, it’s not all CM’s fault, the development error reporting of WPF isn’t exactly world class to begin with.  However, the ability to see clearly what was bound and why, and being able to dig into why a certain property or action wasn’t bound, would be invaluable.  I suspect a lot of CM users just link the source code directly into their projects.  (One of the blessings of open source; try doing the same with Rx).

A special mention should be given to the approved way of working with a busy indicator, the “show busy” and “hide busy” IResult implementations.  I’m sure plenty of people are happy with this approach but, for my money, it’s a huge breaking of encapsulation.  I don’t want every action that performs a database query to have to flip the busy indicator back and forth.  Ideally, I’d like the execution of a query against your back end to automatically show or hide the appropriate busy indicator.  I’m not quite sure how elegantly you could add this to the architecture, though.

Finally, I loathe seeing globally available IoC containers.  It’s just not necessary, all of that stuff could be set up in the bootstrapper, and would probably make the code marginally more elegant.

Summary

I can’t imagine developing another WPF project without using Caliburn Micro or something very like it.  The convention-based property binding and the action are phenomenal.  I would really like to see more documentation on how to build your own conventions, because I think this part is phenomenal.

The event handling/synchronization features are deliberately simple.  There’s a great deal to be said for explicit simplicity, but I do feel that sometimes this edges into “didn’t address the issue”.  Still, I’d much rather have a clean, simple, incomplete framework than an incomprehensible monster.  As useful as Rx is, it is definitely that kind of a monster.  CM is small and enabling, and that’s how I like my frameworks.

There’s a lovely idea out there that states that code shouldn’t make it obvious whether a value is data or computed.  Martin Fowler recently added a bliki article on the subject.  He also observed that the custom is more honoured in the breach than the observance.  But, to be honest, I’m really not that convinced it’s a good idea anyway.  Let’s restate this a different way: a field access should be indistinguishable from a synchronous method call.  Now, this is fine for computations of the form “price * volume”, but if you get a computation that takes appreciable time, this starts to look like a bad idea.

It gets to be an insane idea when you extend the idea to anything that involves I/O.  The first idea that you develop is the idea of the Remote Procedure Call, a brilliant, beautiful, wrong-headed idea.  If network access was cheap, as people seemed to believe it would be in the early 90s, this might be a goer.  As it is, the performance difference between accessing a byte of memory and a byte of memory on a remote machine is so large as to render almost all other concerns, including algorithmic complexity, irrelevant.  You try to write a front end using the Uniform Access Principle and you will have a inconsistently performing UI.

There is a way, of course, to satisfy the uniform access principle and still cope with network access and long computation, and that’s to make absolutely everything asynchronous.  Not even node does that.  In practice, your code is always going to reflect the performance architecture and especially the network architecture of the solution.  If it doesn’t, frankly, your code is wrong.

Here’s how Caliburn finds the view for your view model: it removes the word Model from the FullName of your view model.  So

• Caliburn.Micro.Hello.ShellViewModel becomes Caliburn.Micro.Hello.ShellView
• Caliburn.Micro.ViewModels.ShellView becomes Caliburn.Micro.Views.ShellView

However, it’s important to understand that it removes every instance of the word model from the FullName.  So

• Caliburn.Micro.Models.ShellViewModel becomes Caliburn.Micro.s.ShellView

Since it’s highly unlikely you created a namespace called “s”, it follows that the convention is going to fail to find the view.

More generally, this is a classic case of under-reporting in errors.  The error tells you that it couldn’t find the view, but what it doesn’t tell you is where it looked.  This being an open source application, it’s relatively easy to find out once you’ve determined that you need to be looking at the ViewLocator code.  But still, the error could be better, and it would save people who had made a mistake some time.

Most of you have probably forgotten you even have me on your feed.  I promise normal service will be resumed shortly.  There are a couple of reasons that I’ve not been posting, but easily the most important is that I discovered my wife was pregnant.  It turns out there are one hundred things an expectant father needs to do, not least a great deal of shopping.  However, I’ve been meaning to write this for some time, and I hope someone will find it important.

If you don’t know about Trisomy, it’s one of the worst pieces of news expectant parents can get.  The most common kind, Down’s Syndrome, means that your child will suffer from severe mental impairment, have difficulty with fine motor skills, run a high chance of heart disease and will probably need to live in sheltered housing their entire life.  The less common versions are worse, with only 1% of babies born with Edwards’ Syndrome living to age 10.  Most have died 15 days after birth.  There’s no cure; these are genetic conditions.  The only thing that can be done to prevent it is to abort the fetus.  Even someone who is rabidly pro-choice would agree that they’d rather not have to make that dreadful choice themselves.

Now let’s talk about the maths.  In the hope this information is useful, I’m going to use the actual statistics for my child.  Here’s how it works: the baseline probably of Down’s Syndrome for my wife and I is 1 in 200.  That is way too high and there is nothing that can be done about that.  However, at 3 months, doctors can perform ultrasound scans and check for certain physical abnormalities that are characteristic of the syndrome.  This is an imperfect process, both because of human error and because not all children with the condition exhibit these symptoms.  However, the scan found nothing, and our chances were reduced to 1 in 4000.

However, here’s where the maths turn nasty.  There’s also a 1 in 8000 chance of my baby having a more rare form of trisomy.  One in 8000 sounds like a very small number indeed, but by splitting out the probabilities they’re hiding the combined number, which is something like 1 in 2600 that my child has some form of trisomy.*  These odds may sound small if you have healthy children or no children, but I can assure you that when it’s your kid, those odds aren’t really something you want to live with.
So, what could you do?  Well, there’s a direct genetic test that can establish beyond doubt whether there’s a genetic abnormality.  However, there’s two problems with it.  The first is that, if there is a problem, there’s still no cure.  Your only option would be an abortion, so unless you and your partner are comfortable with that there’s absolutely no point in doing the test.  The second is that the test itself carries a whopping 1% chance of aborting the fetus.  I didn’t like the odds 1 in 2600, I really don’t like the sound of 1 in 100.  So, in practice, you would never use this test unless you had already made a decision to abort and the 3 month scan revealed cause for concern.  Worse, the chance of the test going wrong and the chance of a genetic abormality are completely independent.  This means that if the test did go wrong, the chances would be something like 99.96% that the baby had been perfectly healthy.

Is There Anything That Can Be Done?

As you can imagine, we didn’t elect to take the test.  Now, everything that I’ve told you so far has been, ultimately, stuff you can’t do anything about.  It won’t even help you make a decision, because it’s ultimately not an intellectual thing.  However, you can in fact reduce the chance of your future child having a genetic abnormality.  You can have children early.

The base chance of trisomy or any other birth complication basically starts going up the moment you hit adulthood.  It’s overwhelmingly dependent on the age of the mother.  By the time the mother is over 35, the base probabilities are higher than you’d like to countenance.  Sadly, in the UK that’s pretty much the standard state of affairs amongst people in my socio-economic group.  Basically, we’ve all got it wrong.  If you’ve hit 30, it’s time to think very hard about whether or not you want to have kids.  If you’re not currently with someone with whom you can envisage having children, you should be thinking very hard indeed.  Even if you spent most of your twenties trying not to have a child, you might discover that it takes much longer than you’d expect (and with every passing year, your chances of successful conception go down as well).  Finally, it’s worth considering that there’s no evidence that having children earlier has any long-term impact on your career.  (Having children at all does, but by the age of 40 it won’t matter if you had them at 31 or 36.)

Having children is a big decision, and there are many things that can go wrong for them, including unprepared or absentee parents.  Still, I would encourage anyone who thinks they’ll have children “one day” to think seriously about changing “one day” to “soon” or “next year” (for more reasons than just this one).  My baby girl will be born in July, and there is a 100% chance I will love her completely.

*I’m not sure if different trisomy conditions exclude the possibility of another occurring, but it doesn’t make much of a difference to the maths either way.

I’ve been spending more and more time thinking about how we over-engineer solutions and even libraries.  Currently my feeling is that NuGet and OpenWrap are only going to make this problem worse and not better.  The basic problem with buy versus build is that it’s posing the wrong choice.  Of course buy is cheaper than build.  But it’s like trying to chose between sparkling and still: the correct answer is tap.

A number of years ago I built a system that used Binsor for configuration.  Here were the benefits (to me):

• Concise syntax
• Programmable
• Environmental Deltas

Of these, the first is nice to have, but not essential, the second is vital but can be achieved with the fluent configuration API.  It was only the third that Binsor offered that no other solution had.

Here were the costs:

• Utterly undocumented.  Figuring out how to use a new facility was an exercise in hitting Google until it worked.
• No-one else could understand it other than me.
• It prevented me from using Windsor features it didn’t support.
• The build and upgrade story was an absolute nightmare.

It took someone else to point out that, actually, Binsor was horribly over-engineered for what I actually needed.  Once I’d twigged to this, I realized that it was actually perfectly possible to knock together an alternative.  One that I could easily use to migrate away from Binsor while keeping the features I needed.  I did it in Ruby because, well, I like Ruby.  And I called it Dusty because I used to watch Ted Rogers when I was a kid.

Technical Details

So, it’s now up as a gist.  It’s in three parts.  The main part, dusty.rb is the main code and an example of how to configure it.  The examples are taken from real live running code, but are incomplete.  The delta file is a full valid environmental delta file.  The dusty.cs file just gives the two functions you need to call it.

Ideally, you wouldn’t even need IronRuby for this.  However, it does make the configuration syntax nicer at the cost of some initial setup.  The configuration syntax, as you can see, is deliberately close to Binsor’s, precisely because I was using it to enable a migration away from Binsor.

You’ll note that the only reuse method this supports is Joe Walnes’ favourite technique.  If you need the container, you can just access it directly.  If you need a new feature, just change the code.  And if you don’t need it, don’t use it.

I’m sure most people coming to node.js immediately go looking for the equivalent of gems.  They’ll soon find npm and discover that it does exactly what they expected (with a couple of tweaks along the way to avoid running absolutely everything as root).  However, the chances are, there’s a simpler alternative they haven’t considered yet.

If you’re a C# developer, you should be familiar with the term “DLL hell”.  It’s important to understand that gems do, in fact, suffer from versioning issues.  They don’t bug out at the first sign of trouble like .NET assemblies do, but any centralized repository can and does suffer from this problem.  Ruby Gems does have a way of addressing this, but it doesn’t work because people don’t use it.  To think of this another way, when was the last time you recommended an assembly be put in the GAC?

What’s worse, you probably haven’t figured out yet how you’re going to get your code deployed to live.  I suggest you do so now rather than waiting for the inevitable surprise.

How Require Works

First, we need to understand how “require” actually works.  Require works through the search path, which includes anything in the environment variable “NODE_PATH”.  It will match the following:

• anything with that exact path name
• anything with that path name plus “.js”
• anything with that path name plus “/index.js”
• a native extension

99% of the time you’re looking at one of the first three.  Once require has found the correct file, it runs the file and populates the variable “exports” (aka module.exports), which is the return value of “require”.

The last is a bit more complex. 

What NPM does

Now, NPM by definition can do what it likes, up to and including deleting everything on your hard drive.  But what do most packages actually do?  Well, typically they create an index.js file and download the files.  There’s complex packages like expresso that are more work, but 99% of the time they’re doing very little at all.

So, instead of installing an npm module and messing around with a global repository, why not keep it simple and download the code yourself?  You just type “git submodule add https://github.com/brianc/node-postgres.git” and “require ‘./node-postgres/lib’ (assuming you’ve got your NODE_PATH set correctly).  This is just as easy as using NPM in the vast majority of cases (quite a few projects actually include an index.js file in the root of their repository to make this even simpler).  You can now do the following:

• Keep an exact version of the package that works versioned with your main repository.
• Switch between released versions easily
• Maintain a branch with quick fixes to bugs you find (this will happen more often than you’d hope)
• Deploy easily

This is incredibly easy to do providing the NPM package isn’t complex, which 99% of them aren’t.  Native extensions are more tricky to do this way because you need to automate their build system.  However the benefits are just as great.

If you’re starting a database project, one of the first things you need is the ability to recreate and upgrade the database.  Tarantino has features to do this in the .NET world, but I just needed something quick and dirty.  You can also use this code as an introduction to Brian Carlson’s Node Progres library (connection pooling coming soon…).  Note that, in common with most Node projects, it’s almost impossible to get work done without underscore.js and async.js.

# pg = require 'postgres-js/lib/postgres-pure'
pg = require './node-postgres/lib'
eyes = require 'eyes'
_ = require './underscore'
async = require './async'
fs = require 'fs'

process.on 'uncaughtException', (d) ->
  if d.stack?
    console.log "Message #{d.message}"
    console.log d.stack
  else
    eyes.inspect d

getConnection = (d) ->
  conn = new pg.Client d
  conn.connect()

  conn.on 'error', (err) ->
    eyes.inspect err

  _.extend conn,
    execute : (text, c) ->
      q = @query2 text, c
      q.on 'end', c
    singleValue : (text, c) ->
      q = @query2 text, c
      q.once 'row', (r) ->
        for k,v of r
          c null, v
          q.removeAllListeners 'end'
          return
      q.on 'end', c
    query2 : (text, c) ->
      console.log "Executingn#{text}"
      q = @query text
      q.on 'error', c
      q
   conn

conn = getConnection
  database : 'db_name'
  user : 'postgres'
  password : 'password'

getId = (f) ->
  m = /d+/.exec f
  return 0 if m == null
  parseInt m[0]

passErrorsUp = (c) -> (e) ->
  if e != null
    c e

async.waterfall [
    (c) ->
      @foundSchemaVersion = false
      q = conn.query2 "select tablename from pg_tables;", c
      q.on 'row', (r) =>
        @foundSchemaVersion ||= 'schema_version' == r.tablename
      q.on 'end', => c null, @foundSchemaVersion
    (d, c) ->
      console.log "Found table: #{foundSchemaVersion}"
      if d
        c()
      else
        conn.execute "create table schema_version ( version integer );", c
    (c) -> conn.singleValue "select version from schema_version", c
    (d, c) ->
      if d == null
        conn.execute "insert into schema_version values (0);", -> c null, 0
      else
        c null, d
    (v, c) ->
      console.log "Current Version #{v}"
      fs.readdir './sql', (e, d) -> c e, v, d
    (v, files, c) ->
      files = (_ files).chain()
        .select((f) -> v < getId f)
        .sortBy(getId)
        .value()
      if files.length == 0
        console.log "No files to read!"
        c()
      else
        commands = _.flatten _.map files, (f) -> [
          (c) -> fs.readFile "sql/#{f}", 'utf8', c
          (text, c) ->
            console.log "Read file #{f}"
            text = "#{text};update schema_version set version = #{getId f};"
            conn.execute text, c
          (d, c) ->
            console.log "Executed file #{f}"
            c()
        ]
        async.waterfall commands, passErrorsUp c
], (e) ->
  if e == null || !e?
    process.exit 0
  else
    eyes.inspect e
    process.exit 1

Some notes for Node newbies like me:

• It’s really important to ensure that the callback (c) gets called exactly once for every step in an async waterfall.  This is particularly messy when you kick off a waterfall within the other waterfall.
• The node_postgres API missed some convenience functions I’m used to.  So I added them.  This is JavaScript, after all.

I’ve just been getting started with database access with node, and I’ll save you some time.  There are three competing node Progres libraries at the moment, and the right one is the one you’ll probably try third.  I appreciate that “right” is something of a strong statement, but it’s completely justified in context.

First up, we have postgres-js.  This is by the incredibly talented Tim Caswell aka creationix.  It’s a pure js library, which is a good thing, but it’s missing a couple of things: an example of how to make it work, and a test suite.  The former isn’t as big a problem as the latter, because sadly it doesn’t work.  Relatively simple queries will break as it tries to parse the response stream.  To be honest, I seriously doubt this is much of a focus for him, its last update was in August.

So, how about one by Ryan Dahl himself?  Postgres_Node (note the underscore) tries a different approach and goes to the C-level Postgres API.  Thinking about it, you’d kind of expect this from the guy who wrote node in the first place.  However, it’s in my opinion needlessly complex to do it this way, and although it does have a (short) test suite, I rapidly found myself breaking it badly.  It’s got a great big sign on the front page saying it’s experimental.  He means it.

Finally, Brian Carlson has written Postgres-Node (note the dash).  This is inspired by Tim Caswell’s take, but has an extensive test suite.  It even has (occasionally confusing) documentation.  Even better, it’s the only one that actually allows you to stream results.  To date, I haven’t managed to break it at all.  I highly recommend using this one.