Professional

Sometimes, in a conversation or discussion, you are attacked head on. The other person challenges everything you say, does not let you finish your sentences and always has one more objection. My default reaction in a situation like this is to be defensive. Which is probably wrong in any case, but here I want to write about a special situation: The other person is is playing chicken.

You know, chicken, the game you sometimes see on the movies. Where two cars drive head on at a high speed until one of the drivers "chickens out".

In a conversation, interesting things can happen when you do not chicken out. Maybe the other person is on your side and she only wants to challenge you. When you become defensive, nothing new can happen. But when you fight back, new ideas can be born and a great discussion can emerge. The crash, that would kill the players in a real game of chicken can not happen, so you have nothing to lose. This posting is a note to self: When somebody is playing chicken with you in a discussion, stay head on!

Of course, the other person could also be just an annoying a... . Then there's no fun in playing and you should just leave. The difficult part is to recognise the difference.

The last 2 days I was in Leogang, Austria at the Con-fess conference, where I had a great time. There were good sessions and speakers, and I met many nice people. Leogang is in the middle of nowhere, but that didn't matter, because Hotel Krallerhof, the conference venue, had everything you could wish for. The Salzburg mountains are beautiful, and the weather was good all three days:

My favourite session was Better Presentations by Michael Plöd - although most presentations were good and the speaker lineup was quite impressive. It was nice to meet Ed Burns again! I also had the chance to talk to Kito Mann at dinner and between the sessions. And I finally met Thomas Einwaller who lives and works in the same city as I do.

My session: Apache Wicket and AJAX

My session went quite well but I think there are a couple of things I could improve for the next time. The whole conference was recorded, so as soon as the video is online I will link it here. I have already uploaded my slides an the code examples from my talk, you can download them right here:

confess_2012_Wicket-Ajax.pdf The slides (and notes) from my talk.
confess_2012_wicket_ajax_sources.zip The source code (+ libraries and Eclipse project) from my talk.

Next week I will be giving a one hour talk about Apache Wicket and AJAX at Con-Fess Conference 2012 in Salzburg. Yesterday I finished preparing the first draft of the talk, which I will refine over the weekend.

I have several slides, but I hope I will be done with them in 20-30 minutes, because what I really want to show is code. And I also want to leave some time for discussion.

The slides start with a general introduction to AJAX and an introduction to Apache Wicket, both only very basic stuff. Then I will introduce the concepts needed to do AJAX in Wicket: Components, Behaviors and AJAX-specific behavior. This will show that wicket comes with a lot of AJAX functionality out of the box, but sometimes you need more flexibility. In the last part - if there is still time - I want to show how to achieve that, by using jQuery to send an AJAX request to the Wicket backend.

There will be several code examples: I will show how to use components, behaviors, some AJAX behaviors and the jQuery call. I want to do most of the coding live, because I think this way it is easier to follow for the audience. I have prepared a working solution that I can show if time is running short.

I think this is some pretty interesting stuff, especially for people who had not much previous exposure to Wicket. I hope I'll see you there.

Writing about blogging? I'm not sure if I like that. It's so meta. But Hugh says I should do it, so I guess I have to ;)

I started blogging quite some time ago, but I never really followed through. It was something I did just for me, and I did not care what other people think - or if they even follow me. That has changed a bit recently - but not that much. I still won't be depressed if people disliked my blog, but now I want to be read. But to be read is not the only reason I write. Not even the top reason. If it were, I would have already stopped it.

Freedom is Blogging in your Underwear

... Is the new book by Hugh MacLeod, a great artist and blogger. I must confess I have not read it yet, but it is second from the top of my "To Read" pile (*).

Rebooting my Blog

For a long time I had only been blogging "when I had something interesting to say". That meant that I wrote only a few posts per year. The problem with only writing when - magically - something interesting comes to your mind is that you don't think about things to write about. So nothing interesting comes to your mind. Then I got annoyed by the fact that I wrote so little, and I forced myself to decide if I wanted to have a blog or stop blogging completely. No more half-assed writing.

