Monday, December 26, 2011

2011 Annual Review

Since the end of the year is approaching, I would like to look back on 2011 and take a peek at 2012. Unlike the years before, I'm hardly setting any goals this year. Interests change so quickly, and new opportunities present themselves so regularly, I feel like it might be ignorant to set these things in stone.

My career

The year started out interesting, working on a brand new product for fire departments at Ferranti Computer Systems. Although my role in this project should have been fairly satisfying, I still felt like my position back then failed to fill a certain void. That's why I decided to take the leap into the Great Unknown.

In September, I started working for Euricom as a consultant. So far, I haven't regretted making that decision at all, I ended up in a group of intelligent, progressive and enjoyable people.


This year I managed to write 69 posts (70 including this one), which is a bit more than the year before.

Plenty of posts have gotten decent attention this year, making the traffic tripple compared to 2010. And no matter how other bloggers claim you shouldn't care about your blog statistics, this does mean a bunch to me.

The main topics I wrote about this year were mostly web related (HTML5, JavaScript and ASP.NET MVC). I even wrote some opinionated posts this year, which I found harder, but also more rewarding.

Last year, I set a goal to get better at MVC and to at least look at WebMatrix. I spent a large part of the year building things in ASP.NET MVC at the day job, so that goal was easily achieved. I built one small thing in WebMatrix, which was enough to give me a feel of what WebMatrix is all about.

My guess is that I will cover similar topics next year. My faith in the web has only grown stronger. I think the rise and rise of the browser and JavaScript provides us with unseen opportunities, but also with an enormous amount of challenges. I am really eager to start looking more into serious JavaScript development.


I think I did fairly well this year. I attended several local community meetings and got to to know a lot of nice people in the process.

The highlight probably was my own talk on WebSockets at HTML5 Webcamps. I really enjoyed that experience. I do not aspire to be a speaker though, but should I have interesting things to talk about, I probably won't reject invitations.

I'm not sure if I will be doing a lot of community events in 2012. I often don't seem to get out of them what I hoped for. Also, Euricom regularly organizes meetups to talk about all things software development. These will already consume plenty of time.


This year my girlfriend and I did a three-week roadtrip along the West Coast. This trip was by far the best time of our lives. We are determined to undertake similar projects in the future again.

Next to that, we revisited the Czech Republic, taking plenty of time to visit Prague this time.

We're not sure what 2012 will bring. Right now, we are looking into something more nearby, Italy.


Last year I picked up boxing, but I had to give that up due to scheduling conflicts. I have been working a tweaked P90X routine twice a week instead, which is very much recommended.

I reasonably succeeded in achieving my running ambitions. Altogether, I ran somewhere around 800 kilometers (= 500 miles) this year. This summer, I probably was in the best shape of my life, running 15 km pretty (= 9 miles) comfortably. Although the graph below suggests that I'm slacking, it's only partially true. I have been doing shorter (and higher paced) runs lately, increasing the intensity. Running is probably one of the sports that give me the most energy in return, so I intend to stay at it.


2011 has been an eventful year for me. In 2012, I hope to be able to keep doing the things I love, surrounded by the people I love. Trying to live life as much as I can.

I wish you and your family the best for 2012. That the new year may bring you health, love and plenty of hacking. 

Saturday, December 17, 2011

2011's most read posts

I compiled a list of most popular posts that were published on this blog in 2011. Unlike last year, and the year before that, this year it's not a strict top five list. While analyzing the statistics, I found out that a few topics -covered over multiple posts - were popular this year.

Preparing for my HTML5 Webcamps session on WebSockets, I wrote a few posts on the Microsoft WebSockets prototype. I published a step-by-step guide on how to get the prototype working on your machine. A little later I also published two posts covering the internals of the client and server WebSockets prototype. I'm not surprised search drove a lot of traffic to these posts. Microsoft hardly tried to make it easy to play with the prototype: no tutorials, no source, nothing. Now the specification is stable, and WCF 4.5 has WebSockets support out of the box, I suspect MS will make greater evangelizing efforts. Or maybe, they will wait until one of their browsers support it.

