jan.krutisch.de

Hamburg Deine Radwege Teil 2

2013-06-10T00:00:00+02:00

Ich hatte neulich eine erst etwas unfreundliche, aber dann doch entspannte und lehrreiche Konversation mit einem Stadteil-Polizisten, der mich vollkommen zurecht darauf hinwies, dass ich auf dem Fahrradweg in der falschen Richtung, bzw. auf der falschen Seite unterwegs sei. Im gegensatz zu 100% aller Radfahrer, die der Beamte danach noch angehalten hat, wusste ich wenigstens, das ich im Unrecht war.

Aber darum soll es hier nicht gehen. Einer der Aha-Momente in unserer kurzen Unterhaltung war, dass in Hamburg momentan eine kleine Revolution stattfindet, von der niemand etwas mitbekommt.

Dazu muss ich etwas ausholen - Es gibt nämlich Radwege und Radwege. Genauer gesagt: Benutzunsgpflichte Radwege und Nicht benutzungspflichtige Radwege. Schon gewusst?

Der Unterschied ist eigentlich ganz einfach zu erkennen: Benutzungspflichtige Radwege sind mit einem Schild (Wer auf StVO-Beamten-Sprachverirrungen steht, dem sei der Wikipediaartikel ans Herz gelegt) mit dem typischen Fahrrad auf blauem Grund versehen.

Nicht benutzungspflichtige Radwege hingegen sehen nur nach Radweg aus, haben aber keine Beschilderung. Und wie der Name es sagt: Man muss diese Radwege nicht benutzen. Man darf es aber.

Das interessante ist nicht nur, dass die meisten Fahrradfahrer die ich kenne das nicht wissen, sondern auch dass Hamburg heimlich still und leise die Schilder abbaut. Der Hauptgrund dafür dürfte sein, dass die meisten Radwege der derzeit gültigen Verwaltungsvorschrift zu den baulichen Voraussetzungen (Am wichtigsten: Mindestens 1,50m breit, aber auch “geradlinige Wegführung” und “zumutbare Beschaffenheit”) nicht mehr entsprechen. Ein weiterer Grund dürfte allerdings auch sein, dass es inzwischen reichlich Gutachten darüber gibt, dass zumindest bei traditioneller Bauweise die Unfallgefahr bei Radwegen eher höher ist als wenn die Radfahrer auf der Straße fahren.

Beispiel gefällig? Die Schanzenstraße, durch und durch mit Radwegen versehen und mein Lieblingsort für Beinaheunfälle mit ahnungslosen Fußgängern hat sein geraumer Zeit keine Radwegschilder mehr. Der einzige Grund für mich, da trotzdem auf dem Radweg zu fahren ist die etwas schönere Ampelschaltung für Fuß- und Radweg, sowie der Spaß daran, Fußgänger zu erschrecken. Spaß beiseite.

Und wie gesagt - Niemand weiss das. Weder Fahrradfahrer noch Autofahrer die einen immer noch gerne anpöbeln, wenn man auf der Straße fährt.

Übrigens: Auch auf nicht benutzungspflichtigen Fahrradwegen haben Fußgänger nichts zu suchen und gängige Gerichtsurteile sprechen Fußgängern hier gern die Alleinschuld zu. Allerdings: Schon das verletzen des Luftraumes des Fußwegs (zum Beispiel mit dem Lenker) kann die Schuld umkehren. Noch ein Grund warum schmale Radwege nicht mehr als Pflichtveranstaltung taugen.

Es ist übrigens (ach dieses Rechtszeugs) nicht so, dass ein schmaler Radweg automatisch dazu führt (er entspricht ja nicht mehr den Vorschriften) dass man auf der Straße fahren darf - Das Auszeichnen eines Radweges ist ein Verwaltungsakt und auch illegale Verwaltungsakte sind bindend (aaaaaghrh), so lange sie nicht angefochten oder weggeklagt werden. Tja.

Jedenfalls - Ich empfehle Euch allen, sich mal ein bisschen umzugucken. Nach meinen bescheidenen Recherchen sind das inzwischen schon extrem wenige benutzungspflichte Radwege im Stadtgebiet. Und das ist gut so.

Was übrigens vollkommen verboten ist: Auf dem Gehweg fahren. Entweder Radweg oder Straße. Viele meinen (inklusive meiner Mutter), dass das viel zu gefährlich sei, aber die Statistiken sprechen da eine ganz andere Sprache.

Zurück zum Anfang: Die Benutzung von Radwegen auf der linken Straßenseite (also auf der “falschen” Seite) ist übrigens wirklich nur dann erlaubt, wenn explizit ausgeschildert. Ich wünschte mir, auch das wüssten mehr Leute. Ich missachte diese Regel zwar auch gelegentlich, aber wirklich nur dann, wenn ich den sonst entstehenden Umweg für zu groß halte und dann auch in der Regel nur sehr langsam und vorsichtig.

Ich vermute, manche von Euch halten mich jetzt für einen Gesslerhut. Meine Antwort darauf ist zweigeteilt: Einerseits können wir uns nicht beschweren, dass wir als Fahrradfahrer im Stadverkehr ständig benachteiligt werden, aber dann konsequent so tun als ob die Spielregeln, die das Miteinander in ebenjenigem regulieren nicht für uns gelten und zum anderen habe ich wirklich den Eindruck dass die meisten Menschen diese Spielregeln nicht mal kennen, was man sehr gut an meinem Lieblingsbeispiel erkennt: Radfahrer die wild klingelnd und schimpfend an einer grünen Fußgängerampel vorbeirauschen. In diesem Fall ist es nicht nur so dass man als Fahrradfahrer die rote Straßenampel zu respektieren hat, sondern auch so dass einem eigentlich der gesunde Menschenverstand sagen sollte, dass es nicht richtig sein kann, zu vermuten, dass man dort Vorfahrt hat.

