Sometimes I don’t code, sometimes I am radio-active.

In case you missed it, when it was on air: the episode of the Kulturwelle radioshow I talked about in my last blog post is finally online.

Sometimes I don’t code, sometimes I am radio-active. I was asked to support a group of students at the Berlin Humboldt University in creating an episode of their Kulturwelle radio show. That episode is all about acceleration of time in modern societies, and yes, you can hear me speaking at ~40 minutes into the show.

Curious? Make sure to tune in to piradio 88.4 MHz at 2013/3/20 8:30pm.

Ah yes! One year ago I prepared to move my blog to posterous.com. Just when I was ready to move the DNS name, Twitter announced it acquired that service. Well, this is what I call unlucky timing.

But still: posterous.com did run this blog since, and usually without much hassle. But now it will be gone for for good, and I needed a new hosting infrastructure.

However, the departure of the posterous.com web service teached me one thing: no longer will I rely for a web service to host my blog. Remember: this is not the first move, radiospiel.org lived in many places throughout the times, and with each change of the hoster some content was lost. (As is now: comments are gone, and some timestamps are wrong…)

So: this time I will use a static blog generator: http://octopress.org. After all, static files cannot get lost, right? So, wherever these pages are living in the net: I can just move them to wherever I like.

This time again the comments will be lost. And the ability to automatically post to Twitter and Facebook whenever I write something - but I will try to add this later. And I can’t post from a browser no longer. And there is no mobile app.

Can’t have the cake and eat it too…

a middle aged german woman - the kind that probably votes the Green party since ever - comes through the door, approaches the counter, and says something like (in german): “While I do speak english fine enough, I insist on talking german now.” To a barista that does speak german a bit, but english way better (no surprise, she probably being native US anyways).

Didn’t she see how gross and fremdenfeindlich that is?

If you don’t know it yet: 5 elephants is an american style coffee bar run by americans just around my corner. These guys running a website also: http://www.fiveelephant.com, and I can recommend their coffee.

Just a reminder: this is how to create a Postgresql user and database:

postgres@exs:/root$ sudo su -c psql - postgres 
psql (9.1.4)
Type "help" for help.

postgres=# CREATE USER dontpanic WITH PASSWORD 'PASSWORD';
CREATE ROLE
postgres=# CREATE DATABASE dontpanic;
CREATE DATABASE
postgres=# GRANT ALL PRIVILEGES ON DATABASE dontpanic TO dontpanic;
GRANT
postgres=# \q

wickr promises to let you communicate with others in a secure fashion from your phone – and have your messages dfestroyed after a while. It is free…

…and yet is a ripoff.

There is NO SECURITY to be had on mobile devices. Think about it: you need a strong password to set up strong encryption. Do you need to enter a 40 character string in Wickr each time you start the app? No you don’t.

That lets wickr – and in fact any mobile app – with two choices: generate a strong password and store it in an unsafe place – on the device which is probably secured with a 4-digit-pins only. Or ask the user for a (then) weak password and use that, which leaves wickr users with encredibly easy to break security.

And then: self-destructing messages? Ha! This is not how the net works. It is actually quite easy to interfere with internet routing in such a way that messages you send or received can be intercepted and stored by others. (Note: that doesn’t mean they would be immediately readable. But throw in the weak security inherent to mobile devices… well, there goes security.) Meaning: Wickr probably destroys a message’s copy on their own servers, and in your device and so on; but they can’t do nothing with other potential copies of the message itself.

To add REAL SECURITY to mobile devices we need a sufficiently secure and yet convinient way to set some kind of secret; something like a PIN, but with much more numbers. At this time, noone has anything to offer in that department.

What you get with Wickr is a weak concept with a nice UI; but a weak concept nevertheless. Bad security is actually worse then no security – think about it!

Assume you are living in Europe. Your home currency is EUR. As it so happens in todays global economy, sometimes you stumble upon an online shop outside of Europe that lets you pay only via Paypal.

As a German customer you usually have your checking account and one or more credit cards registered with Paypal. You’ll need the checking account in case you receive money; and the credit card is good for actually paying something, because you still earn loyalty points or so.

This just happened to me: I wanted to checkout items at some New Zealand store. When I went through with the checkout Paypal automatically converted the NZD amount into EUR at a really bad rate: 1.50 vs 1.57 or so – which is a cut of more than 4 percent already! After that they ask me to use my checking account instead of my credit card for the payment, because, so they say, my credit card company would charge me ~3% for international use, and oh are they nice to point that out…

Well, this is a blatant lie: AFAIK CC issuers do not charge extra for international payments, but for non-EUR payments. Which this one isn’t any more since paypal already forced me into a EUR payment. On top of that my credit card company used a fair exchange rate. And also untrue: my credit card company only charges 0.5% for non EUR payments; mentioning 3% seems a bit exaggerated.

Instead, I think, paypal prefers to charge my checking account instead of my credit card because that is basically free (~ 0.5%), while they would have to pay an ~2% costs when I used my credit card.

So paypal chooses to

• force me into a really bad exchange rate to earn an additional 4% on top of the already 3% or so charge the online shop has to bear,
• and feed me lies about my CC issuer to save on processing costs.

I think I will never use paypal on a non-EUR transaction again. And if you are running an online store: please consider adding a non-paypalled credit card payment options.

This one took me a while. I tried to install Ubuntu 12.10 alongside an existing Windows 7 installation on a x121e from an USB stick. And while the installation itself went smoothless, the boot configuration was not written properly.

The reason? Something prevented the master boot record to be written. Hence no grub and no way to choose the Linux OS to be booted. The solution: disable UEFI boot mode in the thinkpad’s BIOS! The default setting tries to be smart: try booting in UEFI mode, and if that fails boot in legacy mode. But this didn’t work, even though the disk itself is in legacy mode.

So save some time, disable UEFI boot mode, and you are good to go.

First of all: Ruby 1.8 does not deal well with umlauts and other non-ASCII characters. But now we have (at least) 1.9, which comes with proper support for encodings.

If both data and source are encoded in UTF-8 (or in the same encoding, to be more precise), then the naive approach works pretty well:

str = "künstlerhaus"
str.delete("ü")
=> knstlerhaus

This is the case if you are trying this code in irb.

If not, the String class implements a String#encode method, which converts a String into a different encoding, if needed. This is probably the best and canonical way to deal with umlaut issues:

str.encode "UTF-8"

This code raises an exception if

• there are some characters in str that cannot be encoded in the target encoding – which is not possible if the target encoding is an UTF encoding, because this by definition contains all characters, even Klingon :)
• or if there is some data in str that cannot be detected as an character. This means that the input string is not a string at all, just a bunch of binary data, and how would you convert that?

Now how to get the umlatu character into your source file? The best option is to save the file in UTF-8 – most editors these days do that just fine – and you tell the ruby interpreter that the source code is, in fact, UTF-8. This is done by a comment line on top of the file like this:

# encoding: utf-8

Alternatively – and probably safer, because it works in all editors, but less readable, is to put the character hexencoded into the source code. For this you look up the UTF-16 codepoint on the internet (in fact, it is not an UTF-16 codepoint, but the codepoint in UTF-16 encoding.) For the “ü” character this is “00FC”. Then you write it down like this:

str.delete("\u00fc")