In this post I rambled on how liberating it can be to build something small on your own now and then, just to keep your sanity and escape from software in the real world. This post got picked up by Hacker News, making it the second entry in this list.

In one of those sporadic academic moments, I had a look at one of the quirks in anonymous type equality. I also looked at the reason why anonymous types can be compared in the first place, being reference types after all.

Starting with a new sideproject in ASP.NET MVC a few months ago, I experimented with patterns to build viewmodels and extract domain models back out of the viewmodels. This last post was featured on the ASP.NET homepage for a few days, ensuring this last topic made the list.

To wrap up this link collection, I would like to thank you for reading. I hope to see you contribute to this little outlet of mine for another year.

Sunday, November 27, 2011

When should you take performance into consideration?

Before publishing my previous post on rewriting an if, I knew some people would hate it, because the refactored construct is less performant.

Although I think performance is important, relevant performance improvements are, apart from in tight loops, hardly ever to find in language constructs. To put it more bluntly, they are a waste of time. When translating your thoughts into code, you should aim to make your intentions as clear as possible for the person who comes after you. Don't obfuscate your code for an negligible performance improvement.

I'm not advocating readability and pretty code are an end goal, performance and quality still are. But look for optimizations where it counts: optimizations which, after measuring, prove to be make a significant impact on the overall performance of your system. These are most likely to be found in I/O operations, architectures and algorithms. Not in language constructs.

Thursday, November 24, 2011

Rewriting an if

Yesterday I came across an if statement that looked something like this.

if (arg == "a" ||
    arg == "b" ||
    arg == "c" ||
    arg == "d" ||
    arg == "e")

An alternative way of writing this could look like this.

if (new [] { "a", "b", "c", "d", "e" }.Contains(arg)) 

I can't remember in which Github repository I spotted this technique, but I'm sure it was written in something other than C#. I think it works for C# as well though. The language hardly gets in the way, although it would be nice to be able to drop the new.

This is one of these trivial things I tend to geek about. The condition fits on one line now, making the eyes do less work. Also adding a variable is less work; you don't have to enter and indent accordingly. I think it's a win in readability, size and maintenance.

But then I stop and wonder: how do you feel about this construct?

Wednesday, November 23, 2011

Blame no one but yourself

Blame no one but yourself. This is one of the few quotes I remember months after reading this book. Although it's a harsh statement, there definitely is some truth to it.

Once I started observing my own behavior when faced with failure, I caught myself regularly blaming others for failures to which I am - at least - an accomplice.

Think about it. You might be guilty of this too.

Frustrated with management because you missed their too tight deadline? Did you tell your project manager that taking that 'one small' task in between would get you behind on schedule? Dissapointed by your team mate because he messed up the task you asked him to do? Are you sure you gave him all the information and provided enough feedback? Tired of doing the same repetitive task over and over? Why haven't you automated it yet? Not happy with a certain implementation? Did you speak up and propose alternative solutions?

So next time you blame someone else, ask yourself: Did I try everything within my reach to make this work or did I unconsciously sabotage this myself?

Sunday, November 20, 2011

Daydreaming about jQuery Mobile and the WebAPI

I recently blogged about programming for the future of mobile with jQuery Mobile and the WebAPI. You probably heard that jQuery Mobile 1.0 was released earlier this week. Although it will take a while before we will see some actual results from the WebAPI initiative, that shouldn't keep us from letting our minds play with things that might be possible one day using the WebAPI.

The thoughts in this post were provoked by an interesting comment Kristof Claes left on my previous post.
One thing I don't like about jQuery Mobile is that it has this iPhony (pun not intended) look to it.

I have a WP7 device and for some reason I don't want applications to look like I'm using an iPhone. I can imagine the average iPhone user wouldn't be happy when jQuery Mobile used a Metro-like skin.
And I agree, it does look iPhony. Although there already is a themeroller for jQuery mobile, it's limited to changing the color scheme. Like Kristof said, the contrast between the Metro UI and the jQuery Mobile UI is enormous.

Platform specific themes might help to close that gap. I really think this makes sense for mobile, because - compared to desktops - most mobile operating systems do leverage a signifantly different feel. Also, the browser is full screen on most mobile devices, saving space, but also losing the native OS context.

