« Posts under General

The God’s Equation for Perfect Highballs

“Mix a stranger a good drink and no longer will he be a stranger”
— Yours truly

I’ve never been a fan of pure mathematics. Even though I must admit that pure maths bears a lot of elegance, it’s real-world applicability that makes mathematical discoveries shine.

Boy oh boy, how time flies! It’s summertime again, at least in the northern hemisphere, on this planet, and what a great time it is for drinking plenty of highballs. For those of you who don’t know: highballs are simple long drinks that are made up of two ingredients: liquor (eg. gin, whisk(e)y, rum) and a non-alcoholic beverage (eg. soda, juice, cola).

Even though there are usually only two ingredients it is not that easy to make a perfect highball. It all depends on the right mixture. Some like their highballs stronger, others lighter. So how do you determine the perfect ratio? The task is complicated by the fact that the strength of the liquor used might vary (for instance, rums come with alcoholic strength levels reaching from 35% to 80%).

So I sat down for a while and did a little math — to solve a real-world problem once and for all. What I’ve come up with is this:

In this equation, Vn is the volume (amount) of non-alcoholic beverage, Vl is the volume (amount) of liquor, R is the mix ratio, Sl is the alcoholic strength of the liquor used and Sh is the desired target strength of the resulting highball. Isn’t this wonderful?

As an example, I happen to like my highballs with a strength of 10% and most liquor in Europe is sold with a strength of 40%. What’s the recipe for a perfect Gin and Tonic? Answer: 40% divided by 10% is four, minus one is three. Therefore, you would need three parts of tonic water for one part of Gin to make me smile.

If you prefer a 5% Gin and Tonic (are you a wimp, by any chance?), note that you will need seven parts of tonic water, not six, as a naive would-be drinks mixer would expect.

There you have it — the formula for perfect, repeatable quality drinks. People in the same spirit (pun intended!) — let’s raise our glasses to this discovery!

Epilog

I know, I know. Some of you smug, mathematically inclined folks with an IQ of 180+ would probably have known this right away. I don’t mind if you point out that my pathetic “discovery” is obviously just a special case of something more profound. Congratulations! I will drink a very special toast to you tonight.

And — just in case you haven’t done the maths yourself in the meantime, here is how I derived it:

Strength of liquor Sl is volume of alcohol in liquor Val divided by the total volume of liquor Vl:

Total volume of highball Vh is volume of liquor Vl + volume of non-alcoholic beverage Vn:

Strength of highball Sh is volume of alcohol from liquor Val divided by the total volume of highball:

Inserting (2) in (4):

Inserting (3) in (5):

Cheers!

Password Sins of Omission — Will They Ever Learn?

“Where have all the passwords gone, long time passing?
Where have all the passwords gone, long time ago?
Where have all the passwords gone?
bad admins stole them everyone.
Oh, when will they ever learn?
Oh, when will they ever learn?”

(With apologies to Peter, Paul, and Mary)

It’s been quite a while but yesterday it happened again: after I had registered with a new electricity provider I was sent an email showing my password — right next to the words “Your Password”. There was also a link that I was supposed to click to verify my personal data, including name, address, date of birth and a lot more things that I certainly don’t want share with the world.

What amazes me most about this incident is that even today some companies are completely oblivious to how easy it is to automatically scan emails for keywords on their way from sender to receiver.

But even if the probability of someone sending around your credentials in plaintext is a lot lower today that ten years ago, the chances of being faced with poor password systems are still quite high. Here is my personal list of the grossest password-related blunders.

1. Storing user passwords. This is probably the greatest of all password sins, especially since it may spawn many other password-related follies. Don’t store passwords, not even encrypted. Instead, salt the password with a random salt and then hash it with a strong hash function before you save it. This way, no rogue admin can run away with your users’ passwords and no crazy customer service team is able to send around mails disclosing credentials.

2. Gratuitously limiting the password character set. I’ve come across password systems that only accept numbers (i. e. PINs), others only a mix of characters and numbers, some would accept special characters like %, &, and ? but not the dollar sign. I don’t see any reason why it’s not possible to use the whole unicode character set; at the very least, all printable ASCII characters should be considered valid. If I wanted to attack a site the very first thing I would do would be to set up an account and find out about their password character limitations in order to prune my search space.

3. Gratuitously limiting the password length. Some folks don’t seem to realize that with passwords, size matters: longer is stronger. An easy-to-type passphrase like “theluckgreensunsdontkiss” is much more secure than the complex, ugly, it’s-so-hard-to-remember-that-I-need-to-write-it-down “B!A7n4$”. While there is good reason to set a limit on the lower bound (I personally would require a minimum of eight characters) it is outright dangerous (read: stupid) to place an upper bound on the length. Be careful: If a site demands a password length of 6 to 8 characters, it is a clear sign that they take security lightheartedly. Maybe they even store your passwords and shorter passwords consume less space on server hard disks. Yikes!

