Moved!

Moved to http://blog.smoothfriction.nl

Moving…

Bear with me for a bit, moving to a subtext powered blog while trying to keep my history intact.

Isolating the domain model from your view

When working with the ASP.NET MVC framework I have a strong urge to not pass my domain models directly to the view (and I feel that’s a good thing). Actually, I should refine that. I do not pass my domain models to the view as a domain class. Let’s investigate.

My model at the moment consists of a class called Contact. It’s very simple:

	public class Contact
	{
		public int Id { get; set; }
		public string LastName { get; set; }
	}

This class is populated with data from my datasource (a static List<Contact> for now), and later on it’ll be used in my domain logic. For now it’s a simple data class. Now, for a view which is used to edit this entity, the first idea is to go with a strongly typed viewdata, like such:

<%@ Page Title="" 
Language="C#" 
MasterPageFile="~/Views/Shared/Site.Master" 
Inherits="ViewPage<Contact>" %>

Basically I’m passing the domain model directly into the view. Not really a good thing in my opinion, because I’m exposing waaay too much of the model to the view. I only need a few simple getters, and perhaps some combined getters (in case of a person, one which appends first/lastname for instance). The solution I use for this is to wrap the domain model in a viewdata class, without exposing the actual model itself.

	public class ViewContact
	{
		private readonly Contact contact;

		public ViewContact(Contact contact)
		{
			this.contact = contact;
		}

		public int Id { get { return contact.Id; } }

		public string DisplayName
		{
			get { return contact.LastName; }
		}
	}

As you can see, the actual model is passed in as a parameter to the constructor, but I’m not exposing it directly. What I can do now is pass this object to the view, without exposing the model:

<%@

Page Title=""


Language="C#"


MasterPageFile="~/Views/Shared/Site.Master"


Inherits="ViewPage<ViewContact>" %>

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

    <h2>Editing: [<%= Model.Id %>] <%= Model.DisplayName %></h2>

    <% using (Html.BeginForm("Update", "Contact")){ %>


        …


        …


    <% } %>

</asp:Content>

Now I’ve got a simple way to isolate my domain model from my view, by using a wrapper class. This way I can explicitly specify what I want to be able to use in my views, without having to conform my domain model to that. I can have a rich domain model, while still limiting the amount of information I get in my view. I’m not sure how this will work out, so I’ll probably follow up on this blog with new insights, or perhaps a complete abandoning of the pattern later ;-)

Taking a step back

So I recently started a personal project with a friend/developer, to try out serious development with ASP.NET MVC. Inspired by Rob Conery’s MVC Storefront/Kona series, we want to try out setting up all parts of a proper environment (automated builds, continuous integration, version control, the works basically). Learning by doing, more or less.

So far, we’ve only just started. We assessed that we want to build an application for record keeping, contact records to be precise, as we’re both interested in keeping our client relations in check. Our first ‘milestone’ is to create a system to insert, delete update and do reports on contact records. We’re working without a database at the moment, using mock repositories for testing purposes. Ok, enough about the background.

I wanted to create a listview, which worked with a set of contacts. Simple, no? Here’s where it went wrong. As you might know, the ASP.NET MVC default solution provides us with a very simple setup. A folder for your models, folder for controllers, folder for views. Let’s look at the views for a moment.

The view structure is set up as follows:

• ControllerX
• ControllerY
• Shared

Each attempt to render a view checks the folder named after the controller for a view with the specified name. If it’s not found, it defaults to the one in the highlighted ‘Shared’ folder. My problem here was that I was anticipating for future expansions right from the start. The WRONG assumption, looking back at it. I tried to create a list view, which would work on any object I’d throw in it. Or actually, in the view model. I have to take a step back.

So, while I started on a very complex solution, I actually decided to go for a view which would probably not live for very long. I will modify it in a later stadium to actually be generic over multiple classes I toss at it. Why don’t I do that now? Because I don’t have to. This is one major insight I had so far over the course of the project, which is actually only a few days old. Seems like it’s paying off already!

What makes developing good PHP applications hard

Jeff Atwood (@codinghorror) recently twittered an url to a blogpost from the guys at OpenX.org about their optimization tactics used for their OpenAds framework. All I can say is that the state of PHP at this moment is abysmal. I’ll explain why.