I decided I wanted to have a blog, and I set out to write at least one blog post per week. I started with a post about Version Numbers, and from that day on, I wrote one or two blog posts every week. Almost ;)

I was always blogging because I wanted to become a better writer (Like I speak at conferences because I want to become a better speaker). And because I learn a lot about things by writing about them - For Example, I learned a lot when I wrote the series about Framework Design Principles. This learning - for me - only works well when I do it on a regular basis, when I constantly have to think and learn about topics to write about.

I also started to announce the posts on Twitter and Google+. I even submitted a few to Hacker News. This brings in a little bit of traffic, but not too much. Hittail (**) shows that search traffic is increasing too. But: I'm still not rich and famous - yet.

The years before

I started blogging quite some time ago: My first blog entry was "Dear Log" on June 3rd, 2004. Later I started a second blog: I wanted guglhupf.net (the site of my good friend Rene Pirringer) to be my private blog (which I stopped completely now) and I wrote about software development on deltalabs.at, which later became davidtanzer.net.

For some time I wrote a series called This week on harmony-dev where I summarized all the discussions on the Apache Harmony Developer Mailing List. This was read quite a lot because I also forwarded these articles to the mailing list. It just was too time consuming for me at the time to read and summarize all these emails, so I had to stop it after several months.

How Blogging changed my life

Blogging is just something I do. Something I started in University and have continued since then. But I really like it. And it has changed my life: I learned a lot about several topics by writing about them. I think my English has improved. And I think I am a better writer than I was a few years ago. Anyway, there is still so much left to learn....

(*) Right under "Grouped" by Paul Adams, which is next because it has been lying there for way too long.
(**) BTW, I love Hittail. Maybe I'll write about it in more detail in the future.

This blog post is the last part of the mini series about Framework Design Principles.

Less lines of code is better. Given that it sill solves the problem. Less code means less debugging, less testing and fewer bugs. A framework has to make sure that the programmers using it can express concepts succinctly and still clearly. Also, the framework or library should not encourage the developer to hide essential parts of the code just for the sake of succinctness.

Succinct is good

I guess an example would be handy right now. The example I used in my talk at "Mathema Campus" earlier this year is from Paul Graham's article Take the Arc Challenge. The challenge is:

Imagine solving this challenge using your favourite web framework... In Apache Wicket, for example, one would have to write 2-3 Java Classes, 3 XHTML-Files and an XML file to solve the challenge. In JSXP it's just about the same effort.

This is the solution written in ARC, the Lisp-dialect created by Paul Graham:

(defop said req
  (aform [w/link (pr "you said: " (arg _ "foo"))
           (pr "click here")]
    (input "foo") 
    (submit)))

The beautiful thing about this solution is that it is really short, but still does not hide anything essential from the reader: Everything from the original requirements can be found directly in the code.

Reasons

There are several reasons why less code is better. An important one is Working Memory Capacity (which I have explained in an earlier article from this series). Programmers have to remember large parts of the code correctly so they can modify it. They have to "Load" it into working memory - This is what gets programmers into "flow". Succinct code means that the programmer can "load" more code more quickly.

There is also some evidence that the number of lines of code a programmer writes per hour is independent of the programming language - also the number of bugs per line of code seems to be pretty independent of the technology used (see for example this paper by Ericsson). So, less code means less bugs and more productivity.

Finding errors is easier too: There is less code where the bug can be hidden, and there are probably less tests affected.

Too succinct

Can a piece of code be too succinct? It can, if it hides things that are essential to understand what the code does. Consider this piece of Ruby code:

while file.gets
	print if ~/third/ .. ~/fifth/
end

This code reads all lines of a file, and as soon as one line matches the string "third" it starts printing all the following lines - until a line matches the string "fifth" (this is what the ".." operator does - it acts like a toggle switch).

But how does it do that? There are no variables involved whatsoever!

