Of course, not everyone remembers to set those lengths, so I thought it'd be great if I could force people to do this. With a little creative use of Fluent NHibernate's conventions, it's quite easy to enforce this:

public class StringsMustHaveLengthConvention: IPropertyConvention, IPropertyConventionAcceptance
{
    public void Apply(IPropertyInstance instance)
    {
        var msg = string.Format("The string property '{0}' of type '{1}' does not have a length value specified, " +
            "which is required for performance reasons. Add something like this to your mapping override:\r\n" + 
            "\tmapping.Map(e => e.{0}).Length(50); // with an appropriate length for this property",
            instance.Property.Name, instance.EntityType.Name);

        throw new MappingException(msg);
    }

    public void Accept(IAcceptanceCriteria<IPropertyInspector> criteria)
    {
        criteria.Expect(x => x.Type == typeof(string)).Expect(x => x.Length == 0);
    }
}

With that convention in place, you won't even be able to run your code until you've specified the string lengths

The biggest issue with storing passwords is that you have to assume that it's always possible that someone can get access to your database. Yes, even if it's not directly exposed to the outside world, which it never should be. Whatever security measures you've put in place to protect your database, it's a good idea to assume that sooner or later, someone will be able to punch a hole through your security measures and be able to read the data. So obviously, you really don't want to store clear-text passwords. You also don't want to store encrypted passwords because encrypted data can always be decrypted. And if people get access to those encrypted passwords even if they weren't supposed to, it'd be wise to assume that they also know how to decrypt them, or that it won't take them long to figure it out.

A much better approach is to store a hashed representation of the password instead, using a strong one-way cryptographic algorithm and a unique salt value per password. If the cryptographic algorithm is one-way, it means you can't apply another algorithm to get the original source value again. The only way to compare passwords is to apply the cryptographic algorithm on a given password using the originally used salt value, and then compare the resulting hash with the one you've stored. If they are identical, the given password is the same as the one that was used originally. If they differ, the password is invalid.

Attackers can still employ rainbow tables to try to find password values that generate the same hashes as the ones in your database. Luckily, generating rainbow tables takes time and plenty of space as well so it makes it much harder for attackers to find the passwords. This is why it's so important to use a unique salt value per password. It effectively means that a rainbow table would have to be generated for every single salt value that you've used, making it practically infeasible to find the original password values.

Let's demonstrate this with a simple example. The example is from a Node.js application, but this technique can be applied with whatever technology stack you're using.

This is my User model:

var mongoose = require('mongoose'),
    crypto = require('crypto'),
    uuid = require('node-uuid'),
    Schema = mongoose.Schema,
    ObjectId = Schema.ObjectId;

var userSchema = new Schema({
    name: { type: String, required: true, unique: true },
    email: { type: String, required: true },
    salt: { type: String, required: true, default: uuid.v1 },
    passwdHash: { type: String, required: true }
});

var hash = function(passwd, salt) {
    return crypto.createHmac('sha256', salt).update(passwd).digest('hex');
};

userSchema.methods.setPassword = function(passwordString) {
    this.passwdHash = hash(passwordString, this.salt);
};

userSchema.methods.isValidPassword = function(passwordString) {
    return this.passwdHash === hash(passwordString, this.salt);
};

mongoose.model('User', userSchema);
module.exports = mongoose.model('User');

Notice that the salt property of my User type has its default value set to 'uuid.v1'. In this case, uuid.v1 is a function which will be invoked by Mongoose whenever a new User instance is created. Every User instance will thus have a UUID value stored in its salt property. You can also see that I'm not storing the given passwordString in the setPassword function, but that I calculate the hash value based on the passwordString and the UUID salt value.

Suppose I create a user with the following code:

var user = new User({
    name: 'test_user',
    email: 'blah'
});
user.setPassword('test');

user.save(function(err, result) {
    if (err) throw err;
}); 

Its database representation will look like this:

{ 
    "passwdHash" : "b604367796274cf64177eec345532fc6ca66c6f0501906f82bb03f7916265e9d", 
    "name" : "test_user", 
    "email" : "blah", 
    "_id" : ObjectId("4f1dbb2cfa6157b118000001"), 
    "salt" : "304a33f0-45fc-11e1-80d2-43c594a44fa0" 
}

If an attacker would get access to this, he'd have to generate a rainbow table using the salt value, which takes time, and even then he has no guarantee that the rainbow table will actually contain the correct password. Again, this is why it's so important to use a unique salt for every password. Also, you can use whatever value you want as the salt value so if you can determine it based on some other fields or by using a specific formula you don't need to store the actual salt value. It's recommended to use a long salt value though. Theoretically speaking, it's safer if the salt value isn't stored so clearly as I'm doing here, but even with the salt value clearly visible to a possible attacker, it would still be practically infeasible for him to generate all those rainbow tables.

And of course, my actual authentication function is still very simple as well:

var authenticate = function(username, password, callback) {
    User.findOne({ name: username }, function(err, user) {
        if (err) return callback(new Error('User not found'));
        if (user.isValidPassword(password)) return callback(null, user);
        return callback(new Error('Invalid password'));
    });
};

So as you can see, there's nothing hard or complicated about storing credentials in a secure manner. It's quite easy to do so and there are no downsides to doing this.

So as I was browsing through a few possible alternatives for my authentication needs, I started thinking about my thought process when evaluating libraries/frameworks to use. I generally base my decision on the following items, listed in order of importance (to me):

