Look alive. Here comes a buzzard.

I’ve been having a lot of fun recently learning about and playing with RavenDb.  It’s a great document database solution for .NET.  The thing that immediately blew me away is how little friction there is getting up and going.  I am writing simple POCO objects and persisting them without having to deal with ORM mapping and other headaches.

However, there are a lot of naysayers out there spreading FUD about document databases.  Why would you need to move away from a relational model that enforces relationship constraints, allows for joins, and supports advanced querying and reporting??

Now, it’s perfectly valid to point those issues out.  If you are thinking of moving to a document database you need to know what you are sacrificing.  BUT – let’s talk about the benefits for just a moment.

Document databases tend to be a closer map to your domain model than relational databases.

Consider the scenario of persisting a customer:

public class Customer {
  public string Name { get; set; }
  public Address ShippingAddress { get; set; }
  public Address BillingAddress { get; set; }
}

In a relational model you will likely have a Customers table and a CustomerAddresses table with references between the two for the addresses. In the DB you will need to make sure the foreign keys are set up correctly and you will probably want deletes from the Customers table to cascade to the CustomerAddresses table. Then you will probably want to use an ORM like NHibernate to map those tables to the customer entity itself.

Think about that for a moment – how much work did we just have to do just to persist a simple customer?? And the reason we had to do that work is because we have to transform our data from the format WE want it in – the domain model – to a format that our relational database understands – tables and columns. That transformation takes real effort and thought. And it continually bites us in the ass with select n+1 scenarios.

I think if we step back for a moment and forget all our history with relational databases and really look at the problems we are trying to solve, it will be easier to choose the best solution for our system. Just because we’ve been building applications with relational databases for the past 20+ years doesn’t mean it’s the only way – or even the best way to go.

Sure with a document database we lose some of the relational power that something like SQL provides. But I believe the gains in many systems could overshadow those losses. And if we are designing our documents well then we won’t need as many relationships as we might have needed in a relational model.

I’ve been playing with FubuMVC for about a week for a new project I’m working on (more to come on that soon).  So far I really like it, but it’s definitely not for everyone.  I thought I would start blogging about some of my experiences learning the framework.

There will probably be a few things I’m wrong about or don’t understand because I’m still new to FubuMVC.  But I want to capture my thoughts and impressions as somebody just starting out to help others who may be in a similar situation, or are evaluating the framework for their own projects.

Good: Conventions Everywhere

I think this is where FubuMVC really shines.  If you can define the conventions for your application up front then FubuMVC is going to save you a lot of time.  For example, FubuMVC lets you define an HTTP Method convention which can automatically apply to all of your controller actions.  You could define this convention based on method name (e.g. all Create, Update, or Delete methods only accept POST), input model type, or just about anything you want.

Here’s a snippet of code from my current application. It specifies that all controller methods which accept an input model ending with “Command” require the POST HTTP method.

This is a bit like Aspect Oriented Programming in that you can define cross-cutting rules which are defined once and applied everywhere by the framework.

Routing/URL Conventions
I really love the way routing/URL conventions are defined in FubuMVC. When working in ASP.NET MVC I find myself hard-coding a lot of routes to get them looking how I want. Defining routes in Fubu is quite a bit different from ASP.NET MVC, but I was able to configure my routing very quickly. FubuMVC also has a really nice diagnostics application that lets you see all routes you have defined for the entire application.

HTML Conventions
I haven’t dug into the HTML conventions yet but on the surface they seem very powerful. For example, you can define a convention where CSS classes are automatically added to lists for even/odd items. This is the kind of thing that should make it easy to apply cross-application UI changes easily.

In practice I think this will be a bit like CSS where as long as you create consistent HTML, style sheet can save you a lot of time in layout and formatting.

Bad: Sooooo many Models!

Okay this one took some getting used to. FubuMVC uses a “One Model In, One Model Out” (OMIOMO) approach for controller actions. That means that each controller action can only accept one model as a parameter, and returns a single model back to the framework. In ASP.NET MVC you might have a controller action that takes one or more simple parameters and returns an ActionResult, but in Fubu you must encapsulate everything into models.

This is the kind of thing that will turn off a lot of potential users. It looks “enterprisey” and feels like overkill at first. I didn’t want to create a ton of view and input models for my controllers so I tried creating generic models that would be used by many actions. For example, I created an EntityRequest model which had a single Id property that I could pass into all of my View, Edit, and Delete controller actions.

