It was time, the old layout and colors wasn’t working but I haven’t gotten around to fix it, especially the comment section looked really bad. Then I found out about blogengine.net. After experimenting with it for a while I found that it had what I liked:

• The code was readable and easy to get into for modification
• It wasn’t depending on a database for storage (how many bloggers are really creating that much information that calls for a full fledge database?). But it could be added.
• It had a clear separation of the view and presentation that makes it easy to build and expand themes.
• I found a good looking basic view that I could modify for my needs.
• It has easy export/import functionality through the standardized BlogML format (it handles posts, comments and images just right, really powerful).

So after tweaking the view a bit (more is coming) I decided to make the switch. And as you can se it’s up and running. Hope you like the new look.

All that happen to subscribe should really shift to the feedburner link instead of the old web link. But for those who are still using the old one I found an easy solution. I used built in syndication http handler and some configuration.

Normally, blogengine is configured so that a call to syndication.axd is fed to a HttpHandler called SyndicationHandler. So I just added the old SyndicationService.asmx (without the extra GetRSS part) to point to the same piece of code. In the web.config I added the following line to the <httpHandlers> section of web.config:

<add verb="*"
path="SyndicationService.asmx"
type="BlogEngine.Core.Web.HttpHandlers.SyndicationHandler,
    BlogEngine.Core"
validate="false" />

And that was all I had to do. Now I just have to get going with some more CSS and images to spice things up a a bit…

// Håkan Reis

Do you think that wasting $150 000 000 of your clients money is ok or have you heard of any companies that does that and get away with it (that are not lawyers)?

Chances are that you are doing business with one of them. But lets start from the beginning here and I’ll get to the $150 million in a while.

This year we got a new time report system at work, and as usual it’s a mess. There is a user experience here but only of confusion and annoyance.  A couple of hideous  problems I spotted in just a few minutes of use were:

• In this system we are forced to use an arcane time code for each report period. The crypto looks like 208522. If you decipher it you get 2008, 52 and the last is 1 or 2 depending on if it it's the first or second month in that week (when the month is shifting). This is just ridicules, we have been using the roman calendar for a couple of thousands years. The porting period calendar code is not logical for any user (not even the developer).
• For each cell we have to use codes, and to find out what codes to use a modal JavaScript dialog is presented where you can do a search that lists a few projects and their code. Each time it takes 3-4 clicks to enter the correct codes. But in this system you have project codes, activities codes, customers codes, account codes, etc.

So how about the numbers then? Well, just the two problems on top here will keep on eating up a couple of minutes each day. Our company size is around 150 people so this mean about 600 hours lost each year. I have no idea how many users the system has, but they claim that 2 600 companies are using their system. Taking our company as an average company is at least a start so lets use that figure. This adds up to 1.5 million hours. With an hourly rate around $100 you get $150 000 000 every single year down the drain.

So what gives them the right to cost their client so much? Is it that they have especially lazy developers or did they really think they could come up with a better calendar. Actually, the truth is that there are many more time report systems out there and I haven’t came across a single one that’s much better and a few that are even worse. This micros study of mine revealed a few common facts on time reports:

• All the reporting systems spring from the economic context. In that context we are often thrown back to entering long rows of numerical data. Codes may make sense in this context as they speed up the entry on a numeric key-pad.
• The next problem is that they try to solve time reporting for everyone. The average user will not need to list 300 clients to find the right one even if the company might have all those clients. You don’t have a gigantic hierarchy of projects, tasks and activities. Actually, if you have demand that fine grained control of every hour you are probably wasting your clients and employees time and money.
• The users of the system do not share the context of time reporting. A small group of users are using as one of their main tool, they might want codes and shortcuts as it can speed up their work. But the biggest user group are probably the ones that report into the system. They might use it one time a day on that occasion they don’t want to waste time on searching for codes.

Actually the solution to some of these issues are quite simple but that doesn’t mean it’s simple to implement. But to start with they could at least get to know their users, and by users I don’t mean customers.

The system will have to be created with a dual view, of course it has to support the the ones that are using the reported time for calculation, planning and business. But there is not a contradiction in supporting the other bigger user group here, the ones that has to enter data. If the overhead for entering my time were just a minute or two a day instead of 10-15, I might not be that annoyed. I could use their system instead of the simple app in my iPhone that keeps track of my projects and how much time I spend on each.