• How well does it work for my scenario? If a library satisfies all other items on this list, that certainly doesn't mean it's an automatic lock. How it works and the impact it has on my code is definitely the most important factor.
• Popularity. I've noticed that I let the number of watchers/forks on sites like Github influence my opinion. If a project has many watchers and many forks, odds are high that there's a relatively large group of happy users as well as people involved with the project. It also increases the odds that the project will be around for a while. Of course, inactive Open Source projects often remain available as well but if nobody's working on it, I'm not exactly tempted to take a dependency on it. Log4net is a notable exception to this, obviously. But when a project has a lot of people interested in it, or better yet, contributing to it, it's a good sign that you'll easily get help if needed, it's only going to get better in the long run and that it might get forked should the original developers stop working on it. As the author of an Open Source project that doesn't have a lot of watchers/forks (Agatha), I'm aware that my point of view on this is rather hypocritical but hey, it is what it is.
• Code quality. I don't have the time to do an in-depth review of the code as I'm sure most of us don't do either. But I do like to glance over the code to get a general feel of the quality of the code. I focus mostly on the clarity of the code and also keep an eye open for sloppiness or downright WTF's. I guess the questions I'm mostly trying to answer when doing this are: "is this code I'd like to try to improve or fix if I need to?" and "how easy would it be to debug this when I need to troubleshoot some non-obvious issues?".
• Location of code and issue tracker. A lot of people will probably take issue with this, but I consider it to be a major plus if the project is on Github. Not just because of my personal preference of Github, but because they truly encourage people to collaborate and contribute to projects and they make it very easy to do so. Also, the site is fast! I cringe when I have to look over issues of projects on Codeplex because it's just terribly slow. And the UI doesn't come close to that of Github either. I've heard that Bitbucket is pretty similar to Github, but I've never even looked for projects there. In any case: I want to be able to download the latest version of the code at any time, or of a particular branch if I need to, as easily as possible. I also prefer an issue tracker which is fast, responsive and easy to search. It doesn't have to be Github, but those 2 requirements are important to me.
• License. If it's GPL, I don't use it. Also, I check whether or not a commercial license needs to be purchased when you want to use the library/framework in production. Pay attention to dual-licensed projects because that Open Source license might not apply to commercial/production use!

I'd love to hear your thoughts on this. Did I miss any important factors? I just quickly put this post together so it's likely that I missed some good ones

First of all, you need a way to start your Node.js process automatically when your system boots, and to shut it down when the system is shut down. This will depend on the type of server you're running on. In my case, it's a Debian server so I just went with the sysv init script from Nico Kaiser. Another popular alternative is the upstart utility, which is already preinstalled if you're using Ubuntu. Once you have a start|stop|restart script in place, you'll want something to monitor the Node.js process to restart it in case it goes down. An easy to use tool for this is monit. Nico Kaiser again has a good example script available for Node.js on Github.

Once you have your sysv init or upstart script in place, as well as monit, your Node.js process can stay running on your server. Of course, you probably have it set to listen to connections on some other port than port 80 because that's what your Apache server is listening on. So now, the only thing you have to do is configure Apache to proxy all requests coming in on port 80 through the URL of your Node.js site to your local Node.js process. You'll first need to install mod_proxy and mod_proxy_http. After that, the configuration to make it work is quite easy:

<VirtualHost 109.74.199.47:80>
    ServerAdmin davy.brion@thatextramile.be
    ServerName thatextramile.be
    ServerAlias www.thatextramile.be

    ProxyRequests off

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    <Location />
        ProxyPass http://localhost:3000/
        ProxyPassReverse http://localhost:3000/
    </Location>
</VirtualHost>

And that's it. Every request coming in at http://thatextramile.be or http://www.thatextramile.be will be forwarded to http://localhost:3000 where Node.js is listening. Note that the ProxyPassReverse is required to make sure that all HTTP response headers will contain the proxied URL instead of the real one (localhost).

If you need the raw throughput that Node.js offers, this solution is far from optimal. Every request that comes in through Apache will cause an Apache thread to wait/block until the response is returned from your Node.js process. This is essentially the same as when hosting PHP or Ruby through Apache, so it's not a problem, but it does take away one of the benefits of using Node.js. Again, this approach only makes sense if you're already using Apache to host other sites and you just want to add a Node.js site with minimal impact to your server.

So of course, I couldn't resist doing the site with Express/Node.js. And I'm pretty happy with the result too: about 130 lines of server-side code that allows me to write the content of the site in Markdown (including caching and automatically updating the cache if the Markdown files are updated) and my preferred solution to displaying feed items. Does a simple site like this call for Express/Node.js? Of course not. But I knew it would be simple and fun, so that's why I used it.

The hardest part was actually writing the content of the site. Apparently, writing content for a company website is a lot harder than churning out a few blog posts occasionally, and I definitely underestimated that. Not because there's a lot of content (there's very little actually), but because you want to avoid ending up with a lot of content. It has to be concise and yet still contain everything you want it to say. After many revisions, it says everything I want it to say, and unlike on this blog I actually managed to keep it short

An extra benefit of doing it with Express/Node.js is that it reminded me how much fun I have working with that stack, so I'm going to get back to work on my breakable toy which I've been neglecting for too long. I suppose this will lead to a few future posts as well

Another great part about being independent is that you're free to do extra things on the side as well. I'm very happy with the responses that I've gotten from the people who've taken my NHibernate course, and I'm going to continue to offer it in 2012. I initially thought it would be something I'd do once or twice, but I was able to do the course 4 times this year: 1 public and 3 private ones. I've got another private one scheduled in February and will organize another public course in 2012, though this time I'm taking care of the whole thing myself instead of working with another company to organize it.

The most important thing I've learned from this first year is that it's important not to try to do too much. The first 6 months of 2011 were way too busy and hectic, and I only spent one full day doing absolutely nothing work-related. I've been taking things much slower since July and I'm spending much more time enjoying other things in life outside of work. For 2012, my biggest priority is pacing myself much better and spreading things out more. I always seem to alternate between months where I'm always working on something, followed by months of doing as little as possible outside of the 40 hours a week I do for my client. Hopefully, I can finally find a maintainable balance between those two extremes in 2012

