I gave my Exploring C# DSLs: LINQ, Fluent Interfaces and Expression Trees talk today at Miracle Open World 2012 about C# Domain Specific Languages.

The slides are now available here.

… and the demo source is available as a git repository on bitbucket here.

Note that some of the source is just mocked implementation, the goal was not really to show production level quality – but rather concepts. The quality of the few tests and commit messages reflect this.

After going through the pain of (re-)discovering how to convert a Mercurial repository into a Git repository on Windows, I thought I’d share how easy it really is. I’ve bounced back and forth between Mercurial and Git a few times – my current preference is Git, mainly because I like Git’s branching strategy a bit better – but really, they’re both excellent choices. I still find the best analogy for comparing them is that Git is MacGyver and Mercurial is James Bond.

You can find quite a few posts describing how to convert – but many of the steps mentioned in those guides are not needed if you have TortoiseHg installed, which most Windows Mercurial users do.

Prerequisites

As I already mentioned, this guide expects that you have TortoiseHg installed on your system.

For the actual conversion, we’re going to be using a Mercurial extension called hggit that enables Mercurial to push and pull from Git repositories. You can either clone the hggit repository on GitHub or grab a zipped version here.

What we need is the hggit folder from the clone or zip file – put this some place handy and remember the path.

Preparing the Git repository

In this guide we’re going to be pushing our repository to a local Git repository – so let’s create a bare repository – this way you’ll avoid Git complains about pushing to a non-bare repository.

Open a command prompt, create a directory for the new repository and from within the directory execute: git init –bare

That’s it – our Git repository is ready. Alternatively you could push directly to a Git repository on either GitHub, Bitbucket or other provider.

Enabling hggit in Mercurial

Now we need to let Mercurial know about the hggit extension. This is done by adding it to the .hgrc or mercurial.ini file in your home directory (for me that’d be c:\users\rasmuskl\mercurial.ini).

In the config file, find the [extensions] section – or add it at bottom if it’s not already there. Then add a reference to the hggit extension followed by the path of the hggit folder:

hggit = c:\path\to\hggit

Converting the repository

To convert the repository, simply open your command prompt, navigate to your Mercurial repository and do: hg push c:\path\to\bare\git\repository

And you’re done. You can now either clone the bare repository to a working directory – or push it to your GitHub or Bitbucket account.

Mogens Heller Grabe wrote a nice post about reducing the amount of clutter in your Visual Studio the other day – and I thought I’d chime in with a few tips.

Hiding the Navigation bar

First up we have the navigation bar – which is taking up a line of your precious screen estate.

To remove it, jump to:

Tools –> Options –> Text Editor –> All Languages

Uncheck ‘Navigation bar’. For extra bonus points, check ‘Line numbers’.

Bringing back the Configuration Manager

The following tip I got from Rasmus Wulff Jensen when I mentioned that the only thing I really like from the standard Visual Studio toolbars is the ‘Configuration Manager’ drop down that allows me to switch between Debug and Release builds. He showed me a neat trick to put it in the top toolbar.

Right click on the tool bar to bring up the tool bar selection.

Choose ‘Customize’. Change the tab to ‘Commands’ and move focus to the bottom of the list, like so:

The hit the ‘Add Command’ button and go to the ‘Build’ category. Scrolling to the bottom, you will find a command labeled ‘Solution Configurations’. Pick it.

You now have an inline configuration manager on your top toolbar without taking up extra space. Same trick can be applied to any other commands.

Docking the Find dialog box

The ‘Find and Replace’ dialog is probably one of the most used dialogs in Visual Studio – however with the default settings, you get a floating dialog that doesn’t seem to want to go away after you’re done using it.

If you dock it – like so:

… and unpin it, it will behave nicely and disappear when you’re done searching or press ESC.

Switch to a dark theme

This is more a matter of taste. Personally I’ve been using dark themes for Visual Studio forever. My eyes feel way more relaxed after a day of using a dark theme. My theory is that since computer monitors use additive colors (with white being a full blast mix of red, green and blue and black being no light), a dark theme simply emits way less light.

If you want, you can download my personal theme here (ReSharper specific). It’s the same as I’ve previously posted, except I’ve adjusted it to work properly with Razor views too.

Working with code is tricky business – the larger and more complex the code base, the more tricky. Ingraining micro-processes into your work day can help fix some of the issues, some of the broken windows that grow into almost any code base over time. Peer reviews is a great starting point.

