Saturday, October 30, 2010

ArrrrCamp - About Ruby, Rails, Radiant and Rum

Yesterday, I attended ArrrrCamp in Gent together with my former colleague Peter Eysermans. This was my very first Ruby conference although I would argue that the focus was more on web development in general. There were a wide range of talks, not only about Ruby and Ruby on Rails, but also on client-side development, JavaScript libraries, OOP, refactoring, … etc.

After Carl Lerche gave his keynote, I went to the first session on “Escaping the Sludgy Swamp of Slow Tests” by Joseph Wilk. The speaker discussed a couple of techniques on how to dramatically speed up your acceptance tests. There was some great advice there, some of which I haven’t considered myself. You know, I had a couple of ‘aha’ moments followed by a couple of ‘why didn’t I think of that before?’. Although he mostly used Cucumber throughout his talk, the content was generally applicable to acceptance/integration tests on other platforms as well.

The next session I attended was about refactoring by Alain Ravet. As someone who continuously refactors his code, I was curious to see how these techniques are perceived and applied in other communities. There are many similarities there, so for me personally, there was not a whole lot of new stuff in this session. I also disagreed on some of the claims about code readability. Nonetheless, this was a nice talk with a great speaker.

After lunch, I attended a talk about “Rich Internet Applications with Sammy.js” by Anthony Heukmes. Sammy.js is a JavaScript library that is heavily inspired by Sinatra and is built on top of jQuery. It was nice to learn more about this framework and its capabilities.

Then it was already time for the last full session. I went to a talk from Drew Neil, who is the producer of the Vim casts, titled “Vim – walking without crutches”. This talk was the highlight of my day. Very entertaining and the way he showed how to use Vim looked so easy that even I could understand. I realized that I definitely have to look into how Vim can make me more productive during my day-to-day coding. Both thumbs up for this session. Drew Neil also announced that he’s writing a book called Practical Vim for the Pragmatic Programmers.

After a very tasty mohjito during the cocktail break, we witnessed another six lightning talks the last of which was about rebooting the Belgian Ruby User Group (B.R.U.G.). It’s very nice to see that the Ruby community here in Belgium is trying to regroup itself. As quite the Ruby noob, I’m definitely interested in attending a couple of their monthly gatherings.

Finally there was the closing keynote by Yehuda Katz which is one of the members of the Ruby on Rails core team, lead developer of the Merb project, a member of the jQuery core team and better know as one of the authors of jQuery in Action. I felt really humble when I heard this guy talk about web development. At that moment, I realized that I have a lot of learning ahead of me if I ever want to become a proficient web developer. Great stuff!

As a member of the .NET community, it was a very humbling experience to step out of my comfort zone and join a bunch of people who are really passionate about web development and listen to the discussions there. I was very much surprised by the high-quality content brought by a selection of awesome speakers for a ridiculous small amount of money. In fact, I took a day off from work and paid for the registration fee myself.

I hereby want to encourage other developers from the Belgian .NET community to attend this little conference next year, especially when you’re heavily involved with web development. Some of the discussions that went on there are also very much needed in the .NET community as well. We need to learn more about this so we can start bringing some of this stuff over to the .NET world.

My complements to the organizers for a job well done. Till next year.

Update: The recordings for some of the sessions are now online.

Wednesday, October 27, 2010

Moving to Greener Pastures

I’m very thrilled to announce that I’ll be joining QFrame starting from February next year. I’ll be working there as a .NET architect/consultant focused on exploring technologies, guiding design and architecture, coaching and spending a lot of time diving into code. In short, I got hired for just being myself ;-).

I’m very much looking forward to this new chapter in my life and the opportunities that are going to cross my path.

Laborers versus Professionals

A while ago, my good friend Michel Grootjans tweeted the following:

Are developers (a) laborers or (b) professionals? If (a) don't expect them to think. If (b) don't expect them to execute without question.

Personally, these few sentences struck a nerve or two. Read it a couple of times and think about this statement for a while. Try to picture your own work environment and how this relates. Go ahead! I can wait.

OK then, let’s move on.

I’ve been working for an enterprise corporation for 5+ years now. One of the things I’ve seen and learned there over this period of time is that laborers are more valued by management than professionals. Let me elaborate on this.