The code works because several ruby functions use global variables by default if no other parameters are given: "file.gets" saves its result in the global variable $_, the "~" operator can match against $_, and if "print" is called with no argument it prints $_.

Something very essential is hidden here: How the data flows through the program. A better - and still very succinct - solution would be:

while line=file.gets
	puts line if line=~/third/ .. line=~/fifth/
end

Conclusion

Less code is better - unless it hides something essential about the solution. Make sure that programmers who use your framework or library can create succinct solutions. Don't force them to write boilerplate code or configuaration files where defaults would do.

Think about one of your favourite frameworks or libraries. Does it force you to create boilerplate code or does it enable you to create succinct, elegant solutions?

I am just at the beginning of my journey - My journey towards becoming a better software developer, towards understanding how teams work and towards helping others. I will always be at the beginning. I hope I'll never forget that.

Whatever we have learned so far is just a good place to start. But I think there is no good place to stop - ever. Sometimes it is hard to admit that. And sometimes it is too easy to become arrogant. I sometimes have to remind myself that there is a lot more for me left to learn. Even about things I think I already know (*).

If there is no good place to stop, then the way ahead is longer than the way already traveled. Because it never ends. This means that I am still at the very beginning (or very close to the beginning). But that's a good thing. Nothing ever really ends. There is always a chance to learn. There is always a way to improve. To make something in our world a little bit better.

When was the last time you thought you didn't need to pick up a book or go to a training because you already knew the topic? Were you really right?

(*) For example, I just bought the Design Patterns book because I realized that I never read it. I learned most of the patterns from other sources.

Up until a few months ago, I used to work on side projects mostly after work, for just about an hour or two. Often I did not really get much done. Now I have set aside one day per week where I work on my side projects, and this greatly improved my productivity. Then, a couple of weeks ago, I won a book about the pomodoro technique in a contest organized by the Trello team, and so far I am quite impressed: It's amazing how much you get done when using this technique!

One day per week

After I had finished the project with my last client in February last year, I had some weeks where I could work exclusively on side projects. During this time I wrote JSXP2 which is almost a complete rewrite of JSXP and I wrote most of the code for gclimbing.com. I was very productive.

Before and after this time I was working full time for clients. I only worked on my side projects for a few minutes to a few hours after "real work". Getting things done was much harder when working like that. I was tired after a long day of work, and the relatively short time I was working on my side projects meant that I never really got into "flow". Still I was quite productive some time, but mostly when I had longer blocks of time where I could work on a single project.

This year, I decided to set aside (at least) a whole day per week to work on my own stuff. I only work on client projects for four days a week. Monday is my side project day. This is when I write code for my side projects, try to learn new things, write blog posts, read books, prepare talks and so on (*).

Now that I have a whole day per week I get much more done. I know that not everybody can work in their "day job" for only four days per week, because most employers will not allow this. Anyway, setting aside large chunks of time for side projects once a week works better than working every day for 30-60 minutes - at least for me.

Pomodoro technique

A few weeks I discovered the pomodoro technique because I won a the book about it. It is quite simple: Write a TODO list for the day. Work for exactly 25 minutes, then take a break. This is called a "pomodoro", because the time is measured with a kitchen timer shaped like a tomato (The italian word for tomato is pomodoro. A differently shaped kitchen timer might work too). Log all interruptions during these 25 minutes and try to minimize them. Log how many "pomodoros" (pomodori?) you spend on every item from the TODO list.

The book about the technique is interesting and easy to read. It is also quite short. I have been trying this technique a couple of times now, and so far I really like it. When working for 25 minutes without any interruptions you can get a lot done. And the breaks make sure that you can concentrate for the full 25 minutes in the next pomodoro. I think I'll need some more days of using this technique until I get really used to working like that. Still, even after a few days I see improvements in productivity yet I don't feel overworked, so this technique really seems to work!

(*) I also read books and work on blog posts when riding the train an on other occasions. But: Different Story ;)

This blog post is part of the mini series about Framework Design Principles.

