This weekend I have published my new blog. Before my blog was hosted by Tumblr, but as a true programmer I needed to write my own. I have focused on making the blog as feature-free as possible. I have no admin interface, I just use Windows Live Writer. For comments I use Disqus.

The blog is running on my own virutal server hosted by ISPHuset ( in Norway).  Having my own web server with the flexibility it brings is great.

The reason for writing a new blog framework is learning. At work you are confined to work with the tools that get the job done. When writing your own software you can experiment.

I decided to try out Autofac for dependency injection, Db4o as a storage and Moq as mocking framework. Usually I would use Structuremap, NHibernate and RhinoMocks.

Autofac

Autofac is ok. It has all the features that I usually use in StrutureMap. The only problem with Autofac is the documentation. Going from version 1 to 2 Autofac has changed its entire API and its conventions. Googeling for help is not easy, as you never know if what your read is version 1 or 2. Documentation is a problem with most OS projects and there should be a better way. I have been playing with the thought of creating a web site that can deal with this issue. All in all, I give Autofac a 4/6 ;)

Db40

I have not worked a lot with Document or Object databases before, so working with Db4o was interesting.

Getting started is very easy:

_db = Db4oEmbedded.OpenFile(Db4oEmbedded.NewConfiguration(), fileName);
_db.Store(myObject);

That’s all you have to do as long as you have a reference to the Db4o dll. Easy schmeasy. I did run into some problems. Consider having a Post object with a list of Tags. So you insert all your posts into the Db and now you want a list of all tags without pulling out every single post in the database. Suddenly you realize you are not dealing with a relational database anymore.

Luckily Db4o has Linq support, so you can query your object without pulling them out of the database. In my case I created a Tag object and asked the database for a unique list of Tags. I’m no master of Db4o so the solution I found might not be the best one.

Using Db4o is very easy in the simple cases, but things easily gets tricky when dealing with relationships. For me to use Db4o effectivly in the future I need to learn more about it, and frankly, I don’t think I want to spend the time. I have more faith in document databases, so maybe I will try out Mongo next time.

Moq

I did’t get to use Moc a whole lot. My first impression is that Moq has a much cleaner interface compared to Rhino Mocks. I think I will be using Moq in the future.

Continous deployment is great

The smartest thing I have done is to set up a TeamCity server at home. Everytime I check my code  into GitHub, TeamCity get’s my changes and deploys them automatically to the Blog. Continous deployment should be mandatory for everybody developing software. Now, you don’t nessecarily need to deploy the changes directly to your customer, but at least you should do in-house deployment. Every single repetitive development task that can be automated should be. The reason ? It saves money and makes programming more fun !

Problems and bugs

Most of the challenges I faced when developing the blog was related to porting the data from the previous blog. I needed to support the Tumblr url schema /Post/[PostId]/[Slug], and also my new one /Post/[Slug]. Also I needed to move my images and make sure that the comment integration continued working.

Making sure that all the RSS feeds continued working was also a challange. Some of you might have noticed that I suddenly released over 30 posts in Google reader. Not sure how I would prevent that behaviour. Hope it didn’t cause any problems.

Bjarte – the designer

I’m not really a web designer, but I have done some design work in the past. I focused on making the reading experience nice and I hope I have done  a good job. When It comes to the rest of the design I am pretty happy with it considering the fact that I’m a developer :) I know the design is different between IE and Chrome b.c. I have deliberately used some CSS 3 features that is not supported everywhere. Also the site doesn’t look good on 1024*800 monitors, and monitors with low contrast. Can’t please them all :)

I have tried to make the HTML as clean as possible by relying on CSS to do most of the work, and letting the HTML be responsible for structure only. In the future I might spice up the site with some nifty JQuery action, but right now I’m content with maintaining a small feature set.

That’s it for now. See you later :)

Comments F Share

        /// <summary>
        /// Gets the constant value.
        /// </summary>
        /// <param name="exp">The exp.</param>
        /// <returns></returns>
        public static object GetConstantValue(this Expression exp){
           ...
        }

I found this code in an open source project. It kinda looks like a joke, but it’s not.

Comments F Share

Sometimes you can identify bad code without reading it at all. If you have big arrows forming in your code you should reconsider your solution. It usually indicates a high cyclomatic complexity (i.e unredable code). Can you see the arrow ?

Comments F Share

I was just skimming thru the ASP.NET MVC code and found this little nasty guy.

