Ruby aktualisieren mit rbenv

Die Aktualisierung einer Entwicklungsumgebung ist mit allen Abhängigkeiten und Werkzeugen meist keine einfache Sache. Für Ruby steht einem für diese Aufgabe das äusserst praktische Werkzeug rbenv zur Verfügung. Dies kümmert sich um alle Abhängigkeiten und führ die Pfad-Variablen automatisch nach. Es gibt allerdings einen kleinen Stolperstein, der einem unnötig viel Zeit kosten kann.

Ubuntu: Akustische Signale für länger laufende Befehle

So manche Aktion auf der Kommandozeile braucht ihre Zeit. Um zügig voran zu kommen kann man entweder immer wieder nachschauen ob das Programm seine Arbeit erledigt hat oder man bleibt gleich vor dem Computer und wartet. Da man meist besseres zu tun hat sind beide Optionen nicht ideal.

Seit langer Zeit gibt es unter Linux den Befehl beep. Hängt man diesen mit zwei & ans Ende einer Befehlszeile wird zuerst der eigentliche Befehl ausgeführt und am Ende ertönt ein schriller Ton. Auf einem aktuellen Ubuntu kann man das Paket beep zwar nachinstallieren, doch bleibt der Lautsprecher stumm. Das von beep benötigte Kernelmodul ist fehleranfällig und daher in Ubuntu deaktiviert. Man kann zwar immer noch in die Kernel-Module abtauchen und in der Datei /etc/modprobe.d/blacklist.conf die richtige Zeile auskommentieren. Im besten Fall kriegt man einen schrillen Ton zurück und im schlechtesten Fall hat man ein unbrauchbares System. Beides ist es nicht Wert diese Option zu verfolgen.

 

Eine bessere Alternative

Viel angenehmer wäre es wenn ein angenehmerer Ton abgespielt werden könnte. Da mittlerweile jeder Desktop seine eigene Sammlung an Systemklängen und Melodien mitbringt findet man sicher eine Audio-Datei die als Hinweiston deutlich angenehmer ist.

Hat man die passende Audio-Datei gefunden braucht es einige kleine Ergänzungen an der .bashrc. Mit dem Editor seines Vertrauens kann man diese Datei im eigenen Home-Verzeichnis öffnen und am Ende diese Zeilen einfügen:

export BEEP_SOUND=/usr/share/sounds/gnome/default/alerts/glass.ogg
alias beep='paplay $BEEP_SOUND'

Wichtig: Der Pfad zur Audio-Datei muss entsprechend angepasst werden!

Sobald diese Datei gespeichert ist kann man die Einstellungen mittels source ~/.bashrc neu laden (oder ein neues Terminal öffnen). Führt man nun diesen Befehl aus ertönt nach 3 Sekunden der Hinweiston:

$ sleep 3 && beep

So lange der eigentliche Befehl korrekt abläuft und eine 0 als Return-Wert liefert ertönt der gewünschte Ton. Soll dies auch im Fall eines Fehlers passieren muss man noch das Programm wait bemühen:

$ sleep 3 & wait; beep

 

Fazit

Kleine Helfer kommen oft in ganz einfachen Befehlen daher. Nur bis man die richtige Idee oder den passenden Ansatz hat dauert es meist ein wenig länger…

Kurz-Tipp: Bildschirmfotos unter Mac OS X erstellen

Eigentlich ist es ganz einfach Bildschirmfotos unter OS X zu erstellen. Aber da es keine extra beschriftete Taste gibt steht man dann doch immer wieder vor der Frage wie die entsprechende Tastenkombination lautet.

 

Ganzer Bildschirm

Um den ganzen Bildschirm zu Fotografieren genügt es die Tasten Cmd + Shift + 3 zu drücken:

 

Bildschirmbereich

Soll hingegen nur ein Bereich des Bildschirms fotografiert werden lautet die Tastenkombination
Cmd + Shift + 4:

 

Einzelnes Fenster oder in die Zwischenablage

Ein einzelnes Fenster kann man fotografieren indem man nach der Tastenkombination Cmd + Shift + 4 noch die Leertaste drückt:

All diese Befehle speichern das Bildschirmfoto als Datei ab. Wenn das Bild allerdings in die Zwischenablage gespeichert werden soll genügt es zusätzlich die Taste Ctrl zu drücken:

Kurz-Tipp: Responsive Design einfach testen mit Window Resizer

Wer heutzutage Webapplikationen erstellt wird kaum um das Thema Responsive Design herum kommen. Dabei geht es um die Anpassungsfähigkeit einer Webseite an verschiedene Bildschirmgrössen. Schliesslich soll die Anwendung nicht nur auf dem Laptop bedienbar sein sondern auch auf dem Smartphone zum Verweilen einladen.

Die technische Seite wird durch Frameworks wie Bootstrap gut abgedeckt und dürfte den meisten Entwicklern bekannt sein. Wenn es allerdings ums Testen der einzelnen Auflösungen geht stutzt man das Browserfenster meist von Hand zurecht. Dies mag zwar ein gangbarer Weg sein, doch ist dies mühsam und ungenau.

Viel einfacher und schneller ist es eine entsprechende Erweiterung für den Browser zu installieren. Davon gibt es für jeden Browser mehr als genug, doch kaum eine kommt an Window Resizer von Ionut Botizan für Chrome heran. Diese Erweiterung ist auf genau einen Zweck optimiert und lässt einem die voreingestellten Fenstergrössen um beliebige eigene Formate erweitern.