The writer speaks about three rules they applied when optimizing their code, being:

• Forget about so-called “common sense” and trust only a profiler;
• Use the minimalist approach;
• Optimize for real life scenarios.

I can only agree with these rules, as they should count for all programming languages. I’m a strong follower of the YAGNI approach. Don’t build things you don’t need now or in the very near future. Also, when optimizing (which should not be done in advance, of course), you have to measure to find your bottlenecks. The third rule makes sense as well. However! It’s not the developers I’m criticizing here. It’s the language.

An example:

The statistics were very interesting and we learned some things about PHP from them. It seems that when we started more than 80% of the delivery time was wasted just on including files. In other words, PHP didn’t do anything useful in that time. Reducing the number of included files gave us such a good performance boost that we even decided to write a delivery merger tool to put all the code from included files together into a single file.

Wait, what? Basically what they’re saying is that dividing your code into separate files (with, hopefully, descriptive names) is actually a big performance hit in PHP. If you want to go for performance, don’t bother dividing your classes over different files. Who would ever do that? I’d have to switch between different files in my editor when developing! (/sarcasm)

And, the other gem:

Another good example of a PHP “quirk” is the way PHP handles constants. It was one of the major factors affecting performance. Just removing all the constants allowed us to improve the performance by almost 2x.

So, by throwing out everything we’ve learned (don’t use magic numbers, extract your strings to constants if possible), we improve the performance twofold. That’s 100% faster! Now, I know PHP has a few annoyances (like array functions which take the needle first in one function, but last in another function), but this is downright appalling. How can we develop proper applications when a language is so very broken?

Why I hate developing in PHP

This is wrong at so many levels:

if($this->mail_protocol == "pop3")
{
	$port = "110";
}
else
{
	if($mods["imap"]["SSL Support"] == "enabled" && ($this->ssltype == "tls" || $this->ssltype == "ssl"))
	{
		$port = "993";
	}
	else
	{
		$port = "143";
	}
}

Whoever can name the most anti-patterns in this small snippet wins a honorable mention in the credits of this post.

A simple refactor step

Here's a short snippet from me to think about. Say we have a some code which retrieves a list of orders from a datasource. The part of the application using this functionality looks like this:

public class OrderProvider
{
	public ICollection<Order> GetOrdersFor(Customer someCustomer)
	{
		ICollection<Order> orders = CallSomethingHereToFetchOrders();
		return orders;
	}
}

	ICollection<Order> orderlist = OrderProvider.GetOrdersFor(someCustomer);

	if(orderlist == null || orderlist.Count == 0)
	{

		//something is happening here//
	}
	else
	{
		//something else is happening here//
	}

At a glance, someone I showed this to said there was nothing inherently wrong to this snippet. I care to disagree. What’s wrong here, in my opinion, is that the provider doesn’t have a unambiguous behavior as far as an empty list is concerned. There should either return an empty collection by default, or throw an exception if it somehow gets a null value to return. A simple implementation would be as follows.

public class OrderProvider
{
	public ICollection<Order> GetOrdersFor(Customer someCustomer)
	{
		ICollection<Order> orders = CallSomethingHereToFetchOrders();
		return orders ?? new List<order>();
	}
}

	ICollection<Order> orderlist = OrderProvider.GetOrdersFor(someCustomer);

	if(orderlist.Count == 0)
	{

		//something is happening here//
	}
	else
	{
		//something else is happening here//
	}

Notice we split up the complexity of the if statement in the calling code, reducing the amount of possible conditions that match the case. We also moved the responsibility of checking the validity of the model to where it belongs: the code actually BUILDING the model we’re going to use. By doing small refactoring operations like these, it’s easy to maintain a good separation of concerns. The calling code, whatever it will do (maybe… print the orders one by one to paper, or show some nice statistics on screen), will never have to worry about null checks on things like this. Now we can focus on the happy part of that bit of code!

Driving instructions for software development