You should never widen your interface to enable unit testing. Doing so is a code smell, and there is (almost) always a better way.

 
[SuppressMessage(
    "Microsoft.Usage", 
    "CA2227:CollectionPropertiesShouldBeReadOnly",
    Justification = "Property is settable so that the dictionary can be provided for unit testing purposes.")]
        protected internal ModelBinderDictionary Binders {
            get {
                if (_binders == null) {
                    _binders = ModelBinders.Binders;
                }
                return _binders;
            }
            set {
                _binders = value;
            }
        }

Comments F Share

I do quite a lot of javascript and C# programming. Linq is one of the greatest things in C# and I was missing it in javascript, so I figured I could just implement what I needed. It took about one minute. Here is how I could improve  some of my code:

var a =[];
for (var i = 0; i < elements.length; i++) {
    a[a.length] = {
        name: elements[i].name,
        id: elements[i].id
    }
};
return a;

becomes

return elements.select(function(item) {
    return {
        Name: item.Name,
        Id: item.Id
    };
});

and

var res = [];
for (var i = 0; i < ids.length; i++) {
     for (var j = 0; j < this._currentList.length; j++) {
           if (ids[i] == this._currentList[j].Id)
               res[res.length] = this._currentList[j];
     }
}
return res;

becomes

return this._currentList.where(function(item) {
    return ids.contains(item.Id);
});

The actual implementation I call Blinq (e.g.) Bjarte Linq :p

if (Array.prototype.where != undefined)
    throw new Error("Duplicatte method definition on Array");

Array.prototype.where = function(match) {
    var a = [];
    for (var i = 0; i < this.length; i++) {
        if (match(this[i])) {
            a[a.length] = this[i];
        }
    }
    return a;
}

if (Array.prototype.select != undefined)
    throw new Error("Duplicatte method definition on Array");

Array.prototype.select = function(selection) {
    var a = [];
    for (var i = 0; i < this.length; i++) {
        a[a.length] = selection(this[i]);
    }
    return a;
}

if (Array.prototype.contains != undefined)
    throw new Error("Duplicatte method definition on Array");

Array.prototype.contains = function(obj) {
    var len = this.length;
    for (var i = 0; i < len; i++) {
        if (this[i] === obj) { return true; }
    }
    return false;
};

Not alot of code really.

Nitpickers corner: LINQ-like implementations of Javascript already exists, but when it takes me a minute to implement I don’t go about learning a new framework to get the job done :)

Comments F Share

This one goes out to all you who are spending valuable time to figure out where the heck you can find these methods:

ActionLink and BuildUrlFromExpression you can find in the MVC Futures:

<%@ Import Namespace="Microsoft.Web.Mvc"%>  
<% =Html.ActionLink<HomeController>(x => x.Index(),"Go home") %> 
<% =Html.BuildUrlFromExpression<HomeController>(x=>x.Index())%> 

Strongly typed RedirectToAction you can find in MvcContrib

using MvcContrib; 
return this.RedirectToAction(x=>x.Index());

You can also read Phil Haacks uber lame exuse for not putting this inside MVC at the end of this post

Comments F Share

I am very impressed with the user interfaces Apple has on it’s products like iPod and the iPhone. Apple really do set the standard. Apple does have some really crappy software as well. The one that constantly annoys me is iTunes. But that’s not a problem Apple. I can forgive you for one mistake. However, what I got this morning when I tried to update my iTunes didn’t please me at all. As we all know when we get an software update we just press next, next and then we’re OK. Apple has realized this as well and is deliberately trying to push some software to you that you DO NOT WANT. This is not acceptable.

The problem is easy to fix. They could just have left the check-boxes unchecked.

Obviously I’m not new to this behaviour. A lot of non-user friendly companies does exactly the same thing. But Apple? Come on. You are supposed to be the usability guys.

The way to create great software is to think about the user experience from the users perspective. Nobody wants an extra browser or a mobile-something application installed when they are just updating their software.

Hopefully you, my readers, don’t do this kind of crap to your customers. Or do you ?

Later.

Comments F Share

We (the team) just had a chat about some ideas we should follow when it comes to source control and code ownership. Here is a short summary.

Code ownership

”Shared code ownership: ” To ensure that more than one person is familiar with a certain part of the code base we have shared code ownership. This will make the team more flexible, and making change easier. It is always allowed to refactor code to make it better. It is actually required to prevent the code base from deteriorating over time. That said, there might be people who knows more about the code base than you do. Also, somebody else might be working with the code right now. ”Consult before making radical change.” Communication is always important.

