blog.fossmo.net

Lately I have tried to learn NHibernate. NHibernate is a object-relational-mapper. It maps data from relational databases to POCO-objects. So, what is useful about that, you may ask? Well, for a starter, it’s very handy when creating a rich domain model. If you read this blog regularly, you may know that I’m also in the process of learning Domain Driven Design.

Domain Driven Design and NHibernate

The idea behind DDD is that you focus on the domain model instead of focusing on the database or GUI when trying to capture the business value from a domain expert. If you follow the guidelines described in the books written by gurus on the topic, you will end up with a domain model that is loosely coupled from the other parts of the system you are creating. That means you don’t have a coupling against the GUI, the database or any other parts of the system. But, you still need to persist the data from the domain model to the database in some way, and this is where NHibernate comes in to play. By setting up a mapping, described in a file, from the domain model to the database you can make NHibernate do the mapping for you. How cool is that? I guess you knew that already, but the purpose of this post is not to tell you how cool NHibernate is, but to guide you in the right direction of how to start learning NHibernate.

How I learned it

My first approach to learning NHibernate was to look at the excellent screen casts made by Stephen A. Bohlen called Summer of NHibernate. I learned a lot from watching these screen casts, but I still felt like something were missing. It’s like when you go to a conference, at the end of the day you can’t sit down in front of the PC and start to crank out code based on what you learn that day. But, it gives you a starting point. You often get information of how to investigate the topic further. This is what Summer of NHibernate did for me and it pointed me in the direction of a book called NHibernate in action.

Beside giving you a good start on setting up and using NHibernate, it also explains how to write real-world domain models. It tells you how to set up pretty complex associations between entities and why it’s important to understand why a domain model should be persistence ignorant and so on and so fourth. If you want to have a look at the index of the book, it can be found at this link.

If you want to learn NHibernate you definitely should look at this book.

Links

Links to NHibernate resources I have used and use:

- Summer of NHibernate (screen casts)
- Dimecasts.org have some screen casts on the topic (max 10 minutes long)
- NHibernate in action (excellent book on the topic)
- NHibernate.org (You can download the binaries from this site and you find documentation)

Happy learning!

Tags: ddd

I’m a big fan of Subversion and I love using TortoiseSVN. Many people prefer AnkSVN over TortoiseSVN because it integrates with Visual Studio, but I feel like I have more control over what’s happening when I’m using TortoiseSVN. Every time I set up a computer for development I have to add a ignore pattern to separate the files I want to check in from the ones I don’t want to check in.

This is my global ignore pattern:

*ReSharper* *.suo *resharper* *Debug* *Release* *.user *.bak

To add this pattern to TortoiseSVN follow these steps:

Right click in Explorer –> Choose TortoiseSVN –> Choose Settings –> Under ‘Global ignore pattern’ add the pattern.

 

Tags: subversion

I have read some books about development the last 15 years. Some I can't remember reading, but some of them have influenced how I develop  today. One of the books that pops up in my mind is Code Complete. This book really made me think of how I should develop applications. It touches on most of the subjects it's important to know about when developing; like how to debug effective, how to comment your code, how to write good loops etc.

Extreme programming
I remember working for an organization some years ago. We didn't have any senior developers working in the company, at least seniors doing development. This resulted in a lot of code that where, well lets say, not as good as it could have been. I remember spending a lot of time in the debugger. We didn't use any development metrology. I was sure we could get a lot of benefits from following one. So I started to look into the new and hot metrology at that time; Extreme programming. The book I started reading was Extreme programming Explained. I remember trying to get the other developers to follow the practices explained in this book and I think we managed to start doing a bit of test driven development. Not long after this I changed my job, but what I read in this book stuck with me. Today I'm completely test driven!

Best practices

When I started working in the company I'm currently working for I was recommended to read a book called Ship it! This is a book where the writer have collected best practices from years of development. It basically describes best practices when developing, and the environment around developing efficiently. A must read for a developer. After reading this book I was really inspired and wanted to read more books in the same category, so I started to read a book called The pragmatic programmer. If you still haven't read this book follow my link to Amazon and order it today. It's one of the most inspiring programming books a developer can read. The last year I have read some books. One of the favorite books are Clean Code. It's a good read, and I recommend it too. If I should compare it to an other book I have read, it must be Code Complete. Clean Code is a easier/faster read than Code Complete.

