today is tomorrow's past

Independence for Content and Layout - Moving away from blogger

2016-05-02T23:20:00.000-07:00

Perhaps it's about time. Move on. Try something different. The way I write and need to publish content changed in the past years. Most of the time, I write either in plain text, Markdown or more recently in Asciidoc. I believe plain text, or slightly enhanced plain text formats, represent a much easier solution to deal with on different platforms. Easy for versioning.

I consider content to be fluid. It must fit different formats to represent it properly. This brings me to the next wish: having a modern, easy to maintain design for my blog. I struggle with the template system and the way templates are organized in blogger. Making changes to the layout feels restricting and complex. There are a couple of instructions out there to tweak the hell out of blogger and bend it to your will. But it all seems like tweaks to me. Blogger works for a lot of cases and people out of the box. In my case, I want to experiment freely and make adjustments to my blog. Without the experience of being slowed down by the system. Blogger represents still a great way for people to get started with blogging. Minimal investment and solid foundation. I Believe, that I grew out of this whole system over time. I feel like I want more space, more breathing room.

In the next couple of weeks, I will move to a different space. I haven't made a decision yet. There are a lot of cool static site generators that I'd like to explore. When I made a decision, you will be notified.
I'll keep all the old content here. Nothing is about to go, but there won't be many new posts in the future.

Sometimes, you want to say good bye to say hello.

Call me! PythonJS and variadic functions

2016-04-19T00:10:00.000-07:00

I’m currently developing UI automation tests for Adobe Experience Design, aka Adobe XD. Or, for anybody who hasn’t heard of the recent name change: Project Comet!

Combine and attach different material

1. This is a note to myself. Mostly

Today, I got stuck in something that looked pretty straight forward to me. I wanted to call a function in a Python API from my JavaScript code. We use PythonJS to make this magic happen. In the most cases, calling a function in the Python API is not a big deal. Scalar values work well, named arguments work well, but variadic function args do not.
The function I wanted to call looks like this:

def menuItem(self, *args)

Calling the function from JavaScript, I tried several things. The most promising for me was to convert the JavaScript arguments into an Array and pass it on.

pythonObj.menuItem(['value1', 'value2', 'value3'])

The result was an error, telling me that I should call the function with a string or int. Okay, the function signature accept either one or multiple `int`s or `string`s. In various combinations.
I guess, my initial approach was a bit too naive. A JavaScript array doesn’t translate to a vararg in Python. Got it! But how do I pass the list of varargs from JavaScript to Python? I tried to apply the arguments from the JavaScript function to obj.menuItem. But this didn’t work with the same error.
I tried to call the Python function by

obj.menuItem("value1", "value2", "value3")

That worked well. But I can’t make this happen from the JavaScript side? How can I split up an unknown number of arguments and pass them all as single arguments? I had no answer for that.

2. Workaround, Hack, you name it

If I would have a fixed number of arguments, the solution would be easier. I ended up with a hacky solution (IMHO), since I didn’t wanted to spent more time on this interesting but blocking issue.

function callPythonFunction(args) {
    switch (args.length) {
        case 1: {

            return app.menuItem(args[0]);
        }

        case 2: {
            return app.menuItem(args[0], args[1]);
        }

        case 3: {
            return app.menuItem(args[0], args[1], args[2]);
        }

        default:
            console.error("Unsupported amount of arguments for args", args.length);
        }
}

Is this a good solution? Until I find something better, I consider it as a good solution.

3. Summary

Bridging languages and make up for missing or non transferrable features requires creative solutions. They might not be the best solutions, but they unblock and let you move on.

What do you think? Is there a better way of doing this? Let me know in the comments.

Thanks for reading!

DxO One - Ein Erfahrungsbericht

2016-04-13T23:54:00.000-07:00

Schon als die interessante Ansteck-Kamera im Frühjahr 2015 angekündigt wurde, hab ich ein Auge auf sie geworfen. Da die Kamera aber nur für den Anschluss an iPhones hergestellt wird, hatte sich die Sache nach Durchsicht der technischen Daten dann aber auch schon erledigt. Ich hatte zu diesem Zeitpunkt kein iPhone. Lediglich ein iPad, aber ich halte nicht so viel davon, mit meinem riesigen iPad durch die Gegend zu laufen und Bilder zu machen.

1. TL;DR

1.1. Kaufen? Ja, Nein, Weiss nicht

1.1.1. Pros

Bildqualität ist sehr gut
Selfie Mode (für alle die es brauchen)
minimales Gewicht, handlich, passt in jede Tasche
mit der Kamera App lässt alles aus der Kamera rausholen
Akku lädt sehr schnell wieder auf

1.1.2. Cons

Batterie hat eine kurze Lebenszeit (und kann nicht gewechselt werden)
Braucht beim speichern von Super RAW Bildern extrem lange
neigt zu überhitzen
der Lightning Connector macht für mich keinen robusten Eindruck

2. Jetzt aber

Mitte 2015 ist die Kamera dann für den Preis von $599 hier auf den Markt gekommen. Der Preisschock ging nach kurzer Zeit wieder weg, aber die Frage blieb: warum ist die Kamera genauso teuer wie ein iPhone oder wie eine gute handliche Kompaktkamera? Und diese Kamera macht definitiv nur mit einem iPhone Sinn, weil sie nur ein winziges Display zur Anzeige von Statusinformationen hat. Also ohne iPhone praktisch unbrauchbar. Ein iPad mit Lightning Anschluss würde auch funktionieren. Aber wie gesagt, bin ich kein großer Freund davon.

Im Februar 2016 hatte dann ein Händler die Kamera für $350 im Angebot. Das war dann der Moment. Ja, ich konnte nicht mehr widerstehen und hab die Kamera gekauft. Ja, ja, ein neues Spielzeug in der Sammlung.

3. Die Kamera

Ist sehr handlich und die Elektronik befindet sich in einem Aluminium Gehäuse. Eine Plastikklappe verdeckt den SD Karten Slot und den USB Anschluss. An der Seite des Gehäuses ist der Lighting Connector angebracht. Er wird einfach eingeklappt. Mehr Anschlüsse hat die Kamera auch nicht

4. Die iPhone/iPad App

Um die Kamera überhaupt bedienen zu können, muß die kostenlose iPhone App installiert werden. Die App kann vom iTunes Store installiert werden. Die App bietet alle Einstellmöglichkeiten die man von einer Kamera her kennt. Es gibt einen Auto Mode, verschiedene Szenenprogramme und die üblichen manuellen Modi (P, A, S, M). Blende und Belichtungszeit kann eingestellt werden. Der Fokus Mode kann aus der App heraus geändert werden. Die App dient auch dazu die Bilder von der Kamera auf das iPhone zu kopieren. Auf dem iPhone kann man sie dann weiter bearbeiten oder direkt von dort im Internet verteilen.

iPhone App - Camera Modi

iPhone App - Sucher und Einstellmöglichkeiten

5. Die Verbindung

Die Kamera wird über einen ausfahrbaren Lightning Connector an das iPhone angeschlossen. Der Anschluss klappt nur aus, wenn man den Objektivschutz ganz nach unten schiebt. Damit wird die Kamera eingeschaltet und der Lightning Connector fährt aus dem Gehäuse heraus.

Der LIghtning Connector zum Anschluss ans iPhone

6. Sensor

Die kleine Kamera hat einen nicht ganz so kleinen Sensor. Im Gehäuse steckt ein 20MP 1 Inch Sensor. Das gleiche Kaliber wie in einer guten handlichen Kompaktkamera. Leider habe ich nicht herausbekommen, ob der Sensor eine Eigenentwicklung ist, oder von einem anderen Hersteller lizensiert wurde. Macht aber auch nicht wirklich einen Unterschied. Ich wollte hier ohnehin nicht die Sensoren vergleichen.

7. Geschwindigkeit

Die Kamera legt ein gutes Tempo an den Tag. Fokussieren (vornehmlich mit dem Finger auf dem Display des iPhones) und dann den Auslöser betätigen. Die Bilder werden schnell gespeichert. Es sollte auf jeden Fall nicht an der SD Karte gespart werden (die übrigens nicht im Liederumfang enthalten ist). Mit einer schnellen SD Karte ist die Kamera schnell wieder einsatzbereit.