Check in

”Check in early, check in often: ” The code is what is in source control, not what is on your computer. By keeping the code in isolation on your computer you are setting yourself (and the team) up for big trouble. By updating(first) and checking in (second) often, you prevent merging and communication problems. Partition your current work into sub problems, and check in when each feature is created or updated. Work on one problem at a time. If you find yourself working on 10 features, where each one is impossible to check in, you are doing it wrong. It’s a code management anti-pattern. The philosophy behind this is simple. Problems are easier to fix right after they occur. In a day, or a week, solving the problem becomes exponentially harder. Considering this philosophy, keeping the code on your machine to avoid problems MAKES NO SENSE !

”If the code isn’t checked into source control, it doesn’t exist”

Write tests

Write tests for the expected behaviour and your usage of the code. This will ensure that new features and refactoring is compatible with existing usage.

Standard

“Standard” is what we do right now (or should do). The standard can be changed as we find better ways to solve our problems. However, we should all follow the current standard.

Comments F Share

The other day when I was up in the mountains in my cabin, I suddenly started thinking about development processes and rapid feedback loops.  I sat down to write about it, and here is the result:

There is a saying “culture eats strategy for breakfast”.  It’s true. I have seen it in action.

Introducing a new process often requires changing the culture in the company. This is hard or impossible. Radical change creates too much friction. Working with the existing process and modifying it slowly is the most feasible route.  Identify your goals and see how you can slowly modify your existing process to achieve the goals.

Let assume that building software faster and with better quality is a good idea in your context. It usually is.  Let’s say this is our goal, assuming that it in the end will lead to more profitability.

I firmly believe that to create maintainable software there is one term that is more powerful than all others. That term is rapid feedback loops (RFL). Rapid feedback loops is the common denominator of all agile processes. The only process I know of where RFL is not a central concept, is the waterfall model.  It is not the details of the agile processes that make them succeed. It is the fact that they all embrace rapid feedback.

Test driven development tells us every minute if our code works. Continuous integration tells if our code is working in the bigger picture. Integration tests checks whether we are fulfilling the product requirements. Periodical demonstrations and conversations with our customers tell us if we are building the right product. It’s all about getting feedback. If you are writing bad code, or creating the wrong features, feedback nudges you back on the right track. Design reviews can prevent architectural erosion. You need feedback as soon as possible so that you don’t waste time working on the wrong thing. Working on the wrong thing is expensive.

Feedback is a good thing if the feedback you are getting is correct. If it’s not you have a problem. We can usually trust well written unit tests. Integration tests are harder, because they are only correct if they are actually testing a feature we need in the end product.  We need to constantly check with our customer that we are on the right track. The customer might be wrong, so we re-check on a continuous basis.

If you want to improve your current process you should start looking at your feedback loops. Slowly introduce feedback on all levels. You don’t need to pick Scrum, XP, RUP, Lean, Kanban, Crystal Clear or ScrumBut. However, you should know roughly what they are about. This way you can pick from a toolbox of practices and make them fit into your existing culture.

I don’t believe in picking an out of the box process if it will crash with your current company culture. However I really do believe in feedback loops and you should introduce them slowly into your current process. There is obliviously more to creating a smooth software machine, but feedback is a key concept.

Peace.

Comments F Share

Here is my ITunes export of podcasts I listen to. Most are software or “software business” related. I hope it’s helpful. Have I missed some crucial ones ? Tell me on twitter or in the comments :)

BTW, I just removed the StackOverflow podcast from the list. It was taking “brain dead” to another level :)

• .NET Rocks!
• Agile Toolkit Podcast
• Elegant Code » CodeCast
• Entrepreneurial Thought Leaders
• Hanselminutes
• Herding Code
• IEEE Software’s “On Architecture” with Grady Booch
• IEEE Talks Software Process
• Lean Agile Straight Talk podcast
• Mixergy - Online Business Tips from Successful Entrepreneurs » Interview
• Pluralcast
• Polymorphic Podcast
• Software Engineering Radio - the podcast for professional software developers
• TEDTalks (audio)
• The Startup Success Podcast
• This Week In Google
• This Week in Startups - Audio Only
• this WEEK in TECH - MP3 Edition
• Venture Voice

Comments F Share