I have been thinking a bit about how this could be implemented. So follow along, and let me know if these ramblings seem feasible.

Serving themes based on the operating system should be doable. A naïve implementation, which only supports Metro, could be as simple as this.
return Request.UserAgent.Contains("Windows Phone OS 7.5") ? "jQueryMobile.Metro.css" : "jQueryMobile.Default.css";            
On my Windows Phone, I can configure the background- and the accent color for the Metro UI. And this is where it gets interesting. Using the SettingsAPI, defined in the WebAPI standards, we might be able to find out those values in our webapplication. Meaning we could make the mobile UI 'experience' completely transparant.

The proposed Settings API standard looks like this.

interface SettingsManager
    // List of known settings.
    const DOMString FOOBAR = "foobar";
    // Setters. SettingsRequest.result is always null.
    SettingsRequest set(DOMString name, DOMString value);
    SettingsRequest set(DOMString name, long value);
    SettingsRequest set(DOMString name, long long value);
    SettingsRequest set(DOMString name, float value);
    // Getters. SettingsRequest.result will be of the requested type if the success event is sent.
    SettingsRequest getString(DOMString name);
    SettingsRequest getInt(DOMString name);
    SettingsRequest getLong(DOMString name);
    SettingsRequest getFloat(DOMString name);

So, dynamically modifying the css to comply to the Metro color sheme could be this easy.