In diesem Sinne: Viel Spaß beim Fahrradfahren, passt auf Euch auf und nehmt öfter mal die Straße: Das ist nicht nur sicherer sondern in den allermeisten Fällen inzwischen vollkommen in Ordnung.

Oh und natürlich: Ich bin kein Anwalt und nicht für eventuelle rechtliche Fehler in meinen Ausführungen haftbar.

Get the book while it is hot!

2013-03-12T00:00:00+01:00

So, finally, about at least two months after my original schedule, I started selling my book.

It’s been a tough decision. Not because I didn’t think the book was ready (I always planned to release it as soon as I thought it had enough material to be interesting to people), but because I, after Hendrik asked me if I knew Leanpub, basically threw 20-30 hours of work into the gutter and went for them instead of building the book on my own.

I did know Leanpub, of course. I even checked it out back in the days. But somehow I ended up trying to do all of this stuff on my own. Which was, as I see it now, a bad decision. From now on, every minute I invest into this project will be about the text and the example code and not about how to fix some weird code highlighter bug in Apple iBooks.

So, thanks Hendrik, for poking me in exactly the right moment (After I spent a full weekend on readying my own infrastructure and publishing chain).

It took me another day or so to convert the whole book to the slightly different markdown dialect Leanpub uses. Their publishing workflow is just insanely simple and brilliant - Thank you Peter and Scott for this great great platform.

And now I advise you to Buy The Book!

JavaScript Styleguides

2013-01-19T00:00:00+01:00

As an author of a soon-to-be-published book on JavaScript applications, I had to come up with a coding style to use in the examples I have in the book. So I wrote this article to explain my way of thinking about JavaScript coding styles.

Having said that, the JavaScript community if there’s such a thing, has a few elements that leave me baffled every time. One of them is the battle over coding styles.

One particularly curious example, that also often gets cited, is the npm styleguide. So to explain why my JavaScript coding style looks as old fashioned and C-Like, let’s look at this extreme example and why I don’t follow it.

I once made fun of the proposed semicolon-first, comma-first style at a lightning talk at last years Railsberry, but of course if someone comes up with such a weird, uncommon proposal (well, as it seems, it’s not so uncommon in the node.js world, but in general, JavaScript doesn’t get written that way a lot, I guess), it makes sense to take a look at the rationale behind it.

npm’s coding style is a bit unconventional. It is not different for difference’s sake, but rather a carefully crafted style that is designed to reduce visual clutter and make bugs more apparent.

There is something to be said about the “make bugs more apparent” part, especially with the comma/semicolon first approach. I do tend to forget commas a lot, especially when configuring stuff in JavaScript using the object notation syntax. I must admit, though, that it’s not bothering me as much as it should - I usually find these errors quite easily and as annoying as it sometimes is to make an extra roundtrip, it happens so seldom that I am not willing to sacrifice something else, something that I would like to dub the “aesthetics of language”: Punctuation, when writing in roman literals, belongs to the end of the sentence (or, in the case of a comma, the end of a section of a sentence). It’s how we consume written text. We start learning that stuff, or at least most of us these days, at an age of 4-6. We spend at least 10-20 years using language this way before we first make contact with these so called “programming languages”.

Here’s the example from the npm styleguide regarding comma first:

var magicWords = [ "abracadabra"
                 , "gesundheit"
                 , "ventrilo"
                 ]
  , spells = { "fireball" : function () { setOnFire() }
             , "water" : function () { putOut() }
             }
  , a = 1
  , b = "abc"
  , etc
  , somethingElse

The array example actually looks visually pleasing, but everything falls apart after that pretty quickly. For one, the stand alone comma at the beginning of a line just makes me cringe. This does not happen in normal language. On the other hand, the array literal in most programming languages is modelled after something that we use in normal language every day, the comma separated list. Add flour, water, sugar, two eggs, stirr quickly.

So, while the CF syntax does have a few technical benefits, what gets completely lost here is the connection of our programming languages to, well, our languages, which doesn’t only make me cringe, which is bad enough, but it also is, by the way our brains are wired by using normal written language every day for most part of our life, way harder to parse. I don’t have real scientific proof for that, of course, only my anecdotal evidence.

So let’s get to the semicolons real quick. In npm code, semicolons are to be avoided at any cost. Now, this is interesting. For some reason, JavaScript has this thing called Automatic Semicolon Insertion, or ASI. As you can see in the npm styleguide, there are a few situations where ASI fails, because it cannot reliably detect boundaries between statements. The npm statement lists 5 exceptions to the “no semicolons” rule and in the end you might end up with code like this:

;(x || y).doSomething()
;[a, b, c].forEach(doSomething)

Again, a pretty bad violation of normal punctuation rules, but understandable if you hate the visual clutter created by semicolons at the end of statements. Which, I’m sorry, I can’t understand. Yes, I do love me my Ruby, and no, you usually don’t use semicolons there, but then again, we don’t have these funky edge cases to worry about, so unless you don’t want to have more than one statement on one line, your Ruby code will probably never have semicolons in it.

Now, you could argue that the semicolon is a violation of normal punctuation rules anyway, and I love programming languages where a statement is closed by a full stop instead, but somehow someone messed up and now we use the dot to pass messages and the semicolon to end statements. Still, having punctuation at the beginning of a statement looks confusing to me. (The fact that the semicolon is used for one line comments in most LISP variants and Assemblers is only adding insult to injury here)