On the blogging front, 2011 was a different year than the previous ones on this blog. In the previous years, I averaged about 150 posts a year but this year I only published 71 posts. And I'm actually happy about that. In fact, I hope to get that number down to 50 next year. I still like writing posts, but I no longer feel the need to like I did in the past while I was trying to build a bit of an audience. That often meant pushing myself to keep publishing new posts. Nowadays, I'll only write a post if I really feel like it, which in the long run is much more sustainable anyway. As far as topics covered this year, things have changed quite a bit as well. Some of my views, opinions and technical preferences have changed this year, which naturally reflects in the content I've published. I'm sure I've lost some readers this year because of it, but I also seem to have gained a lot more readers than I've lost. I don't know yet what I'll be writing about in 2012, but I will continue to push people to learn new things (or old things that people seem to forget about) and do better like I always have on this blog, in my own unique way of course

I hope you all enjoyed Christmas, and I wish you all a happy 2012. If it does turn out to be our last year on this planet, we might as well make it count.

• It needs to be fast
• The fewer requests that are impacted by retrieving the feed data, the better
• If I publish a post, the links on the company website should contain the new link within 30 minutes
• The simpler the solution, the better

I came up with a very simple solution, which satisfies these requirements better than any other solution I could think of, or heard of from other people. It is extremely fast, doesn't delay any requests, and doesn't require me to deploy anything but the company website. I'm building the site with Express on Node.js, which means I can take full advantage of the asynchronous nature of Node.js to implement this.

Let's go over the code... in the script that starts the express server, I have the following code:

var express = require('express'),
    app = module.exports = express.createServer(),
    NodePie = require('nodepie'),
    request = require('request'),
    recentFeedItems = null;

app.dynamicHelpers({
    getRecentFeedItems: function() {
        return recentFeedItems;
    }
});

// ... some extra configuration of Express that isn't relevant to this post

var processFeed = function(callback) {
    request('http://feeds.feedburner.com/davybrion', function(err, response, body) {
        if (!err && response.statusCode == 200) {
            var feed = new NodePie(body);
            feed.init();
            recentFeedItems = feed.getItems(0, 5);
            if (callback) callback();
        };
    }); 
};

setInterval(processFeed, 1800000); // process feed items every 30 minutes

processFeed(function() {
    app.listen(3000);
    console.log('Express started on port 3000');    
});

I'll discuss the code in just a moment, but first I want to show the view code that renders the links:

<ul>
<% getRecentFeedItems.forEach(function(item) { %>
    <li><time class="date"><%= item.getDate().getDate() + '/' + (item.getDate().getMonth() + 1) %></time><a href="<%= item.getPermalink() %>"><%= item.getTitle() %></a></li>
<% }); %>
</ul>

And that's all. This is the solution in its entirety!

If you're new to Node, this code probably requires some explanation. Let's start with this part:

app.dynamicHelpers({
    getRecentFeedItems: function() {
        return recentFeedItems;
    }
});

Here I'm adding a dynamic helper to the Express application. It basically means that my views have access to the getRecentFeedItems function, which returns the value of the recentFeedItems variable. It's important to know that the getRecentFeedItems function creates a closure on the recentFeedItems variable created above it. That means that if the value of the recentFeedItems variable changes at any point in time, the getRecentFeedItems function will return that new value.

var processFeed = function(callback) {
    request('http://feeds.feedburner.com/davybrion', function(err, response, body) {
        if (!err && response.statusCode == 200) {
            var feed = new NodePie(body);
            feed.init();
            recentFeedItems = feed.getItems(0, 5);
            if (callback) callback();
        };
    }); 
};

This just creates a function that we can use later on. It retrieves the feed asynchronously, and when the result is retrieved, we parse the feed using the NodePie library and we get the 5 most recent items which we store in the recentFeedItems variable. Again, this creates a closure on the recentFeedItems variable which means that every time we assign a value to this variable, any subsequent call to the getRecentFeedItems function will return the value we just assigned to it because both functions point to the same memory thanks to the magic of closures. Finally, if a callback is provided as a parameter, the callback will be invoked.

setInterval(processFeed, 1800000); // process feed items every 30 minutes

processFeed(function() {
    app.listen(3000);
    console.log('Express started on port 3000');    
});

The call to setInterval makes sure that the processFeed function is called every 30 minutes. After that, we call the processFeed function manually, and we pass in a callback where we start the Express server. This guarantees that the feed items will be in memory before the server starts processing requests.

What makes this solution so great is that we take full advantage of some of Node's benefits. Whenever we retrieve the RSS feed, Node.JS will retrieve that data asynchronously. As soon as it has fired the request to get the RSS feed, it just goes to the next event in its eventloop so no request is kept waiting while we wait for the data to be downloaded. Until the data from the RSS feed is returned, each request will just use the items that are stored in the recentFeedItems variable. Once the data has been returned, our callback is executed which overwrites the value of the recentFeedItems variable. We don't need to do any locking here because the Node.JS eventloop is single-threaded: while our callback is running, no other code that has access to the recentFeedItems variable can be executed anyway. And the actual parsing of the RSS feed is done by NodePie, which uses expat behind the scenes, which is supposedly the fastest C XML parser available.

Looking back on my initial requirements, I think this solution matches very well.

Evented/Asynchronous I/O

