Hello there! My name is Rob Eisenberg.

 

With your kind permission, I’d like to take this opportunity to introduce myself and my work to you.

 

A Brief History of Me

I got my start when I was nine years old. I remember going to Sears with my dad to buy our first computer: a Commodore 64. Almost immediately I was awed and fascinated by it. I needed to know how those pixels moved around on screen, so I bought a book on Commodore Basic, and thus began my programming adventure. When we got our 286, I dove into QBasic, all along hearing about some really powerful language called C. Eventually I picked up C and then C++. One interesting memory I have is teaching my high school CS class how to program a doubly linked list in C++. Ah … those were the days …

 

After high school, I took a break from all that to pursue my other great life interest: Music. I attended Florida State University where I obtained two music degrees, a B.M. in Music Composition and a B.M. in Music Theory. (My principle instrument was Percussion, in case you were curios). I stayed on at FSU to work on a Master’s in Music Composition and study jazz drumming, but for various reasons decided that wasn’t the place for me.

 

After that, I thought I would try to combine my love of computers with my musical training by attempting to jump into the video game music industry. It was a spectacular failure. That’s one industry that’s about knowing the right people and being in the right place … and I didn’t have either. However, while attending the GDC, I picked up a couple of programming books …

 

.NET

Sometime in early 2003 I bought my first C# book … on a whim. The world of programming had certainly changed since my last experiences with C and Win32. I still had Borland’s OWL on my brain … remember that? Well, looking at the .NET framework for the first time … was really exciting. I liked what I saw and so I dove in deep.

 

My initial experiences with .NET were doing WinForms development, but my first job was 100% WebForms. I worked on that project for two years before starting my own company. We did a lot of ASP.NET consulting in the beginning and some Monorail consulting as well. When “Avalon” first appeared, I started spending lots of my spare time learning its ins and outs. It was new, cool and the most versatile app platform I had seen yet. Despite the raw power of WPF and the following XAML technologies, it still lacked a structure and consistent development strategy that seemed to be common in almost all web stacks. Enter Caliburn and Caliburn.Micro …

 

Open Source

Because my experimentation with Avalon overlapped my “paying gig” developing with Monorail (and later ASP.NET MVC), I began to try to imagine what it would look like to take the structured approach of modern web programming and apply it to XAML development. In other words: could MVVM for desktop apps be as simple as MVC for web apps? I believed it could, so I started putting together a framework which eventually became known as Caliburn.

 

Caliburn was my first crack at this problem and it ended up being fairly large and complex, which wasn’t very inviting for the average developer. But, I still believed that some of the core ideas we had come up with could greatly improve developer workflow and experience. As a result, I put together a small 500LOC mini-framework, which I presented at the Mix conference in 2010. The presentation received surprisingly high praise and several companies and prominent individuals in the community “strongly encouraged” me to take the sample I built for the talk and turn it into an open source project.

 

Caliburn.Micro

I coded up the first version of Caliburn.Micro in about two weeks’ time as a favor for a local company that needed it for an upcoming gig. I started with my Mix sample code and gradually matured the implementation so that it would work for general application development. Since its release to CodePlex, Caliburn.Micro has become one of the most popular frameworks for building XAML-based applications. It’s been used by the biggest of the big companies and the smallest of the small alike. But, what is it exactly?

 

As I mentioned earlier, my original goal was to try to bring the structure of modern MVC development to the XAML, MVVM world. To do that Caliburn.Micro embraces three core concepts:

 

Actions

Actions, inspired by Ruby on Rails/Monorail/MVC actions, are simple methods on a ViewModel that are executed in response to a user’s “action”. One of the painful parts of MVVM was having to create all those delegate commands just to connect a button click to a ViewModel method … or being able to use lots of databinding, but still having to resort to code behind because you needed to wire some event to call into your ViewModel. Actions were designed to eliminate that tedium by allowing you to wire any event (actually any trigger) to the execution of a ViewModel method directly. But it goes beyond that. Actions in Caliburn.Micro can also take parameters, pulled from the view and they can be used to easily write elegant asynchronous code via the magic of Coroutines.

 

Conventions

Most modern MVC frameworks leverage conventions to simplify development, so I looked to see how the XAML world could benefit from that. What I discovered is that there was a common naming convention developers seemed to use already. If they had a ViewModel (VM) called CustomerViewModel they would almost always have a View called CustomerView. Frequently developers kept all the VMs in a ViewModels namespace and their Views in a Views namespace or they organized their applications by feature. Regardless, even though they were already using naming conventions, they were still wasting time manually hooking all these pieces together. So, it seemed that the most obvious path was to have Caliburn.Micro do that work instead … and it does. It automatically inspects ViewModel types, locates the appropriate view, binds it to its ViewModel and displays in on the screen. Of course it’s completely customizable.

 

We didn’t stop with the auto lookup and connection of views. We realized there was more tedium to be removed from this process. So we enabled Actions to be wired by convention. This means that if your View has a Button named Save and your ViewModel has a method named Save, we create the Action for you: simple and clean. We took it one step further though. We enabled the same functionality for databinding. Just name any control the same as a property on your ViewModel and we’ll automatically create the binding expression for you, intelligently detecting the binding mode, validation settings, converters, etc. It’s a lot less typing … believe me.

 

Composition

The final core area to Caliburn.Micro is composition. This is the notion that complex apps, screens, etc. should be easy to decompose into small, focused, manageable pieces. The framework should provide a simple way to connect all those small pieces into a functioning whole at runtime. To do this we started by enabling Inversion of Control (IoC) in the core of the framework and by allowing nearly every aspect of the framework to be customizable via simple function composition. Then, we built a set of base classes for ViewModels that enable simple modeling of different UI patterns. Naturally, this set of objects is composable. Finally, we provided services for loosely coupled communication via our EventAggregator and a common mechanism for displaying UI in different physical and logical contexts.

 

IdeaBlade

Since building Caliburn and Caliburn.Micro, I’ve had the opportunity to work on many interesting projects … everything from Line of Business apps (LOBs) to developer tools, designer tools, call center apps, DSL and modeling tools, consumer facing products, etc. I’ve continued to take my experiences and those of the developers I’ve interacted with and use them to improve on Caliburn.Micro. It’s certainly been an adventure. Hopefully you’ve had an opportunity to reap the benefits yourself.

 

Towards the end of last year I began discussions with IdeaBlade around the topic of a new vision for improved developer experience in building LOB applications. They really believed in the ideas behind Caliburn.Micro and wanted to embrace the framework in their expanded initiative to simplify LOB development. They had been working on Cocktail, a framework that seamlessly integrates Caliburn.Micro with their existing DevForce product, and wanted me to join them in their effort. I took a look and liked what I saw and the opportunities and ideas we shared. Since then, I’ve been working behind the scenes here putting together pieces of the Cocktail family, prepping something you haven’t seen before … something that’s going to change the way you build LOBs … oops … that’s a secret.