And for the two problems found in our current system there are two super simple solutions that I give away for free.

• Let me use the calendar i know and use (you know the one that starts with January and ends with December)
• Provide me with incrementally searchable dropdowns with real projects and activities names – not the damn codes.

Ah well, I should probably report that time from last week instead of writing up this rant. And I really hope my company will not just lose money on the system, but save a dime or two on the reports and invoices that it produces.

// Håkan Reis

Version 4 of TeamCity has been out for a few weeks now and there are a lot of improvements in this release. A few of them are:

• Improved build runners now with of FxCop an new versions of NUnit
• Test reordering (problematic and failed tests are executed first to give even faster feedback)
• Build agent improvements
• Artifact dependencies

There are a lot more and not all are .Net features of course. I’m going to focus on the last one here that are a big improvement in my current project.

We have a setup of development builds and a few nightly test and analysis builds. To top it of we have deployment builds to testing environments. The development builds are easy to maintain. But the analysis and deployment scripts were giving us a lot of problems. In the scripts we were copying files from the development builds to deployment and analysis but this was not a stable solution. If the development builds were running the deploy and analysis builds would fail. Artifact dependencies to the rescue.

Artifacts

Whenever a build is completed I can direct files to a special TeamCity repository. Here it gets saved in a structure I define. So for example when a development build of our web project is done I store the files for deploying to the web, unit and function testing, and a few shared assemblies. the shared files are stored as build artifacts using the following artifact paths (Build Configuration Step 1 – General settings):

So for each successful build we get a copy of the produced shared assemblies (and all other supporting files in the two release folders). So the artifact structure for each web build will look like the following image:

Here we have the Web files, the shared Common and Core assemblies and unit test projects.

Artifact dependencies

Moving on to the deployment builds, we want to start out with Common and Core assemblies already in place but from the last successful development build. This is really easy with the new artifact dependencies. Going into the deployment build configuration we set up this artifact dependency (Build Configuration Step 5 - Dependencies) like this:

Now the assemblies in Shared/Common/ and Shared/Core/ folders in TeamCity will be placed in my deployment build checkout folder before the subversion checkout is done. This dependency can be modified to only work on pinned builds and even specific build numbers. And you can add more artifact paths and of course artifacts from multiple build configurations. So if you haven’t upgraded to TeamCity 4.0.1 go ahead now.

// Håkan Reis

It’s easy to get stuck in old trails. You know, when you first log on you should set you password, change it periodically, blah blah blah, you know the drill. But if you just keep on going in this track you will not simplify it for the user. Reading the post regarding the upcoming Windows 7 and the HomeGroup feature was liberating.

And the reflection that each person in your home is really equal and part of your home group was great. Also when you are at home you are safe and don’t need a lot of passwords to keep safe from family members.

This conclusion wasn’t drawn from computer usage, it was identified looking at the real world:

People don’t allow strangers into their homes and usually lock their exterior doors. People within the confines of the home are typically considered to be trusted.

Within the home, doors to rooms are usually not locked, allowing members of the household to have free access. Books, photographs, magazines, CDs, and DVDs are often freely shared.

Social norms prevent most people from snooping into areas where they shouldn’t and, if needed, adding locks to rooms or drawers is relatively easy.

I love this notion on how reality really affect the computer usage. Another interesting fact was the pre-generated password. It’s really like a key, each family member don’t want to make decisions regarding what type and look the key should have? They want the same key. Also from the post:

You may ask, why don’t we enable people to set their own passwords by default? The answer is actually quite ironic, since that was our initial design. In testing, this concept raised quite a bit of alarm with people. It seems that most people generally have 1 or 2 passwords that they use for all their online or offline activities. When asked to input a user password for their HomeGroup, they gravitated towards using one of those, and then reacted with alarm when they realized that this password needs to be shared with other users in the home! People generally reacted better to the auto-generated password, since they knew to write it down and hand it around. The other interesting benefit we got from this was a reduction in the amount of time people would spend on the UI that introduced them to the HomeGroup concept.

This last issue would not have been identified if they didn’t do user testing. I strongly suggest you read this post. And the others too in the Engineering Windows 7 blog. They are truly worth reading and I am really looking forward to start testing the first beta as it comes out.

// Håkan Reis