In most technology stacks, API calls for I/O operations are synchronous. As in, the thread that executes the operation is blocked for the duration of the I/O operation until that operation has completed. Once completed, execution of your code proceeds. Of course, a lot of technology stacks have asynchronous variants of those operations available as well, but generally speaking, they aren't used as often as the synchronous variants. In Node.js, it's the other way around. All I/O operations are asynchronous and there are only a few synchronous implementations available (and you're generally discouraged from using them).

This means that whenever you do an I/O operation (file manipulation, network requests, database operations, etc…), Node.js initiates the I/O operation through a lower-level C/C++ layer which will perform the operation asynchronously. Once the operation has completed, Node.js will execute your callback function that you passed as a parameter to the I/O operation's function call. The important thing here is that while the I/O operation is being executed, Node.js doesn't have to wait for the operation to complete, and is able to focus entirely on processing other events. And those events can be anything: incoming network requests, executing callbacks from other operations that have completed, or invoking whatever function that is assigned to a particular event.

Eventloop

The Node.js eventloop is what makes Node.js so interesting and powerful. Node.js basically just keeps reading from an event queue until that queue is empty. As it loops through the events to be processed, it invokes the JavaScript functions that have been assigned for those events. If any of those functions performs an I/O operation, Node.js will initiate the operation and then immediately move to the next event in the event queue. Once the I/O operation has completed, an event will be added to the event queue with a reference to your original callback. Once all preceding events have been processed, Node.js will get to the newly added event and invoke your callback. Because all I/O operations are asynchronous, this enables Node.js to maximize its efficiency as it processes events because it doesn't need to wait for slow I/O operations to complete.

Single-threaded

One thing that people don't always realize is that the Node.js eventloop is single-threaded. This has some nice benefits but there's a huge drawback as well. The biggest benefit is that you don't need to worry about concurrent access to shared state. After all, there is never more than 1 thread executing your JavaScript functions. This means you don't have to write any locking code to protect shared state. The drawback to the single-threaded eventloop is that you need to be careful not to block the event loop. If you're planning on doing heavy synchronous processing in your JavaScript code, you need to realize that no other events can be processed by Node.js until that synchronous block of code has completed. Obviously, since there's only one thread going through the eventloop, any delay you cause in your code can be very costly to overall throughput and performance. For now, it's best to execute synchronous processing routines as a child process, possibly even in a language that is more suitable for this than JavaScript. But it seems that future Node.js versions will provide a more integrated way to deal with this.

Why JavaScript?

JavaScript's support of closures and it treating functions as first class objects means it's ideally suited for the evented programming model that Node.js offers. Many people still think of JavaScript as a joke or a toy language, but it's a lot more powerful than many people think it is. Yes, it certainly has problems as well, but it's definitely worth learning. I do hope that this post has made it clear that there's a lot more to Node.js than simply being server-side JavaScript. What makes Node.js so interesting are the principles that I've tried to explain in this post. Those principles can be implemented with other languages as well, and could be made to work just as great as, or perhaps even greater than Node.js itself. But you'd be hard-pressed to find a language that's so ubiquitous, yet completely devoid of a pre-existing synchronous I/O infrastructure.

Anyways, I hope I succeeded at making it somewhat clear how Node.js works and why it's so different from most other technology stacks.

Of course, I don't want to update those links manually whenever I publish a new post, so they need to be retrieved from my blog's RSS feed, which is published by Feedburner. I was hoping to be able to retrieve only the metadata from the posts (date, title and URL is all I need) because my feed always contains the last 20 posts and its total size is usually above 100KB. I haven't found a way to do that, so getting the information I need has to be retrieved through the full feed. Sure, 100KB isn't much but keep in mind that you need to retrieve it and parse it and that I absolutely want to minimize the time each request takes and that I'd rather not see any visual delays on the page either.

I'm interested in hearing how you would implement this. You have total freedom to pick the technologies you'd like to use and no limits on how you'd use them. My only requirements are these:

• It needs to be fast
• The fewer requests that are impacted by retrieving the feed data, the better
• If I publish a post, the links on the company website should contain the new link within 30 minutes
• The simpler the solution, the better

My solution can be found here.

A lot of people think that I'm anti-Microsoft. And I'm really not. I'm not anti-anything. I am pro-quality. I have high standards because I've seen and experienced high quality solutions elsewhere and when I have to deal with lower quality alternatives to those solutions, I tend to compare them, which is only natural. If Microsoft releases good stuff, I'm more than happy to use it. I even considered creating an Entity Framework training course, similar to my NHibernate training course, because I was hearing many good things about it. But after trying to deal with a certain Entity Framework problem that came up this week in the one project at work that uses Entity Framework, I couldn't help but think "I don't want this mess in my life, no matter how much money I could make with it". I sincerely want to use good Microsoft technology, but too often it just disappoints me. And that in itself, isn't much of a problem since there are plenty of good Open Source alternatives around. What I do consider to be a problem is the reaction that many people have when you're critical of Microsoft technology.

I've often compared it to living in The Matrix. A lot of us are living in a world where they are being pushed into believing something that just isn't true. And some of us at some point get to choose between taking the blue pill or the red pill. The blue pill symbolizes blissful ignorance of illusion, while the red pill symbolizes the sometimes painful truth of reality. A lot of developers in the Microsoft world choose to keep their eyes closed and blindly believe whatever Microsoft tells them to believe. They'll run into a variety of problems with the technologies they've been told to use but a lot of people just accept it for what it is because they don't know any better, or because they're scared of the seemingly harsh world that awaits them should they choose to ignore Microsoft's guidance and venture out into a world that is more chaotic, yet offers more possibilities and flexibility. If you take the red pill, you learn a lot about what's really possible yet you face the added burden of having to deal with the people who've picked the blue pill and even worse, the technology that comes with it. Because that truly is the only bad part about taking the red pill. You'll start taking some things for granted, and when faced with technologies that don't quite match up to what you've recently become used to, you will get frustrated because of it. After all, you know things can be done much better with less friction, yet here you are, dealing with problems that have been solved by other libraries/frameworks already. That is the only sour taste you'll experience after having swallowed the red pill.

The choice between the blue pill or the red pill is one that everyone has to make for themselves. And honestly, I can't be bothered anymore to try to convince people to take the red pill instead of the blue pill. I've learned to adopt a "whatever floats your boat without sinking mine is fine with me" attitude, but sometimes, I can't help but wish for a world were people would try to think just a little bit more for themselves instead of blindly following what a dominant entity is telling them to do or use. Look around, see what other people and communities are doing and honestly ask yourself "are they doing things better than I am?". And if they are, put in the effort to figure out why and how they're doing what they're doing. The worst thing that could possibly happen is a temporarily sour taste, and there are many ways to wash that away.

Of course, that doesn't mean that you have to approach it like that as well. You can indeed learn a lot about a certain technology while preparing for a certification exam, but the whole thing is completely devalued by the incredibly large group of people who do game the system and are only in it to add the certificates to their CV, or to demand a higher salary or rates because they are after all certified professionals. Never mind the fact that many of them never even bother to focus on learning fundamental principles that would benefit their careers as well as increasing the value they bring to clients/employers far more than intimate (temporary) knowledge of a specific technology that's probably going to be replaced by something new in about 4 years anyway. To those of you who've taken exams on WPF: how's that working out for you? Still debugging memory leaks I'm sure

Even though a lot of people know this all too well, they'll still come up with arguments like "but it really helps when clients ask for certificates" or "certificates give me a leg up when clients need to go over tons of CVs". Sorry, but I'm not buying it. Well, I do know that some companies indeed consider certificates a benefit when evaluating candidates but I prefer to look at it from a slightly different angle: those kind of companies often employ people who got their certificates by gaming the system at a much higher rate than companies who don't care about certificates and prefer to focus on real experience and solid knowledge of important fundamentals instead. Simply put: if you choose to work for companies that value certificates, odds are very high that you'll be working with certified idiots.

If you're wondering whether you should invest time in getting certified, I'd advise a different approach. Don't bother with certifications and spend your time and energy on attaining knowledge that will last you far longer, and will even improve your abilities of quickly picking up new technologies. And the way to do that is pretty simple. Work on hobby projects. Experiment with multiple technologies. Study code from established projects and developers. And read books. Lot's of them even! If you don't know which ones, I've got a good list available here and you might notice that the majority of those books are technology-independent. They focus on fundamental principles and common knowledge that you'll be able to reuse no matter what technology you're using now or will end up using later on.

Of course, all of this does take more effort than simply showing up for a 2-day course where everybody gets a meaningless piece of paper or spending a weekend cramming API details that you don't actually need to remember to be productive at your job. But hey, if your goal is to improve your value, and not just your perceived status, it's worth it, right?

Plenty of Silverlight developers were concerned that their investment in the technology would end up being worthless. I never really understood that since I've always believed that good developers focus on skills that are transferable to multiple technologies instead of betting it all on a single technology. Nevertheless, many Silverlight developers were up in arms, but their worries and fears seem to have been calmed by the news that Windows 8 will make extensive use of XAML. Silverlight developers will be able to transfer their XAML skills to building Metro apps and of course, WP7 apps. And there's no reason to assume that Microsoft intends to change its smartphone platform in a way that would diminish the importance of XAML. So, Silverlight developers who were worried that their skills will be worthless don't really have anything to worry about and I'm sure many of them are quite relieved by that. After all, many Silverlight projects will be able to run as native apps on Windows 8 with relatively minor modifications.

Of course, that doesn't quite offer a solution to the thorny little issue about all the Silverlight projects that have been developed because of some of the benefits that Silverlight promised: cross platform and browser-independent availability of the plugin. The promise was that you could develop projects that would be available to users no matter what platform or browser that they were using (believers of this promise would even mention Moonlight, which has never really offered a truly compatible version), and with no deployment-related issues. After all, users only needed to have the Silverlight plugin installed to run your software. And that promise has been broken. Yes, you can migrate your Silverlight projects to Windows 8. Yes, people will be able to keep running existing Silverlight projects as long as they have the upcoming Silverlight 5 runtime installed. But we also already know that the Metro version of IE10 will not run the Silverlight plugin and that running the plugin in the 'desktop' version of IE10 will require users to install it themselves. For enterprise software, that's not much of an issue but you do have to ask yourself: how long are you willing to hang on to a plugin that Microsoft itself is no longer interested in improving in the long run?

The reality of the matter is that your Silverlight products only have a future if you convert them to WinRT so they can run on Metro natively. Which means you've lost the ability to reach users on multiple platforms and devices. The very same technology you picked because of its cross-browser and cross-platform benefits has forced you on a path where in the future, you can only target users on the Windows platform meaning either Windows 8 or WP7. Sure, you can hang on to the fact that the plugin will be available for a few more years, but that also is a limiting choice since an ever increasing number of users will be running iOS and Android, and there's no reason whatsoever to expect the plugin to actually run on those platforms. Hell, WP7 doesn't even have the Silverlight plugin for its browser. My previous employer pretty much bet it all on Silverlight, mostly because they didn't want to deal with HTML/JavaScript, but also because they thought it would eventually be available on all devices. Which essentially means they're stuck with a couple of products that only really have a long-term future on Windows 8 or WP7, and its subsequent versions. Unless of course, current promises about said platforms are broken again. Yet another reason to start taking open standards and technologies that have multiple stakeholders seriously, I suppose.

The simplest, and probably most effective example is that of giving developers SSD's instead of regular disks. I'm willing to bet that using an SSD instead of a regular disk could save an hour of lost time per day, per developer on average. Suppose the hourly cost of a developer is 80€. Now suppose you have 30 developers in total. That would be waste of 2400€ a day. Now suppose you have to buy 30 SSD's at 300€ each, which would set the company back 9000€.

That 9000€ investment will have paid itself back after 112,5 man-days, which is only 5 calendar days if you have 30 devs. After those 5 calendar days, the investment starts reducing development costs with 2400€ a day (on average), which for a full year (using 220 working days) could result in a yearly saving of 528000€ for the company.

Of course, Operations is usually a separate division from those that are responsible for development, which means that they have a separate budget sanctioned for what they need to do. Now suppose that Operations has to spend about 5000€ per year to replace failed SSD's. And lets assume that the yearly support cost for those SSD's is 20000€. I pulled that number out of my ass, which unless I'm mistaken is standard operating procedure whenever an Operations division gives you an estimate of support costs. Anyway, it would mean that on top of the 9000€ investment, a yearly recurrent cost of 25000€ would need to budgetted. And for what? The Operations division can't demonstrate a single benefit for their division to justify the cost.

Nevermind the fact that the company would save about 500000€ a year...

Whether you love or hate Steve Jobs, Walter Isaacson's biography on the man is well worth reading. I found it to be a fascinating read, and quite funny at times as well. I was expecting it to have a somewhat balanced view on Job's personality, but the author went way beyond that. He doesn't waste many opportunities to point out a negative reaction by Jobs, which is good. There's no glorification of Jobs, just a balanced and honest view. Another important thing that I highly appreciate is that you often get both sides of the story. You get Jobs' recollections and opinions, as well as those of the people who were involved in the many situations that are covered. And again, differences between those recollections are not ignored.

Most things are covered in chronological order, from Steve being put up for adoption, to his time in college, to dropping out of college and going to India, to starting Apple, to getting ousted at Apple and starting Next and buying Pixar, to returning to Apple and returning it to prominence, to him getting cancer and eventually resigning from Apple because of it. There are also parts about his personal life and his family, though the majority of the book covers his successes and failures in his professional life.

For a long time, I thought Steve Jobs was the perfect salesman for what the various teams at Apple were cooking up. I knew he was involved with the product design, but I had no idea he was as involved as he really turned out to be. He was very hands-on in the way he worked with the various product teams, and in many cases he led them based on his vision for what a product should be. But it would be false to say that he originally thought of every successful product Apple has put out, though he apparently had no problems claiming other people's ideas as his own. Stories about his temper and the awful way he treated his employees have been around for a long time, and there are plenty of examples in the book.

What I did find surprising though, is that a lot of people he worked with claim that Jobs pushed them into achieving things they never considered possible and that they loved making such an impact with their work, despite their complaints of his outbursts and the way he treated people. I also found Jobs' take on it interesting. It was his way of making sure that Apple would have as many A players as possible, and to get rid of as many B players (or bozos, as he called them) as possible. He felt that A players only want to work with A players, and that mixing them with B players would reduce their value. You have to admit it's hard to disagree with the results of his approach.

As for his approach to being a CEO in the latter years of his career, the most interesting part to me was that he refused to split his company into divisions where each division had its own Profit & Loss balance. Instead, you just had many teams and the only Profit & Loss balance that they looked at was the company-wide one. Jobs forced them to work together instead of competing with each other (which is the complete opposite of what the young Jobs did in his first stint with Apple) and when people didn't work together, he'd get rid of them. He made sure everyone was on the same page and that there was no confusion about the priorities of the company. He made sure Apple only focused on a few products so they could do them as well as possible, instead of trying to do as much as possible. It's pretty much the exact opposite of how Microsoft is being managed by Ballmer, and that contrast seems to reflect in both companies' success over the last couple of years.

The way he dealt with people, both in his personal as well as his professional life, wasn't as impressive though. It must have been hard to know him personally, and there are 2 stories of his behavior in the book that are downright shameful. In many of the stories of the book, he comes across as a total dick and a cry baby. You can take that literally even: there are countless moments in the book where it's mentioned that Jobs began crying when he didn't get his way. Saying that he had a complex personality is quite the understatement. But he was very good at knowing what people wanted and what they didn't want, even if they didn't know it yet, as he often said. Of course, it's exactly that arrogance that many of the people who don't like Apple products hate. Different strokes for different folks I guess, though I wouldn't be surprised if Jobs turns out to be right in most cases when it comes to most people, or non-techies in particular.

Despite his financial success, I do believe he was driven by building great products, and not just money. Had money been his primary motivation, I think he would've ended up with a lot more of it. The money issues that sometimes come up in the book seem to be more about respect than pure monetary gain, with the exception of one case, when he screwed one of his longtime friends during Apple's initial IPO. In that particular case, the author should've have dug deeper to find out Jobs' motivation. But again, from reading the book it's hard not to believe in Jobs' drive to create things that were truly great. I enjoy many of Apple's products, so in my opinion he's clearly succeeded at that. Though many of the Jobs-haters would probably disagree. Despite what you may think of the man or the products he's introduced, he's had a profound impact on many of the ways in which you and a lot of people you know interact with technology and media. And for that, I am glad he was the man that he was, regardless of his faults.

The biggest problem in the .NET world is that most companies that do .NET development just stick to what Microsoft tells them to use and how to use it. Many .NET developers largely focus on that, because they know all too well that it increases their odds of getting hired. And let's face it: Microsoft has a solution for practically everything. The only problem is that those solutions are rarely the best in what they're trying to solve. But hey, no manager gets fired for going with Microsoft, right?

The result is that there are too many companies and too many developers that focus only on what Microsoft offers. But there's a lot more to software development than what Microsoft offers, or even knows about. There are countless examples of Microsoft being late to whatever technical party is interesting at the time. And when they show up, they certainly don't always make a good impression.

If you're the kind of developer that likes to learn from what other software development communities are doing, odds are high that you're screwed. There is an interesting OSS community within the .NET world, and they frequently produce great solutions, quite often based on succes stories coming from other development communities. The problem is not that .NET developers don't have great solutions available to them. The problem is that the majority of them simply don't know about them only because there hasn't been any Microsoft hype about it, or that the devs who do know about it aren't allowed to use it because their managers are sceptical about it, most likely also because there's no Microsoft backing for the technology or architectural style that is being proposed.

I'm not advocating the avoidance of Microsoft products or solutions. By all means, use Microsoft products if they are indeed the best solution to your problem. But do be aware of the things that are getting attention outside of the Microsoft sphere and use them when it makes more sense to use them. That's the essence of the 'non-typical .NET job' and that's exactly what makes it interesting: using the right tool for the right job.

• The fixed mindset: People who have this, think that we have a certain amount of intelligence and can't do much to change it. To them, a mistake is a failure, a sign that their capabilities aren't up to the task.
• The growth mindset: People who have this believe that they can get better at almost everything, as long as they can invest the necessary time and energy. They see mistakes as an essential precursor to knowledge, the engine of education.

Needless to say, people with a growth mindset turned out to be significantly better at learning from their mistakes. The article also covers a very interesting experiment involving school children. The children were given a test, and half of them were told "You must be smart at this". The other half was told "You must have worked really hard". After that, they could choose between 2 new tests. The first one was more difficult, but came with a mention that the students would learn a lot from them. The other test was similar to the test they had just taken.

And here's where it gets really interesting: of the kids that were praised for their effort instead of their intelligence (I'm going to refer to this group as the effort-kids from now on), 90% of them chose the harder test. Of the kids that were praised for their intelligence (I'm going to refer to this group as the intelligence-kids from now on), the majority chose the test that was similar to the one they had just taken. Presumably, to avoid risking a low score after having already been praised for their intelligence. After the second test, all of the kids took the same third test, which was the hardest one so far. The effort-kids worked hard at figuring out the puzzles, while the intelligence-kids were easily discouraged by their mistakes. After the third test, the kids were given the choice to look at the exams of kids that did better than them, or the exams of kids that did worse. The effort-kids generally wanted to look at the exams of the people who did better. The intelligence-kids mostly picked the exams of those who did worse. The final test had the same difficulty level as the initial test. The effort-kids raised their average score by 30%, whereas the intelligence-kids saw their average score drop by 20%.

I find that kinda stuff fascinating. It also kinda confirms what I've seen from fellow developers ever since I graduated and started working. Every good developer I've met isn't afraid to make mistakes and sees mistakes as learning opportunities. These people routinely challenge themselves by learning something new. They also keep an eye on what other people are doing to get better and they actively try to learn from people they consider to be better than them.

One guy I used to work with was considered to be a great developer a few years ago. Now this was the kind of guy who was not only used to being praised for his 'intelligence', but his self-confidence was largely based on it. He once told me his favorite class in high-school was math because the other people in his class thought it was hard, while it was easy for him. He actually said it like that. When other people started getting more attention for their technical skills and knowledge, he began to move away from coding and started focusing more on writing functional analysis documents. He wasn't bad at it, but it wasn't great either. Now he does a little bit of everything from what I've heard. I'm pretty sure that if his self-confidence wasn't based on the praise he gets, he could've been much better at whatever he wanted to do.

That's just one story but I've seen similar things with other people who seemed to be more interested in what other people thought of what they could do as opposed to actually trying to improve on what they can do on a continuous basis. If they start thinking rather highly of themselves because of the praise they get, they often start thinking it's just not necessary anymore to keep working on improving their skills.

Keep challenging yourself. If you think you're pretty good at what you do (and there's nothing wrong with that), make sure you keep searching for new and better ways to do what you do. And when people praise you for being good at what you do, don't let it get to your head because before you know it, you won't be getting much praise at all anymore.