One of the biggest issues in a typical enterprise corporation is trust, specifically the lack thereof. The direct consequence of this lack of trust are massive amounts of constraints, regulatory processes and fear-driven development. This is the natural habitat of laborer developers, a nice and cozy place where they can spend their hibernation until retirement. This is where the term ‘code monkey’ originates from. Nine to five, no thinking, narrow focus, like soldiers in the military obeying orders to make a big mess. But sometimes, amongst these massive cohorts of laborers, there are small islands that exist of one or more professional developers. These are the kind of people that are very passionate about their craft, that want drive innovation and also want to continuously learn and improve. If you’re a developer and you’re reading this blog post, you probably fall into this category of developers.

But professional developers always have one part of the establishment going against them. It’s not the laborers. They don’t care. It’s an instrument better known as management. A large part of the IT industry, especially corporate IT shops, are being run by giant flocks of managers. Some of these managers started out as software developers and some of them are just born that way. But there’s something that they all have in common: they don’t write code as part of their day job. Although they don’t get their hands dirty with writing software, most managers do feel compelled to impose all kinds of political decisions regarding business requirements, software architecture/design, tools and technologies to the development teams they are ‘managing’. I for one want to make it clear that this has to stop. In order to lift this industry to the next level, we as software professionals need to free ourselves from the leash that is currently being held by management.  

Professional developers working in these kinds of corporate environments are generally considered as troublemakers, if not by their direct bosses then certainly by other parts of management. The general attitude towards professionals is slamming them with more  procedures, so called ‘company standards’ and ‘default architectures’. This ends up with a lot of frustration, a feeling of burn-out or even worse, suffocation as it may seem that the walls are closing in. Professional developers generally have a hard time placing this attitude towards them. They just want to do the right thing and provide the best possible solution they’re able to come up with. If managers don’t trust their development teams to make the right decisions, then why did they got hired in the first place?

I for one am pleading to get past this all this. Any business that wants to survive in this hard world economy and even wants to get ahead of its competition has to free its professional developers from management. It’s that simple. Management is great for enforcing compliance, but if engagement is what you want (and is definitely needed for bringing innovation), self-direction is essential. I already wrote a blog post about self-organizing teams a couple of years ago. Today, I’m even more convinced that self-direction is one of the major key enablers for innovation in the IT industry of the 21th century. Anyway, someone who isn’t coding at least 50% of his day job shouldn’t be allowed to interfere with any kind technical decision making. Period!

I’m not saying that development teams should get a signed blank check. On the contrary. Financial and business constraints should still be taken into account. But when it comes to creativity, methodologies, technologies and tools, management shouldn’t get in the way. Development teams should be able to take responsibility for their own actions. Managers should know their place by making sure that their development teams can operate as optimal and efficient as possible by removing as many impediments as possible.

Let me show you a couple of examples where this principle of autonomy has immensely paid of so that you’re able to judge for yourself.

I personally find health care a fascinating craft. I find it fascinating simply because there are so many parallels than can be drawn between software engineering and the state of health care roughly 200 years ago :-). Lets take about modern hospitals for example. Medical facilities are generally being run by senior medical staff and not by managers! Senior medical staff are people that have a high degree of mastery in what they do and still perform their craft every single day. Maybe they’re not doing it full time so that they’re able to fulfill their ‘path-finding’ responsibilities, but still, they are still fixing their patients. Hospitals do have managers however, but they are there simply for enabling the medical staff to not worry about anything else besides saving lives. Can you picture lying in an operating room when a manager in a suit bursts through the door, yelling at the surgeon that he’s not allowed to use technique xyz to save your live? Preposterous you say? Not so with the current state of affairs in IT departments of the enterprise corporations.

There are a couple of concrete examples in the IT industry as well. Remember when Google announced that their engineers get to spend 20 percent of their time to work on something of their own interest? This resulted in massive improvements for products like GMail, Google Maps, Google Docs, etc … and directly contributed to Google’s success and current market share. Other companies like Atlassian and Facebook are enabling innovation in basically the same way.

Yet another example is Pixar. If you haven’t seen or listened to this interview with Ed Catmull, the president of Pixar, stop reading this blog post and let it inspire you now! Somewhere along this awesome interview he mentions the following:

Part of the behavior is I don’t know the answers. And at first that seems a little bit glib. But after awhile people get that I really don’t know the answer to a lot of these things. So we set it up so that the management really doesn’t tell people what to do. 