This worked at first, but in the long run it made the UI code a lot harder and more complicated. Creating links or form targets in FubuMVC is really easy if you can just give it a model. Honestly I’m not even sure how to construct a link to a controller action method.

In the long run I decided to simply create models for my different types of actions. And although this is quite a bit different from classic ASP.NET MVC, I actually like it better. It lets me de-couple the UI from the back-end. The UI simply says “give me the link to some model” and Fubu gets to figure out what actually handles that model.

Good: Moving away from Controllers

Once I accepted the OMIOMO approach I decided to make another change and do away with my controllers. Instead I will be adopting a Command/Query approach with Handlers on the back end to handle each command or query. I like this because my handlers can be a bit more generic and not tied so much to the UI.

Now even if you don’t want to move away from a Controller model, I think the real power here is that FubuMVC will still work just fine even if you want to adopt a different architecture.

Bad: Limited support for other view engines

Unfortunately the choice of view engines is limited to ASP.NET Web Forms and Spark. That being said, the ASP.NET view engine is pretty close to standard ASP.NET MVC. But I’d really like support for Razor or NHaml. I’m sticking with ASP.NET for now and it’s not that bad.

Bad: Documentation is still sparse

This comes with any open source project to a certain extent. But FubuMVC is pretty lacking in documentation at the moment. The getting started guides will only take you so far. Once you start trying to build your own application you will likely hit the limits of what you can learn from the guides themselves.

Another thing that complicates things is that FubuMVC went through a reboot a while back so there are some blog entries out there that are out of date with the current version. Many of the ideas in those posts are still valid, but syntax is slightly different in many cases.

Ultimately I’ve relied heavily on the FubuMVC source itself to figure out how to do things. For anyone trying to build a non-trivial application with Fubu it’s probably a requirement.

Final Thoughts

Lastly I thought I would compare FubuMVC to other frameworks/approaches out there. In many ways FubuMVC can feel quite a bit heavier and more “enterprisey” than other frameworks. But I really think it depends on the type of application you are building and what point in the application lifecycle you are at.

When you are just starting out, FubuMVC can feel very heavy getting everything set up. If you are building a small application with little functionality, you are probably better off with WebMatrix or ASP.NET MVC. WebMatrix especially gets you up and running very very fast.

But as your application grows and becomes more complex, FubuMVC should actually start to feel lighter and more flexible than those other frameworks. I’ve had many experiences with ASP.NET MVC where a change in design requires you to touch many different controllers, views, etc. If you are following your conventions these kinds of changes should be much faster and lighter in FubuMVC. At least that’s my impression at this point.

Perhaps a good approach is to start with something super light like WebMatrix and get a fast prototype up and running. Once your application starts to take shape and you can better visualize your conventions it might make sense to jump over to FubuMVC for the final implementation.

So far I am really enjoying FubuMVC even with all of the ups and downs. I’ll keep blogging about my experience building a non-trivial application with Fubu.

I heard about Nu on the Herding Code podcast and was immediately interested.  Ruby Gems is a great way to distribute open source libraries and manage dependencies.  The .NET scene has been struggling with this issue for quite a while so it’s great to see somebody take on this issue.

Not only does Nu make it super simple to add existing libraries to your project, but it’s also a great resource for finding existing open source projects out there.

I just happened to be building a brand new system so I’ll go through the steps I took to get Nu up and running.

1. Installed Ruby for Windows using the latest Ruby Installer
2. Opened a command prompt and ran the following commands:
   
   c:\gem update --system
   c:\gem update
   c:\gem install activesupport
   c:\gem install nu

3. Next I navigated to a new project folder and typed the following commands to add NHibernate and FluentNHibernate:
   
nu install nhibernate
nu install fluentnhibernate


That’s it – super simple!

One of my biggest complaints about SharePoint 2007 is that as a developer, it is virtually impossible to employ professional development techniques when building SharePoint solutions.  I’m talking about source control, continuous integration, test driven development, etc.  Obviously you can use these techniques when it comes to custom web parts, event receivers, and other “code only” solutions, but when you’re talking about larger projects that include content types, SharePoint Designer workflows, custom lists, in addition to custom code, it simply isn’t practical to try and cram everything into source control.  It’s just too much effort.

