Monthly Archives: May 2019

Whisky Head to Head

The idea is to drink two different whiskies and make a few comments. I usually do this alone, in the evening, with two small drams, a glas of water and some salty snacks (like crisps).

To me the way I experience a whisky can change from time to time. Not the least, it depends on what I have eaten and drunk before I taste the whisky. I find it very hard to drink one whisky one day, and another the next day, and compare them. I also find it hard to try many whiskies, because my senses quickly change. So two whiskies, head to head, should be the most fair way I can compare and rate whisky.

It is not my intention to rate value-for-money. I will mostly try standard whiskies that are produced and available, and expected to have somewhat consistent quality. I think it is more interesting to find good affordable available whiskies, than to seek the ultimate bottle from a lost distillery. Occasionally I will however try a more unique, rare and expensive bottle, to see how it compares.

Deanston 18 vs Old Pulteney 18: Color very similar, Old Pulteney somewhat darker. On the nose Old Pulteney is more pleasant; sweeter and richer. Deanston is dryer and slightly more chemical. Old Pulteney tastes perfectly balanced with a clear (but not overwhelming) hint of its Spanish oak casks, nice after taste. Deanston also very nicely balanced, with (to my taste) a more dry traditional single malt character. Both are very stable representatives of 18 year old Scotch single malt, but neither is very brave. If I have to choose I prefer the Deanston, I find it more interesting.

Jameson Black Barrel vs White Walker: Jameson has a deep sweet characteristic scent while White Walker is more subtle, a bit chemical to me. Taste impressions are quite the same; White Walker has a quite thin, somewhat sweet taste (perhaps the best I can say is that its not too bad considering its a blend). Jameson tastes caramel, very good, but a bit too much of something. I prefer Jameson, even without considering it is both cheaper an generally available. The reason I tried these two is that I found White Walker ice cold quite nice. I froze another blend (J&B) and it was not at all as good, and not as sweet. So I thought perhaps White Walker had a sweetness like Jameson Black Barrel, but it wasn’t so. I will try Black Barrel frozen some day (since White Walker is limited edition).

Glenmorangie 10 vs Storm: Both rather pale color, and light fruity on the nose. The Storm may actually have a slightly richer aroma. Glenmorangie tastes excellent in its light simplicity, although some bitterness remains. Storm is heavier, more flavour, less fruity, a bit chemical and more bitterness: I lack a defined character. After a while, I clearly prefer Glenmorangie, despite it is lighter (usually a more heavy whisky wins head to head, is my experience). Later, Glenmorange remains flawless in its simplicity, while there is something unpleasant about Storm.

Makers Mark vs Motörhead: Unsurprisingly they are both nice dark amber in color, very similar. Makers Mark has a much sweeter (raisin, vanilla) aroma while Motörhead is much more subtle. Same is true for the taste; Makers Mark has a fine Bourbon flavour also after drinking the drier and lighter Motörhead. They are both good. For those who like Bourbon Makers Mark is clearly the winner. Motörhead is still a good oakflavoured whisky, perhaps too sweet and Bourbon-like to those who don’t like that. Considering price, or not, I must say Makers Mark is the better whisk(e)y. Although, there are situations when I could prefer Motörhead.

Caol Ila 12 vs Kilchoman Machir Bay: As I expected quite similar color and aroma. Kilchoman slightly paler. On the nose they are clearly different, but I have a hard time putting words on it. Caol Ila is heavier, more oily. Starting tasting Kilchoman is like a sparkling firework in the mouth, very good. Caol Ila is, even when it comes to flavour heavier, more oily and more smooth. Sometimes I love heavily peated whisky and sometimes I think it is too much. This time I like them both. Ultimately, Caol Ila comes out slightly better for being richer and more smooth, but it is very close.


I will based on my notes above try to rank all the whiskys from best to worst. I will update this as I try more.

  1. Deanston 18
  2. Old Pulteney 18
  3. Glenmorangie 10
  4. Makers Mark
  5. Motörhead
  6. Jameson Black Barren
  7. Johnny Walker White Walker
  8. Storm

Heavily Peated

  1. Caol Ila 12
  2. Kilchoman Machir Bay

Simple Mobile First Design

If you build a web site today you need to think about the experience on mobiles, tablets and desktops with different screen sizes. This is not very easy. In this article I have applications (SPAs) in mind rather than sites/pages.

If you are a real, ambitious, skilled designer with a significant budget, there is nothing stopping you from doing it right. Responsive design is dead, because most often you have no choice, so it is just design.

However, you may not have that budget, skill, time and ambition, but you still need to think about vastly different screen sizes. Or perhaps you just need to build a simple native-app-like website.

Two separate implementations

In many cases I would argue that it makes sense to simply make a separate site for mobile and desktop. There are many arguments but I will give one: use cases are often very different. A desktop app is often opened, kept open for a long time, and much data may be presented and analysed on screen, in memory. A mobile app is often opened shortly, to accomplish a single task, and then closed. This means that you probably want to manage state, data and workflow very differently as well.