8. Bild Qualität

Die Bilder sind gut bis sehr gut. Auf jeden Fall besser als die mit dem iPhone erstellten Bilder. Aber das sollte mich auch nicht wirklich wundern. Die Kamera kann Bilder als JPEG und RAW und Super RAW speichern (dazu unten mehr). Ich fotografiere generell in RAW, um bei der Nachbearbeitung die meisten Möglichkeiten für die Korrekturen zur Verfügung zu haben.

9. Super RAW

Hoppla, was ist das denn? Besser als RAW? Ich wusste ja nur, das es unkomprimiertes RAW gibt, aber Super RAW. Okay, und was ist es nun? Die Kamera macht 4 Aufnahmen kurz hintereinander und diese 4 Aufnahmen werden in eine Datei geschrieben. Zum importieren muss man dann DxO Connect bemühen (siehe unten). Das ist eine zusätzliche Software, die man erst downloaden kann, nachdem man die Kamera registriert hat. Leider funktioniert die Registrierung der Kamera nur aus der iPhone App heraus. Beim Import mit DxO Connect (siehe unten), werden die Bilder dann mittels verschiedener Algorithmen zusammengeführt (das Rauschen wird stark minimiert) und so ein besseres Bild erzeugt. Das resultierende Bild liegt dann als optimierte JPEG Datei vor. Das Rauschen ist im JPEG definitiv geringer als in der orignalen RAW Datei. Aber ich weiß nicht, ob das diese riesigen Files Super RAW Files das Ergebnis rechtfertigen. Aber okay, irgendein merkwürdiges Verkaufsargument darf eben nicht fehlen.

Das Rauschen im JPEG ist auf jeden Fall geringer als in der Super RAW Ausgangsdatei

Auf jeden Fall sorgt der Super RAW Modus dafür, dass die Kamera ziemlich lange braucht um die Daten auf die Karte zu schreiben. Das ist auch nicht besonders überraschend, da die 4 fache Datenmenge gespeichert werden muß. Und ein RAW Bild ist so um die 40 MB groß! Die DXO Datei ist satte 160 MB groß.

Ich habe es mehrere male erlebt, dass die Kamera im Super RAW Modus ziemlich warm geworden ist. Ich habe nur einmal die Hitze Warnmeldung im Display der Kamera gesehen. Andere Benutzer scheinen damit mehr Erfahrung gemacht zu haben.

10. Firmware Updates

Das letzte Firmwareupdate hat der Kamera einen "Retro-Mode" verschafft. Was ist das? Das kleine Monochrome Display kann jetzt als Sucher benutzt werden, wenn die Kamera nicht an das iPhone angeschlossen ist. Damit kann man dann ohne das iPhone mit der Kamera Bilder machen (hätte man vorher auch schon machen können, wäre aber ein kompletter Blindflug gewesen). Das geht so als Notfall-Lösung durch. Richtig was sehen, kann man auf dem kleinen Display nicht. Nur Schwarz/Weiß und viel zu geringe Auflösung. Aber man sieht zumindest in welche Richtung die Kamera blickt.

Das kleine Display

11. Software

Eigentlich braucht man die zusätzliche Software nicht um die Bilder von der Kamera zu bekommen. Wenn man aber Bilder im Super RAW Format gemacht hat, dann sollte man DxO Connect auf jeden Fall installieren. Denn nur damit kann man den Super RAW Bildern die ganzen Informationen entlocken. Ansonsten können die Bilder auch direkt von der angeschlossenen Kamera oder der SD-Karte in Lightroom oder Apples Photos importiert werden.

12. Testbilder

Closeup

Farben

Abend

Langzeitbelichtung

Closeup

Licht und Schatten

Sonnenschein

Kunstlicht

Tageslicht

Sonnenschein

5 npm script secrets

2016-03-05T22:44:00.000-08:00

No Secret

Last week I was hosting a workshop about Electron Shell, ES6 and Reactjs at ForwardJS in San Francisco. Preparing all the sample code, I was inspired by this blog post to avoid any build tool like grunt or gulp at all. In fact, I wanted to remove anything that could distract the attendees of the workshop by throwing another unknown toolset at them. Instead, leveraging the build in capabilities of npm.

The Idea

Why use grunt, gulp, etc. if you can leverage the power of npm scripts? Not having to maintain a build script is a good idea and helps to remove another piece of complexity from your project.

Secrets

Different types of scripts

npm supports custom scripts defined by scripts property of package.json. npm distinguishes between 2 different kind of scripts

lifecycle scripts
directly-run scripts

Lifecycle scripts tie into a specific phase of your project lifecycle, like install, publish, start, stop, etc. These scripts can be executed with npm lifecycle-script. Each lifecycle script can have a pre and post script for that phase, e.g. preinstall and postinstall.

The directly-run scripts need the extra run command after npm, e.g. npm run *my-script-name*. Your directly-run scripts can have a pre and post step with the same name as your script name, e.g. premy-script-name and *postmy-script-name. Always without space between the prefix and the script name.

You can read more about it in the official docs.

Call your own scripts always with npm run <script-name>.

Platform differences

Sometimes you need to do things differenly when it comes to build your project on multiple platforms. I ran into the issue, where I needed to copy files. On OSX this is as simple as cp srcfile.txt destfile.txt. On Windows, this didn’t work, since cp is an unknown command, unless you have cygwin installed. Building your project in the default Windows command prompt fails with an error, once you want to copy those important files. On Windows you should use copy instead.

Create an external copy.js file and do the OS specific tasks there. You can use process.platform === 'win32' to determine if you are running Windows.

DRY - refer to anything defined in your package.json

DRY (don’t repeat yourself) is a great principle when it comes to software development. You can even refer to anything defined in your package.json when you execute your script. Let’s assume, you want to create a zip for distribution.

"scripts": {
    "create-zip": "zip -r app-1.0.zip dist"
}

Now you can call npm run create-zip to create a zip containing all the files to distribute your app.

But why can’t we just refer to the name of the app and the version already defined in package.json? Well, we can. npm exposes all config keys from package.json in the form npm_package_configkey for you to use in your scripts.

"scripts": {
    "create-zip": "zip -r $npm_package_name-$npm_package_version.zip $npm_package_distdir"
}

Stay DRY! Refer to information already available in package.json. You can define whatever config option in package.json and refer to it in the same way.

Call any script in another script

What if you want to run more than one script at the same time? You want for example watch *.js files and *.scss files and preprocess them? How can you do this with one npm script?

You can concatenate different scripts and run them all at the same time:

"scripts": {
    "sass-watch": "node-sass -watch src/style.scss dest/style.css",
    "babel-watch": "babel -w *.js dist",
    "watch": "npm run sass-watch & npm run babel-watch" // 
}

npm run watch will call both custom scripts and run them at the same time. This will create two processes that run independently from each other.

Concatenate multiple scripts with & to run them as one script.

Run any script in your node_modules/.bin directory

Installing any node module that adds it’s own executable script, will be available from projectDir/node_modules/.bin. Let’s say, you need babel for your project and you installed it with npm install babel-cli --save-dev, you can run babel from within your project directory by typing ./node_modules/.bin/babel. That is great, since you don’t have to rely on a global installation of babel.

If you want to run babel as part of a script, you would probably specify the whole path to the babel script:

"scripts": {
    "babel-watch": "./node_modules/.bin/babel -w *.js dist"
}

Since npm adds all executable script to the PATH for the script, you can instead write

"scripts": {
    "babel-watch": "babel -w *.js dist"
}

Don’t specify the full path to a script in your projects node_modules/.bin folder. Use the command without the path.

Thank you very much for reading. If you have any comments or questions, please leave them in the comments below.

Einmal Tennessee und zurück

2015-11-01T23:30:00.000-08:00

"Put on my blue suede shoesAnd I boarded the planeTouched down in the land of the Delta BluesIn the middle of the pouring rain"

Chattanooga