Another difficult part is always having a list of things you want to do, or need to do. Implementing that pet project you've had on your mind for a while now. Contributing to some Open Source projects that you're fond of. Accepting pull requests. Writing a blog post about something. There's always something, and you never quite manage to cross off every item on that list. I have a list like that. And so do you.

And you know what? That's ok. You have to accept the fact that between your job and your personal life, there is a limited amount of spare time available to you. And you just can't spend all of it on learning new stuff all the time or working on things that you think are important. Sure, learning is important. And so is taking the time to work on things that matter to you. But what's equally important is giving yourself enough time off to sit back, relax and maybe even do nothing.

I spend about 80 minutes each day on the train. Sometimes I'll read. Sometimes I'll code. And sometimes I just listen to some tunes while I stare out the window, either thinking about nothing or thinking about whatever comes to mind. It's a conscious decision. That's me saying "I just wanna relax right now". Which means I don't even want to think about software development stuff, or blogging, or anything else that I'm supposed to do. On some free evenings I think "damn, I really should do something useful". And on some of those nights, I will. But I'll also consciously choose not to do anything useful from time to time as well. It all kinda depends on how busy I've been in the days leading up to that free evening.

Your brain is like a semi-intelligent battery. It has a limited amount of energy and it can only do so much between charges. It's smart enough to scale down its activity when it's starting to run low, but most of us are too stupid to realize it and we just try to keep going. The result is that whatever we're trying to do, we're not going to do it as well as we think we are. You will have trouble learning new things when you're running low. You certainly won't do your best work when you're running low. In fact, you're likely to do a half-assed job which ironically only increases your workload.