Bootstrap (or similar)

There are frameworks (like Bootstrap) and technologies like Flexbox to allow you to build a responsive app. Before using those, I think you should ask yourself a question.

How do you want to take advantage of more screen space?

Think of regular desktop applications (Word, Photoshop, Visual Studio) or your operating system: when you have more screen available you can have more stuff next to each other. You can have more windows and more panels at the same time. Mostly. Also, but less so, small things get larger (when they benefit from it). It helps to be able to see an entire A4 page when you work with Word. But when you have an Excel sheet with 4 used columns, those don’t use your entire screen just because they can.

Bootstrap tends to create larger space between elements, and larger elements where it is not needed (dropdown <select>, input fields). I say tends to, because if you are good and very careful, you can probably do a better job than I can. But it is not automatic and it is not trivial, to make it good

What I mean is that if my calendar/table looks gorgeous when it is 400px wide, what good does it make to make it larger if the screen gets larger? So I think a better approach to responsiveness is to say that my calendar/table takes 400px. If I have more space available, I can show something else as well.

Mobile Screen Sizes

To complicate things further, mobile phones have different screen sizes, different screen resolutions, and then there are hi-resolution screens that have different virtual and physical resolutions.

So you have your table that looks good on a “standard” mobile with 320px width. What do you want to do if the user has a better/larger screen?

  1. make it look exactly the same (just better/larger)?
  2. reactively change the way your app looks and works?

If you are opting for (2), I need to wonder why, really?

I argue that if you pick (1) you can make development, testing, documentation and support easier. And your users will have a more consistent experience. At the expense that those with a large mobile may not get the most out of it when using your app.

I propose a simple Mobile First Responsive design

What I propose is not for everyone and everywhere. It may suck for your product and project. That is fine, there are different needs.

I propose a Mobile First (Semi-)Responsive design:

  1. Pick a width (320px is fine).
  2. Design all parts, all pages, all controllers of your app for that width.
  3. On mobile, set the viewport to your width for consistent behaviour on all mobiles.
  4. Optionally, on desktop (and possibly tablets), allow pages to open next to each other rather than on top of (and hiding) each other to make some use of more screen when available.

Seems crazy? Please check out my Proof of Concept and decide for yourself! It is only a PoC. It is not a framework, not a working app, not demonstrating Vue best practices, and it is not very pretty. Under Settings (click ?) you can check/change between Desktop, Tablet and Mobile mode (there is a crude auto-discover mechanism in place but it is not perfect). You can obviously try it with “Responsive Design Mode” in your browser and that should work quite fine (except some elements don’t render correctly).

Implementation Details

First, I set (despite this is not normally a recommended thing to do):

<meta id="viewport" name="viewport" content="width=320">

Later I use JavaScript to change this to 640 on a tablet, to allow two columns. Desktops should ignore it.

Second, I use a header div fixed at the top, a footer div fixed at the bottom, and the rest of the page has corresponding margins (top/bottom).