Diese Zeilen aus dem Song "Walking in Memphis" von Marc Cohn, hatte ich im Kopf, als ich letzten Donnerstag mit dem Flugzeug in Chattanooga gelandet bin. Wow, wo bin ich hier gelandet? Alles irgendwie anders, langsamer, aber spannend und interessant. Chattanooga ist eine Kleinstadt, die wirtschaftlich stark gelitten hat, als die großen Industriebetriebe ihre Türen geschlossen haben. Viele gutbezahlte Arbeitskräfte haben ihren Job verloren und zu einer hohen Arbeitslosenquote geführt. Mehr als 20 Jahre hat die Stadt gebraucht, um sich von diesem wirtschaftlichen Untergang zu erholen. Heute hat Chattanooga den Tourismus für sich entdeckt. Ansonsten finden eine ganze Menge Sportveranstaltungen in Chattanooga statt. Die größte Veranstaltung ist ein Ironman.

Chattanooga Airport

Die orangenen Laufschuhe

Statt Lederschuhen hatte ich meine Laufschuhe an.

Downtown Chattanooga

Coco Cola in Chattanooga

Ein paar weise Worte.

Market Street Bridge über den Tennessee River

Sonnenuntergang am Tennessee River

Leider auch hier: Bausünden

"Kleine Kuchenauswahl" in einem lokalem Cafe

Ich war hier angekommen um an einer, ich möchte mal vorsichtig sagen, verrückten Veranstaltung teilzunehmen: ein Staffellauf von Chattanooga nach Nashville. Distanz ca. 200 Meilen (ungefähr 320 km). Teams haben entweder 12 oder 6 Läufer. Gelaufen wird die ganze Zeit. Egal wie spät es ist. Ankunft aller Läufer in Nashville ca. 24-30 Stunden später.
Mein Team bestand aus 12 Läufern und jeder von uns ist 3 mal in dieser Zeit gelaufen. Die zu laufende Distanz pro Läufer variierte zwischen 3 und 10 Meilen.

Jedes Team hat 2 Vans mit jeweils 6 Läufern. Ich war in Van 1 unseres Teams und der letzte Läufer der 6er Gruppe.
Ich bin das erste mal am Freitag um 14:30h unterwegs gewesen. 3.1 Meilen in der prallen Mittagssonne. Nicht meine Lieblingsbedingungen zum Laufen. Aber was solls. Immerhin hatte ich eine relativ flache und kurze Strecke zu absolvieren.

Mein nächster Einsatz war dann erst Nachts um 23:30h. Kurze und flache Strecke mit 2.7 Meilen Länge. Der letzte Lauf war dann am nächsten Tag um 9:00h. Diesmal 4.5 Meilen und mit ziemlich vielen Anstiegen. Immerhin war die Temperatur angenehm zum laufen.
Danach war ich aber auch froh, dass ich nicht nochmal Laufen musste.

Nach dem letzten Lauf. Fertig, aber glücklich.

Jo, genau das richtige nach dem Laufen: Zucker, Mehl und Fett in Kreisform. Auch als Donut bekannt.

Zieleinlauf in Nashville bei bedecktem Himmel

Lea und ich warten mit den anderen auf die Ankunft unserer 6 Läufer aus Van Nr. 2

Sehr coole Idee: alle unsere Medaillen ergeben zusammen eine grosse Medaille

Abendessen mit dem gesamten Team nach fast 30 Stunden

Die ganze Veranstaltung war sehr gut organisiert. Viele Helfer bei den Übergabestellen. Für die längeren Pausen wurden immer Schulen hergerichtet und die Turnhallen zu Schlafplätzen umfunktioniert. Auch in den Schulen waren sehr viele Helfer unterwegs. Sei es nun, um das Chaos auf den Parkplätzen zu koordinieren oder aber um Essen und Getränke in der Schulkantine zu verkaufen.

Drei Dinge sind mir aufgefallen, als ich in Tennessee war:

Hier läuft die Zeit langsamer! Im Vergleich zur Bay Area, wo sich alles schnell bewegt, ist in Tennessee alles ein paar Takte langsamer. Aber das war sehr entspannend, obwohl die Wartezeit in Restaurants manchmal schon als grenzwertig lang zu bezeichnen war.
Die Menschen sind hier sehr freundlich. Jemand hat mir gesagt, dass das die Southern Hospitality ist. Aufgesetzt und hinter der Fassade sieht es anders aus. Ich hab mich dort aber sehr wohlgefühlt und die Interaktion mit den Menschen war ausgesprochen nett.
Es mangelt hier nicht an Kirchen!!!

Nashville ist cool!

Wirklich? Ja, ich finde schon. Die Stadt hat ein paar schöne Ecken. Für Unterhaltung ist auf dem Broadway gesorgt. Bars und Restaurants mit Live Musik. Country Musik ist nicht jedermanns Sache, aber es passt alles zusammen hier. Die Menschen haben Spass und die Stimmung war überall toll. Es gibt noch ein Football und ein Eishockey Team. Beide Teams haben ihre Stadien in Laufweite vom Broadway. Rundherum um den Broadway gibt es eine ganze Menge Geschäfte zum Einkaufen (Cowboy Hut und Stiefel gefällig?). Des Weiteren sind noch eine Menge Museen vorhanden. Allen voran die Country Music Hall of Fame. Leider war die Hall of Fame am Sonntag geschlossen und wir sind ins Johnny Cash Museum gegangen. Sehr interessant und in einer Stunde gut zu schaffen.

Der hippste und teuerste Coffeeshop in Nashville

Noch eine kurze Anekdote zum oben abgebildeten Coffeeshop: ich wollte für mein Team Kaffee besorgen, da wir vor dem Restaurant auf unser Frühstück etwas länger warten mussten (Ansage was 30 Minuten). Ich bin also schnell um die Ecke gegangen, hab dort ein paar Kaffee geordert und wollte dann schnell wieder zurück sein, damit die anderen ihren Kaffee trinken konnten solange sie in der Schlange draussen warten mussten. Nach 20 Minuten bekam ich eine Nachricht von meinem Team. Die Frage nach dem Kaffee musste ich verneinen und meine Bestellung hab ich per SMS übermittelt. Leider hatte ich nach 20 Minuten immer noch keinen Kaffee in der Hand. Kurz darauf hab ich den Kaffee bekommen und bin schnell wieder zurück zum Frühstückslokal. Schmunzelnde Gesichter bei meiner Ankunft. Der Kaffee war gut und teuer (Cappucino $5,50, Ice Cafe Latte $7,50) und hat ewig gedauert. Wie ich eingangs schon mal erwähnte: alles läuft hier langsamer als anderswo. Lektion gelernt.

Und zurück in die Bay Area

Die Kolumne in der New York Times heißt "36 Stunden in xxx" (xxx=nimm irgendeine Stadt auf der Welt). Leider hatte ich weniger als 36 Stunden in Nashville. Ich hab ein bisschen was gesehen von der Stadt. Aber es gibt noch soviel andere Dinge zu entdecken, die ich mir für einen zukünftigen Besuch gemerkt habe. Also, bis bald mal wieder in Nashville. Dann mit etwas mehr Zeit.

Install ownCloud on Synology NAS DS413

2015-10-29T08:30:00.000-07:00

Here is a list of steps required to install ownCloud on a Synology NAS. I have a DS413 and I was able to install ownCloud on it. I don't know about the other Synology models out there. Let me know, if you succeeded to install ownCloud on any other model.

ownCloud is not part of the official Synology packet repository. You need to add the community repository to install packets from there.