There are many forms of peer review – but this post is mainly about informal check-in reviews. The process is simple: Any commit to the code repository must be signed off by another member of the team. Many argue that small commits are okay to go unchecked – but the size of a “small commit” grows in my experience. My counterargument is that a small commit will only take 30 seconds or less. Simply bring up the change set, go over the changes, discuss anything needed informally, then add “Review: <initials>” to the commit message and fire away.

Benefits?

One of the first things you’ll notice when you introduce peer reviews is catching common commit mistakes. These include small changes in files made while testing or debugging that were not meant to be committed, files that were not related to the current commit and, if your reviewer is alert, files missing from the commit.

Another small side effect is a subconscious increase in code quality. Knowing that someone else will review your code closely will increase the mental barrier to introducing hacks and other peculiarities that sometimes sneak into code.

While many developers focus more on writing self-documenting, readable code, getting another pair of eyes on the code is great for clarifying the intent of the code – uncovering small scale refactorings such as renames and extractions. The earlier you uncover and discuss minor design issues like these and further aligning team coding styles, the better shape the code base is likely to end up. Aligning coding styles across multiple teams is a hard task, any improvement is worth taking. Once in a while a peer review will uncover larger design issues and ultimately lead to discarding the code under review and going for a different solution. This is not always a pleasant experience, but it’s easier to kill your darlings when nudged in the right direction by a colleague.

In line with the last paragraph, reviews also often spur discussions about larger things like domain concepts and architecture – it just seems to come up more when looking at concrete issues in the code base. Likewise, the reviewer is investing some of this time in the code and putting his name on it, thus increasing shared code ownership of the code.

Lastly, just seeing how other developers work can give insight in other developers IDE and tool tricks. Being a keyboard-junkie myself, I often find myself exchanging IDE / productivity tips during reviews.

Conclusion

Information code reviews are, in my opinion, one of the cheaper ways to directly affect code quality – assuming it’s taken seriously of course. You might notice that many of these benefits are the same as with pair programming – and they are. Pair programming is usually harder to get started on and not suited for all assignments, although most teams ought to do way more pair programming than they are. Peer review is broadly applicable. Try it with your team for a week or a month – if I’m wrong and nothing improves, I’ll buy you a beer next time we meet :-)

Your backup is only as good as your last restore. I recently changed my backup strategy on my SQL Server 2008 from doing a full nightly backup to doing incremental nightly backups and only a full backup each week. SQL Server incremental backups base themselves on the last full backup. This is nice when you go to restore them since you will only need the full backup + the incremental backup, not any intermediary backups.

However, a few days back I wanted to check some queries on a larger dataset and decided to check my backups at the same time. Fetched full + incremental backups from the server and started the local restore:

RESTORE DATABASE [testdb] 
FROM DISK = N'C:\temp\full.wbak' 
WITH FILE = 1, NORECOVERY, REPLACE

RESTORE DATABASE [testdb] 
FROM DISK = N'C:\temp\incremental.bak' 
WITH FILE = 1, RECOVERY

The first backup went through fine, but restoring the incremental backup resulted in the following error message:

This differential backup cannot be restored because the database has not been restored to the correct earlier state.

SQL Server refused to restore my incremental database – this is only supposed to happen if there has been another full backup in between. I double checked the backups I had fetched, checked that I had the set up the new backups correctly and that the old backup job was gone. Everything seemed fine.

I then explored the backup history a bit further with a query adjusted from the one found in this post:

SELECT TOP 10
s.database_name,
m.physical_device_name,
s.backup_start_date
FROM msdb.dbo.backupset s
INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id
WHERE s.database_name = DB_NAME() -- Remove this line for all the database
ORDER BY backup_start_date DESC

The result showed that there had indeed been backups in between my nightly runs:

Further research revealed that backup devices with a GUID name are virtual backup devices and the times of backups matched the daily schedule of our bare metal system backup. Turns out that R1Soft's backup software integrates with SQL Server’s VSS writer service to perform backups when it finds databases on disk.

Disabling the VSS writer service returned the backups to a working state (VSS backup + my own incremental would also have worked). I did consider skipping my own nightly backups (since the VSS backup is super fast) and just using the R1Soft one, but decided against it for now – my own management is already set up and if I do need to restore, grabbing the backup from the external backup is much slower and more tedious than having it on disk already.

Working with NHibernate, you will eventually have to know something about flushing. Flushing is the process of persisting the current session changes to the database. In this post, I will explain how flushing works in NHibernate, which options you have and what the benefits and disadvantages are.

