Christoph Jahn

Having been a very happy iPod user for more than six years, I finally got myself a Mac Mini as a kind of New Year’s present. And I must admit that it totally blew me away! The overall usability and the many tiny details that show the degree of thinking that was put into the product are awesome. And of course the design is so much beyond any computer I ever had before.

My only problem now is to find and play with all those nice tools that make one’s life even better. What I already installed are of course Emacs, Eclipse, and a few more. Once I have gained enough experience there will probably be a separate post on what I consider useful.

Just a quick post to share two awesome utilities that I have been using for a while now. I like working with the keyboard over the mouse in many cases, simply because I am faster with that, and was recently pointed to a a tool that will make things even better:

Auto Hotkey: This allows you to “play” an arbitrary set of key strokes and commands either by replacing text you just typed or by re-assigning a key (combination). Very handy for emails where you can now simply type “brc” and get “Best regards,<NEW_LINE>Christoph”

Another tool worth mentioning is Key Tweak, which provides a GUI over the registry that allows to remap the keyboard. My use-case was a very old IBM Model M keyboard that does not have a Windows key (I was made aware of the tool by this post)

I stumbled over this when reading a German article about the Visual Studio ALM Days 2011. Eric Ries basically makes the argument that startups, like any company, need management; you cannot expect to succeed without it. The key point, though, is that a special flavor of management is needed, which is tailored to the specifics of startup companies.

When looking at the reviews at Amazon, it becomes apparent that the author has hit a nerve. Although not all of them are really enthusiastic, already their sheer number (142 as of this writing) is interesting. I will not repeat things here but provide a few of my thoughts:

• First of all, I was reading this not from the perspective of someone who works for a startup or wants to create one any time soon. Instead my background is on distributed systems working for a well-established software company. So the aspect of how to change innovation within an existing organization was the interesting part for me.
• The key aspect I took away was that in many, many cases it is better to start building something quickly, fully accepting that the initial solution is far from perfect, and get feedback fast. This also coincides with my observation that most people have great difficulty to really grasp and understand something really new. Instead of spending much time on slides, just do a mock-up or prototype and some screenshots and all your discussions will be much smoother.
• If you expect checklists and concrete advice for your particular situation, you will probably be disappointed. I would argue, however, that the book’s approach to tell you how to think is certainly better than to have a one-size-fits-all list of things to check off.

Overall I enjoyed the reading and fell that it has expanded my way of thinking. Also, I found quite a few parallels (e.g. with agile software development) and this reiteration has helped to “persist” things in my mind.

Recently, I came across a very interesting post on Harward Business Review’s blogs. The article from Peter Bregman is called “How to Counter Resistance to Change” and I recommend you read it and also scan the other posts from the author. The part that will probably create a few raised eyebrows is when it advises against getting buy-ins. Well, at least in the dumb way this is usually done: In most cases I have personally experienced, what people effectively did, was try to persuade me (or even talk me to death). Folks, this is not getting a buy-in, this is talking someone to death.

In my view getting someone else’s buy-in usually means that the other party needs to change, at least partly, a position they had taken before. To make matters more difficult, in many cases the incumbent position has also been communicated to others, so we add the not-loosing-face factor to the equation. Variations of the latter are things like being seen in control by superiors as well as subordinates. But also the impact on relative strength perceived, compared to the person that gets his or her own view through, plays a role. So all in all this is quite a minefield and careful handling is required from a short as well as a long-term perspective.

What I found particularly interesting, or rather amusing, is that the author’s approach is something I also heard about in a TV series where it was called the “horse dealer’s approach”. So nothing really new, but still very relevant to many situations. Also, you can look at it as identifying a given pattern in as many different scenarios as possible. I am very much someone thinking in patterns and always find that one gets tremendous insight into the core of something following this approach.

I am quite happy that my first contribution to a pretty well known open source program has made it into the latest release of JMeter, the famous load-testing tool from the Apache folks. At the beginning of this year I needed to do some load-testing on JMS topics with durable subscriptions. At the time those weren’t available in JMeter so I dug into the code and added the functionality, which was less difficult than anticipated.

There is a bunch of information available that explain how to perform an unattended (aka silent) installation of Java on Windows  (examples for JRE and JDK).

What is usually not mentioned is the fact that when you specify a non-standard target directory, it must not contain any spaces. The easiest way to achieve this is the use of the 8.3 format. So instead of “C:\Program Files” you can use “C:\Progra~1″.

If you are looking for a small cross-platform WebDAV client, you should probably check on DAV Explorer. It looks a bit old-fashioned but is small (less than 600 KB), does not require installation, and simply worked for me. The only requirement is a JDK and its “bin” sub-directory in the path, but you have that anyway, don’t you?