Log into the Synology admin site
Open Package Center and open the Settings. Under Package Sources, add http://packages.synocommunity.com/ as a source (see screenshot). Click Ok to confirm the new repository.
In Package Center, refresh the list of available packets by pressing the Refresh button at the top of the window
Now search for MariaDB and install it. This is required to install Owncloud. Otherwise, the installation of ownCloud will abort with an error. MariaDB is a fork of MySQL and is one of two databases recommended by ownCloud. The other one is PostgreSQL.
Next enable Web Station in the Control Panel. ownCloud is a webapp and needs the http server to properly work.
Before we continue with the ownCloud installation, you need to create a new shared folder. The installation of ownCloud failed in the beginning, because this folder is required, but could not be created.
Open the Control Panel and open Shared Folder. Create a new shared folder and give it the name ownCloud (this is the default during the ownCloud installation).
Check off Hide this shared folder in "My Network Places". Nobody should modify any content in this directory. This belongs to the ownCloud installation!
Change the permissions of the newly created shared folder. In order to grant ownCloud read/write permissions, select http from the Local Groups (in the Dropdown list on the left hand side above the table) and check the box in the Read/Write column. Press the OK button when done.
Now search for ownCloud and install it.
During the installation of ownCloud, you will be asked to enter the password for the root user. Leave this field empty. By default there root password is not set (this is not secure at all, but for demo purposes, this should be alright)
After ownCloud was installed properly, click on the URL in the ownCloud overview page in the Package Center. In my case it's http://192.168.1.22/owncloud.
Now you will be greeted with ownCloud's login page. Type in your admin password and log into your ownCloud installation. The administration is part of another blog post.

Summary

This is a list of steps to install ownCloud on a Synology NAS DS413. The steps cover the installation of dependencies required to run ownCloud. The administration of ownCloud is not part of this post.

I hope this will help anyone to successfully install ownCloud. Let me know if you have any questions or other constructive feedback.

What I've learnt today

2015-10-12T22:30:00.000-07:00

Here is a list of things I have learnt today. Things to remember for myself and to reflect on.

AppCode has a simple, yet very useful CocoaPods integration. Easily create a podfile and fill in your dependencies. AppCode will provide you with a button to install your dependencies. Bonus: if you remove a dependency from your podfile, AppCode will give the uninstall button. Keeps your project directory neat and tidy. You can do this on the command line too, but it fits perfectly into the IDE.
Swift playground in XCode 7.0.1 on El Capitan 10.11 sucks! I had so many crashes in the playground, that I had to restart XCode several times to get it back working.
Swift and Objective-C seem to have a "Love and Hate" relationship? Why, you might ask? I tried to use some library that was written in Objective-C with my Swift project. It took a good amount of work to navigate around those little compile errors and find alternative ways to use the library anyways. But it was painful and not fun at all. What I did? I created a custom XML deserializer for Alamofire with Ono.

1st Electron-Shell User Group Meetup

2015-09-01T00:15:00.000-07:00

I went to the 1st Bay Area Electron-Shell User Group Meetup last Tuesday, 8/25/2016. The meetup was hosted by (WagonHQ) in San Francisco’s Mission district. It started at 6pm and was scheduled to last until 9pm. The nice folks at WagonHQ provided some food and drinks for all attendees.

The Agenda for this meetup is available (here).

There was a good crowd of interested engineers (between 40 and 60 people). Some of them were already using electron-shell in one or the other project.

The Talks

There were 4 tech talks for this event:

The History of Electron (Kevin Sawicki - Engineer at GitHub)
Integrating with Native Code (Paul Betts - Engineer at Slack)
Electron, React, and Haskell. Oh my! (Mike Craig - CTO at Wagon)
Making a web app feel native (Ben Gotow - Engineer at Nylas)

The talks covered different parts of app development and the specialities of building a cross platform desktop app with web technolgy. A lot of questions around styling, using node modules, write your own node modules, call C# APIs to integrate with Windows, call Objective-C to integrate better with OSX and app packaging (I might have missed something).

I’m looking forward to attend the next meetup. I think that some attendees might have tried electron-shell for their own projects and have some eperiences to share.

Simple date math in bash script

2015-06-09T00:00:00.000-07:00

To catch up with my blog, I needed to extract data from a twitter feed. Usually I update the blog on a weekly basis. Since I didn’t find the time recently, I fell behind.

I was looking for a quick solution to download all the feed data at once. A bash script should be good enough.

The script that I use to extract the data from the twitter feed, expects a date argument in the form mm/dd/yyyy. The script will extract all data for the range [date - 7days, date]

Create the series of dates

I need to create a series of dates for several weeks. Given a start date, I’m going to produce new dates with a 7 day interval. The starting date is included in the series. Here is what I ended up with:

#!/usr/bin/env bash

set -e

# startdate in the form mm/dd/yyyy
startDate=$1
weeks=$2

for ((i=0;i<${weeks};i++)); do
    offsetDays=$((${i}*7))
    newDate=`date -j -v+${offsetDays}d -f "%m/%d/%Y" ${startDate} "+%m/%d/%Y"`

    startDateFilename=`echo ${newDate} | sed "s/\//-/g"`

    echo ${startDateFilename}
    # download the twitter data and redirect all output to that file
    exec &> weeklyTwitterData-${startDateFilename}.txt
    # call the script to extract the data from twitter stream
    coffee src/WeeklyStats.coffee -n ${startDate}
done

Since I didn’t want to do all the calendar math myself, I rely on the magic of the date utility. The line defining newDate is where the magic happens. Parsing a date ${startDate} in a given format %m/%d/%Y, adding $offsetDays to the parsed date and print out the new date in the format %m/%d/%Y.

That’s it.

Setup iTerm2, zsh, oh-my-zsh and powerline fonts on OSX

2015-05-13T23:57:00.001-07:00

After waiting for a long time, I finally updated my Mac to OSX 10.10. Right after the installation, the usual tweaking process begins to make you feel at home. These are my notes to make the shell look good.

I wanted z-shell, oh-my-zsh and these modified powerline fonts to make the command prompt look cool.

If you want to follow these steps, it's recommended to have homebrew installed to install zsh-shell.

Ready, set, go!

Open your terminal and prepare to type.

iTerm2

The easiest way it to install iTerm2 with homebrew. Run this command:

brew install iTerm2

oh-my-zsh

Run this command curl -L https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh | sh

powerline

Powerline is a project that provides tools to customize the status line and command prompt of several applications. To achieve this, they use special glyphs that are available through patched fonts. These are the powerline fonts. Download the font from here and install it by double clicking. This will open the Font Book application and install the font for you.

Configuration

Now it's time to put everything together.

Open iTerm2
Go to Preferences -> Profiles -> Default -> General and type /bin/zsh into the text field next to Command (this will use zsh instead of your default shell)
Go to Preferences -> Profiles -> Default -> Text and change the Regular Font and the Non-ASCII Font to 11pt Inconsolata-dz for Powerline
open ~/.zshrc with your favorite text editor and change ZSH_THEME to agnoster

That's it. Make sure to start/restart iTerm to see all the changes.

Resources

oh-my-zsh Powerline change osx shell

Electron mystery on OSX solved

2015-05-06T22:29:00.001-07:00

Do I look like an idiot? I don't know. But I felt like one for the last 2 days.

2 days ago I started to look into on a great project idea, to replace the Brackets Shell with Electron. Great idea! I wanted to contribute and fix issues that crossed my way. But, I followed the given instruction to clone the repo and setup all dependencies. After everything was download and in the right place, I ran npm start to bring up Brackets in it's new electron shell. But that first attempt failed with this error:

> Brackets@1.3.0-0 start ~/develop/fun/OSS/brackets-electron
> electron .