var backgroundColorRequest = settingsManager.getString('metro-backgroundColor');
backgroundColorRequest.onSuccess = function() {
    $(".main").css("background-color", this.result);
var accentColorRequest = settingsManager.getString('metro-accentColor');
accentColorRequest.onSuccess = function() {
    $(".tile").css("background-color", this.result);

Is it just me, or does the WebAPI have some sick potential?

Wednesday, November 9, 2011

Programming for the future of mobile

I have been working on something small on the side lately. I hardly have anything to show for it though, most of it is still being shaped in my head.

Anyhow, a very important part of the front-end is built using jQuery mobile. Although the framework hasn't been released - release candidates are available though -, it's something you should start looking into today. Why? Because the browser is the future of mobile applications. With the Flash and Silverlight bombs that were dropped today, I am even more confident that that future might be nearer than we think.

Built upon the jQuery and jQuery UI foundation, jQuery mobile aims to make mobile web applications seriously cross-platform and cross-device, while optimizing for touchfriendliness. From what I've seen so far, the jQuery team has (once again) succeeded at making the web just work.

To start using jQuery mobile, you just have to add one extra script file and one stylesheet on top of the existing jQuery infrastructure. Once that is done, the framework will already do most of the heavy lifting for you. Depending on your needs, you might want to enrich some elements explicitly in a nice semantic fashion.

For example, this is how you would get some collapsible panel action going.
<div data-role="collapsible" data-theme="c" data-content-theme="c" data-collapsed="@dataCollapsed" id="entriesList">
    <ul data-role="listview" data-inset="true" data-theme="d">        
        @foreach (var entry in entryGroup.Entries)
                @entry.CreatedOn.ToString("HH:mm") @entry.Description                     
To give you an idea, this would result in something that looks like this. Clean, right?

Now that these problems are out of the way soon, the only barrier left for mobile web applications is that the browser has no actual hooks in the device itself. But this last barrier can't hold forever... Mozilla initiated a very interesting project not so long ago. They started defining standards for a set of APIs that should give you direct access to the device: a camera API, telephony and messaging API, accelerometer API.. Find everything about the WebAPI initiative here. Subscribe to the mailing list, participate and help pushing the web forward.

I'm fairly optimistic about the future of mobile web applications. It's impossible to put a timeframe on it, but eventually WWW, the Web Will Win.

Sunday, October 30, 2011

The gift of legacy

Just after graduating, I hated legacy with the heat of a thousand suns. I felt unfortunate, having to work on old code, built using outdated technologies, while software is all about making new and shiny things. Right, guys? Those naïve expectations of a rookie got crumbled very soon. Legacy is a constant in our industry. You can try to ignore it as long as possible, but it's impossible to keep that up forever.
Over the years, I have come to accept that. I even have been fully embracing it lately.

Legacy is an opportunity to learn from the past. To learn from the costly mistakes our predecessors made, so you can avoid them in the present. Often legacy also helps me fully comprehend the motivation behind more modern architectures and software practices. Finding yourself all alone in thousands of lines of code, where the smallest change can impact an unknown amount of long forgotten scenarios, makes it perfectly clear why we test our code, and why it should be a crime not to.

It's a shame that there often isn't a whole lot of glory in maintaining old software. Although, I do think some programmers should be awarded a medal of honor after serving multiple months in the trenches. There is, however, a lot of space to make small refactorings, improving the code quality and in the meanwhile giving you the small wins you need to keep going.

All legacy isn't bad per se though. Once in a while you discover a ruby in the dust; a creative solution or a small but interesting trick, which you might be able to apply later on.

Legacy is a gift, learn to embrace it.

Wednesday, October 26, 2011

Oops, Pluralsight

Only a few weeks ago, we got an annual Pluralsight subscription at Euricom. Since then, I have downloaded a couple of videos, raw wmv's, to watch offline on my laptop, commuting.

Yesterday, being out of material, I headed over to the Pluralsight website to download some more content. I discovered the site was redesigned, removing download links next to the videos.

Heading over to their blog, I found out more.

On 24 October, they announced the site redesign, obsoleting the download links and focusing on support for mobile devices.
However, this change does require you to have a supported mobile device to take advantage of offline viewing moving forward. We no longer support offline viewing on laptops/desktops, at least for now. 
Just one day later, after receiving - probably a shitload of - negative feedback, they promised to support offline support for laptops and desktops in the near future again. 
We’ve listened to your feedback and have decided to support offline viewing for laptop/desktop users. We’re going to implement a desktop app that will provide offline viewing as soon as possible. We’re going to work around the clock to get this desktop app ready for release as soon as possible and hope to have the initial beta out within a few weeks from now.
After reading the initial post, I was somewhat dissatisfied as a customer. I knew the decision had to make sense though, from a business perspective. Supporting less platforms means less code, which is good. And mobile is big, it feels big anyway.

Based on the time it took to make the second announcement, I'm pretty sure mobile is nowhere near big enough to forget about laptops and desktops. Hey, being able to have a desktop on my lap still feels mobile enough to me.

I'm satisfied again though. I'm content Pluralsight didn't pull a 'Steve Jobs', and just pushed through their vision. Or maybe, they just can't afford to make a small (?) percentage of customers unhappy.

Some other random thoughts: Pluralsight, is it hard to include the links back in the website for now? Or is all the old infrastructure gone? What were other (business?) motivations to completely get rid of raw videos? Pirates, aay?

Monday, October 17, 2011

Viewmodel extractors in ASP.NET MVC

Last week, I wrote something on assembling viewmodels in ASP.NET MVC. In that post, I said it would be nice to have a layer between my controller and my domain services that would assemble viewmodels for me. This would work one-way. In the other direction - from controller to domain services - I would just take a piece of my composite viewmodel and pass that directly to my domain services.

Well, that last part didn't really work out eventually. I found it hard to find real-world scenarios where I could just pick a piece of my viewmodel and directly pass it to the domain services.

I was in need of something that could extract my domain models from my dumb viewmodels. I really didn't want this logic to be a fixed part of my viewmodel, nor did I want to make helper classes for these utility methods. Looking for a place to put this, I thought of a set of extension methods that pulls out every useful domain model per viewmodel.
public static class AddEntryViewModelExtractors
    public static Entry ExtractEntry(this AddEntryViewModel addEntryViewModel) 
        var entry = new Entry();
        entry.Activity = new Activity();
        entry.Activity.Name = addEntryViewModel.ActivityName;            
        entry.Meta = addEntryViewModel.Meta;
        return entry;

This makes it possible to do something like this in my controller.

public ActionResult Add(AddEntryViewModel addEntryViewModel)
    if (ModelState.IsValid)
        return RedirectToAction("Index", "Home");
        return View(addEntryViewModel);

So far, I'm liking this approach, pushing code away from the controller, helping me to keep my controllers as lean as possible. I also enjoy that it's trivial to test these extractor methods.

Oh btw, I had a chance to look at AutoMapper, but I haven't decided yet whether I find it helpful or not. I hardly came across scenarios where simple mappings were sufficient.

As always, I welcome your feedback and thoughts!

Wednesday, October 12, 2011

Viewmodel assemblers in ASP.NET MVC

Working on a new ASP.NET MVC side-project, I have the luxury to experiment with new technologies, but also with different patterns and naming conventions.

Something which bugged me in a previous project was that we made our service layer return viewmodels. It worked rather well because the service layer in our MVC project was just another layer between the real domain services - where most of its work was creating viewmodels from domain objects or translating viewmodels into domain objects, so they could be passed to the domain services. Although it somehow worked rather well, it felt dirty. Mostly because the name service is so overloaded and overused, that it's often not clear what its responsibility is.

Searching for a more meaningful name, I thought of an assembler. A simple object which fetches some domain objects and assembles them into a clean viewmodel. I also consider making the assemblers work one-way, from domain objects to viewmodels. Wrapping communication in the other direction feels like overhead, bringing no added value. I'm comfortable making the controller responsible for taking a piece of my composite viewmodel and passing it to the domain services, avoiding layers of unnecessary abstraction where possible.

I tried representing this into a nice PowerPoint drawing.

Something for me to find out in the coming days, is how AutoMapper can facilitate me in assembling these viewmodels.

Anyway, as always, I appreciate your feedback. How do you handle these scenarios? I'm also interested in hearing what naming conventions work for you.

Saturday, October 8, 2011

Commute hacking: Chromapaper

Since I changed jobs, I do my daily commute by train. This adds two hours of leasure time to the day, which I used to lose in traffic.

So far, I have been spending these two won hours programming and/or reading. I have been looking for a way to read online content offline on my laptop. Searching for software that could make this happen, I mostly came across programs which would mirror a whole site locally. Eventually I asked Twitter, and Lee Dumond pointed me to Chromapaper.

Chromapaper is a free Chrome application which caches Instapaper entries locally. Through the day, I mark interesting, but lenghty articles for reading later, so that I can simply synchronise them to my machine before leaving the connected cocoon.

You can find the Instapaper and the Chromapaper plugins in the Chrome Web Store.

Add articles to Instapaper, and start an offline sync.

Open Chromapaper offline.

Thursday, October 6, 2011

Book review: The Art of Unit Testing

I think The Art of Unit Testing targets a broad audience. Beginners will find every part of the book useful, where intermediates might be more interested in the final two parts.

Roy Osherove starts this book by laying a solid foundation of the unit testing concept. Why is testing important? What defines a good unit test, and how does a unit test differ from an integration test? In the second part of the book, he demonstrates the use of two core unit testing techniques: stubs and mocks. After showing you how these techniques work, he shows off various isolation frameworks which can help you creating stubs and mocks at runtime (fakes), greatly reducing the effort of writing these objects.

If you have some experience with unit testing, you might not be impressed with the content of the book so far. If you're somewhat like me, and have been writing tests for some while, but often find yourself wondering if your tests will still be considered solid six months from now, you will find the content of part three very useful. In this part, Roy talks about organizing your tests and how to strive for satisfying the three pillars of good tests: trustworthiness, maintainability and readability.

The final part wasn't something I expected to find in this book. In this chapter it's very clear that the author has been an agent of change himself for a long time. Next to sharing successful strategies on how to usher testing into the organization, he answers a bunch of hard questions you will be asked when you're on your own quest to bring change.

As I said before, there's something in the book for everyone. While there are a lot of topics discussed, the book counts less than 300 pages. It's well written at large, sometimes a bit sloppy, but in general a smooth read. All of the concepts are explained using examples written in C#, where the problems are small enough to keep it simple, yet comprehensive enough to make it a plausible scenario.

If you want to start out with unit testing, are looking for confirmation on how you're doing or want to refine some techniques, this book might be the one to get.

Sunday, October 2, 2011

Ninjecting MVC3

Dabbling with a new MVC3 side-project, I chose Ninject to handle dependency injection. The creative project name might have something to do with that decision. So far, I am really impressed. Setting up Ninject is a breeze, and the framework does a really good job of not getting in your way.

In this post, I will walk you through a simple MVC3 project using Ninject.

Adding Ninject

Adding Ninject to your MVC3 project is simple enough.

Open the Nuget console and type 'Install-Package Ninject.MVC3'. This will make Nuget go to work, fetching the NinjectMVC3 package and its dependencies.
Attempting to resolve dependency 'Ninject (= && <'.
Attempting to resolve dependency 'WebActivator (= 1.4)'.
Attempting to resolve dependency 'Microsoft.Web.Infrastructure (='.
Successfully installed 'Ninject'.
Successfully installed 'Microsoft.Web.Infrastructure'.
Successfully installed 'WebActivator 1.4.4'.
Successfully installed 'Ninject.MVC3'.
Successfully added 'Ninject' to PrettyDIBaby.
Successfully added 'Microsoft.Web.Infrastructure' to PrettyDIBaby.
Successfully added 'WebActivator 1.4.4' to PrettyDIBaby.
Successfully added 'Ninject.MVC3' to PrettyDIBaby.
Making up some dependencies

Let's add an ITimeService to our models.
public interface ITimeService
    DateTime GetCurrentDateTime();
The implementation could look like this.
public class TimeService : ITimeService
    public DateTime GetCurrentDateTime()
        return DateTime.Now;
Now, we can make our HomeController depend on the ITimeService by adding it as a constructor argument.
public class HomeController : Controller
    private ITimeService _timeService;

    public HomeController(ITimeService timeService)
        _timeService = timeService;
The Index action on our controller will make use of this service to display the date on the Index view.
public ActionResult Index()
    ViewData["Time"] = _timeService.GetCurrentDateTime();

    return View();
Binding them dependencies

So far we have added Ninject to our project, added a silly ITimeService, and made our HomeController dependant on that service.

The only thing that's left for us to do, is binding the ITimeService interface to the TimeService implementation.

If you look in your project root, you will find an App_Start folder, containing a NinjectMVC3 class. All of this was added by Nuget for us. The NinjectMVC3 class is used to initialize and shut down Ninject using the bootstrapper. WebActivator makes sure that this happens when the application starts and stops. When the Ninject bootstrapper is initialized, we need to bind our dependencies.

In our example, I modified the RegisterServices method to look like this.
private static void RegisterServices(IKernel kernel)
Finishing strong

Et voila.

There is no need to mark your dependencies in the controller, nor is there any need to resolve your dependencies through the dependency container. Ninject will automagically resolve your dependencies.

You can download the source here.

Thursday, September 29, 2011

A real developer knows when to pull the plug

My mini-website will no longer be available online after tomorrow.

I slapped it together over a weekend, trying out WebMatrix, which turned out to be the perfect companion for building small things.

A pleasant surprise was the mention of 'A Real Developer' by the guys at Channel9. This made the traffic go through the roof for a few days.

A few months later the site was a ghosttown. But I don't mind, I even predicted this. It never had the ambition to deliver real value. I was more than happy to deliver five minutes of entertainment.

To have a memento, I uploaded the source to GitHub. Remember, it's far from clever or impressive. However, I do think it can serve as a nice introduction-by-example to WebMatrix.

I committed the latest database as well, so now you can read all the quotes (even the bad ones), and start your own t-shirt business ;).

Wednesday, September 21, 2011

Comfortably numb

Something that can bother me tremendously is being surrounded by people who are in a constant state of being comfortably numb. People who don't welcome change, try to scare away new concepts and are just too much at home in their comfort zone. Some are perfectly happy filling their days keeping up appearances of being busy. They don't care about self-improvement, but only care about augmenting their paychecks by accumulating as much legacy baggage as possible, with the sole intention of being perceived as an irreplaceable asset to the company, whilst not having to leave their comfort zone. These people also have the tendency to shy away from responsibility and commitment. They are satisfied with doing just enough to not draw any attention to themselves.

It's really tempting to just go along, and follow. After all, it's in human nature to strive for comfort: the path of the least resistance. If you are reading this blog, you probably already belong to the group of people who care about their craft, and are aiming for something more than the status quo. I applaud you. For you, this post only serves as a reminder that you should constantly evaluate your current position and be honest with yourself: Am I still moving forward?

Sunday, September 18, 2011

Building small things

Due to the nature of things we build in our day to day job, writing software can wear out even the most fit of us.

Most software jobs make you constantly deal with complexity. The amount of things which can lead to a complex software project are immense. A poor first design, and failure to redesign. External dependencies, which seem to behave different every time around. Or just the complexity of the problems itself.
You are almost always working in a team, which can be exhausting as well. If the team doesn't share your passion and you have a hard time getting your ideas across, you will get frustrated, real soon. Add some coroporate politics to the mix and you'll be on your way to Paranoia.

It feels like I'm turning this into a rant, but I'll stop right here, you get where I'm going at. Building software in the real world can be hard. Very hard.

I like to think building something small on your own once in a while can be extremely liberating. It can help you keep your sanity and not lose your passion towards software. You pick what to build. Something small. Something new. Something built with your favorite tools, on your favorite platform. Something that can be shipped. Something which takes only you and your machine.

Having problems finding something meaningful to make? Look around you, the most trivial problem can lead to a satisfying little sideproject. Look for things that bother you, and try making them bother you less. Listen to others, maybe you can help solve their problems. Who cares if it already exists in one way or the other? Look for something that looks fun. And just build it.

Saturday, September 17, 2011

Once upon a time in the West

The girlfriend and I returned from our West Coast roadtrip yesterday morning.

We found this trip to be an unforgettable experience, which made us even more hungry for future travels.

This blog will return to business as usual, with mainly technical content and opinions.

Here is an overview of our posts exploring the West Coast:

Once upon a time in the West..

Tuesday, September 13, 2011

City of fallen angels

After seeing the celebrities at Madame Tussaud's in Las Vegas, we went for the real deal.

Turns out Hollywood is a lot less glamourous than we expected. The Walk of Fame isn't a lot different from any other gray sidewalk, paved with long-forgotten stars. The famous Hollywood sign isn't even lit a night, making the contrast with Beverly Hills at the other side of town even bigger. 

Maybe there's another side to Hollywood that we haven't seen, since we only stayed for two days, one of which at the Universal Studios. Here we took a sneak peek behind the scenes of movies like The Fast and the Furious, Jaws and Jurassic Park. We also drove through Wisteria Lane and other generic-built shooting sets.

This will probably be our last post from the US. We will spend our last few days driving the coast line back to the Bay Area, to depart there on Thursday.

Sunday, September 11, 2011

Fear and loathing in Las Vegas

Driving back into the desert after our breakfast, with Las Vegas in the rear-view mirror, we secretly feel a little relieved to be heading back to the real world. The cocktail of fake pyramids, indoor jungles, Paris landmarks, castles and volcanoes became a little nauseating. With hotels and casinoes resembling labyrinths, designed to get people trapped inside, it feels liberating to drive through the wide open landscape again.

Some of the things we enjoyed the most were the late nights walking the Strip, watching free shows, standing on top of the Stratosphere and posing with the wax celebs at Madame Tussaud's. 

Although we had a great time, Vegas probably only shows its full potential when you're a highroller.

Wednesday, September 7, 2011

Edge of eternity

We all know the Grand Canyon as one of the seven natural wonders of the world, today I learned why. As one of the locals described: 'Pretty amazing for a big hole in the ground'. 

Being the closest to the south entrance, we visited the South Rim of the canyon. A trip to the visitor center taught us there were no easy hikes (except for the going down part), so we didn't attempt at one. A hike down the canyon and back up is a two day endeavor. A shuttle bus took us along the scenic route, dropping us off at three viewpoints. Standing on the edge, stunned by the view, we were accompanied by some California Condors circling above us. However, their view must have been more impressive, being able to stare down right into the 4000 feet (1200m) deep canyon. 

After visiting the park, we went to see the National Geographic Grand Canyon movie at the IMAX. This film revealed parts of the inner canyon, following in the footsteps of John Wesley Powell. The show is a cheap alternative to an expensive helicopter flight through the canyon.

Tomorrow morning we will return to the more civilized (?) man-made world: Las Vegas.

Tuesday, September 6, 2011

From Glen to Grand

Yesterday, we drove from Saint-George to Page, Arizona. The Pipe Springs National Monument happened to be on our way, so we made a stop. Turned out there wasn't much to see. A 30-minute ranger-led tour made it worthwhile though. During the tour through the Winsor Castle, she told us about the Mormons who used to live there. The Fort manager, also head of their Mormon church, married 58 women, resulting in plenty of children to work the Fort.

Arriving at Page, we hiked the Horseshoe Bend trail, which ended in one of the most amazing views we've seen so far. To cool off, we took a swim in Lake Powell, the reservoir above the Glen Canyon Dam

Today we took a guided tour through Antelope Canyon, which resulted in some interesting pictures. 

At the moment we're in Flagstaff, which will be our launching point to the Grand Canyon tomorrow.

Sunday, September 4, 2011

Rusty rocks

We started the day with a short drive to Zion National Park. On our way we came across some colossal rock formations, layered with different shades of red. Since the park is almost entirely car free, we took the shuttle bus along the scenic route. We got off at different stops, to take short hikes to the park's natural treasures. The Emerald Pools were first up, followed by the Weeping Rock and a riverside walk to the Narrows, which are architected by the Virgin river. Wading in the river gave us some much needed refreshment after a long day of hiking.

Our next destination is Lake Powell.

Saturday, September 3, 2011

Sands of Nevada

Yesterday evening we spent the night in a town called Tonopah, which is literally in the middle of nowhere. Today we continued our trip to Zion (Utah), driving hundreds of miles through the Nevada desert, getting sunburned on the way. There was not a soul in sight, except for cattle crossing the road, who seemed to be waiting for us to pass to say hello. 

We just arrived at St. George, which is a launching point to Zion National Park.

So, not much to report today. Anyway, here are a few random pictures of our drive through the Nevada desert.

Friday, September 2, 2011

Yosemite skyscrapers

These skyscrapers are, other than the enormous mountains, the redwood sequoia on top of them. Some of these trees are the same height as a thirty story building, which is higher than the Statue Of Liberty. It's almost impossible to capture these giants on camera. 

After a short hike between the sequoia, we drove off to Yosemite Valley to discover the Yosemity Falls. Although the falls must be more impressive in Winter, they were still worth visiting. 

Today we drove through Yosemite National Park once again, this time on our way to cross the border to Nevada. On the route, we came across breathtaking swirling roads. 

Just before crossing the border to Nevada, we stopped at two Mono Lake vista points.

Tomorrow, we are continuing our trip to Zion

Wednesday, August 31, 2011

If you're going to San Francisco

While I'm writing this, the girlfriend and I are on our way from San Francisco to Yosemite National Park. We have spent two full days visiting 'Fog City'. During these two intensive days we were able to see everything we aimed for, maybe more.

Financial District

This part of town is definitely worth a visit. The multiplicity of skyscrapers merging into the San Francisco fog, is an impressive view. When the fog has gone, the shadows the buildings cast on each other are just as amazing.

Pier 39

While obviously a tourist trap, I found strolling through the shops and restaurants on the pier to be surprisingly amusing.

Alcatraz Island

One of the main attractions of San Francisco, and a must see. If you plan on taking a tour on the island, you must make reservations a few days ahead. We failed to do that, and ended up taking a cruise around Alcatraz Island. I feel like we missed out, but the boat tour was definitely good value for money too.

SS Jeremiah O'Brien

Not so far from Pier 39, you can find a very nicely preserved World War II liberty ship. If you have been on one of those ships before, it might not be worth the 10 bucks.

Lombard Street

Thé most famous street in San Francisco, but kind of overrated. Save yourself the steep hill climb, and try finding a view from a few blocks away.


Always a charming neighbourhood to window shop small boutiques for Chinese kitsch.

Golden Gate Bridge

An amazing piece of architecture. Can you imagine building that in the thirties? We drove there by bike, very recommended. Not for the faint of heart though.

Palace of Fine Arts

On your way to the Golden Gate Bridge, you should drop by the Palace of Fine Arts.


If Anonymous isn't hacking the Sony network, they are protesting in the streets of San Francisco.

I hope this post might have given you some ideas on locations to visit when you're going to San Francisco.