4. Not telling users about limitations. Limiting the password length and character set is by itself a horrible practice, only made worse by not telling users what the limits are beforehand. It is quite annoying if you attempt to set a new password only to be rejected with an error message saying that your password is not in line with the password policy. This has happened to me many times and in one case there was a link to the policy that was broken.

5. No “show password” option. I vividly remember the day when I had to choose a password for a smartcard-based access system at a company I worked for. At the company’s registration office was a terminal that asked me to select a new password for my card. Since there were quite some (gratuitous) limitations (at least one number, a single capital letter, no number at the beginning, no underscore, just to name a few, and they were not displayed beforehand, of course), I had to try several times making minor variations to my favorite password until it was finally accepted. Later, when I had to use it for the first time, I couldn’t remember it anymore. I’m not sure, but I guess that if I had been able to see my weird password in plaintext after I set it, my chances of remembering it would have greatly increased. Normally, I know if somebody is staring at my screen (and this is rarely the case), so why not add a “show password” check box that I can tick? This would also help me in cases where caps lock was on or when I inadvertently switched to a foreign keyboard layout.

6. Setting constraints on the login name. Why does the login have to be an email address (which an attacker is likely to know or which might change in the future), or a number, or an eight character word in all uppercase? One of my web hosters forces me to sign in with my 12 digit customer ID that they assigned to me years ago; I always have to look it up and I always curse the web hoster. Users should have absolute freedom regarding their choice of login name — not only when they create the account; also at any point later in time.

7. Not encrypting passwords before sending them to the server. There are still some sites (and email providers) out there that ask for your credentials without establishing a secure channel first. What that means is that your login name and password are transferred in plaintext to the server and every random wiretapper is able to use it to place adverts to all kinds of shady products in your name. I don’t know how many bloggers are out there using WordPress, but it must be hundreds of thousands; and almost all of them login through a login page that doesn’t use any form of encryption. Even if the NSA is able to read your SSL-protected traffic anyway, it doesn’t mean that you want everybody else to read it, too.

8. Not (or wrongly) using a brute-force attack countermeasure. To prevent brute force attacks a good password system should track the number of failed login attempts. My bank does this but in a rather stupid way: after three unsuccessful tries, your account will be locked and you have to personally go to your local branch office to request a password reset. My suggestion: from three unsuccessful attempts on, have the user wait 10 minutes for every further attempt; additionally present a Captcha to defend against automated denial-of-service attacks.

So here you have it and this is just my personal tip of the iceberg. In order to get real security, password systems need to be both: secure from a technical point of view and user-friendly; at least, they shouldn’t haphazardly limit freedom. The best password policy is worthless (actually dangerous) if it requires users to invent next-to-impossible-to-remember passwords that will end up written down on sticky notes.

Since there are so many sites out there that carelessly deal with passwords and personal user data, I think it is a about time for a law that requires companies to follow certain minimum standards. We just can’t rely on good will and common sense. We have done this for quite some time now and it demonstrably hasn’t work out.

Circular Adventures V: The Christmas Edition

“And the Grinch, with his Grinch-feet ice cold in the snow,
stood puzzling and puzzling, how could it be so?
It came without ribbons. It came without tags.
It came without packages, boxes or bags.
And he puzzled and puzzled ’till his puzzler was sore.
Then the Grinch thought of something he hadn’t before.
What if Christmas, he thought, doesn’t come from a store?
What if Christmas, perhaps, means a little bit more?”

— Dr. Seuss
“How the Grinch Stole Christmas”

Oh well, oh well, it’s Christmas time again. Year after year, in this dark season, people contemplate the circle of life, watch reruns on TV, and rush to shopping malls to buy overpriced items for their loved ones; it is not unlikely, that — as soon as the shops are open again — these loved ones rush to return all the stuff that they don’t really need and buy something cool instead. You can also be sure that the level of madness increases every year — due to a well-known effect that economists call “inflation”.

Since so many things recur around Christmas, this is the perfect time for me to share more “circular” thoughts with you.

But first some background on the origins of Christmas. The reason why people celebrate Christmas on December 25 has little to do with the birth of Jesus, but rather with an ancient Roman cult called “Sol Invictus” (which means something like “unconquerable or invincible sun”). When the Julian calendar system was introduced around BC 45, the winter solstice occurred on December  25 (as opposed to today, where it happens on either December 21 or 22); this day was celebrated as the birth of the sun: on December 25, the sun would come back and rise to its full power over the next months.