Ahh..I need to remember to mention a book that describes much of the practices I follow today; Code Leader. A great book written by Patrick Cauldwell. It describes things like how to set up a  continuous integration server. How to write your build script and how to structure your development tree.

Domain Driven Design

At the customer I work for at the moment, we use Domain Driven Development. I must say I'm a big fan of capturing the requirements using DDD. There are three books I have read/browsed through on this topic. They are Domain-Driven Design: Tackling Complexity in the Heart of Software written by Eric Evans. Applying Domain-Driven Design and Patterns: With Examples in C# and .NET written by Jimmy Nilsson and .NET Domain-Driven Design with C#: Problem - Design - Solution (Programmer to Programmer) written by Tim McCarthy. I recommend reading all of this books to really understand what DDD is. I first started reading Nilssons book, and it's a great book. It uses a lot of code examples, but he often refers to Evans book, so it's a good thing to also have this book at hand. Evans book is considered the bible for DDD. I think it's a bit vague on some areas but it's a must read if you want to learn DDD. The last book, written by Tim McCarthy, is the most concrete book on the topic, and I have used many of the ideas from this book to create the application for the client I'm currently working for. If you want to get an introduction to DDD, you should take a look at the free book called Domain Driven Design Quickly. It's a summary of Evans book and is hosted at InfoQ.

SCRUM

I have been practicing SCRUM for a while now. The book that got me up to speed in this area, is a free book by a Swedish guy called Henrik Kinberg. The book  is called Scrum from the trenches.

This post is a response to Gørans post; A software craftsman’s bookshelf. At the end of his  post he encourage other Norwegian developers to write about their recommendations when it comes to programming books. I picked up some good tips from his post and some of the other guys he linked to.

Do you have any book recommendations for me?

Tags: books

I held a lightning talk a on a seminar a while back about electronic storyboards being pacifying. I like to share it with you. It’s in Norwegian.

Elektroniske storyboard er passifiserende from Pål Fossmo on Vimeo.

Tags: presentation

At the next Norwegian .NET User Group meeting I’m going to talk about my experience with Domain Driven Design. I hope we can get a discussion around the topic after the talk. I’m really exited and looking forward to the meeting. Sign up for the meeting here.

Tags: nnug, ddd

These last months I have been learning Domain Driven Design. It’s often shorted to DDD. I have had plans to start looking into DDD for a while, but other things have always gotten in the way. I’m working as a consultant and some months ago I was assigned to a new customer, and they wanted to use DDD in their new project. Lucky for me :-)  Now I got the change to look into this DDD stuff and I must say that it will influence how I design my applications in the future.
I find this subject extremely exiting, so I have decided to write some posts about it. Some of the subjects I will cover is Ubiquitous language, Domain Model, Entities, Value objects, Services, Aggregates, Repositories, Factories, Bounded context to list some.

How to get started

I started out my DDD journey by reading some books:

Domain-Driven Design: Tackling Complexity in the Heart of Software. This book is written by Erik Evans. It’s considered the bible of DDD. I have heard people referring to it as “Lord of the rings” for developers because it uses so many references to references to references. You know; Legolas was the son of Thranduil, King of the Woodland Realm of Northern Mirkwood, son of … you get the picture? 
I use this book more as a reference, and I haven’t read it from page to page, but I have read a book which is a summary of Evans book; Domain Driven Design Quickly. It’s a good book and only a bit over 100 pages. It’s free and can be downloaded from InfoQ.

The book to blame for me learning DDD is written by Jimmy Nilssons and is called Applying Domain-Driven Design and Patterns: With Examples in C# and .NET. It’s a great book which is easy to read and he uses a lot of examples to explain the concepts in DDD. Nilsson uses TDD through the hole book to explain what DDD is. This makes it very easy from the reader to follow.