How can we make sure that our code is extensible? How can we enable or even encourage the users of our library to use the library in new, interesting and unexpected ways? First of all, Simplicity is really important here. Also, we should support inversion of control (IOC) - and if possible we should not constrain our users to a specific IOC container. You can deliberately create "leaks" in your abstractions. And, last but not least, lambda expressions and closures can be an awesome tool for providing extensibility.

Simplicity

Only simple code is extensible.Useless abstractions in the code, trying to anticipate future requirements and even adding design patterns where they are not needed can make the code unnecessary complicated. Just as I have mentioned in my blog post "Simplicity", the benefits of these things are local and grow linear, while the drawbacks have global effects and grow exponentially.

To ensure extensibility it is vital to keep things simple. There are some principles we can keep in mind that are based on the idea of simplicity. The Single Responsibility Principle, the Single Level of Abstraction Principle and the Direct Call Pattern are only a few of them. See also SOLID object oriented design.

Inversion of Control

Inversion of control - and especially dependency injection - can make extending existing code easier (even if it violates the direct call pattern - at least somewhat ;) ). This does not mean that your framework should be an IOC container. It also does not mean that you should force the users of your framework to use a specific IOC container.

You should just make sure that the framework or library you created can be used with an IOC container. Wicket, for example, lets you specify an "Injector" which is called every time a component is created to inject dependencies into this component. There are several Injector-implementations that support popular IOC containers, like Spring or Google Guice.

Leaks

Your library and framework should create new Abstractions and/or Simplifications. These abstractions will be (to some degree) leaky. But is this a bad thing?

Not necessarily. You can even create such "leaks" deliberately if it makes extending the framework easier! For example, Apache Wicket abstracts the fact that you are dealing with a web container. But sometimes, when writing a web application, direct access of the container would be handy! And it does not really make sense for the wicket developers to wrap all of the functionality of the container.

So, when you really need access to the container, you can get it:

getRequest().getContainerRequest()

You can do this too: Create your abstractions for the common case - for the 90% of the use cases where creating abstractions is easy. But, when these abstractions are not enough, allow your users to access the underlying technology in a controlled and defined way.

Lambdas and Closures

Paul Graham posted the following challenge in his essay Revenge of the Nerds:

In Javascript the solution looks like this:

function accgen(n) {
	return function(i) {
		return n += i;
	}
}

A function that creates another, anonymous function. How would the solution look in Java? Well, you can not solve this problem in Java - That is, you can not write a (reasonably short) solution that fulfills all the requirements. You might think "Well, nice, but what does that have to do with extensibility?". With anonymous functions and closures it is very easy to write reusable algorithms, like map reduce.

Of course you can simulate a lot of this behaviour in Java too, but there is a lot more boiler plate code you have to write. So, if your programming language supports closures and anonymous functions, use them to make your libraries and frameworks extensible.

This blog post is part of the mini series about Framework Design Principles.

When writing a framework or library, we have to simplify things and create abstractions. But: With every new concept or abstraction, our users have to learn more. They can not simply forget about the underlying stuff. And they can not simply ignore other concepts. This does not have to be a problem, we just have to think about it.

The law of leaky abstractions

Abstractions make working on large code bases possible: We don't want to deal with low level stuff. In fact, we can not deal with it - A large project would not be feasible if we had to write it in assembler. Or if we had to take care about disk I/O or scheduling. So, we need libraries that create new abstractions and/or simplify things for us.

But, as Joel Spolsky has said:

Wicket

This means that the abstraction, in some cases, does not work anymore. The user has to "dig deeper". The underlying concepts "leak" through the abstraction. For example, Apache Wicket tries to hide the fact that we are dealing with HTTP, a stateless protocol. Writing a web application with Wicket feels a little bit like writing a desktop application: There is a flow of events, components pass data to callback methods, etc. The communication over HTTP is not an issue, ever.

Except when it is. Every wicket component has a strange method:

setOutputMarkupPlaceholderTag(boolean)

