June is open space month. This year I won't be organizing my own open space. I decided it would be easier to just let Devnology do all the hard work and attend their open space instead. So if you have nothing planned for June 5th and feel like spending your Saturday talking to fellow geeks about programming come join me there.

Here’s the last post in my Javascript Tetris series. Time to show the final version of the Tetris implementation I built. It’s not completely finished but I did come pretty far. I only put in a few hours in total. I’m going to race through the final implementation in this post. After this I’ll go back to writing about C#. I promise :-)

More...

Here’s just a short update on the Tetris project (if you can call it a project). I had a pretty busy week but I did find some time to play around some more with javascript, try out some GOF creational patterns, and build a nice domain model to make working with squares and blocks a bit easier.

More...

Here’s a little update on the javascript front. I’ve been busy working on tetris this weekend. Lots of new stuff to learn and lots to do. First of all I got a list of issues from Sebastiaan Janssen that needed fixing (thanks, that was exactly the kind of feedback I was hoping for). I’ve been playing around with unit testing javascript with QUnit. Of course my existing code wasn’t really testable so I had to refactor things a bit too. And I tried to test-drive a couple of small stories.

More...

To prepare for the Devnology meeting next month I have to write a version of Tetris in a language of my choosing. I had already fired up Visual Studio to build a kick-ass C# XNA version with explosions and 3D visuals when I realized it would be much more fun and educational to pick a language I’m less familiar with. I’m pretty sure there will be Ruby, Python, Java and Haskell implementations by some people who are pretty good at programming in those languages so I decided not to pick any of those obvious languages. But I’d still like to invest my time learning something I’m actually going to use, so Cobol wasn't an option.

So I picked javascript.

More...

I’ve been using xUnit.Net for a while now. It’s just a tiny bit cleaner and slightly less abrasive than other .Net unit testing frameworks. Leaving out unnecessary stuff like [TestFixture] and shortening Assert.AreEqual to the equally clear but shorter Assert.Equal don’t seem like big improvements but when you type them several times a day tiny improvements start to add up. I also like the use of the [Fact] attribute instead of [Test]. It shifts the focus from testing to defining behavior. So how do we get all this goodness working with the Visual Studio 2010 beta?

More...

I'm helping organize an Open Coffee in Delft the 4th of September together with dotNed, the dutch .Net usergroup. The event is hosted by QDelft and will start at around 5 o clock.

All .Net devs (or people interested in talking to these geeks) are welcome, so just come over, have a drink and exchange ideas with fellow developers!

For more information visit the dotNed site over here.

Many tools (especially on the Microsoft platform) make it easy to start your new project by just dragging and dropping some controls on a window. Just add some logic to event handlers in the window-class that represents that window and be done with it. Most programmers who have done this a few times will know that the result will probably an unmaintainable and untestable mess. UI patterns solve this problem by splitting up your application in different parts, each with their own responsibilities. The first part of this series will look at how different UI patterns divide responsibilities between their components

More...

I have never met anyone who could explain the differences between all the Presentation  patterns to me, but new ones seem to spring up almost daily. The last time I checked I found

Model View Controller, Model View Presenter, Document View, Supervising Controller, Passive View, Front Controller, Page Controller, Humble View, Humble Dialog, Model View Viewmodel, Presentation Model and Application Model,

More...

In a previous post about agile architecture I reasoned why big design up front isn’t a good solution to the problem of handling complexity in software. The best solution is architecting your application to avoid complexity as much as possible. At the end of the post I suggested reducing complexity by not implementing anything you don’t need right now. This principle is well known as YAGNI, short for You Aint Gonna Need It. Don’t implement anything you don’t need now. This will keep complexity down making it simpler to extend when you do need it. There’s another solutions to handling complexity though. You can reduce complexity by modularization. In software engineering we’ve got the SOLID principles for this. Unfortunately the SOLID principles seem to go against what YAGNI tells us. They tell us to add interfaces, separate out our dependencies and add all kinds of structures to our code that we don’t need just yet. So what’s it going to be SOLID or YAGNI?

More...