It is probably not the best choice if you are a non-technical person, want to work with it every day, and look for a nice integration into your system’s GUI. But for quick tests or the occasional development-centric work it’s absolutely sufficient.

I can honestly say that I when I wrote my post about ALM and middleware, I hadn’t heard about the Open Services for Lifecycle Collaboration initiative. But it is exactly the kind of thing I had in mind. These guys are working on the definition of a minimum (but expandable) set of features and functions that allow easy integration between the various tools, which can usually be found in an organization. To my knowledge no products exist yet, but I really like the idea and approach.

Recently, I wanted to create a bunch of symbolic links pointing from an Eclipse workspace to all sub-directories in a given directory (SRC_MAIN). I usually keep the actual source code separate from the workspaces for various reasons and now had to set up a new workspace with a lot of projects in there.  The mklink command finally offers symbolic links (junction creates hard links which come with various side-effects I don’t like) and I needed a small wrapper around it, that I wanted to share.

@echo off
for /d %%A in (.\*) do (
	MKLINK /D %1\%%A %CD%\%%A
)

In order to keep things lean and easy, there is a prerequisite that the script must be placed in SRC_MAIN (in my case c:\Users\chris\src). The usage for a default Eclipse workspace is then
cd c:\Users\chris\src
symlink_all_subdirs.bat c:\Users\chris\workspaceNothing sophisticated but perhaps someone can use it (and it’s a backup for me as well).

For a while now I have been contemplating various aspects on logging and related areas.  Some of them have found their way into this post. I look purely at application logging, leaving out the underlying layers. In particular those comprise the operating system and other software that from the application’s perspective can be considered infrastructure (e.g. databases, middleware).

Stake Holders

There is a bunch of different groups that are affected by the logging aspects of an application. They all have specific requirements and some of those aspects will be looked at now.

• Developer: Yes, also the developer has some demands towards logging. For me two things are particularly relevant: During the creation of code I don’t want to be distracted from writing the actual logic. And later I don’t want to wade through lots of boiler-plate code.
• Application administrator: This person knows the internals of the application quite well and helps users when they run into problems with the application; often he or she also serves as a liaison with the system’s administrator. They must be able to quickly find out if a quirk comes from a real problem within the application, is a result of some external problem, or perhaps stems from “wrong” usage.
• Operations: These guys have to ensure that the entire IT landscape is running smoothly. All too often stuff is thrown upon them that has been designed with very little thought on daily usage. They must be given the possibility to quickly see whether everything is ok or things need to be escalated with application support. In particular this requires integration into system management tools. Those are usually working with JMX, SNMP and log file monitoring.

There is certainly a lot more to say here, but this should give a first overview and make clear that a variety of requirements needs to be fulfilled.

Logging vs. Monitoring vs. Management

One way how to look at the above line is that it describes a hierarchy of aspects that built upon each other: A set of log entries allows me to monitor my application; and monitoring is the basis for management. So logging is indeed a very important step for a smooth, efficient and compliant operation of my organization. The more you move towards the higher-level facets, the more important it is to abstract from the single, raw “event” and see the bigger picture. What also becomes important is correlation of events. Perhaps my application becomes less stable whenever database response times exceed a certain threshold. And Cloud Computing will certainly add something here, too.

Logging Dislike

Most developers think of logging as an unloved necessity. But why is that? In my post about Asynchronous Communication I made the point that poor tooling does not make a pattern bad, it is just poor tooling. Likewise, I think many people simply don’t have the proper tools for logging. Last year, while developing a small system management component, I conducted a small experiment on myself. Instead of hard-coding log messages I went the extract mile and wrote my own message catalog. The result is that my (implicit) workflow has changed. Whenever an additional log statement is needed, I now only have to do the following:

• Check the message catalog for a message I can re-use; if yes I’m done already (and perhaps have to wire in some parameters).
• If a new message is needed I need to decide on a new key. This should be done with some confidence that I don’t need to change it later (although this would already be much easier than plain text).
• Also a message and log level need to be chosen for the key. Those can both be done in a pretty quick-and-dirt approach, since changing them later in the catalog file is easy.

At first this may sound more complex than just putting in a plain text statement. But when putting everything directly into the code, all these things must be chosen with careful consideration because changing them later is much more effort. This distracts me a great deal, since coming up with a good log message and the appropriate log level is often far from trivial. While my initial rational for the message catalog had mainly been automated log file watching this ease of development proved to be the real “killer” for me.