To really understand what this method does and why it is needed, one has to understand how AJAX works and that we deal with a stateless protocol here. This method is only needed when a hidden component should be manipulated with an AJAX call. Hidden components are normally not written to the output (HTML) at all. The AJAX request is a new, stateless HTTP request, and the only thing at the client side that can be manipulated is the HTML from the last (stateless) HTTP request. Because of this, when an AJAX result should manipulate the hidden element, there has to be a HTML element which can be replaced with the AJAX result - the "Markup Placeholder Tag".

Moq - .NET

Another example is Moq, a neat mocking framework for .NET. Moq is great: It uses lambda expressions to configure mocks - They are checked by the compiler at compile time and refactoring safe. Configuring the return value of a method looks like this:

mock.Setup(
	foo =>foo.DoSomething(It.IsAny())
	).Returns(true);

This means: If a method called DoSomething is called on a given mock object ("foo") with a string parameter (It.IsAny() - the value of the string doesn't matter), then return true. There is some magic going on behind the scenes to make this work, but normally you don't have to care about that. Except when the magic stops working: Like, when you want to mock a protected method. Then, suddenly, you have to write different code:

using Moq.Protected()
...
mock.Protected()
	.Setup("Execute")
	.Returns(5);

If you want to truly understand why this difference exists you'd have to understand how the magic works in the first place and why this is not possible with protected methods. The easier way is: Just use the second code snippet for protected methods. This probably works for most of the users of this framework, but when there are unexpected problems, they still have to dig deeper.

What do do

So, all abstractions we create will be leaky. But we have to create them, otherwise developing large system might not be possible anymore some time in the future. For every new concept our users potentially have to deal with 2 concepts: The new one, and the old one. But inventing and creating new concepts is part of the essence of our job as programmers.

Are these "leaks" a bad thing? Not necessarily, I think. We just have to be aware of them when designing a framework. And we have to make sure that they happen at defined places, and in defined situations. We have to know the limits of our abstractions and concepts. And we have to look at our framework or library from the perspective of our potential users. Both are a good idea anyway.

Anyway, we should be really careful with creating new abstractions in the first place. We are always at risk of causing more trouble for our users than what they get as benefit: They have to remember more concepts and their programs become potentially harder to read, write and debug.

Last week I tweeted "Just *try* to tell a construction worker to use a cheap plastic drill because a hilti is too expensive." - A statement that I shamelessly stole from a co-worker. To most people I know, the idea of professional construction workers using cheap, crappy tools seems hilarious. But what about software developers? Well...

When I tell people that I use an expensive mouse and keyboard, or that I bought a mobile workstation for 5x the price of a cheap laptop, or that I have a really cool office chair, I often hear something like "Whoa! Why do you waste your money like that?"

And when it comes to software... "A text editor for $60? Don't you know Windows comes with one out of the box?" Or "Why do you need a $499 Profiler? Aren't there cheaper ones?".

Good tools are (sometimes) expensive. [*] But they are always worth it. Working with bad tools is not only inefficient, it is also frustrating. And frustration kills productivity.

I hear these comments about wasting money even in our own industry - from fellow programmers and from my customers! I worked for several customers where it was not possible to get a second monitor. One customer wouldn't even let me bring my own. I never had a good mouse or keyboard when I had to work on computers provided by my customers. And don't get me started about office chairs...

Of course I could use the cheap keyboard and mouse that came with my computer. And I could sit on a chair from Ikea. I could work on a $500 laptop. I could use the built-in profiler of Visual Studio or Java. The construction worker could drill holes with the $50 drill from the discount store.

But: I use these things 8 hours a day - or longer. I want them to feel right. I don't want my hand to hurt after using a cheap mouse for a day. Good tools allow me to do my work more efficiently. And for some kinds of problems the cheap tools won't work at all or take way too long.

Good tools are (sometimes) expensive. [*] But they are always worth it.

[*] And sometimes they are not. But that's a completely different story. Also, expensive tools are not always good.