Take care of that battery. Recharge it regularly, and don't think you can get by with minimum recharging. If it doesn't work for your phone, it won't work for you either.

It's weird how much change we've seen in the technology and websites we use in the past 3 years or so, compared to how little change there was in the 5 years before that.

She's not a techie. She's just a normal person who doesn't care about news from the technology world. But she is interested in devices and sites that make her life easier and better. We've all noticed that in an ever increasing way among non-techies in the past few years. If you think about it, it's a pretty big jump from where we were 5 years ago. Back then, the only technology innovations that people heard about were faster CPU's, bigger hard-drives and more memory. And most people didn't really care. The primary reason they bought new technology was because their computers 'got slow' doing the same tasks they once completed fast enough. With the notable exception of Napster (and its derivatives after that), there was nothing really that changed the way people consumed information and media. We didn't like the clunky mobile devices that were available. And while social networks already existed, they weren't as ubiquitous as they are now. For a few years, it seemed like there was hardly any progress in technology apart from the things that only geeks got excited about.

Back then, there was really only one tech-giant that mattered when it came to the consumer market: Microsoft. They were dominant and had little competition in their core markets. They then started to put a lot of resources into entering other markets, which meant they were basically building the same things that other companies were already offering. There were minor innovations, typically limited to small features and integration with other services/products that competing products didn't have. But nothing really substantial, they didn't introduce any game-changers. You could argue that hardware improvements at the time weren't coming along fast enough to create game-changing products, but I'd argue that such improvements largely come from companies that push for the required advancements in order to create the products they've envisioned. I like to compare it to how we were able to put a man on the moon 40 years ago because the space race pushed us ahead, yet we can't even match that feat (let alone exceed it) nowadays because nobody is pushing for it.