It is believed that early Christians also took part in these festivities and celebrated together with the pagans by kindling lights. When the “Sol Invictus” cult was finally replaced by Christianity around AD 300, Christians decided to keep that special day but celebrate the birth of Jesus Christ, instead. (Today, it is assumed that Jesus Christ was born somewhere around March, BC 4.)

But now back to more technical stuff. You might have observed that the weekday of a particular date within a year gets advanced by one weekday in the following year. That is, if first of August is a Tuesday this year it will be a Wednesday next year. But how come?

Being a veteran circular adventurer by know, you should be able to come up with an answer yourself — at least you should try. Don’t cheat. Don’t read on. Think about it.

OK, here you go. A regular year (no leap year) has 365 days and a week comprises seven days. 365 mod 7 is 1, which means that after 52 7-day weeks, there is still this one day left in the old year to be filled with a weekday. You can think of it like this: the old year nibbles away one weekday from the new year and thus weekdays in the new year are “rotated left” by one. For leap years, the “rotate value” is two, since 366 mod 7 equals 2.

Regardless of your convictions, regardless of how strange they might look to adherents of other convictions, regardless of whether or what you celebrate, I wish all of you, dear readers of my blog, a Great Time and the best for the New Year.

More circular adventures…

The “Sofware-Project-as-a-Ladder” Metaphor

ladderThe world of software development is a world full of metaphors. Since its early days, software development has been compared to fields like writing, construction, and even rugby.

Metaphors are important for understanding unfamiliar topics and, yes, even in the 21st century, software development — with its own set of peculiarities — is still unfamiliar to many, including people who have worked in the software industry for decades.

Today, I would like to contribute yet another analogy by comparing a software project to a ladder.

A classic wooden ladder is made of two rails and multiple rungs, mounted together with wood glue.

THE RAILS

No matter what kind of ladder you build — short or long — you need two firm rails that act as a framework for the rungs.

In software development, the first rail corresponds to the people and the second to the process.

It is fairly obvious (and much has been written elsewhere about the fact!) that you need the right people in order to succeed. Right means highly motivated, proactive developers with the required skill set for the job at hand.

But you also need the right process that makes sure that developers are going in the right direction. The process doesn’t need to be heavy and bureaucratic (it shouldn’t be, in fact), but it must ensure that work progresses steadily towards the final product and that no important aspect of the product is overlooked. In short, a systematic process is essential to remove the “chance factor” from a software project.

THE RUNGS

Once you have the rails you can add rungs. Rungs will ultimately determine how long your ladder will be. Every rung gets you higher and closer to your goal.

In software development, rungs correspond to practices. Practices like continuous integration, unit testing, refactoring, static analysis, just to name a few. While the process has long-term, far-reaching influence on a software project, practices are micro-processes, steps that are taken by developers on a daily or hourly basis. Processes are strategic, practices are tactical. Each rung on a ladder only has a small impact on the overall length of the ladder, but it is the sum of all rungs that makes up a ladder.

THE GLUE

To get a sturdy wooden ladder, you have to put wood glue inside the notches. This way, you ensure that the rungs will stay in place, even under load.
Even if you have the best-quality rails and rungs, your ladder will sooner or later fall apart without glue.

In a software development project, glue corresponds to the environment that an organization provides to the team: quality of offices and technical equipment, but also issues like work appreciation, salary, and overtime — in short: how people are treated. These factors influence developer motivation and productivity and whether they will stay with the project and the company. In a bad environment sustained quality work is impossible.

I know that every analogy breaks down at some point but what I like about the “Ladder” metaphor is that it doesn’t favor any particular element. For a successful project, one that delivers a great product on time, everything needs to be right: people, process, practices, and environment.

The Online Programmer

“You should not have a favorite weapon, or any other exaggerated preference for that matter. To become overly attached to one weapon is as bad as not knowing it sufficiently well.”

— Miyamoto Musashi
“The Book of Five Rings”

Recently, my principles were put to the test when I was asked to integrate my existing Java application with another application that was implemented in C#/.NET — a task that made me shudder. I had fully absorbed Richard Stallman‘s philosophy, I was (and still am) a great fan of free and open software.

C#, I thought (and still think), was a nice language, but not really that much different from Java, it’s main purpose just being yet another attempt from Microsoft to lock in people into their technology and operating system (I have to clarify here that I’m not a Microsoft hater; Microsoft has done incredible services to the computing world. What I don’t like is that their operating systems are for users and not for programmers. With Mac OS X, Apple has proved that it is possible make an operating system that is friendly to users and developers at the same time; yet I avoid Apple for other reasons, but I’m digressing…)