From what I’ve seen so far, many of these issues will be resolved with SharePoint 2010 and Visual Studio 2010.  I’m looking forward to digging into a real project so I can find out where the “gotchas” are (and I’m sure there will be plenty), but so far I’m optimistic.  I am hopeful that as a developer, I will be able to bring professional development techniques to all areas of a SharePoint project.

In my opinion this is critical if Microsoft wants to make SharePoint a true application development platform.

It struck me the other day that the way I use source control is very similar to how I play video games – specifically, when and how I save my game.  I like to use source control as a safety net – it’s a way to keep track of a place I may need to return to.  It allows me to continue on with my work and not be worried if I go down a wrong path.  I can always revert and be right back where I started.

Taking this one step further, we might say that the quick save in a video game is like a commit in source control. Saving your game with a specific name is like creating a branch.

Let’s say I just finish taking out a whole horde of zombies (Left 4 Dead anticipation is infiltrating my blog).  I’ll probably do a quick-save to make sure I don’t have to re-play the same encounter again.  This is just like committing some code you just finished.  You’re saving your current progress to make sure you don’t have to re-write the same code twice.

Now, back to my game, what if I come to a fork in the road.  I can go left through the ominous looking sewer, or I can go right through the abandoned city.  Well at this point I’ll go and save my game with some sort of name like “Taking the sewer”.  That way I can continue playing, quick-saving as I go, but I can always get back to that fork if it turns out I made a mistake.

This is very similar to creating a branch in source control. You want to start working on something new, or something experimental, and you need to be able to save your progress as you go, but you always may need to go back to that original point.

I find that many developers wait too long to commit their changes.  The more frequently you commit, and the more organized you are about it, the less you have to worry about keeping track of every change you make.  This means you have left cruft floating around in your mind to remember and you can concentrate on writing good code.  I think if developers think about source control the same way they think about saving their game progress, it would help them get into the habit of committing frequently and branching appropriately.

I wrote a small introduction to SharePoint scripting with Python a while back and this weekend I didn’t have anything better to do (well actually I did, but I’m an addict – what can I say) so I decided to expand on it.  I’ve started putting together a small Python library for working with SharePoint using IronPython.  It’s called – amazingly – sp.py.

So far the library if pretty small – although it does include a nice little module for workign with stsadm commands.  I’ll be adding to it as necessary.  I’ve decided that although adding custom stsadm extensions is nice and does fit into the “way to do things in SharePoint”, it’s just too much overhead when you want to do something simple.  So at this point when things come up that need automation, I’ll be adding new sp.py scripts.

In addition to the sp.py library I’ve added three scripts:

• applytheme.py – apply a theme to all webs in a web application
• backupsites.py – backup all site collections in a web application
• setprofileprop.py – set a property on all user profiles based on a dynamic pattern

So where can you get this awesomeness?  Well, actually you can get it on github.  Github???  You mean that totally web 2.0 site for hosting Git repositories?  Yeah – that’s the place.  If you’re wondering why I’m using git for source control, well I guess Subversion just wasn’t “edge” enough anymore.  Git’s actually pretty cool – and if you need to use Windows you can download a Windows version here.

At some point I’ll figure out how to post it as a zip or something instead of a tarball.  But until that point, you can grab the tarball here.

As a long time Microsoft developer who is in the progress of branching out and learning new things, I sometimes find it hard to give up certain features I’ve grown accustom to.  When it comes to writing code, one feature of Visual Studio I have learned to rely on is folding sections of code using #region and #endregion.  I find regions to be a great way to organize code around different subjects, activities, etc.  For me it’s a way to reduce the visual clutter and immediately jump to the section of code I need to work on.

On the Mac, TextMate does a great job of code folding based on syntax.  I’m doing a fair amount of work with Ruby these days and TextMate is an excellent tool.  Unfortunately for me however all folding is based on the syntax of the code, and not extra non-code markers like #region.  Luckily TextMate’s bundle system is completely extensible and customizable.  Folding is based on regular expressions so with a fairly simple change I was able to get #region folding in TextMate.

The first step is to figure out the regular expression.  The core regex for #region folding would be this:

^\s*\#region
^\s*\#endregion

Next open up TextMate’s Bundle editor, open the Ruby language, and locate  the foldingStartMarker and foldingStopMarker sections.  Below is the entire contents of my foldingStartMarker and foldingStopMarker sections.