Luckily for us, we now live in a time where we're back to multiple tech-giants that matter to consumers. Apple, Google, Amazon, Facebook, Samsung, … they're all creating things that change the way we do things or consume things. They're all competing heavily and as a result, innovating because they simply have to. If they don't innovate, they quickly become irrelevant and that impedes their ability to compete. And if they no longer need to compete, it becomes less important for them to innovate. They'd only need to provide just enough innovation to get their customer base to upgrade regularly. And we, the consumers, would be back to where we were 5 years ago. Getting minor upgrades that slightly improve what we're already doing.

Despite any preferences you may have, you really ought to hope that none of the new tech-giants become as dominant in the areas they're active in as Microsoft used to be. If you're an Apple fan, you should be happy that Google and Samsung are fighting them so hard in the mobile space. If you're a Google fan, you should be happy that Facebook has them worried. If you're a Facebook fan, you should be happy about the changes that Google+ has inspired them to make already. If you're a Microsoft fan, you… well, that probably means your income is dependent on Microsoft's relevance. With the exception of Kinect and XBox, the only people that seem to get excited about Microsoft products are .NET developers, Windows sysadmins and tech journalists that cater to either of the first 2 groups. But the good news is that even Microsoft is being forced to innovate if they want people to buy their products. They can't leverage their Windows monopoly into automatic success in other markets anymore.