This all doesn’t invalidate the arguments the author of the npm styleguide. And other people have their own takes on this as well. I also didn’t write all this to diss the npm style and their authors, but to highlight that obviously these people have very different priorities, but also a very different perception about this. The above post by Mikeal Rogers contains this bit:

I’m very happy using the npm coding style and not just for aesthetic reasons. I find that I have less errors and that I can read code faster and tend to lose my place less often than I did before. This is anecdotal and even though I wrote code with semicolons for years you could argue that I had a hidden aesthetic preference for this style I had not yet realized, but you can’t say that this method is error prone because in all this time I’ve never shipped a bug related to lack of semicolon.

To sum up: Mikeal finds npm code more aesthetic and easier to parse. I find, for myself, both to be completely the other way around.

@isaacs spent a lot of time in the comment thread on this gist to again and again explain his rationale. His core argument is that you are getting used to the (un-)aesthetical parts and you end up with only the benefits.

I don’t buy that. I do subscribe to the notion that you can get used to the style. I mean, after all, I managed to get used to JavaScript in the first place, which was an ugly and verbose language from the beginning. What I don’t subscribe to, and oppose strongly, is the notion that it’s okay to think of code as something completely different from normal language and thus okay to break conventions that exist in both spaces.

So, in the end, my JavaScript almost looks like what this guy wrote. It is not because I’m taking the Crockford for gospel. It is because I think that this is the way of writing JavaScript code that will be the easierst to parse for most people, either because it is closer to normal language or because it is just closer to how most people wrote C, C++ and Java for the last 40 years.

(It is interesting to note that CoffeScript, which I like quite a lot, fixes most of the problems the npm guide tries to address with syntax. The semicolon exceptions are fixed. You don’t need commas in an object literal, so no need to put them in the front, etc.)

Premature Abstractions Illustrated

2013-01-06T00:00:00+01:00

A lot of the discussion in the Ruby community are revolving around abstractions and when to use/do them and when not to. This is a struggle every developer faces every day, on various levels of, wait for it, abstractions.

It is also something the JavaScript community discusses very often, hotly, with very mixed results. If you look at, for example, the discussions around backbone.js and all of those add ons like Marionette, you can easily see that this is a topic that can lead to hot blood and unclear results.

Funnily, I recently fell into the “premature abstractions” trap pretty badly myself. I can’t share details in code, because it’s a yet to be released client project, but the story goes a little something like this (drop the bass): (Note: I shared part of that story on my mailing list for The Single Page App Book in the december post. A list you should subscribe to, of course.)

I spent quite some during october and november last year to develop the code for what I would call an “interactive child book”. A website, suitable for tablets and desktop browsers both telling a story and having some interactive elements. It was a joint effort and we were making good progress when, one day, our designer slash illustrator, my dear friend Benjamin, came in very unhappily and with some bad news: He was afraid that the whole thing wasn’t working, really. His main gripe was the very linear, page-by-page navigation that we’ve built.

And after some consideration, we all had to agree: It was uninteresting, technologically boring and didn’t serve the story we were trying to tell.

After working on this for quite some time, news like these don’t go down very well. But, yes, the current version simply sucked. No doubt about that.

Now, with some distance, It’s a good idea to look back and try to find out, how we ended up in that unfortunate position. I think the problem was twofold. The main mistake was mine: When we started with the production, I decided very early on to use Middleman as our “production system”, a simple means to have niceties like compass, coffescript etc. available. And Middleman, well, it’s based on HTML pages, right? So using pages as an abstraction for our content made total sense. We added some small animations and even a game to it and hey, it worked. Only, it didn’t, really.

The other problem was that we didn’t test our results with outside people. And we ourselves were so entrenched in our work that we didn’t see the big picture anymore, a problem that is very common and you really have to be careful to avoid that trap.

So, very close to Xmas last year, I cooked up some ideas on how to fix our problem technologically while the other guys (Consisting of Benjamin and the story experts from the three headed monkeys) tried to create a more visual storyboard with cues on how to do more complex transitions and how to vary the rhythm of the story both visually and textually.

And I fell into the abstraction trap again. Looking at the story board, I cooked up a json representation of the scenes, only to fail at implementing the animation part properly. The typical “design up front” fallacy. Almost always, when you try to come up with a design for something before actually coding, you’ll end up with bad code.

So I took this weekend and gave it some more thought. While fetching me a doughnut (Berliner!) from my favourite bakery, it hit me: Do away with as much abstraction as you can, implement some test animations and then build abstractions based on the low level constructs I used to build the test animations.