The last book I have looked into is a book written by Tim McCharty. It’s called .NET Domain-Driven Design with C#: Problem - Design - Solution (Programmer to Programmer). This book contains a lot of code. The code can be found at Codeplex. I got some hint on how to implement some of the patterns that DDD fronts from this book.

I you find videos and podcasts more easy to learn from, I can recommend listening to Alt.NET podcast show about DDD. Scott Hanselman also have a interview with Rob Conery where the topic is DDD. The last podcast I will recommend is one from Deep fried bytes. This is a conversation with David Laribee. 

If you want more links, you should go to this site. This guy have gathered some links to different DDD sources. You can also check my delicious bookmarks for updates to links.

Ubiquitous language and domain model

The first thing that pops into my mind when someone ask me about DDD is the domain model. That’s kind of obvious because we are talking about Domain Driven Design. DDD recommends that you start out by creating a domain model before you focus on anything else. Many developers would start out by focusing on the database when they create a application. This is not recommended by DDD. The reason for this is that you want to capture the domain in a model that the business person can understand. I’m referring to business person and domain expert in this post and I’m actually talking about the same person. The business person and domain expert is often the same person or at least, the business person is the product owner and should understand the domain model. You should sit down with the domain expert and try to create a shared language; the ubiquitous language. The reason for this is that you want a language that the business person and the developer understands. By doing this you will avoid many misunderstandings. What we did when starting to figure out the domain for the customer, was to get the domain experts to write down important concepts from the business we where trying to capture. We focused on using the same terms. They didn’t, for example, use the term order, but they used sale, so we called it sale in our domain model although it looked more like an order to me.  When we had talked about the terms and how the different parts of the application should fit together, we started to mold the domain. We also created some simple sketches of parts of the domain.

The nice thing with the domain model, from a developers perspective, is that the model is the code. You don’t try to model the domain with a strange notation or tool. The code is the model. The reason we can use the code as the model, is the ubiquitous language. You are capturing requirements in terms the domain experts understands. If the domain expert is a developer, this is even simpler.

I’ll try to keep these posts short and focus at one thing at a time, so I guess this is time to end this post. Next time I will explain what a entity and a value object is.

Tags: domain driven design

In the beginning of May I’m going to speak at a agile seminar in Trondheim. The topic for my talk is called “Electronic storyboards are pacifying!” and is based on a blog post I wrote some months ago. The seminar are arranged by Dataforeningen and XPmeetup. I’m looking forward to presenting my topic and the seminar.

Tags: presentation

I probably don’t need to tell you that you shouldn’t code without having a source control system. In some of my later projects I have used Git to handle my source control. What is great about Git is that it’s a distributed version control system, but it’s also a centralized version control system.

You can use github.com or another service to host your git repositories, but you only get 300 MB if you choose the free account. If you want more space, you have to pay for it. If you are like me you probably have more than 300 MB of source code. So, what are your choices if you don’t want to pay for hosting?

One solution can be to to use Live Mesh to host your repositories. It gives you over 5 GB of space and it’s completely free. If this sounds cool, keep reading on.

I have created 10 steps on how to use Live Mesh as a centralized repository for Git:

1)
First I download Git for Windows from Google Code. The URL is http://code.google.com/p/msysgit/
The version I’m running is Git 1.6.2.2

2)
Then I install the software. I use the default settings (next, next, next)

3)
The next step is to create a Live Mesh account (you can, of course, use your old account).  The URL is http://www.mesh.com
I follow the steps on the webpage and finally install the software. 

 

4)
Then I create a folder called Git on my Live Desktop.

 

And the folder shows up on my local desktop.

5)
Then it’s time to create a local repository. My project is called Time Tracker. I navigate to the folder I want to add to Git and right-click on the folder and chooses Git GUI Here. A dialog pops up and I choose Create New Repository. 

 

Git GUI shows up on the screen.

As you can see from the screenshot, files I don’t want in my repository are shown (like files generated by ReSharper). I need to remove them and this is what I will do in the next step of this guide.

6)
In the folder where I keep my code, a directory called .git shows up. I navigate into that folder and further into the info folder. Then I open the file called exclude in my favorite text editor.
In this file I can add files and folders I don’t want in my repository. The file looks like this:

7)
Then it’s time to add the project to my local git repository. This time I’m going to use the command prompt. I right-click on the Time Tracker project folder and choose ‘Git Bash Here’ and write: ‘git add .’.

The explanation of this command, cut from the help file, is:

“This command adds the current content of new or modified files to the index, thus staging that content for inclusion in the next commit.”

8)
The next step is to commit the files to the repository. That is done like this: ‘git commit –m “The first commit” ’
Ok, so now I have the files in my local repository. It’s time to add them to Live Mesh.

9)
At the command prompt I write git clone --bare . C:/Users/<user>/Desktop/Git/TimeTracker (I’m using Windows Vista).
The –bare keyword I use in the clone command means that I want to create a directory that contains the contents of the .git directory and not the actual workspace.

10)
Now I can work on my local repository and when I want to update the repository in Live Mesh I can simply use this command:
git push C:/Users/<user>/Desktop/Git/TimeTracker master

Changes done in the local repository are now reflected to Live Mesh and I can work on the project on an other computer (as long as Live Mesh and Git are installed) or share the mesh folder with other project members.

Hope you enjoyed this walkthrough of how to use Git with Live Mesh!

Tags: source control

This is insane. I got a MVP award in Visual C#. I must say I feel a bit humble when I browse through the list of other Visual C# MVP awardees. Names like Roy Osherove, Jeremy Miller, Oren Eini and Derik Whittaker, to mention some of them, come up.

If everything goes according to the plan I’m going to talk at the NNUG meeting in Trondheim in May. I guess the reason for me getting this award is because I have been active in the local community for some years. I’m going to continue to be active in the years to come.

Thank you, Microsoft!

EDIT: I forgot to mention that my friend and colleague Joar also got a MVP award today. He got the award in the category Connected System Developer. Congratulations, Joar, you really deserve this award.

Tags:

Last month Kjetil and I where speakers at the MSDN Live tour in Norway. We held presentations in Stavanger, Bergen, Trondheim and Oslo. After this tour I learned something about doing a technical presentation for developers. I want to share my experience from this tour. I have gathered nine points with experience:

1) Use a lot of code in the presentation.
We did a big mistake in the first presentation in Stavanger. We didn’t show much code. I guess when a developer goes to a event like this, (s)he wants to see code, preferably live code in Visual Studio. We increased our ratings when we added more code to the second presentation in Bergen.

2) Know the stuff your presenting so well that you are dreaming about it! 
Developers want to be impressed when going to a presentation. There is no room for errors!

3) Use pictures and make the slides sexy
Design sells, just ask Apple. Spend some time to polish the slides. Use pictures to underline what you are talking about. You probably know the old saying; “Pictures tells more than thousand words”.

4) Don’t use to many slides.
People may go into a “PowerPoint coma” and you don’t want that.

5) Show that you are enthusiastic about the stuff you are presenting.
There is nothing more inspiring than to watch a person that is enthusiastic about the stuff (s)he is presenting. It rubs of to the audience.

6) Talk about something you have worked with.
The audience will more likely believe in what you are saying if you talk about something you have worked with and have real life experience with.

7) Think twice before doing a presentation together with another person 
You would probably think that being two persons working on the presentation will make the preparation go faster. Well it won’t. It’s much harder to be two persons working on a presentation. It’s a lot of decisions to be made and it’s easier to argue with yourself than another person. Create the presentation on your own, and then get feedback from other people, but don’t trust every advice you get. Be critical because it’s you who know the thing you're presenting best. The great thing about doing a presentation together with another person is that you are not alone on the stage and feel more safe. We managed to get a good interaction on stage, which the audience appreciated.

8) People may leave and not pay attention during your presentation.
F**k them. Don’t let things like this interfere with your presentation. I have experienced people having a conversation during a presentation I did and it’s quite annoying. It can throw you a bit off so be mentally prepared for this.

9) Make the audience laugh
Most technical presentations are boring by default. Do something to entertain the audience, but don’t make yourself look stupid. Don’t make fun of the thing you are presenting.

Tags: presentation