~/develop/fun/OSS/brackets-electron/app/shell-config.js:13
r CONFIG_PATH = path.resolve(utils.convertWindowsPathToUnixPath(app.getPath("u
                                                                    ^
TypeError: app.getPath is not a function
    at Object.<anonymous> (~/develop/fun/OSS/brackets-electron/app/shell-config.js:13:71)
    at Module._compile (module.js:418:26)
    at Object.Module._extensions..js (module.js:436:10)

I was wondering, if there was something important missing in the setup instruction, I simply made a mistake or my system config was tricking me. After checking with the guys who started that effort, I was left with this weird error.

I started to research and looked for others having the same issue, but I couldn't find anything. Okay, it has to be my machine setup. Back at home, I started to setup everything on another machine to see if it works there. The result was the same! The error showed up on a different Macs, with a different OSX versions.

I went back to our slack channel and carefully mentioned, that I'm still not able to get it running yet. Someone replied, that I can install Electron globally and try it again. But this turned out to be a red herring. Nothing has changed and it was really frustrating, since nobody else seemed to have these issues on OSX. I promised them to help, but I could even review and test pull requests.

I did some more research and came across this great blogpost from Thorstenhans. He provided a boilerplate project for an app that uses Electron. I was so happy. I followed his instructions to create a clean app. Everything went fine and I was excited because it's using es6. Unfortunately, the result with Electron was the same.

I left a comment for the blogpost asking, if he has encountered this issue before. Nothing worked for me as expected. So, it must be my machine I concluded. But two machines at the same time?

I mentioned my inability to launch Electron on OSX, briefly in the slack channel for electron-brackets. I felt like an idiot at this point. Somebody who distracts everybody with some nonsense. Nobody had an idea what might help to resolve this misery to help me getting started.

Since the electron-brackets version on Linux seemed to work fine, I decided to pull my Linux VM out of the drawer and give it a try. I cloned the repo, installed everything and typed npm start at the console. Guess what? It worked! I was happy. That is awesome and I'm finally able to help.

But I wasn't happy that my day-to-day machine didn't play well with me. I had a conversation with Thorsten Hans (look at the comments here). He solved another mystery for himself along the way, but I didn't make any progress.

Long story short, I started to get rid of my nodejs installation, install nvm from scratch and hoped to resolve the issue. No luck. But then I inspected the environment variables for anything nodejs related and I found NODE_PATH. It seemed somehow messed up. This post recommended to undef NODE_PATH to solve another issue. But it helped me too. npm start is finally working and the biggest mystery, that let me look like an idiot was resolved.

Thanks

To Thorstenhans for the back and forth to help me resolve the issue. Thanks to Andrew MacKenzie to mention often enough, that the Linux version is doing a good job for him.

Something I Learnt About sed

2015-01-02T12:34:00.000-08:00

Note: I’m writing this down to remind myself for the next time I’m using sed and any kind of regex.

I was working on some very simple task: replace a string in a file with a different string.
All of this should happen on our build machine during the product build. Nothing too fancy. But then I got bitten by different versions of sed available on the build machines.
We build our product on OSX, Windows and Linux and I had to realize, that the regex I used, didn’t work with every sed version on the build machines.

My Regex Confusion

To make it clear: I’m not a regex guru. I use it for simple things. When it get’s complex, I usually consult some tools like regex101.com to get it right.
I started with this simple regex to replace the number after the - (the number of commits). The buildnumber looks like 1.0.0-12345.
Here is the command I started with

`cat build.prop | sed "s/(brackets_build_version=\d+.\d+.\d+-)(\d+)/\1${NEW_COMMITS}/" > build.prop.new`.

The result:

`sed: 1: "s/(brackets_build_versi ...": \1 not defined in the RE`

Okay, that doesn’t help that much. After some research I have found the solution: -E needs to be added to the command.
Okay, that error went away, but the replace didn’t work either. Hm, now I had to debug the Regex and find the issue.
After several rounds of experimentation, I started to read the documentation for re_format. That explained a lot: there are modern RE and obsolete RE (they are sometimes referred to as Basic Regular Expression (BRE) and Extended Regular Expression (ERE)), that mainly exist for backward compatibility. They are not as powerful as the modern RE and lack some features.
The last working version looked like:

`cat build.prop | sed -E "s/(brackets_build_version=[[:digit:]]+.[[:digit:]]+.[[:digit:]]+)-([[:digit:]]+)/\1-${COMMITS}/"`

This worked! Heureka.
~~But wait, why do I have to used [[:digit:]] instead of the much shorter \d+? I don’t know and probably I will never find out.~~

Deploy on Build Machines

Happy, that I finally found a solution that worked on OSX. I totally forgot about the other OSses. Once I made the changes and started the build, it failed on Linux and Windows.
WTH? What was I missing? Why doesn’t it even work on Linux? Quickly started my Linux VM and gave it try. The solution was simple: I had to call sed with -r in order to make it work.

Conclusion or What I have Learnt

sed behaves differently on different OS versions. This is probably no exciting news, but I thought I keep this as a reminder for myself.
Using bash or some derivative of it like cygwin or gitbash on Windows does make a difference for some tools. Especially sed comes in two variants: BSD and GNU.
OSX uses BSD and I guess linux and cygwin come with GNU. They might have different command line switched for the same option. So be careful and testing is always required.
Another difference is the Regex engine tha can be used. sed supports basic regular expressions (BRE’s) and extended (ERE or modern) regular expressions
As I mentioned bofore, enabling the extended regular expressions you need to call sed -E on OSX and sed -r on Linux and cygwin.

Moto 360 - Was ich wollte und was ich bekam

2014-11-29T00:28:00.001-08:00

Heute vor 2 Wochen (17. September) 10 Wochen habe ich von einem Freund eine Moto 360 geschenkt bekommen. Der Grund: er hat als Teilnehmer der Google I/O eine zugeschickt bekommen, hat aber selber kein Android Phone und somit keine Verwendung dafür. Ich hab mich sehr darüber gefreut, wollte ich mir doch selber eine kaufen. Leider, in diesem Fall eher Glück, war die Uhr bei Motorola innerhalb kürzester Zeit ausverkauft und ich hab keine mehr bekommen. Naja, ich hab mich auf eine etwas längere Wartezeit eingestellt. Umso überraschender war dann die Lieferung an mich.

Erwartung

Was habe ich von dieser Uhr alles erwartet? Die Artikel, in denen über die Uhr geschrieben wurde, haben sich ja vor Begeisterung gar nicht mehr einbekommen. Ich denke, dass sollte sich bei erscheinen der Uhr etwas legen. Das ich seit 1,5 Jahren eine Pebble Smartwatch habe, bin ich schon mit einer hohen Erwartungshaltung angetreten. Darunter waren

Akkulaufzeit von mindestens 3 Tagen
Herzfrequenzmesser für sportliche Aktivitäten (Ersatz für Brustgurt)
Schlaftracker
Eine Uhr im coolen Design und coole Watchfaces

Der erste Tag

Ich hab die Uhr nur noch auf die Ladestation gestellt und bis zum nächsten Morgen gewartet. Der Tag fing erstmal mit einem Update an. Ich hatte das am Abend zuvor nicht mehr gesehen und deshalb wurde die Uhr jetzt erstmal aktualisiert. Schon mal nicht schlecht. Die ersten Probleme haben sie (Motorola) also schon beseitigt.

Nachdem das Firmware Update durchgeführt und die Uhr endlich einsatzbereit war, hab ich erstmal ein bisschen rumgespielt. Leider hat dadurch die Batterielaufzeit sehr gelitten. An diesem Tag war die Uhr Nachmittags um 16 Uhr fertig. Aus, Ende und vorbei. Wow, das war sehr viel weniger als ich erwartet hatte. Am nächsten Tag habe ich dann tatsächlich das Ladegerät der Uhr mit ins Büro genommen. Ich wollte ja nicht mit einem unbrauchbaren, weil leerem, Hightech Spielzeug rumlaufen. Schon echt blöd, für etwas was eigentlich die Uhrzeit anzeigen soll. In den folgenden Tagen habe ich die Uhr weniger benutzt, ausser um die Uhrzeit abzulesen. Auf jeden Fall hielt die Batterie jetzt bis Abends um 9 Uhr. Das war aber immer noch nicht das, was Motorola auf ihrer Website verkündet hat: Hält einen ganzen Tag. Vielleicht haben wir unterschiedliche Vorstellungen wie lang so ein ganzer, normaler Tag ist.

Alles wird besser oder das große Firmware Update

Die ersten Wochen waren eher ernüchternd. Die Batterie war schnell erledigt und Bedienungstechnisch gab es auch noch einiges zu verbessern. Okay, so ist das eben, wenn man mit einem neuen technischen Spielzeug spielen möchte. Die Ecken müssen erst rundgeschliffen werden. Warum sollte das bei der neuen Smartwatch anders sein? Umso erfreuter war ich, als dann eines Tages die Verfügbarkeit eines Firmwareupdates angezeigt wurde. Also, die Uhr schnell auf die Ladestation und dann das Update starten. Auf den ersten Blick hat sich erstmal nichts verändert. Unter der Haube wurde auf jeden Fall der Batterieverbrauch reduziert. Super! Endlich hält die Uhr einen ganzen langen Tag durch (bei moderater Benutzung!).

Firmware Update die Zweite

Ein paar Wochen später gab es dann Update Nr. 2. Hier wurde hauptsächlich die Bedienbarkeit der Uhr verbessert. Notifications können jetzt ganz aus dem Sichtfeld an den unteren Rand verschoben werden. Damit kann dann die Uhr komplett betrachtet werden. Weiterhin soll die Bluetooth Verbindung mit dem Smartphone jetzt stabiler sein.

Was ist aus den anderen Wünschen geworden?

Herzfrequenzmesser

Der Herzfrequenzmesser ist, ich sag es mal vorsichtig, nicht ganz so gut wie ich mir das vorgestellt habe. Messungen dauern zu lange und eine kontinuierliche Messung ist anscheinend nicht möglich oder die Apps unterstützen das einfach noch nicht. Messungen funktionieren in vielen Fällen nicht beim ersten mal. Die Uhr legt großen Wert auf die richtige Armhaltung. Der Kontakt zwischen Uhr und Haut muss komplett hergestellt sein. Vielleicht passiert hier ja noch etwas zum besseren. Momentan gehört das noch in die Kategorie "Nutzlos und Überflüssig".

Schlaftracker

Okay, ich hab dann mal ausprobiert ob ich die Uhr auch zum Schlaftracking benutzen kann. Ich bin um Mitternacht ins Bett gegangen und die Uhr war zu 100% aufgeladen. Als ich am morgen um 6:30 h aufwachte, war sie... Aus! Alle! Leer! Unfassbar. Ich weiss ja nicht was die Uhr so zum Schlaftracking macht, aber das ist mehr als enttäuschend. Da hatte ich mal wieder mehr erwartet.

Lederarmband

Was ich bis jetzt gar nicht nachvollziehen kann, ist die Tatsache das eine Uhr, die jeden Abend aufs Ladegerät gelegt werden muss, mit einem herkömmlichen Lederarmband ausgestattet wird. Das Armband wird ständig an der selben Stelle geknickt und sieht mit der Zeit nicht mehr schön aus. Für eine Uhr, die zum Sport getragen wird, halte ich Lederarmbänder auch nur für bedingt brauchbar. Duschen ist auch keine gute Idee, da das Leder darunter sehr leidet. Ich hätte mir gewünscht, das die Uhr auch mit einem Metallarmband verkauft wird. Diese Option stand leider nicht zur Verfügung, soll aber zum Ende des Jahres erhältlich sein. Ich bin gespannt. Ich werde mir sofort ein Metallarmband besorgen.

Fazit oder was ich bekam

Um noch auf den Punkt "Erwartungen" zurückzukommen. Leider habe ich mir viel gewünscht und nicht so viel bekommen. Akkulaufzeit war am Anfang mehr als enttäuschend. Weniger als ein Tag durchgehalten und das "Mitschleppen" des Ladegeräts für die Uhr geht gar nicht. Das wurde besser mit dem ersten "großen Firmware Update". Das Update hat vieles verbessert. Bei 3 Tagen Batterielaufzeit bin ich trotzdem noch nicht angekommen. Aber immerhin bei der Hälfte.

Bleibt also noch eine Uhr im coolen Design. Jawoll, das ist auf jeden Fall erfüllt worden. Die Uhr sieht gut aus, die bisher erhältlichen Zifferblätter sehen gut bis originell aus. Immer mehr Apps bekommen die Möglichkeit Informationen auf der Uhr darzustellen.

Ich benutzte die Uhr jeden Tag. Sie hat sich zu einem zuverlässigen und unauffälligen Begleiter entwickelt. Die Spracheingabe funktioniert, zumindest in Englisch, überraschend gut. Zum Sport benutze ich die Uhr nicht. Aus irgendeinem nicht offensichtlichen Grund steigt der Batterieverbrauch während dieser Zeit erheblich an. Ich benutzt die Smartwatch als Schrittzähler und Activitytracker (hauptsächlich Radfahren). Ich glaube, dass es noch viele Verbesserungen geben wird. Die Pebble Smartwatch hat auch mit relativ wenigen Features angefangen und wurde mit der Zeit immer leistungsfähiger. Also abwarten und geduldig sein.

Pros und Cons

Pro

Ladezeit
Bedienung
Induktionsladegerät

Con

Batterielaufzeit
Lederarmband
Schlaftracking

Kaufen oder nicht?

Thrillseeker? Spielkind? Muss ich immer das neueste, coolste technische Gadget haben? Dann gibt es nur eine Antwort: Kaufen! Die erste gut aussehende Smartwatch, die nicht wie ein merkwürdiger Klotz am Handgelenk aussieht. Naja, zumindest nicht an meinem Handgelenk. Wie es sich aber immer so mit neuem technischen Spielzeug verhält, gibt es noch einiges zu verbessern.

Aber anscheinend gibt sich Motorola hier viel Mühe die Kunden mit aktualisierter Firmware und besserer 3rd Party Integration glücklich zu machen. Und nicht vergessen, wir haben es hier mit einer jungen, neuen Produktgeneration zu tun. Es wird noch viel passieren in den nächsten Wochen und Monaten. Google Fit ist erst der Anfang.

Guest post about Brackets and building Brackets Extensions

2013-12-16T15:18:00.001-08:00

It’s already a couple of weeks ago, that I provided two guest posts about Brackets for Safari Books Online.

Please have a look at introduction to Brackets and Building a Brackets Extension and let me know what you think.
I’d like to hear your feedback. Thanks.

git re-merge done easy

2013-11-08T12:29:00.000-08:00

I messed up some files during a larger merge a couple of days ago. When I tracked down the files that had issues (in my case the unit tests didn't succeed anymore), I wondered if there is an easy way to revert to the version of the file before the merge and redo the merge or at least bring back the file with the conflict markers.

I was looking for an elegant solution. Something must exist that helps engineers to easily resolve situations like this.
After 45 seconds of research (sometimes it's that quick if you know the right words to search for), this result on StackOverflow came up.

git checkout -m <filename>

Very nice solution. I was able to go back to the state, where the file contained all the conflict markers and I was able to resolve the issue pretty quickly.

Yes, sometimes git is really easy.

Using cobertura with gradle

2013-03-03T23:13:00.000-08:00

I wanted to get code coverage for my current groovy project. Since I use gradle and all of my source is written in groovy, I searched for a gradle plugin that provides cobertura functionality for groovy files. I found two (perhaps there are a more available)

Using both plugins wasn’t a big deal. There is a slight difference how to set them up in your build.gradle file though. Both plugins provide very similar configuration options to tweak cobertura’s behavior. Let’s take a look.

Using Eric Wendelin’s Cobertura plugin

Adding the plugin to the build.gradle

I’m using gradle 1.4 for this exercise and I added the following to my build.gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "net.saliman:gradle-cobertura-plugin:1.1.0"
    }
}

apply plugin: 'cobertura

This will provide you with four new tasks:

coberturaInstrumentMain
coberturaInstrumentTest
testCoberturaReport
coberturaConfigureTest

So, which task to call to determine the code coverage? Simply run the test tasks and your source will be instrumented prior to executing your tests.

But what you really want, is to run the check tasks because this will not only run your tests on your previously instrumented source, but it will also create the coverage report. And that’s basically what we want.

The plugin provides some configuration options to tweak cobertura’s behavior

option	description
format	`’html’` (default) or `’xml’`
reportsDir	Path to report directory for coverage report. Defaults to `${project.reportsDir.path}/cobertura`
includes	List glob paths to be reported on. Defaults to `[‘*/.java', ‘*/.groovy', ‘*/.scala’]`
excludes	List glob paths to exclude from reporting. Defaults to `[‘*/Test.java', '*/Test.groovy', '*/Test.scala’]`
ignores	List regexes of classes to exclude from instrumentation. Defaults to `[‘org.apache.tools.', 'net.sourceforge.cobertura.’]`

To specify the output format of cobertura’s coverage report you have to do this:

cobertura {
    format = ‘xml’
}

Using Steve Saliman’s Cobertura plugin

This plugin is based on the work of gradle_cobertura. The original version had some issue with the latest gradle version, so I decided to pick one of the 20 forks. The one with the most recent changes was Steve Saliman’s Cobertura plugin. You can find the setup instructions in the README. Currently the compatibility chart shows that gradle 1.1 is the highest supported version right now. I’m using it with gradle 1.2, 1.3 and 1.4 and they work too. So, let’s move ahead and give it a try.

Adding the plugin to the build.gradle

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath "net.saliman:gradle-cobertura-plugin:1.1.1"
    }
}
apply plugin: 'cobertura'

This will add 2 new tasks:

cobertura
instrument

To get your coverage report you need to run the cobertura task and the report will be created.

There are a couple of options available to this plugin to change the cobertura behavior:

option	description
coverageDirs	Directories under the base directory containing classes to be instrumented. Defaults to `${project.sourceSets.main.classesDir.path}`
coverageDatafile	Path to data file to use for Cobertura. Defaults to `${project.buildDir.path}/cobertura/cobertura.ser`
coverageReportDir	Path to report directory for coverage report. Defaults to `${project.reportsDir.path}/cobertura`
coverageFormats	Formats of cobertura report. Default is a single report in ‘html’ format
coverageSourceDirs	Directories of source files to use. Defaults to `${project.sourceSets.main.java.srcDirs]`
coverageIncludes	List of include patterns
coverageExcludes	List of exclude patterns
coverageIgnores	List of ignore patterns

Fix broken links in coverage report

In order to have a working link to the groovy source files in the coverage report, it’s necessary to add the following to your build.gradle. This will add the groovy source directory to the list of coverageSourceDirs

cobertura {
    coverageSourceDirs << project.sourceSets.main.groovy.srcDirs
}

Report location

For both plugins, the generated report can be found in build/reports/cobertura.

Summary

I have to admit, that both plugins are too similar in functionality to declare a clear favorite. In general, both plugins have subtle differences in regards of their configuration. I like that Eric Wendelin’s Cobertura plugin supports groovy (and scala) files right out of the box without further configuration. But this is only a very small advantage. I’ll stick with Steve Saliman’s Cobertura plugin for a while, since there is still active development. Not a strong reason, but as I mentioned earlier, there are only subtle differences between both plugins.

The choice is up to you.

List all available instruments templates

2013-02-11T17:55:00.001-08:00

Using Apple's instruments on the command line to inspect an iOS application on the device, usually involves a specific template to capture data from the application running on the device.

For my current project I usually used the Automation.tracetemplate to launch my iOS app. But after I've upgraded Xcode from 4.3 to 4.5, the filesystem location of the instruments templates have been slightly changed. The framework that I wrote for the performance tracking system failed in finding the template. I started to investigate a better solution to be able to deal with different Xcode versions that could be found on the dev machines.

For that reason I created a little helper class to identify the version of Xcode to locate the correct path of the Automation.tracetemplate. That works pretty fine, but I don't know if this will work for future Xcode versions too. This solution required xcodebuild -version to determine the Xcode version and xcode-select -print-path to determine the location of the Xcode folder. I needed this information to assemble the path to the templates.
There must be a better, shorter way of getting this information.

A better solution

Running instruments on the command line produces a rather concise than helpful overview of the available options. I couldn't find any manpage for instruments on my machine. Rather by accident than intentional, I came across the instruments manpage on Apple's Developer Connection website.

The manpage contained far more information about the available options including some description for the unknowing user. I discovered the option -s that produces a list of all available instrument templates. Even if the manpage was targeting the Xcode tools 3.2.5 version (I couldn't find a more recent version), the option is still recognized by the latest instruments (as time of writing I used Xcode 4.6).

Running instruments -s and parsing the output will give me path to the Automation.template. without any guessing or probing. I hope this option will remain available in instruments in future versions.

Das tote Pferd

2013-01-29T16:10:00.000-08:00

Es gibt diese Weißheit der Dakota Indianer: „Wenn Du entdeckst, dass Du ein totes Pferd reitest, steig ab!”

Und heute ist es wieder passiert. Ich hab die Zeichen wieder nicht gesehen. Vielleicht waren dort auch keine, aber das Pferd auf dem ich geritten bin ist definitv tot. Leider bin ich nicht aus freien Stücken abgestiegen, sondern abgestiegen worden.
Mit anderen Worten: mein Arbeitgeber hat heute mal wieder eine neue strategische Ausrichtung bekannt gegeben und leider war mein Team, und damit eine Menge anderer Kollegen, nicht mehr direkt Teil dieser neuen Strategie. Zum Glück wurde aber keiner meiner Kollegen entlassen. Das hat die Firma aus den vergangenen Umstrukturierungen gelernt. Erst fire, dann hire ist teuer.

Hab ich noch einen Job? Ja, hab ich. Also kein Grund zum meckern. Was für ein Job? Keine Ahnung.

Warum rege ich mich darüber auf? Du bist in den USA. Da ist das doch gang und gebe. Ja, das ist zwar richtig und es verwundert mich auch nicht wirklich. Es ist nur die Häufigkeit der Veränderungen in den letzten 2 Jahren gewesen. Und jedes mal das ungute Gefühl, dass ich irgendwann durch die Mühlen falle und keinen Job mehr habe, wir das Land verlassen müssen, weil das Visum an meinen Arbeitgeber gebunden ist.
Naja, jetzt heisst es erstmal abwarten und sehen was das kommt. Jeder Neuanfang ist auch eine Chance etwas Neues zu lernen.
Also, es ist mal wieder Zeit etwas Neues zu lernen.

Frohe Weihnachten/Merry Christmas

2012-12-24T10:15:00.002-08:00

Frohe Weihnachten/Merry Christmas

San Francisco City Hall 2012

R.I.P. Nexus 7

2012-08-27T11:00:00.000-07:00

Beginning of this month I received my Nexus 7 Tablet. I really like the form factor, the performance and how handsome this device feels in my hands. We had a great time.

Last Wednesday, without any further warning and totally surprising, the Nexus 7 died in my hands. I'm really sad about this loss, since I had no chance to properly say goodbye.

What happened? The screen started to show a lot of horizontal lines dancing from left to right and back. After a couple of seconds, the tablet shut itself down. There was no way to switch it on again. I tried everything. Finally I attached the tablet to my computer and it started to show signs of life again. I was so lucky. The battery charging symbol appeared and it seemed I was able to save the life of it. After some hours of continuous charging, it seemed that everything turned back to normal, but after some minutes using it, the same symptoms came back. This time, the tablet shutdown much more quickly. I was unable to switch it back on again. I declared the tablet dead at 3:21pm, Wednesday, 22nd of August 2012.

I called the undertaker (Google Support) how to proceed with this dead patient now. They offered me a replacement Nexus 7 tablet that will be send to me in the next couple of days (nothing can replace my beloved original Nexus 7 tablet).
Once arrived, I have to send the dead one back to them and they hopefully will give it the appropriate final treatment in it's short life.

Rest in peace.

New Job: ActionScript VM Performance Engineer

2012-07-03T09:39:00.000-07:00

A couple of weeks ago I started to work for a new team within Adobe. The team: Performance Engineering for the ActionScript VM (AVM). What am I doing there? Build the infrastructure to track the performance data, analyze performance issues and develop performance workloads for the AVM.

For all reader not familiar with the AVM, it's the virtual machine that is used by the Flash Player to run Flash content. Wait, did I say Flash Player? Yes, the piece of well known software that so many people use and so many believe it's dead (or about to die). I can tell you, that at least from Adobes perspective, that the opposite is the truth (even if the perception out there might be different). Adobe is investing in ActionScript and Flash Player to make it the best language and execution environment for modern web enabled applications. There will be changes to the ActionScript language, which will improve the overall execution performance. The roadmap is available here.

One of the improvements already in place are Workers. Workers help the developer to execute code in a separate thread to create a smooth user experience. Think of some heavy computation that doesn't have to happen in the UI thread anymore. Have a look at the Worker example.

To better keep track of the upcoming performance improvements, this new team was build and I'm happy to be part of it. I'm going to work on a lot of different things over the next few months: automation, webapp/database development, analyzing performance issues, developing the relevant workloads to measure the performance, etc. This sounds exciting.
Riding a dead horse looks different.

Grape: adding a repo to the ivy configuration

2012-05-08T00:01:00.000-07:00

Grape is a great thing. It’s one of my favorite features in groovy. It makes groovy script distribution so easy and painless. You want to use your groovy script on a new machine? Install groovy (if not already done) on the other machine and copy the script to the new machine. The script and all declared dependencies will be downloaded for you and the script is ready to run. What a timesaver.

@Grab(group='mycompany.com', module='awesome-lib', version='1.2')

This statement specifies a dependency to a library that your groovy script depends on. No need to copy this jar and all transitive dependencies manually to your machine. No need to make it manually available in the classpath. You know maven, gradle and ivy. They do the same job during build time. Grape provides the same dependency resolving functionality in the runtime scenario. No worries about missing dependencies anymore.

What happens if a required dependency is part of a not-so-famous or a company internal repository? Grape has a solution for it! You specify the repository with a Grape annotation and tell the dependency resolver to consult your company repository in order to resolve dependencies.

The following statement will add a repository named ‘my_unknown_repository’ and a root URL ‘http://repo.mycompany.com’ to the list of resolvers.

@GrabResolver(name='my_unknown_repository', root='http://repo.mycompany.com')

In case that you have a company internal repository (which also acts as a proxy to the outside world) and you always want to consult this repository without always remembering the GrabResolver annotation for every script you write, there is another way of specifying the repository. This option is less flexible, but it saves this one line in every script and probably makes more sense in a larger context like companies. To add your repository permanently to the resolver list, I recommend to obtain a copy of the configuration file that Grape uses to configure the underlying ivy to perform the heavy-lifting.

Grape uses a specific configuration that can be found in the groovy-x.y.z.jar. In order to customize the configuration, we need to create a grapeConfig.xml and add our repository there. But how does the content of the file look like? To preserve the existing configuration, we get a copy of the original config file from the groovy.jar.

Let’s jump to the command line (I assume that java’s jar is in the search path and /path/to/groovy exists):

jar -xf /path/to/groovy/lib/groovy-1.8.6.jar groovy/grape/defaultGrapeConfig.xml

This command extracts the defaultGrapeConfig.xml to the current directory. Open this file with your favorite editor and you will probably see something like this:

<ivysettings>
  <settings defaultResolver="downloadGrapes"/>
  <resolvers>
    <chain name="downloadGrapes">
      <filesystem name="cachedGrapes">
        <ivy pattern="${user.home}/.groovy/grapes/[organisation]/[module]/ivy-[revision].xml"/>
        <artifact pattern="${user.home}/.groovy/grapes/[organisation]/[module]/[type]s/[artifact]-[revision].[ext]"/>
      </filesystem>
        <!-- todo add 'endorsed groovy extensions' resolver here -->
      <ibiblio name="codehaus" root="http://repository.codehaus.org/"   m2compatible="true"/>
      <ibiblio name="ibiblio" m2compatible="true"/>
      <ibiblio name="java.net2" root="http://download.java.net/maven/2/" m2compatible="true"/>
    </chain>
  </resolvers>
</ivysettings>

Now go ahead and copy one of the <ibiblio… /> lines and add your repository configuration. Finished with editing? Save the file as grapeConfig.xml in ~/.groovy/. From now on Grape will search your repository every time there is a dependency to resolve. If you want Grape to use only your repository, because it’s caching downloaded dependencies, you should remove all <ibiblio… /> lines, except the one for your repository.

Additional documentation about Grape can be found here.

How do machines learn?

2012-04-26T13:10:00.001-07:00

I already thought that I know the answer, until I met someone at a Party who told me about Machine Learning. That was the point when I realized that I only know a small fraction of this topic. Luckily, I found this free online class from Stanford University. The class runs for 10 weeks and I hope to learn the basics about Machine Learning, the tools and how to develop great algorithms for large datasets. The class started last Monday, so I already watched some of the videos and installed Octave. Now I need to learn how to use it.

git and why I sometimes feel lost

2012-03-26T09:00:00.000-07:00

Yes, I had an affair with cvs, svn and Perforce the last couple of years! But most of the time I'm using Perforce, since this is used by my employer. Last year I started to look closer at git and mercurial. For some open source projects that I'm contributing to, I had to use git (Jenkins and homebrew) and mercurial (tamarin) to keep track of my changes. Having used Version Control Systems (VCS) for a long time, I thought that git and mercurial (hg) are just another new system that couldn't be too difficult to deal with. The start wasn't that bad: clone a repo, work locally, submitting changes locally without connection to the repository server is really a very productive feature.

How does it work if you meet somebody new and you try to build a relationship? You look for similarities and things that make it easier to find common ground. I my case I was still thinking: hey, they are all VCS's (Version Control Systems). That's true, they have a lot in common, but I also think they are more different than everybody thinks. I had to learn new concepts (which I always consider good) because of the centralized/decentralized nature of the different systems. The different terminology that all the systems use, is one of the issues that makes working not as smooth as I was used to it. Why? Every time I run into issues with branches, merges, resolving and I had to search for the "thing or situation" that described my situation best. But always in the language of the VCS that I was currently using. The longer I use the system, the better I should get to find the appropriate information quickly next time. I found numerous community driven site with tips and tricks and work flows for git and mercurial. There is the git and the mercurial handbook which will provide enough information to manage the most complex work- flows one can think of. But sometimes I'm looking for the simple tasks and how to manage them.

I'm getting better. I like git and hg. I don't love them yet, but we are working on our relationship. Even if they sometimes give me a hard time solving simple tasks, like this one: I wanted to delete a branch in one of my github repositories. As an example: in Perforce GUI tool I select the branch and delete it. Done. With git I had to do this in order to delete the branch:
git push git@github:ingorichter/homebrew.git :update-libzip
A push really deleted the branch. Perfect!? I hope I remember the command for the next time if I need to do it again.

Don't get me wrong: git and hg are very powerful, but it takes some time until your brain embraces the massive power of these VCS's. Until then, I assume that I will feel lost from time to time.

An IMHO very interesting podcast about VCS's can be found here.

Jenkins: OSX installer now supports the creation of it's own jenkins user

2012-03-09T19:00:00.000-08:00

Okay, this doesn't sound like big thing, but there were some valid complaints from users that used jenkins to run their iOS and maven builds. Some of them had trouble with ssh. See https://ljnelson.posterous.com/getting-jenkins-running-on-a-mac and http://colonelpanic.net/2011/06/jenkins-on-mac-os-x-git-w-ssh-public-key.

Since jenkins version 1.449, the OSX installer provides an option to run the jenkins service no longer as daemon user. The installer is able to create a new jenkins user with it's own home directory (maven and ssh, here we come!). It should be easier to grant the jenkins user access to the keychain to allow codesigning of iOS deliverables.

Some facts about the new jenkins user:

uid will be determined automatically to avoid any collisions with existing users
guid of jenkins group is determined automatically to avoid collisions with existing groups
home directory of the jenkins user will be /Users/Shared/Jenkins

Installer options

How to get rid of the jenkins installation?

I heard people talking about issues with the installer updating an existing installation (how can this be?). Some of them asked for way to get rid of the installed files. Since OSX doesn't have a mechanism to un-install files, there are only the options to remove the files manually or use some 3rd party tool (TrashMe) to get rid of the files. Since these tools use some heuristic methods to determine the files to remove, I created a simple shell script to remove all files installed by the installer. The script can be found here.
Warning: I used the script for testing purpose when experimenting with the installer. The are no error checks and it's far from being perfect. So, please use at your own risk!