Now, in my case, I actually used a pretty amazing abstraction to build my low level prototype: Greensocks amazing TimelineMax and TweenMax from their Animation Platform, which is amazing, btw.. It can animate almost any css and element property (and does amazing things like automatically morphing (!) from one css class to another by interpolating with inline styles. All while being extremely performant even on mobile devices. As soon as we’re able to push out the project to the public, I’ll do a writeup on that software, because it is amazing.

In the end, I had a few hundred lines of JavaScript, css and HTML that were doing exactly what I wanted. My abstraction on top of the GSAP has about a hundred lines of code and already deals with a lot of the cases we’ll need. And by leaving out certain high level concepts my original idea had, I gained a lot of flexibility.

Just an hour ago, I finally pushed a branch to our private repo that contained by work of this weekend. And I’m really, really happy with the way this turned out, because I am now very confident that we can deliver an awesome product, even if we only have a few days left.

The lessons I’ve learned:

Make sure you have someone on the team or externally available that will keep the critical, outside look at the project, ready to scream and shout if things turn bad.
Don’t let your technical solution influence your design decisions. It’s the tool that needs to fit the job, not the other way round.
Don’t build abstractions as long as you have no proven idea on how the levels below that abstraction will look like.

Your Design Principles

2013-01-03T00:00:00+01:00

A quick show of hands, how many of you have seen Dave Thomas’ closing keynote at the Scottish Ruby Conf?

For me, this keynote was one of the most liberating moments of 2012. Why? Because in essence, he was telling me that I wasn’t crazy. He was telling my that my gut feelings of what I thought was wrong with the rails community were at least shared by someone who I hold in high regard.

(By the way. If you have never read “The Pragmatic Programmer”, please do. Really.)

Here’s the contents of the slide where Dave made me jump with joy:

“Good” code is not the only code

Dave said:

I think there’s this increasing tendency in the ruby community to feel that somehow we’re the guardians of “good” programming taste. Right? Everything has to be done right. Everything has to be done using patterns. Everything has to be done using factories and injection and all this other kind of bullshit that I tried to escape when I left the Java world 1999. And what happens? You’re bringing it back to me. STOP!

Yes, you could say that this resonated with me.

The Gospel

There is this weird misconception in many developers heads that the works of Uncle Bob Martin and Martin Fowler and the GOF are set in stone. That it is something to be followed religiously and if you don’t do that, you’re a bad programmer.

Don’t get me wrong. There’s a lot of valuable information in these books. You are certainly a better programmer if you have read, understood and, (here comes the tricky part) contextualized some of these books. But they are not gospel. They do not apply to every software design problem. They are not always the best solution.

So here’s my number one design principle, the only one I consider universally applicable to my work:

Get sh*t done.

Dave Thomas, in his keynote said this:

…if it works for you, and it is maintainable, then it’s good.

Which makes an important point: “Getting sh*t done” means that you should also be able to get sh*t done in two years or a few hundred commits down the line.

So, yes, Rails controllers do violate the SRP, but for the most part, they get sh*t done.

And that’s the thing with rails: Web development with rails is so efficient not despite the fact the rails core team chooses to ignore a lot of OO design principles, but often just because it chooses to do so.

Oh the complexity

Now, one of the biggest gripes people often have with large rails codebases are the tests. The source for their gripes usually is test runtime, which is a valid concern. Software that is hard to test is by definition not very maintainable, at least in my book. But here starts the rabbit hole descent:

Because then you find out that Rails’ unit tests are not really unit tests. Tests involving ActiveRecord often hit the database, something that Uncle Bob would probably want to shoot you for. And there you go, suddenly you discover that the rails codebase has all kind of ugly coupling going on that makes it really hard to test things in isolation. Because testing things in isolation makes tests fast.

And there is absolutely nothing wrong with that. This is a huge problem for larger codebases and test suites that run several minutes (if you are lucky) are a pain in the arse to work with.

What you do forget, though, if you argue against rails here, is that this is a deliberately chosen tradeoff. Because of this very bad tight coupling, you can do things in rails with a minimum amount of code in a few hours that takes ages in other technologies. If you look at all the decisions the rails core team made over the last years, in the end practical solutions that work almost always trumped design principles. You might not like it, but that’s how Rails rolls.

But, well, that statement doesn’t really fix your problem with that huge codebase, right?

More than one way

Right. If your codebase starts to grow beyond the limits of what’s acceptable from a test run time perspective, you do have a serious problem that needs to be fixed. And the problem only begins with test run time, because usually that’s just a very good indicator for general complexity in your app.

The gospel dictates that you should use Design Patterns and apply design principles to give you an idea to improve the code base. Decoupling things so that you can test things in isolation. Services, Presenters, Concerns, whatever. And that is a fine strategy. But by far not the only one.

Here’s something to think about first:

Why did your code base grow like that? Do you really need all that code? Did you relentlessly refactor and trim your code where possible? Do your users really use all of that app? Can you deactivate, then delete some code?

I’m asking this because I know a lot of examples where the complexity of a codebase was much more the result of a relentlessly pushed forward feature creep (hey, all those product managers need to do something, right?) than actual business requirements.

If you are in a situation like this, there are two solutions: Trying to push back, maybe by constantly asking a few “whys” before accepting a feature into the process. Or accepting that this environment will inherently produce complexity and then applying whatever strategy necessary to deal with that.

But instead of completely giving up on rails’ conventions and niceties as a tradeoff for a “better” design, what about trying to extract parts of your app as external services that can be built and tested independently? Bringing each of those apps back to a level of complexity that better fits rails’ conventions and assumptions?

There’s usually more than one way, that’s all I’m trying to say.

Complex things are complex

Because in the end, regardless of how hard you try, by ruthlessly applying OOP principles to your Rails app, you might actually make things more complicated. In a million ways. Starting with having to find common code conventions with your team, something that is a lot easier when you can take the rails conventions for granted. Also, while the resulting code hopefully is less complex on the inside (mostly: less coupling), it will be, at first, way more complex from the outside. Just take a look at the common examples of refactoring a rails controller into a class based construct. A lot more code to scan (less code is a value in itself, peeps), even if the code is more idiomatic.

Again, don’t get me wrong: That might be the only solution for your case that will actually gonna fix your problems. Sometimes requirements and solutions are just that: complex.

Before that, though, the wrongly named ActiveRecord and the wrongly named Concern and the wrongly named unit tests and the wrongly named functional tests, all weirdly coupled together in a big freaking mess, carried you a long, long way.

Don’t you dare to forget that.

From what I can see, DHH and the rest of the core team don’t care so much about naming, but they do care a great deal about “getting sh*t done”.

And that’s why I still love working with rails after now close to 8 years.

There simply is no alternative solution that is as pure as you would like Rails to be that is as effective to get sh*t done (for the specific use case of database backed web applications, that is). Indeed if you look at other frameworks that have similar capabilities in other languages, the pureness of their OO approach is usually not their biggest selling point.

Don’t make the mistake of thinking that this is just because nobody tried hard enough. You would make a fool out of yourself.

Der Sündenfall der Deutschen Presse

2012-12-01T00:00:00+01:00

Lasst uns bitte aufhören über das Leistungsschutzrecht zu reden. Also ich meine Inhaltlich. Das haben genug Menschen bereits getan und alle die sich auskennen und nicht befangen sind kommen zu dem Schluss dass das Quatsch ist. It’s understood.

Der große weiße Elefant im Raum ist, und darüber wurde zwar auch reichlich berichtet (wenn auch nicht in “der Presse”), aber vielen ist hier die Dimension glaube ich nicht wirklich klar: Das LSR stellt für die Deutsche Presse (und das gilt dieses Mal leider dann nicht mehr nur für Springer) einen echten Sündenfall dar.

Es wird immer viel gelabert über die “4. Macht” und die Kontrollfunktion, die die Presse innehat. Aber egal wie man dazu steht: Aktuell hat die Presse, also Tageszeitungen, Fernsehen, Wochenzeitungen/Magazine und dergleichen, noch einen relativ großen Einfluss auf die Politik. Ich will das gar nicht groß bewerten. Das Leistungsschutzrecht zeigt nun leider, dass die Deutsche Presse offensichtlich nicht in der Lage ist, verantwortungsvoll mit dieser Macht umzugehen. Die Berichterstattung zum LSR ist von wenigen Ausnahmen abgesehen von einer politischen Kampagne nicht zu unterscheiden, inklusive zahlreicher falscher Behauptungen, die gebetsmühlenartig wiederholt werden (“Was Google macht verstößt gegen das Urheberrecht”), Bewerfen des politischen Gegners (Google) mit Schmutz und Unredlichkeiten, nur weil der es am Ende doch nicht lassen konnte, mit einer Gegenkampagne zu antworten (“Missbrauch von Marktmacht” - Das Ironiemeter ist seit letzter Woche in Reparatur), usw..

Was wiederum daran liegen könnte, dass es genau das ist: Eine politische Kampagne.

Nun ist es zwar so, dass man wirklich politisch unabhängige Medien inzwischen eh mit der Lupe suchen muss und sich leider allzu oft die politischen Überzeugungen des Herausgebers oder des Chefredakteurs deutlich im Chrarakter des Blattes niederschlagen. Man könnte sagen, das wäre okay, so lange das Blattübergreifende Spektrum einigermaßen ausgeglichen ist und die Welt und die TAZ immer noch beide Existieren.

Im Falle des LSR hat sich allerdings eine unheilvolle Allianz gebildet, die, sagen wir es ruhig, vermutlich nicht zuletzt von der Angst getrieben ist, dass man nicht mehr so genau weiss, wie man Journalismus demnächst noch vernünftig bezahlen soll. Wenn aber die, die eigentlich dafür da sind, durch einen permanenten Wettstreit der Ideen und gleichzeitiger scharfer Beobachtung der Politiker diesen ganzen Wahnsinnsapparat den wir Demokratie nennen zu beobachten, zu kontrollieren und zu kommentieren, in eigener Sache plötzlich zu einer gemeinsamen Kampagnenmacht werden, die nachweislicherweise kritische Kommentare unterdrücken und gleichzeitig auf allen Kanälen mit maximaler Lautstärke eine einzige Botschaft herauspusten: “Gebt uns das Leistungsschutzrecht”, dann ist damit sehr schön demonstriert, wie weit es mit vorgeblichen Ehrenkodices her ist, wenn es um die eigene Sache geht.

Und damit wird am Ende das Kind mit dem Bade ausgeschüttet: Liebens- und Rettenswerter stellen sich Springer, SZ, FAZ und Konsorten mit dieser Nummer jedenfalls nicht dar.

Um mal ein total kaputtes Bild in die Welt zu setzen: Die Deutsche Presse 2012: Eher Schettino als Walbridge.

Zu blöd, dass dies alles für ein halbgares, vollkommen überflüssiges Gesetzt passiert, das am Ende (wenn es kommt) deutlich mehr für die Gilde der Rechtsanwälte leisten wird als für die zu Recht in die Krise geratene Deutsch Presse.

Endlich auf dem eBookCamp!

2012-11-06T00:00:00+01:00

Ich tendiere ja dazu, Berichte über Veranstaltungen inzwischen auf Englisch zu verfassen, aber beim eBookCamp, dass letztes Wochenende in Hamburg stattfand, mache ich mal eine Ausnahme: Zum einen war die Veranstaltung eine rein deutsche Veranstaltung und zum anderen sind die Leser, die diesen Artikel interessant finden könnten sicher auch in der überwiegenden Mehrzahl deutsprachig.

Mein Weg zum eBookCamp ist ein eher sonderbarer: Ich finde das Umfeld zwar schon seit Ewigkeiten spannend und war einer der ersten in meinem Umfeld die auch einen eBook-Reader hatten, aber mit der Verlagsbranche, an die sich das Camp vor allem richtet, habe ich bisher nicht so richtig viel zu tun gehabt, jedenfalls wenn man strikt von Buchverlagen ausgeht. Aber wie das Leben so spielt: Andrea Schlotfeldt veranstaltet nicht nur eBookCamps sondern ist auch noch mit dem Betahaus-Mitgründer Lars Brücher liiert, den ich nun wiederum seit besten Dot-Com-Zeiten durch unsere gemeinse Bürookkupation bei silver.screen kenne. Wir teilten uns damals lange ein Büro und ein paar Stereolautsprecher, über die wir damals sehr enthusiastisch Napster entdeckten. Those were the days. Und so saß ich eines schönen Tages im letzten Jahr mit Andrea in einem Reisebus im Cilento und wir sprachen über eBooks. Das letzte Jahr scheiterte meine Teilnahme noch an irgendwelchen Doppelbuchungen, dieses Jahr passte das Camp auf vollkommen magische Weise zwischen Reykjavík und Tel Aviv.

Am Samstag saß ich nun als erstes in einer Session zum Thema Piraterie und nachdem ich nach der Sessionvorstellung noch dachte, dass das eine gute Gelegenheit wäre, ein bisschen Ärger zu verursachen, stellte sich schnell heraus, dass Maike Prehn eine ziemlich gute und nüchterne Sicht der Dinge präsentierte und ich als jemand, der gerne Bücher kauft, sich aber andererseits nicht scheut die großen Versorgungslücken im deutschen Buchhandel auch mal, sagen wir, unkonventionell zu schließen eher ein geeignetes Anschauungsobjekt war. Gute Session mit ein bisschen Gegrummel, aber zumindest im Kreise dieser Session schien die Einsicht dass DRM jetzt dann auch endlich mal vom Tisch muss schon vor dem Vortrag vorhanden gewesen zu sein. Das war mal eine erste kleine Überraschung.

Babara Bossert hatte dann in der zweiten Session die etwas undankbare, aber irgendwie ja auch selbstgestellte Aufgabe, ihre etwas unergiebige Masterarbeit zu einer Idee namens ePub-Mixer vorzustellen. Unergiebig insofern dass der Grundtenor der Arbeit zu sein schien dass das alles nicht so einfach sein würde. Die Idee fand ich eigentlich ganz charmant (und deswegen war ich auch in der Session), nämlich Kunden zu ermöglichen, in einer Art Shop inhalte von Büchern wahlfrei miteinander zu kombinieren und dann das Endergebnis als ePub zu bekommen. Das ganze wirft nicht nur technische Fragen auf, sondern auch organisatorische, (urheber-)rechtliche, finanzielle und nicht zuletzt inhaltliche - Es ist z.B. vollkommen unklar, ob und wie Verlage ihre Inhalte so granular aufbauen können, dass eine Rekombination überhaupt möglich ist. Mein persönliches Fazit: Handgeschnitzte eBooks werden sich vermutlich vor allem in Bereichen ausbreiten wo Customization nicht nur einfach, sondern auch sinnvoll ist, also z.B. bei Reiseführern, Kochbüchern und allen anderen Formen von kleinteiligen Ratgebern. In der Belletristik ist das Konzept angesichts aktueller Verlagsworkflows, aber auch aus inhaltlichen Gründen vermutlich eher nicht drin in der nächsten Zeit.

Die dritte Session war dann meine und mit nur einer Handvoll Slides als Einleitung entstand eine wie ich finde sehr schöne Diskussion darüber, ob und warum Containerformate wie ePub und .mobi auf lange Sicht nicht sinnvoll sind, was man mit Hypertext alles anfangen kann und was verloren geht, wenn das lineare lesen verloren geht. Ich glaube am meisten Aufmerksamkeit hat meine Idee, Nils Holgersson von Selma Lagerlöf als geokodiertes Hypertext-Gesamtkunstwerk aufzuarbeiten bekommen - was mich darin bestärkt, dass doch mal anzugehen. Einzig, die Zeit fehlt wie so oft. Viel mehr kann ich zu meiner Session auch gar nicht mehr sagen, die Zeit flog an mir vorbei - Ich hoffe, das holen andere nach.

Alles in allem fand ich das eBookCamp eine auch für einen Aussenseiter wie mich erstaunlich entspannte Veranstaltung, ich fühlte mich sehr herzlich aufgenommen und hatte aber auch den Eindruck, dass das Publikum, dass auf so einer Veranstaltung auftaucht im Kopf schon deutlich weiter ist als seine Branche - Man hatte oft das Gefühl, dass sich im Betahaus eine Art Selbsthilfegruppe von Erleuchteten traf, denn oft wurde recht laut über die Unbeweglichkeit der eigenen Branche geklagt. Das einzige was ich wirklich schade fand war dass ich durch die drei parallelen Tracks immer zwei Sessions verpasst habe - Bei nur drei Sessions am Tag drängt sich das Gefühl auf dass man das ein bisschen in die Länge hätte strecken können und so die parallelisierung etwas hätte minimieren können.

Vielen herzlichen Dank an die Organisatoren und Sponsoren, auch für das tolle Präsent, dass ich mir als Sessionleiter zum Schluss noch abholen durfte. Nächstes Jahr werfe ich gerne wieder einen Blick in Eure Branche!

Distributed synthesis - my MHD Reykjavik hack

2012-10-30T00:00:00+01:00

This is actually a pretty sad moment - I am sitting in an airport cafe at KEF and am about to leave Iceland after a brief, 6 day love affair with one of the most exciting places I’ve ever been to.

The reason I’m here is the Music Hack Day Reykjavik which, as Johan, one of the organizers, told us, started off more as some sort of joke and then turned into the most awesome Music Hack Days I’ve ever been to. The event itself was great: Awesome food, great crowd of people, small enough to be able to get to know each other, pretty much the most awesome food I ever had at a hack day (Lobster soup from the Sea Baron. Need I say more?) and some pretty awesome hacks. But on top of this awesomeness: Iceland. With Geysirs and Huge Waterfalls (Gullfoss), Edges of continental plates.

But enough of that. If you can find a chance, to go to iceland, it’s worth it. I will definitely go back for a longer visit.

My Hack was something I had in mind for a long time now, but in contrast to earlier hackdays I didn’t actually prepare myself: I wanted to build some form of distributed synthesizer. With the Web Audio API available on iOS devices since iOS6 came out, this project got even more interesting. My original plan was to create something together with our long time MHD travelmate Michael aka Rockitbaby, but he had to cancel the trip on short notice due to very unfortunate events, so I was on my own. Early in on the hackday I then settled to deviate even more from my orginal plans and to make the hack Web Audio API only. This allowed me to use the Web Audio API building blocks to build a pretty nice sounding synth without actually having to calculate stuff in javascript. While this is certainly possible with current iOS devices if you don’t do totally crazy stuff, my new approach is certainly a lot less CPU intense, with the cost of lost Firefox compatibility. As soon as Firefox will support the Web Audio API, The Mozilla Wiki has some more Info on that, and progress of implementation can be checked in Bugzilla, only minor prefix changes will enable output there as well.

Implementation was pretty straight forward: I use a small-ish node server based on express and socket.io to deliver the two apps and to receive and send note-on and note-off events. One app is a very simple multitouch (with fallback mousedown/mouseup implementation) control surface that could use a lot of refinement, but in essence it only records touches and for every touch sends a note-on event with a note that is derived from one of two simple pentatonic scales and a control value between 0 and 1 that’s derived from the y-pos of the touch. The server distributes the notes round-robin to all connected clients under the rule that every client can only play one one. This limitation seems a bit stupid in retrospect and there’s no good reason to keep it, but I really wanted to have every note ending up at a different client.

The cool thing about the Web Audio API and a fact I have not really put to use before is that there are all building blocks to build a simple realtime pseudo virtual analog synthesizer, with a simple, but usable oscillator that can switch between the usual suspects like sine, saw, triangle and square and a custom wavetable that can be created by specifying the fourier coefficients for that wave, a nice versatile biquad filter and other blocks that can be nicely plugged together in any fashion you want.

What surprised me is that Chris Rogers, who created this at Google and who wrote the first spec draft and still is the editor of the spec, managed to choose the most flexible building blocks. As an example, it might be disappointing that the spec doesn’t include a generic Reverb effect, but instead Chris implemented a convolution effect, that allows you to use generic impulse responses to create a really really wide range of reverb, echo and other effects. Another example would be the above mentioned WaveTable implementation or the waveshaper that uses a customizable wave shaping table to create a variety of saturation and distortion effects.

You can take a look at the source at the githubs and it should be reasonably easy to set this up locally if you have nodejs and npm installed.

I love where this is going. I also love that I’ll be giving a talk about this web synthesizer stuff at codebits.eu in little more than a week (if the portuguese general strike will let me do it) and I’m pretty sure there will be a video of that available later on.

(Here’s a simple example on how to use the Web Audio API for synthesizer sounds I just plugged together)

Die Sache mit den Unternehmen

2012-10-18T00:00:00+02:00

Ich bin heute auf Twitter über Umwege auf ein paar Tweets von @christiansoeder gestolpert, der mit der These aufwartete, dass es Unsinn sei, von Unternehmen zu Fordern, Werte zu haben oder zu entwickeln - Unternehmen seien dazu da, Geld zu verdienen und Werte könne man Unternehmen nur durch geeignete Regulierung durch die Politik vorgeben.

Ich hab darauf hin eine sehr kurze Diskussion mit ihm gehabt, die er aber einseitig sehr schnell abgebrochen hat. Das will ich ihm nicht vorwerfen, ich war gefühlt einer von 200 Leuten, die ihn dafür verprügelt haben.

Ich beschäftige mich, wenn auch nur Hobby-mäßig und total unwissenschaftlich schon seit Ewigkeiten mit diesem Thema und mich ärgert diese Sichtweise. Aus mehreren Gründen.

Zum einen ist diese Sichtweise so typisch Sozialdemokratisch: Die Unternehmen, das sind die bösen, das wird man nie ändern können, und deswegen brauchen wir Gesetze!

Zum anderen passt es ironischerweise natürlich überhaupt nicht zu dem, was die Sozialdemokratie, wenn sie denn mal in Regierungsverantwortung war, an Politik betrieben hat.

Aber wichtiger ist eigentlich, dass mir diese Betrachtungsweise stinkt. Davon auszugehen, das Unternehmen per se kein Gewissen haben können, weil sie nur dem wirtschaftlichen Handeln verpflichtet sind ist eigentlich eine sehr wirtschaftsliberale Sichtweise, die nur insofern rot eingefärbt wird, als dass der Liberale davon ausgeht, dass die Marktmechanismen das Unternehmen zu gutem Handeln zwingen, während der Sozi meint, dass das Quatsch sei und nur Gesetze und Regulierungen für ethisches Handeln sorgen können.

Das Problem dabei ist, dass wir in beiden Fällen Unternehmen einen Persilschein für unethisches, wertefreies Handeln aussprechen. “Geht ja nich anders, muss halt wirtschaftlich denken, das dumme Unternehmen”.

Aber in einem Unternehmen und in einer Unternehmensführung arbeiten Menschen. Menschen, die man für unethisches Verhalten kritisieren und zur Rechenschaft ziehen kann. Menschen, von denen man verlangen kann, dass sie ein Gewissen haben.

Allgemeiner gesprochen: Gesetze und Regulierungen legen nicht das Verhalten von Menschen fest, sondern die Grenzen des akzeptablen Verhaltens. Der überwiegende Teil der Menschen würde einem anderen nie die Geldbörse aus der Tasche klauen. Für die paar Prozent, für die das nicht gilt (aus welchen Gründen auch immer), gibt es Gesetze.

Und dennoch geht man bei Unternehmen davon aus, dass es vollkommen normal ist, alles im Rahmen von Gesetzen und Regulierungen mögliche zu tun um Gewinn und Umsatz zu steigern. Lohndumping ist vollkommen normal und quasi zwangsläufig (weil Ergebnis eines Marktmechanismus), also brauchen wir Mindestlöhne.

Man verstehe mich bitte nicht falsch: Ich halte Regulierungen für nötig und wir brauchen eher mehr davon als weniger, gerade in diesen Zeiten. Mindestlöhne - Ja, bitte. Aber das darunter liegende Problem ist das ökonomisch geprägte Weltbild, das ökonomisches Handeln quasi per Staatsreligion (Weltreligion) über andere Leitsätze hebt.

Es ist meine feste Überzeugung, dass wir die so großen Probleme unserer Zeit (steigende Einkommensunterschiede, Altersarmut, kollabierendes Gesundheitssystem) nicht lösen werden.

Nicht so lange wir so tun als wären Unternehmen quasi nur auf maximalen Gewinn optimierte Algorithmen.

Ein bisschen lame, aber ich mach’s trotzdem. Hier, Grundgesetz Artikel 14, Absatz 2:

Eigentum verpflichtet. Sein Gebrauch soll zugleich dem Wohle der Allgemeinheit dienen.

Unternehmertum ist kein Selbstzweck. So lange wir das als Gesellschaft nicht begreifen und endlich anfangen, die Menschen, die die falschen, zynischen und ungerechten Entscheidungen treffen, dafür zu verurteilen anstatt sie sich hinter den anonymen Fassaden von “Unternehmen” verstecken zu lassen, kann Politik, im besten Falle, immer nur versuchen, durch weitere Regulierungen Schlupflöcher zu stopfen und so die gröbsten Schnitzer zu verhindern.

Man kann das am Ende naiv nennen, und so tun, als wenn ich verlangen würde zur Lösung aller Probleme die komplette Erdbevölkerung auf den Mars zu verlagern. Man kann aber auch z.B. Leuten wie Umair Haque zuhören (bzw. sein Buch “Betterness” lesen), die sich im Gegensatz zu mir auf wissenschaftlichem Niveau und gänzlich ohne den Verdacht dastehend, Naive Spinner zu sein, schon sehr lange mit dem Thema beschäftigen.

Wie heisst es so schön im englischen: We are better than this.

I'll be writing another book

2012-10-17T00:00:00+02:00

Just a quick post from another night where the sleep doesn’t come so easily. I am really happy to finally having gotten my sh-t together enough so that I can spread the news: I’ll be writing another book. The first one was definitely an interesting experience - It’s definitely worth a lot to be able to mention that you are actually the co-author of one of the first books on a subject when you are applying for a job.

That being said, financially, writing a technical book with a traditional publisher is a complete desaster. I knew this beforehand and since I was writing the book while being employed, this was not a huge problem in terms of financial risk.

This time, things will be a bit different.

First of all, I’ll be writing in english. I’m writing a lot, most of it in this place I call my blog, and I do think my writing isn’t that bad - But still, it’s a risk. I’m thinking about getting a proofreader, but that’s not decided. The main reason for an english book obviously is the much larger target market.

The second change will be that I’ll take the risk and try to publish it on my own. A lot of people in my surroundings are doing self-publishing experiments, and with Mathias Meyer I have a pretty prominent example in my contact list. Why self-publishing? Well, let me put it this way: The risk is actually not that big (tech book publishers don’t pay advances, so it’s not like the situation moneywise would be any different, at least for the time spent writing) and the benefits of having a publisher are getting smaller and smaller.

It’s relatively easy to put together a nice publishing toolchain that produces relatively good looking pdf’s and ePub/Kindle formats. Plus, you obviously make a much better cut. To put this in perspective: From the 29 EUR that my first book was sold for at a bookstore (Keep in mind that book prices are fixed in Germany), less than 10% of that went into my pocket (We wrote that book with two people, so writing it alone would have doubled that, but still).

What you are losing, of course, is the publishers marketing, but, while this will be hard work, I hope to be able to learn my own lessons on online marketing here.

What will the book be about? The general theme is “Single Page Apps”, and after my recent presentations and blog posts this should come as no surprise to most of my readers (all three of you). Regarding the content, I haven’t really decided yet. I started writing some parts I definitely want to have in the book, but research on this is ongoing, especially since there are now a lot of new books coming out and I want to prevent from being “just another book on javascript apps”. As people say, you really have to find your small niche, and “single page apps” is becoming a larger niche by the day.

Also, I have not yet decided on form (one large book or a collection of small books on single subjects, for example) and, obviously, pricing. They say pricing is hard, but so is writing a book.

What’s the timeline on that?

Glad you asked, here’s what I have in mind: I would love to have some form of test chapter online by mid-november, which incidentally will be when I’ll be giving my next talks at RailsIsrael and Codebits. I’m currently not totally sure if this is realistic because it’s been a while since I’ve had to crank out that much text. The next step will be a very rough beta release so that I can confidently start charging money for it, and my current plan says “end of this year”, but I’ll probably have to adjust that date at some point.

If you want me to keep you up to date on the progess, the best way will be to subscribe to “The Single Page App Newsletter” (yes, a mouth full). I will try to come up with some nice goodies and some tips and tricks for the subscribers.

You can also follow @singlepageapp on twitter or follow the plus page or like the facebook page (collect’em all!). I’ll try to keep all these places updated on my progress as well.

The official page will be thesinglepageapp.com, but I am the first one to admit that it’s largely placeholder content for now.

You can also expect some more blogging activity here, and I’ll try to follow Mathias’ example and will share my experience as much as I’ll be able to.