Someone, by the name of Bryan Adams, once said “Ain’t no use in complainin’, when you got a job to do” and he was definitely right: a job is a job and life isn’t always a bowl of coffee beans. So I started porting my code to C#, I even did it in Visual Studio (Folks, since I do most of my typing in Vim, you cannot imagine what a torture that was; I constantly had to leave the home row of my keyboard, grab the mouse, go back to the keyboard, again and again. Luckily, I found a nice Vim plugin for Visual Studio that relieved most of my pains. Derek Wyatt has made some terrific screen casts about Vim; if you don’t know the benefits of Vim, please, please watch them!). Contrary to my initial belief, the job didn’t turn out to be that difficult and disgusting, mainly due to the friendly help of two guys: one was a colleague who is an experienced C#/.NET developer and the other was Mr Google himself.

The way I program these days is different to the way I programmed ten years ago. In the old days, I tried hard to learn every aspect of a programming language and most of what the libraries had to offer.

But this doesn’t work anymore, at least for me. Programming language elements and class libraries are so similar that I cannot keep them in separate compartments of my brains. But this is not a problem, at least if I have an Internet connection.

I don’t even bother to consult books, not even the HTML API documentation. Instead, I ask Mr Google things like this:

“ArrayList in C#”
“socket python”
“asynchronous IO in Java”
“XPath Java”
“random numbers C++”

In return, I get links to Q&A sites, tutorials, and online API documentation. Within seconds, I get my problem solved, sometimes even examples that I can use in my own code.

The advantage is that I’m now able to program in many languages, which is great fun and gives me a competitive edge over developers who only call themselves “C++” or “Java” experts. On top of that, I get many new insights by working with different languages; insights that turn out to be useful in completely other contexts.

I hope the Internet never goes down, though…

Documenting is a Team Sport, Too!

baton.jpgEveryone likes good documentation — unless they have to write it themselves, right?

One reason for this is that writing good documentation is hard, very hard in fact. It took Joseph Heller eight years to complete “Catch-22” and many other novels took even longer to write. As a countermeasure, some authors use a pipelined approach to writing (see Gerald M. Weinberg, “Weinberg on Writing: The Fieldstone Method“) that nevertheless allows them to release in shorter time-frames by working on many projects in parallel.

Speaking as a developer, documentation gets into my way of doing other, more enjoyable things, like, well, coding, for instance. I’m writing (!) this article to the defense of the poor chap who has been given the ungrateful job of writing version 1 of a document.

Imagine this situation. One of your team members, let’s call him Jack, is given the task of finding out how to setup a new development environment for some embedded Linux development board. After a week of trial and error he finally gets everything to work properly. Now — of course — he is expected to document what he did so that everyone else on the team can set up their own boards, too. Being a professional developer he sits down and types away; an hour later, he is finished.

What happens next is typical: Harry, the first guy who tries out Jack’s HOWTO, runs into problems. Not one — many. In some cases essential steps are missing, while others are confusing or just plain wrong.

Harry is upset. He runs about and whines how bad the documentation is, what a poor job Jack did and how unfair life is in general…

For sure, in a perfect world, Jack would have written a perfect document that lays out the shortest route from A to B; it would be instructive, entertaining, a work of great pedagogical value. In real life, Jack is exhausted. He had been a pioneer for an extended period of time, tried out many things that didn’t work, suffered hours of frustration and got stuck in a rut many times. Most likely he operated under time pressure and even more likely he doesn’t exactly remember what he did (and did not). Isn’t it a bit too much to expect that he now takes the perspective of the uninitiated developer and writes the perfect manual?

In my view, Harry shouldn’t complain — he should rather spend his energy on improving the document. He benefits tremendously from Jack’s pioneering work and I think it is only fair if he contributes a share. And what he can contribute is something that the original author can’t: When he reads Jack’s document his mind is fresh and clear, without any assumptions, so he is the best person to tune the document for the same kind of audience. And Jack is always there to support him — provided Harry didn’t insult him for not doing his job properly…

But even the next guy after Harry might spot mistakes or inconsistencies; and many month later people will discover parts that are obsolete because the environment has changed in the meantime. Then, it is their job to clean up; they are again the best persons to do it.

Writing good documentation takes both, a different mindset and time; and as the writer’s saying goes: “All good writing is rewriting”. Especially in an agile environment it is a bit too much to expect to get everything from a single person. XPers have long been used to this mode of software development through the principles of collective ownership and refactoring. I believe, these principles apply to writing documentation as well.