I just had a moment of deeper understanding in how real life guidelines apply to software development as well (as far as software development isn't real life of course).
When I was taking driving lessons for my license a while ago, my driving instructor gave me a few tips, which with a little creative reasoning apply to software development as well:

1. Be decisive. Don't hesitate, do what you have to do. When you make a decision, follow through! Don't wait when you don't need to, just do it!
   In sofware development: When in a situation that seems difficult, find a way to solve it or a way around.
   
2. When in doubt, don't. Although this might seem to conflict with rule one, it really doesn't. When you think something won't fit, it probably won't. You'll break rule one if you do something when you're in doubt.
   In software development: When you can get a project you're not sure about, try to not take it if at all possible.
   
3. Plan ahead. When going somewhere you've never been before (different country, or in software: new technique) do some research about the rules, applications, dos and don'ts.
   In software development: Do some research on the techniques you will have to use before applying them.
   
4. Aim for where you want to go, not for what you try to avoid. Set your focus on the goal, not the pitfalls!
   In software development: Solve the hard parts of your problem first, or (again) find a good way around them.
   

Seems like I got more out of my driving lessons than just my license! Thanks instructor dude!

Refactoring spaghetti PHP

So, for my current job I (together with two peers) write-slash-maintain a moderately big stack of PHP code. It’s written in a typical PHP fashion: (almost) no object-oriented principles, a bad attempt of separating presentation and business logic, code duplication all over the place, and, currently my biggest nemesis, zealous usage of the ‘global’ keyword. What is the global keyword you ask?

By declaring $a and $b global within the function, all references to either variable will refer to the global version. There is no limit to the number of global variables that can be manipulated by a function.

What this means is that I can define a variable in the global scope of the script, and then pull it into my function without having to pass it as an argument. A small example:

<?php

$myGlobalVar = “Hello World”;

function Hello()
{
	global $myGlobalVar;
	echo $myGlobalVar;
}

Hello();

?>

This code shows how to use the global keyword to basically get a variable from the global scope into the scope of the function being called. Another (in my opinion, better) option, is to pass the variable being used as an argument to the function. Another example from my cookbook:

<?php

$myVar = “Hello World”;

function Hello($gonnaPrintThis)
{
	echo $gonnaPrintThis;
}

Hello($myVar);

?>

Even though the code is different, the output is the same. We’ve gotten rid of the global keyword, thus making the function reusable and more robust. Not only that, but if I wanted to test it in isolation, that would be very easy as well.

Now, most examples you see, these ones included, are very simple, and don’t really show the pain of bad design. Imagine the following situation, where globals are misused.

file1.php
<?php

// bunch of code here

?>

file2.php
<?php
require_once("file1.php");

// bunch of code here

?>

file3.php
<?php
require_once("file2.php");

// bunch of code here

function HelloAgain()
{
	global $someGlobal;
	echo $someGlobal;
}
?>

File 3, containing our function HelloAgain, requires file 2, which in turn requires file 1. Obviously, those files contain more than just some variables being set. In this situation, there’s absolutely NO way to determine the current state of the global variable $someGlobal at the moment the function HelloAgain is being called. The global could’ve been set (OR NOT!) in any other place imaginable. This my friends, is what I call a maintenance nightmare. One which you can not solve in a few minutes once it has settled itself firmly within the darkest corners of your codebase.

HOWEVER! With a few simple steps, you can isolate the scope of your global. I realize some OO purists will burn me for this, but this situation is easily solved by using a singleton pattern. A singleton pattern is a well known object-oriented pattern, which ensures that one, and only one instance of a certain object exists at any given time. A simple implementation in PHP 5.x (courtesy of wikipedia.org):

<?php
class Singleton
{

	private static $instance;

	protected function __construct() { }

	public function __clone() {
		trigger_error('Clone is not allowed.', E_USER_ERROR);
	}
 
 	public function __wakeup() {
 		trigger_error('Deserializing is not allowed.', E_USER_ERROR);
	}

	//This method must be static, and must return an instance of the object if the object
	//does not already exist.
	public static function getInstance() {
		if (!self::$instance instanceof self) { 
			self::$instance = new self;
		}
		return self::$instance;
	}

	public funtion getMyVar() {
		return "Hello world! I'm still here!";
	}
}

function Hello()
{
	$printVar = Singleton::getInstance()->getMyVar();
	echo $printVar;
}

Hello();
// or //

function HelloAgain($gonnaPrintThis)
{
	echo $gonnaPrintThis;
}

$myVar = Singleton::getInstance()->getMyVar();
HelloAgain($myVar);

?>

Using this pattern to wrap a global variable might seem overkill, and on the other hand, not a big improvement over using globals. But it is. Making the global variable you need a return value for a function on your singleton object not only encapsulates the variable, it also opens up all sorts of options. You can later on easily add logic to fetch the value from the database, cache it and what not. You can refactor some more, and eventually create a coherent, object-oriented solution instead of a big lump of meaningless code. But first and foremost: You are now back in control!

Jenga Programming

I’m coining a new programming discipline, called Jenga Programming, or Jenga Driven Design (JDD). It’s something I see happening all the time, and it’s driving me crazy now and then.

For those of you who don’t know what Jenga is:

Jenga is a game of physical and mental skill, marketed by Hasbro, in which players remove blocks from a tower and put them on top. The word jenga is derived from kujenga, the Swahili verb "to build"; jenga! is the imperative form. (http://en.wikipedia.org/wiki/Jenga)

Basically what you do is you start with a solid tower, and keep removing parts and adding them to the top of the tower until it falls over. It’s a simple game, and quite fun to play. In programming however, this is arguably one of the best ways to create a maintenance nightmare.

At a glance, JDD looks promising. You start with a big solid block of code, and simply start removing the bits that are not needed to keep it standing. After that, you’re adding new things to the top. Sounds like iterative development and refactoring to me. If it was that simple, I wouldn’t have come up with this theory.

So what do I mean with JDD? We’ll dive a bit deeper into Jenga for that.

When you play Jenga, you remove blocks by gut feeling. When you’re removing a block you’re free to bump around the other blocks, or leave a block half removed if you think it will topple the tower. After you removed the block, usually you simply put it on the top in such a way that the tower won’t fall over. The only thing that matters when putting the block on the top is making sure the rest of the tower doesn’t come crashing down.

Superimposing this view of the game on ‘the game of software development’ will make it painfully clear where this goes wrong:

When you’re doing proper refactoring you (ideally) make sure that the code is covered by well-written tests, and that the functionality of the code is known. This is not the case when doing JDD: you remove bits which you think do nothing useful.

When you add new functionality to your application you make sure you know why you’re adding the specific functionality, and that it written well. When playing the JDD game, you add functionality whenever someone asks for it (adding a multitude of meaningless options/settings, anyone?). You don’t really care about the rest of the system, as long as it works.

Of course, JDD doesn’t work so well in compiled languages like Java, C or C#. When you remove something that’s still used, your compiler will cry out in pain, and you won’t be able to deploy the application into the wild. That’s why JDD is a typical (anti)pattern seen in PHP (and other script languages) development. Now, I’m not saying PHP is bad (well, not in this blog at least), but it does tend to let programmers do things like this. I blame it on the programmer though.

To summarize, JDD is programming without a solid plan, adding and removing things without a lot of thought. This is not to be confused with agile/extreme programming methods, where there IS a lot of thought going on.  So next time you encounter an application which falls over after a simple change, there’s only one thing to say:

 

JENGA!

Things I still want to blog about

So, it’s busy, life’s busy, I’m busy. So I want to make a list for myself what to blog about. I’ve got a lot of interests, but I’d like to stay in line with the general topics I’ve written about so far. So, here’s my list for the coming weeks (months?).

• NHibernate and custom usertypes
  I’ve recently ran into a simple case where this might apply. I’ve got the code, just need the explanation.
  
• Storing an unbounded tree structure with NHibernate
  Using modified preorder tree traversal. This seems to be a great way of storing trees, it’s just very clumsy to use.
  
• More on moving from SVN to Mercurial
  I’ve already taken Mercurial into my production cycle, but I need to finish my drafts on this!
  
• Making yourself known on the web
  It’s what I am doing. I want a good professional presence on the web, as it might help getting credibility in the future.
  
• Contributing to OSS series
  In my opinion, one of the best ways of gaining ‘web-cred’. Especially if you pick something that’s going to be the next best thing since sliced bread which is still small enough to make an impact on. Subjects in this series would be something like ‘choosing your pet project’, ‘first steps into contributing’ and something about how documenting/translating is helping too. This series will also mark my experiences so far with contributing to OSS (which I intend to pick up a lot more).
  
• Something about IoC containers, notably Unity and Windsor
  

And some ‘maybes':

• Selection of a suitable WYSYWIG web editor
  We all need a good one, but there’s a lot of outdated stuff out there. Malformed/deprecated HTML, embedded styles…
  
• jQuery fun
  jQuery is fun to use, but I don’t know if there’s enough material for me to write about.

To get myself up to speed, I want to write something at least once a week, as long as I have material to write about. I want to see that hitcounter ticking in real time!

jQuery delete link with downlevel support: my version

Phil Haack recently blogged on using jQuery for creating a delete link in ASP.NET MVC which uses ajax when available, while still using conventional form posts when needed. One of the comments was about using the same html link in both cases opposed to changing from a html link to a submit button and vice versa. One advantage of that is that you enable a common case when deleting an item: a confirmation dialog/screen.
It just so happens that I recently implemented a very crude version of this in my pet project.

First off, I’d like to mention that I left out some of the implementation details, as that would cloud the example. Things like anti forgery tokens and such are your own responsibility. Ok, let’s get started.

The HTML rendered looks like this, more or less:

<table class=”gridview”>
 <tr>
   <th>field1</th>
   <th>field2</th>
   <th>actions</th>
 </tr>
 <tr>
   <td>fieldvalue1</td>
   <td>fieldvalue2</td>
   <td><a href=”/MyController/Delete/1” class=”delete-link”>delete</a>
 </tr>
</table>

When this renders, it will show a simple grid, with a delete link on the data row. Each additional data row follows the same pattern, obviously. The route on the link leads to the following method on the controller:

[AcceptVerbs(HttpVerbs.Get)]
public ActionResult Delete(int? id)
{
   ViewData["id"] = id;
   return View();
}

Simple enough, it renders a view called delete.aspx, which will render our confirmation form. I accept a nullable int here, I’ll explain why later on. The view rendered outputs the a form in this fashion:

<form action=”/MyController/Delete/1”>
 <input type=”submit” value=”yes I’m sure!” />
</form>

It takes the id for the route from the viewdata, nothing more, nothing less. When submitted, it leads to this method on the controller:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Delete(int id)
{
 // delete your entity here, then check if it’s ajax, if not, redirect to your list overview or something
 return RedirectToAction(“list”);
}

Now, this is why I accepted a nullable int as an argument for the confirmation form. Because I needed an int on both the post- and the get-action, I wanted two different methods. However, I can’t have two methods on the same class which have the same signature. By changing one of the ints to nullable I have two different methods, with the same name and almost the same signature. Close enough to allow the same route to lead to both methods if needed. By distinguishing on HTTP verbs I won’t get an exception about ambigious routes.

Now, for the jQuery ajax magic, I added a little script to the top of the page, which does little more than add an onclick event to the delete links. It’s not much different from Phil’s code:

$(".gridview .delete").click(function()
{
 if(confirm("Are you really sure?"))
 {
   $.post(this.href);
 }
 return false;
});

There you have it. When javascript is turned off, the delete link leads to a confirmation page showing a form with a confirmation button. Click the button and the delete function is called, redirecting to the list view after deleting the item. When javascript IS available, a confirm dialog pops up, and it will delete the item when you click ‘Ok’. Now you will have to fill in the blanks, like reloading your list view when an item is deleted or something like that.

I couldn’t resist the calling

Ladies and gentlemen, I am now on Twitter. You can find me as tedkees. Feel free to follow me, or just ignore it. That’s fine too.

What made me do it? Well, Scott Hanselman of course!

Running a business 101: Treat your customer with respect

This post is inspired by a lengthy open letter blog from Ayende about his experiences with a licensing component, interlaced with my own experiences on dealing with my clients. In my day job I regularly have to talk to (potential) clients about their wishes, their problems and overall product satisfaction. So even though I don’t run my own company, I think I do have some experience with dealing with clients now and then.

Communication is the key. Communication is essential for managing your clients. Software development inherently introduces bugs, requirements mismatch and all sorts of other problems. The biggest cause of this is simply that your client doesn’t understand what you do, and vice-versa. In a development project, you should spend a lot of time on getting the intention clear: what’s the problem, and how do we intend to solve it. Notice that I explicitly avoided using the word ‘requirements’, as those (details) can change along the way.

Support doesn’t mean fixing the problem right away. What’s your biggest annoyance when the product is not working like it’s supposed to? Right. You don’t know WHAT is happening, or WHY. When a client comes to you with a problem, try to identify it and acknowledge that the issue has been recorded. Give them a real deadline (don’t fall in the ‘we’ll look at it soon(tm)’ trap!) so they know when to expect information. Also give them an indication on what you intend to have for them at the deadline. Don’t offer help if you can’t follow through!

Some people might argue that there IS NO bad publicity. Although this might hold true for some cases, usually bad publicity will haunt you. Of course you could try to categorize your clients by their influence, but aside from that being at least unethical, it’s also impossible to know how much of your performance with that specific customer will come out. The best thing you can do when something doesn’t work out is diagnose the failure as soon as possible. Don’t drag it out because you hope it ‘will all work out eventually’, because this will usually end up in you needing a massive amount of time (= money) to fix the problems if at all possible, and your client will get more and more annoyed. Even if you eventually produce what they want, the harm is already done. Your relationship with the client will have taken a lot of damage, which may or may not be permanent.

If all else fails, offer a refund. Take your loss, don’t worry too much about the money they gave (or owe) you. If it’s about a product that works out of the box (like Photoshop, Visual Studio), just offer a full refund. When it’s about a development project, try to agree how much you can deliver which they can still use. For instance, if you did a feasibility study, find out if they can reuse it when they take the project elsewhere. If your client can use it, offer it to them for part of the total sum of the project.

I think XHEO (the author of the component Ayende wanted to use) didn’t realize the amount of influence Ayende has in the blogosphere. A lot of people that read his blog are (semi)professional .NET developers which are potential customers. Thanks to his story, they will think twice before choosing XHEO components. That’s what bad manners (or perceived manners) with your customers can cause.

So remember: Treat your customers with respect, and try to help them however you can. If you can’t, try to find an acceptable solution for both so you can put the problems behind you.

Turning spikes into a solution

Spike: A simple prototype program to prove your assumptions. This can range from feasibility to performance and back again.

I recently found that almost half of my time is spent creating spikes for ‘difficult’ situations I encounter. One of the pitfalls of writing spikes is getting stuck in an endless cycle of writing them. You’ll end up with a bunch of proofs that the problem can be solved, but your problem is still present. So, how do we avoid getting stuck on spikes? I use the following steps:

Analyze
Before you start building your spike you should decide what you’re building. I’ve seen people (myself included) start building a spike for something, which turned out to be a prototype for half of the wanted solution. If you’re familiar with the Single Responsibility Principle, you could apply it here as well, but on a higher level. For instance, if you need to prove that your system can successfully connect to a stock exchange webservice, don’t bother spiking your xml serialization, or pay any attention to a pretty UI.

Quantify
View your spikes as any other task on your project. You will have to set a deadline, make sure dependant tasks are planned accordingly, and most important of all: decide how much time you’ll need to build it. If you’re anything like me, you enjoy building spikes, and think finishing up a project is tedious work. If you don’t quantify, you’ll be building your spike till the end of times (over dramatization)!

Build
Start creating your spike, with the previous steps in mind. If you feel you’re doing too much, prototyping too much functionality, consider planning another spike for the extra functionality. Focus on the problem at hand, it’s perfectly fine to test an algorithm in a console application. If possible, build your spike as a separate project, instead of inside your existing system. This is usually easier and faster.

Refactor (optional)
Your spike is likely not the best programming possible, as the only goal is to see if your assumptions are correct. Refactor your code to apply the usual guidelines (like low coupling, high cohesion, SRP, etc.), and make sure your tests still pass (assuming you use some form of testing).

Integrate (optional)
If applicable, integrate your spike into your solution. Make sure it doesn’t break anything (automated testing anyone?) and make sure it follows your coding guidelines. All in all, make sure it fits in as part of the whole solution.

This being said, theoretically it’s all very easy. The most difficult part of the whole process is discipline. You will have to constantly keep an eye on yourself and make sure you either stick to the plan, or adapt the plan to stick to you. The first one is safer, the second one is more flexible.