As long as none of the tech-giants can get comfortable in their position, we're going to keep benefiting from the competition and the resulting innovations. Just something to keep in mind for fanbois on all sides

We mostly cared about getting our assignments working. When you completed an assignment, you moved on to the next one and none of the code of the previous assignment really mattered anymore. Maintainability or even readability were things that never even occurred to us. Maybe a few of the teachers tried to tell us about it at some point, but it certainly didn't stick.

In the final year, we could pick a project to work on for the majority of the year. There were no limits on the assignment, so most people picked something that interested them. I was pretty interested in manager/simulation games, so I figured I'd just build my own Formula 1 manager game. The player would get full control over a F1 team, which in my game meant:

• picking the suppliers for tires, fuel and engines, all of which had varying levels of quality and costs associated with it
• hiring a chief-designer, chief-mechanic and drivers, all of which had a specified talent level and negotiations took the results of the team's previous year into account, as well as the results of the potential hire's previous team, which influenced prices and negotiation tactics.
• landing sponsors, some of which were more than happy to sponsor your team depending on last year's results, or wouldn't even answer your calls and they all had varying budgets as well

I came up with a pretty good formula to simulate realistic race results based on all these factors as well as a dose of luck, or bad luck. If you played for a few seasons, the decisions you made all added up nicely, and gradually. When the project was due, it all worked. Since I loved playing those kind of games, I tested it very extensively by playing it regularly. When issues came up, I'd fix them. When I thought of improvements, I implemented them. I delivered something that worked, and that was large enough in scope and complexity to be impressive for a school project.

But the codebase was truly atrocious. I wasn't using proper structures for either data or behavior and I ended up with a shitload of extensive multi-dimensional arrays. All of my types were in those arrays, as I just didn't know yet that they should've been types of their own. Of course, I listed all of the indices on pieces of paper so I'd know which data properties corresponded with each index. Behavior was all implemented in the UI layer. I was using VB5 at the time, which didn't really encourage me to seek out nicer ways to structure my code. I copy/pasted large gobs of code whenever I needed to reuse something. And of course, whenever I had to make a change, I needed to do it in multiple places. Quite a few places in most cases even. I was using flat files to store data, so I didn't have the opportunity to make a horrendous mess out of a SQL-based data layer but if I had used a database, my usage of it would've surely been epic.

I got a very good grade for the project, and while I was happy to see that all of my hard work was rewarded, it did kinda scare me that a codebase that was so brittle and so painful could actually work, and work well even. It was my first encounter with what is by far the biggest problem with software development to this day: if you keep adding code, sooner or later it might actually work. Luckily, this was just a school project. But can you imagine if this were a project done by a professional company? That codebase would've cost money to develop, and the company would actually have a working project, no matter how expensive it would've been to keep working on it. At the time, I couldn't imagine a company in such a situation that would say: "ah, it sucks… we need to start over". And I think we all know that very few companies would actually do that.

I love that horrendous codebase for the lessons it taught me so early on. I learned a lot about what you shouldn't do when you're developing something that's supposed to stick around for a while, and I'm glad I learned it without it costing a lot of money. Of course, that doesn't mean that every single thing I've written since is all roses and peaches, but it put me on the path of trying to continuously improve as a developer, not only in what I was able to do with code, but also as to how clear I could make it to others.

Note: I no longer have that codebase unfortunately. Really wish I did, if only because it'd be pretty funny going through it after all these years.