Think about how amazing it would be like to work in an environment like that. It’s inevitable that great things are bound to happen.

There are plenty of other examples out there, like open-source software, Wikipedia, etc. … . They all prove that self-management results in engagement and that this is going to be a major differentiator in tomorrow’s economy. 

Make sure to check out the following resources as well:

Till next time.

Saturday, October 23, 2010

Basic JavaScript Part 1 : Functions

Functions are a very important concept in most programming languages, but they are even more important in JavaScript. When you read this as a C# or VB developer you probably won’t see this as a big deal. But there are some essential things you can do with functions that you should be aware of when doing JavaScript development.

Self-executing functions

As the name implies, these are functions that are called after they are defined. Let’s look at an example:

  function() {
    alert("Hello Mars");

This basically is an anonymous function that is invoked immediately, caused by the last pair of parentheses. It’s also possible to specify arguments to the anonymous function like so:

  function(planet) {
    alert("Hello " +  planet);

Why is this useful? Well, you can do all sorts of stuff with self-executing functions like one-off initialization without having to mess around with global variables. They are also commonly used for variable scoping. Variables declared inside a self-executing function cannot be accessed from outside the function. This way it’s possible to provide proper encapsulation, which I might come back in a later blog post. 

Inner functions

This feature reminds me to the early stages of career as a software developer when I was still programming Delphi. Just like Delphi, JavaScript makes it possible to define functions inside another function.

function show() {
  function getPlanet() {
    return "Saturn";
  alert("Hello " + getPlanet());

The function show() is publicly available, but the function getPlanet() is a private function and can only be called from code that lives inside the show() function. So the main benefit here is encapsulation.

Self-rewriting functions

It’s possible to assign functions to a variable. Nothing unusual there. But we can also assign a new function to the same variable from within the function that was originally assigned to the variable. You can think of it as a function that rewrites itself from the inside when it is executed. This probably sounds more complicated that it really is so I’ll show you an example.

var doSomething = function() {
  alert("Doing something useful");

  doSomething = function() {
    alert("But I already did something!");    

Again, this technique is quite useful when you need to do some one-off initialization or perhaps feature sniffing on different browsers.


In order to understand closures in JavaScript, it is also vital to understand scoping. Unlike other programming languages, JavaScript has function scope instead of block scope. This is also called scope chain.

function foo() {
  var x = 8;
  if(x > 0)
    var y = 12;
    function bar() {
      alert(x + y);  

This might come of a little bit strange, but this code is completely legit. Both the variables x and y are available inside our self-executing function bar(). Variable y is available in function foo() after its definition inside the if block. This is why it’s a best practice in JavaScript to declare all variables at the top of the function in order to prevent some nastiness later on.

JavaScript functions also have lexical scope. This means that a function doesn’t create its scope at runtime but when its defined. I have to admit that I still run into some issues regarding this concept from time to time.

Now let’s get back to closures by looking at a very basic example.

function foo()
  var x = 15;
  return function() {
    return x;

This might look familiar when you’ve worked with lambdas in C#. Calling the function foo() returns another function that returns the value of the local variable x. Closures are often used when doing OO-style programming in JavaScript. An example of this are getters and setters.


These are just some of the nice little tidbits that are very powerful tools in your JavaScript tool belt. Actually sitting down and learning about JavaScript as a programming language can be a real eye opener and a very rewarding experience.

Wednesday, October 20, 2010

Book Review: A Whole New Mind: Why Right-Brainers Will Rule the Future


After having listened to the recording of a speech by Daniel Pink, I quickly decided to purchase the audio version of A Whole New Mind: Why Right-Brainers Will Rule the Future. In this book, the author first starts to describe how our brains work from a high-level point of view. The human brain is divided into two hemispheres, a left and a right part. The author explains the differences between these two parts of our brains, stating that left-brain (L-directed) thinking implies more logical, linear reasoning while right-brain (R-directed) thinking is more holistic and artistic.

The message that he is trying to bring across, is that while society highly values L-directed thinking, R-directed thinking is getting more and more important in the world of tomorrow. There are three basic questions that identify and point to R-directed activities:

  1. Can someone overseas do it cheaper?
  2. Can a computer do it faster?
  3. Am I offering something that satisfies the nonmaterial, transcendent desires of an abundant age?

The answer to these questions should be “no, no and yes”. If not, then those kind of activities can be automated or done much cheaper by out-sourcing. Those kind of activities are delineated as left-brain activities.

The second part of the book is called “The Six Senses”, which are:

  • Design
  • Story
  • Symphony
  • Empathy
  • Play
  • Meaning

For each of these senses, the author tries to find real-world examples and stories to prove the values of these aptitudes.

In short, this is simply a fascinating book. I can highly recommend this book to just about anyone. Two thumbs up! 

Saturday, October 16, 2010

Elegant Documentation Never Lies

I was taking a close look at the API documentation of the ExtJS JavaScript library the other day and I noticed something very interesting.


You can see that the ExtJS folks have put out some great amounts of effort into documenting their API’s. The example shown here is from the Ajax ‘class’. No big deal so far. But when you click on the name of a  method (e.g. fireEvent), you get the following:


You’ll dive right into the source code! Interesting approach, don’t you think?

I mean, picture this: you’re looking at the documentation of NHibernate’s ISession interface. You click on the link for the Get method and it will take you right down to the source code for that particular version of NHibernate.

Wouldn’t this be cool for the documentation of the BCL as well? Or is it just me … ? 

Friday, October 15, 2010

Book Review: jQuery in Action (2nd Edition)


I wanted to pick up a book on jQuery for quite some time now so I decided to give jQuery in Action a try. Besides all the nice things I’ve heard and read about jQuery, I didn’t have a clue about any of its capabilities. This book got me up to speed fairly quickly, but I reckon this is also partly due to the flat learning curve inherent to jQuery. After reading through the first three chapters I’ve come to realize how amazingly powerful this JavaScript library really is. 

I can now see why jQuery (re-)popularized the JavaScript programming language. I got quickly overwhelmed by how well thought-out the API is and how it consistently shields you from having to deal with browser-specific issues. Its simplicity, conciseness and small footprint makes it an essential tool for rapid web development.

Back to the book itself now :-).

The book consists of two major parts. The first part is devoted to the jQuery core library consisting of eight chapters and the second part deals with jQuery UI which exists of three chapters. 

The first chapter provides an introduction to jQuery, an explanation about the concept of unobtrusive JavaScript (which is a very important principle carried forward by the library) as well as an high-level overview of the features and capabilities of jQuery.

The second chapter facilitates an in-depth discussion of the popularized jQuery selectors, generating HTML and various ways on how to manage the wrapped element set. The authors did a great job providing a thorough and complete description of all the CSS and custom jQuery selectors. This chapter alone is worthy enough for buying the book.

The third chapter shows how to manipulate element properties and attributes, changing CSS styles and operating on HTML content.

The fourth chapter is dedicated to events, describing how to bind or remove event handlers using jQuery without having to deal with the different browser event models. This chapter concludes with a nice example that puts all the knowledge of the previous chapters into practice.

The fifth chapter is all about showing or hiding elements using effects and animations. The part on queuing functions and how jQuery provides support for this is really fascinating.

The sixth chapter provides an explanation for a whole bunch of jQuery utility functions, among which are functions for trimming strings, performing operations on JavaScript arrays and extending objects, etc. …

The seventh chapter is one I skipped. It talks about how to extend jQuery.

The eight and final chapter of the first part of the book is about Ajax. It shows all the high-level and more low-level features that are provided by jQuery for making Ajax requests. This chapter again provides a thorough view on these capabilities which I also used as a reference a couple of times already.

I skipped reading the second part of the book which I’ll probably reference later when I’m going to need themes, UI effects, UI widgets, mouse interactions, etc. … . The most important thing for me was to learn about the jQuery core library.

I really liked the labs and exercises that are spread throughout the book. Those were very helpful to play around with a particular part of the jQuery API. All the chapters and topics were very thorough and complete. You can both learn jQuery from this book as well as use it as a reference for later, although I personally have the feeling that its a tiny bit more of a reference book than a learning book. The downside of these kind of books is that they become out-of-date really soon. Something I would really love to see in a future edition of the book is a chapter on best practices (or contexts), pitfalls and lessons learned with using jQuery. For example, some parts of the jQuery API can have a significant impact on performance (like calling appendTo() in a loop) while there are some specific solutions that are a lot faster.

This book opened the gates to the world of jQuery for me and it encouraged me to learn and exercise the jQuery coolness. I really enjoyed the learning experience.