As you work with the NHibernate session, loading existing entities and attaching new entities, NHibernate will keep track of the objects that are associated with current session. When a flush is triggered, NHibernate will perform dirty checking; inspect the list of attached entities to determine what needs to be saved and which SQL statements are required to persist the changes.

NHibernate offers several different flush modes that determine when a flush is triggered. The flush mode can be set using a property on the session (usually when opening the session).

Out of the box NHibernate defaults to FlushMode.Auto which is a flush mode that offers a minimum of surprises while providing decent performance. Auto will flush changes to the database when a manual flush is performed (using ISession.Flush()), when a transaction is committed and when NHibernate deems that an auto flush is necessary to serve up-to-date results in response to queries. While the auto flush is convenient, it does cause a few disadvantages as well. To determine whether an auto flush is required before executing a query NHibernate has to inspect the entities attached to the session. This is clearly a performance overhead and unfortunately as application complexity (and thus likely session length, number of queries and number of attached entities) increases, the cost will be in the ballpark of O(q*e) – quadratic growth based on number of queries and entities. Furthermore auto flushes are not always easy to predict, especially in complex systems – this can lead to unexpected exceptions if using things like NHibernates merge and replicate features (a blog post all by itself).

A better solution for bigger applications is FlushMode.Commit, this flush mode will flush on manual flushes and when transactions are committed. Avoiding auto flushes provides quite a few performance opportunities, it will potentially require fewer SQL statements (multiple changes to the same data), it will cause fewer round trips to the database and thus enable better batching. What you need to understand before changing your flush mode to FlushMode.Commit is that your queries may return stale results until you commit transactions. However, this is generally what people expect when working with transactions, so it is usually not a problem. In some cases, you might have to perform a manual flush, but it makes sense to reduce the number of these (since they defeat the benefit of the flush mode).

NHibernate offers two more (usable) flush modes. FlushMode.Always will trigger a flush before every query and is thus generally not useful except for maybe some special edge cases. FlushMode.Never will cause the session to only flush when manually flushing – this can be useful to create a read-only session (better performance and more assurance that no flushes are performed). For read-only / bulk needs, it’s also practical to look into IStatelessSession (low memory / performant for bulk operations) and ReadOnly on queries and criterias introduced in NHibernate 3.1.

I demoed a small app today at the Demo Dag session at Community Day.

The app was developed at an ANUG Code Dojo - and the purpose is simply to create timers that are a few pixels high either at the bottom or top of your screen - to be used for running Pomodoros or other timing needs - like an informal timer for a presentation.

I got a few requests for the app, so I've uploaded the source to Bitbucket here (there's also a v. 0.1 zip file with an executable - if you don't want to build from source). 

Bear in mind that this app was hacked together in a few hours (with the purpose of learning WPF actually - we got sidetracked) - so don't expect quality code or an excellent polished app. It has quirks - you have been warned :-)

Enjoy.

I spoke last week about ReSharper 5 at ANUG’s Visual Studio 2010 launch event.

Here are the slides from my presentation. The slides are in danish and probably won’t make too much sense as most of my presentation was done demoing stuff – but they should give the gist of it.

Slides

If you have any questions on my presentation, feel free to shoot me a mail here on the blog :-)

I have been using black background in Visual Studio for as long I can remember. I started out using Rob Conery’s black / orange TextMate theme, but last year I created my own black theme with a blueish style. Today at the ANUG code dojo we tweaked it to actually look alright with the changes in Visual Studio and especially ReSharper.

You can download the theme here if you want a nice black theme.

It looks like this:

Selection:

Subtle highlights of active identifier:

Enjoy :-)

Last week I gave two talks at MOW2010. Was an awesome conference and the 80% talks + 80% networking concept really held true. Hope to be going again next year – as speaker or otherwise. Here is the slides from my two talks.

Increasing productivity with ReSharper

This talk is about optimizing the mechanical part of your work. See how a keyboard-centric focus can speed
up your work and how to navigate codebases easily independent of size. Visual Studio 2010 has introduced more
advanced keyboard features, but ReSharper is still king, so it will be the main focus of the talk. While this
session will contain a lot of fast-paced flashy keyboard shortcuts, it will also contain basic techniques and
advice for you to get started with your own keyboard.

Slides

Practical ASP.NET MVC 2

ASP.NET MVC is the new kid on the Microsoft block. This talk will give you a short introduction to the framework
and the new features in ASP.NET MVC 2. After the introduction, we will dig into some practical experiences and
common situations of actually implementing a system using ASP.NET MVC. Detours will include other alternative
open-source web frameworks and maybe even some JavaScript.

Slides