Für mich gibt aber eine Tastenkombination den Ausschlag Window Resizer zu verwenden: Mittels [Strg] + [Umschalt] + [Abwärtspfeil] lässt sich sehr schnell durch die einzelnen Fenstergrössen durchschalten. Dies ist sehr praktisch wenn man nicht nur wissen will ob eine bestimmte Grösse funktioniert sondern ob alles noch wie gewünscht aussieht.

Hat man sich einmal an die damit gewonnene Flexibilität gewöhnt will man so eine Erweiterung nicht mehr missen.

Von Zeit und Datenmengen

Bei Datenmigrationen und der Batchverarbeitung kommen 2 Bereiche zusammen bei denen viele Entwickler (mich eingeschlossen) schnell an eine mentale Grenze stossen:

• Zeit
• Datenmenge

Wohl ist jedem bekannt das ein Tag 24 Stunden hat und ein Terabyte aus 1024 Gigabyte besteht. Und doch kommt es immer wieder zu bösen Überraschungen.

 

Eine Optimierung am Code ist reine Zeitverschwendung, da die Arbeit in einer Sekunde erledigt ist.

 

Wer hat nicht schon solche Aussagen gehört? Das Problem von dieser einen Sekunde ist nicht die Dauer. Das Problem liegt in der impliziten Aussage über die Geschwindigkeit. Eine Sekunde ist kurz, meine Arbeit gross und daraus folgt mein Code ist schnell. Wenn es so doch nur so einfach wäre…

 

Wie lange kann es auf der Produktion schon gehen wenn es auf dem Testsystem gar nicht messbar ist?

 

Ist die wohl noch schönere Frage. Wer schon einmal versuchte eine grössere Datenmenge zu migrieren kennt die unbequeme Antwort: Lange – viel zu lange.

 

Was genau messen wir?

Wie immer wenn etwas gemessen wird kommt es auf die Relevanz an. Ob 1 Sekunde schnell oder langsam ist hängt davon ab, was darin gemacht wurde. Wie viele Datensätze wurden verarbeitet? Und in welchem Verhältnis steht diese Datenmenge zum Zielsystem?

Die einzelnen Sekunden summieren sich sehr schnell, alles was es dazu braucht ist eine unterschiedliche Menge an Daten auf dem Test- und auf dem Produktionssystem. Bei einem linearen Anstieg wächst die Verarbeitungsdauer gleichmässig mit der Datenmenge. Verdoppelt sich die Datenmenge, verdoppelt sich auch die Verarbeitungsdauer. Hat man 60x mehr Daten in der Produktion als auf dem Testsystem wird aus dieser einen Sekunde bei der Einführung eine Minute.

 

Eine Hochrechnungstabelle

Was passiert aber wenn man statt auf dem Testsystem auf dem Entwicklungssystem gemessen hat? Da ist das Verhältnis vielleicht nicht 1:60, sondern 1:1’000, 1:10’000 oder gar 1:100’000. Wie lange waren nochmal 100’000 Sekunden?

Diese kleine Hochrechnungstabelle nimmt das Rechenbeispiel auf und geht von einer Sekunde für eine bestimmte Menge von Daten aus. 10x mehr Daten ergeben den Faktor 10, der für diesen linearen Anstieg auch in einer 10x längeren Dauer resultiert:

Faktor Datenmenge	Dauer
1	00:00:01
10	00:00:10
100	00:01:40
1’000	00:16:40
10’000	02:46:40
100’000	27:46:40 oder 1 Tag 03:46:40
1’000’000	277:46:40 oder 11 Tage 13:46:40

Die 100’000x mehr Daten machen aus der getesteten Sekunde bei der Einführung eine Aufgabe die sich in einem Tag nicht mehr abschliessen lässt. Aber schon bei 10’000x mehr Daten dürfte so mancher Einführungsplan in den kritischen Bereich kommen.

 

Probleme vermeiden

Diese Probleme lassen sich am einfachsten dadurch vermeiden, dass man die Performance-Messungen auf vergleichbaren Systemen mit vergleichbaren Datenmengen macht.

Ist es nicht möglich muss man die Werte entsprechend umrechnen. Dies ist viel aufwändiger und weniger genau, aber immer noch besser als sich einzureden die Arbeit sei in einer Sekunde erledigt. Dabei gilt es aber nicht nur die Datenmenge zu bedenken. SSD-Festplatten sind gerade in Kombination mit kleinen Datenmengen deutlich schneller als so manche Server-Festplatte. Von CPU, Netzwerk und Systemdiensten die auch noch laufen ganz zu schweigen.

 

Fazit

Wenn man eine Performance-Messung nur auf die Dauer reduziert führt dies zu völlig falschen Annahmen. Um lange Wartezeiten bei der produktiven Einführung zu verhindern muss daher unbedingt beachtet werden wie sich die Daten und Systeme gegenüber der Produktion unterschieden. Mehr Daten bedeutet eine längere Verarbeitungszeit. Und nur weil es auf irgendeinem System schnell ist bedeutet dies nicht automatisch das man aufs optimieren verzichten kann. Ganz abgesehen davon dass eine exponentielle Zunahme der Verarbeitungszeit alles noch viel schlimmer macht…