.app_headers {
   position: fixed;
   top: 0;
   left: 0;
 .app_header {
   float: left;
   height: 30px;
   width: 320px;
 .app_footers {
   position: fixed;
   bottom: 0;
   left: 0;
 .app_footer {
   float: left;
   height: 14px;
   width: 320px;
 .app_pages {
   clear: both;
 .app_page {
   margin-top: 30px;
   margin-bottom: 12px;
   width: 320px;
   float: left;

In mobile mode I just add one app_header, app_footer and app_page (div with class). But for Tablets and Desktops I can add more of them (equally many) as the user navigates deeper into the app. It is basically:

<div class="app_headers">
  <div class="app_header">
    Content of first header (to the left)
  <div class="app_header">
    Content of second header (to the right)
<div class="app_pages">
  <div class="app_page">
    Content of first page (to the left)
  <div class="app_page">
    Content of second page (to the right)
<div class="app_footers">
  <div class="app_footer">
    Content of first footer (to the left)
  <div class="app_footer">
    Content of second footer (to the right)

I use little JavaScript to not add too many pages side-by-side should the display/window not be large enough.

It is a good idea to reset margins, paddings and borders to 0 on common items.

I also found that you need a font size of 16px on iPhone, otherwise the Apple mobile Safari browser will immediately zoom when user edits <input> and <select>.

Most effort when I wrote my Proof of Concept was

  1. Getting the HTML/CSS right and as simple as possible (I am simply not good enough with HTML/CSS to just get it right)
  2. Implementing a “router” that supports this behaviour

Being able to scroll the different pages separately would be possible, a bit more complicated, and perhaps not so desirable.


Exploiting the viewport you can build a web app that works fine on different mobiles, and where the issue with different screen sizes and screen resolution is quite much out of your way.

The site will truly be mobile-first, but with the side-by-side-strategy presented, your users can take advantage of larger screens on non-mobiles as well.

This way, you can build a responsive app, with quite little need for testing on different devices as the app grows. You just need to keep 320px in mind, and have a clear idea about navigating your site.

First look at Swift

Apple invented the Swift programming language to make application programming for iOS and macOS a better experience. If you are new to all this (as I am), I guess there are three approaches (depending on your background):

  1. Learn with the Swift Playground App for iOS
  2. Find a book/guide/tutorial to build actual iOS apps (learning Swift along the way)
  3. Use tools that you are used to, solving problems you are familiar with, using Swift (a programmers’ approach)

I decided to just write some Swift code. There is a cool web page called with implementations of different “problems” in different languages. I started looking at Swift code there to see if I could learn anything, and decided I could to better. (Admittedly, that is quite arrogant: I have never written a line of Swift code before, and now contribute Swift code)

I started looking at the problem Caesar Encryption and solved it for Swift. The full code comes below (in case someone changes it on Rosettacode)

I have a C/C#/Java/JavaScript background. This is what I find most notable about Swift.

Backward declaration of variables, arguments and function return types. Type comes after the name (with colon in between).

Named parameters to function, unless you prepend an _ to the name.

Closures can be written (quite just) like in JavaScript. (see charRotateWithKey in the caesar function)

Wrapping/optional: a normal variable, after it is declared must have a valid value. The language ensures this for you. Look at the first line in the function charRotate below: the ! means that if the parameter c does not have an ascii value the program will terminate right there. Look at the line starting with guard in main. The language guarantees that key is a valid integer after the guard, otherwise the function (program) must exit. I am far from an expert on this, find a better source! But you can’t do what you do in C/C#/Java/JavaScript – just hope it goes well, and if it does not catch an exception or deal with it afterwards.

ARC rather than garbage collection or explicit memory management. This matters not in my program, but it is worth mentioning. I first thought Swift and Rust were very similar and that it is more or less an incident that they are different languages, but I don’t really think so anymore.

The swift command can be used not only to compile a source file. It can be used to set up a swift project (directory), run tests, run the REPL (read-eval-print-loop) and more things. This seems quite nice, but I will write no more of it here.

My program below demonstrates type conversions, command arguments, usage of map and closures, string and ascii low level operations and output.

I think Swift is a quite fine language that I would be happy to use. I notice that the language has evolved quite much over the few years it has exited. So when you find things on the web or stackoverflow, you might not find current best practices.

func usage(_ e:String) {
   print("error: \(e)")
   print("./caeser -e 19 a-secret-string")
   print("./caeser -d 19 tskxvjxlskljafz")
 func charIsValid(_ c:Character) -> Bool {
   return c.isASCII && ( c.isLowercase || 45 == c.asciiValue ) // '-' = 45
 func charRotate(_ c:Character, _ by:Int) -> Character {
   var cv:UInt8! = c.asciiValue
   if 45 == cv { cv = 96 }  // if '-', set it to 'a'-1
   cv += UInt8(by)
   if 122 < cv { cv -= 27 } // if larget than 'z', reduce by 27
   if 96 == cv { cv = 45 }  // restore '-'
   return Character(UnicodeScalar(cv))
 func caesar(_ enc:Bool, _ key:Int, _ word:String) -> String {
   let r = enc ? key : 27 - key
   func charRotateWithKey(_ c:Character) -> Character {
     return charRotate(c,r)
   return String(
 func main() {
   var encrypt = true
   if 4 != CommandLine.arguments.count {
     return usage("caesar expects exactly three arguments")
   switch ( CommandLine.arguments[1] ) {
   case "-e":
     encrypt = true
   case "-d":
     encrypt = false
     return usage("first argument must be -e (encrypt) or -d (decrypt)")
   guard let key = Int(CommandLine.arguments[2]) else {
     return usage("second argument not a number (must be in range 0-26)")
   if key < 0 || 26 < key {
     return usage("second argument not in range 0-26")
   if !CommandLine.arguments[3].allSatisfy(charIsValid) {
     return usage("third argument must only be lowercase ascii characters, or -")
   let ans = caesar(encrypt,key,CommandLine.arguments[3])
 func test() {
   if ( Character("a") != charRotate(Character("a"),0) ) {
     print("Test Fail 1")
   if ( Character("-") != charRotate(Character("-"),0) ) {
     print("Test Fail 2")
   if ( Character("-") != charRotate(Character("z"),1) ) {
     print("Test Fail 3")
   if ( Character("z") != charRotate(Character("-"),26)) {
     print("Test Fail 4")
   if ( "ihgmkzma" != caesar(true,8,"a-zecret") ) {
     print("Test Fail 5")
   if ( "a-zecret" != caesar(false,8,"ihgmkzma") ) {
     print("Test Fail 6")