foldingStartMarker = '(?x)^
(\s*+
(module|class|def
|unless|if
|case
|begin
|for|while|until
|(  "(\\.|[^"])*+"          # eat a double quoted string
| ''(\\.|[^''])*+''        # eat a single quoted string
|   [^#"'']                # eat all but comments and strings
)*
(                 \s   (do|begin|case)
| [-+=&|*/~%^<>~] \s*+ (if|unless)
)
)\b
(?! [^;]*+ ; .*? \bend\b )
|(  "(\\.|[^"])*+"              # eat a double quoted string
| ''(\\.|[^''])*+''            # eat a single quoted string
|   [^#"'']                    # eat all but comments and strings
)*
( \{ (?!  [^}]*+ \} )
| \[ (?! [^\]]*+ \] )
)
).*$
|   [#] .*? \(fold\) \s*+ $         # Sune’s special marker
|    ^\s*\#region
';
foldingStopMarker = '(?x)
(   (^|;) \s*+ end   \s*+ ([#].*)? $
|   ^     \s*+ [}\]] \s*+ ([#].*)? $
|   [#] .*? \(end\) \s*+ $    # Sune’s special marker
|   ^\s*\#endregion
)';

You can see where my two regular expressions were added near the end of each section.

Once you do that, close the editor, reload your bundles, and you’re good to go.

I’ve got good news and bad news. First the good news: as a manager, having motivated employees is completely within your control. It doesn’t matter how big your budget is, how many employees you have, or how high in the corporate food chain you are. It is absolutely within your power to have motivated and enthusiastic employees.

Now the bad news: having motivated employees is your responsibility – yours and yours alone. It’s not the responsibility of the HR department or some disconnected “Chief Culture Officer”. It is your responsibility. And it gets worse – if you want to motivate your employees, you have to mean it.

So, before you read any further you need to ask yourself a question: do you feel motivated? Do you want to motivate your employees? Do you want to motivate your employees because you want them to feel the same commitment and passion you do? Or because you want to squeeze a few more hours out of their already long work day?

Motivation is all about communication and vision. It’s about transferring your own motivation and drive to your employees. If you don’t believe in the vision, then no amount of “employee retreats” or “team building exercises” are going to make a difference.

So again, ask yourself if you really feel it. If you don’t, it might be a good idea to step aside so someone who is truly motivated can take the reins. On the other hand, if you are motivated and are looking for some tools to help you transfer that motivation to your team, please keep reading.

Still here? Okay well either you’re lying to yourself, you’re really bored and are reading anyway, or you really do feel enthusiastic and want to pass some of that along. Hopefully it’s the latter, but I’m not going to be picky.

I’ve broken this article into four parts:

1. Being Available
2. Empathize, to a point
3. Commitments
4. General conduct

Part 1 (Being Available) is ready to go now. The other 3 parts will be posted as my time allows.

Being Available
Or, how I learned to get up off my ass and walk around a lot

As I said up front, motivation has a lot to do with transferring your enthusiasm to your employees. But in order to do this effectively you have to be genuine about it. If you aren’t feeling it, you’ll end up doing more harm than good. Employees only need a few “fake” ra ra sessions to start seeing everything you do in that light. So the best thing to do if you aren’t feeling the enthusiasm is to do nothing. Doing nothing is much better than doing something in this case because that something is likely to cause damage that is very difficult to undo. Continue Reading »

It seems like every small software company out there has a blog these days. It’s become a requirement. In fact, most times these days the blog shows up before the actual product. But if you ask me, by and large it’s a waste of time. If you’re blogging in the hopes that it will attract potential customers or keep customers interested then you need to look long and hard at the kind of content you’re publishing.

Look, marketing is important – critically important to the success of your company. But if your blog is going to be a marketing tool, it’s got to be targeted at your potential customers. Your customers don’t care that you really liked some Joel on Software post. Your customers don’t care that you’re putting the finishing touches on some feature or that you contributed to some open source project over the weekend. Your customers want to read things they care about – not things you care about.

The key to a successful blog for a software company is one that truly provides value and connects with your customer base. If you are passionate about the subject of your software, then you have a good chance of writing a compelling blog which adds value on top of the software you sell. If you’re not that passionate, or if you suck at writing, a better approach would be to try and aggregate news articles or other industry/subject related blog postings.

At the end of the day, look at everything you do through the eyes of your customer. Is it valuable to them? If not, then you should stop and put that valuable time into something else.