[Videotutorial] Workflow: vom RAW-Foto zum fertigen Bild

Lange habe ich es mir vorgenommen, und gestern hab ich es nun endlich fertiggestellt: mein erstes Videotutorial.

Darin stelle ich euch meinen Workflow vor, mit dem ich die Bilder, die meine Kamera so hervorbringt, bearbeite, zuschneide und anschließend abspeichere. Ich hoffe, dass ihr den einen oder anderen Tip abstauben könnt und würde mich besonders über Feedback freuen, da ich in Zukunft mehr davon produzieren möchte.

Als Beispiel verwende ich das Bild father&daughter, welches ich letzte Woche am Stachus in München geschossen habe:

Aber nun – Film ab:

Alternative Version auf Youtube

Drahtlosen Hardware Keylogger selber bauen

Jerry arbeitet bei keelog.com – einem kommerziellen Anbieter für Hardware Keylogger. Doch Jerry ist auch ein Fan von Open Source und so hat er eine Anleitung ins Netz gestellt, nach der man so ein Teil selbst bauen kann. Darin enthalten sind eine detailierte Teileliste, die Baupläne, PCB Masken (Schaltkreise), die Firmware (also Steuersoftware) und natürlich die Bauanleitung selbst. Wenn man es etwas leichter haben will kann man aber auch ein DYI Kit (do it yourself) kaufen und spart sich somit die Zeit für die Suche der Einzelteile. Im Endeffekt hat man am Ende einen PS/2 Stecker, der am Ziel-PC angesteckt in Echtzeit alle Codes der gedrückten Tasten an ein bis zu 18m entferntes USB-Dongle sendet.

Natürlich bewegen wir uns hier in einer Grauzone, da es sowohl legale als auch illegale Einsatzzwecke dafür gibt. Da mich als Techniker in erster Linie auch nur die Technik interessiert, möchte ich dies erstmal außen vor lassen. Ich denke einfach, dass wenn jemand etwas böses tun will, er auch einen Weg findet dies zu tun. Und dann gibt es uns Nerds, die einfach nur Spass an Technik haben.

So, aber nun genug gequatscht, hier die Anleitung:
keelog.com

Via hack-a-day

Die Ego Box – der Hardware Visitscounter für deine Website

Cooles Teil, oder? Wenn ich elektrotechnisch etwas begabter wäre, dann würde ich mir so ein Teil bauen. Bin ich aber nicht. Sollte es aber jemanden hier geben, der in solchen Themen fitter ist: Unter

www.electrobob.com/ego-box/

findet ihr die Anleitung für den Bau der Hardware sowie der Software. Falls jemand lange Weile hat – ich würde mich sehr über ein derartiges Geschenk freuen 😉

via hack-a-day

Facebook Chat mit Adium – Fehlerbehebung

Seit einiger Zeit hatte ich in Adium das Problem, dass ich zwar erfolgreich im Facebook Chat eingeloggt war und Kontakte, die mich anschrieben auch in der Kontaktliste erschienen – ich sah aber nicht, ob Kontakte online waren oder nicht. Scheinbar hat Facebook mal wieder was an der API geändert und die Jungs von Adium haben noch nicht nachgezogen.

Egal – nachdem es mich nun richtig genervt hat, habe ich mal eine kurze Recherche angestellt und schnell die Lösung gefunden. Facebook selbst gibt eine offizielle Vorgehensweise an 😉
Und zwar verwendet man nicht das Facebook Plugin, sondern das gute alte Jabber Protokoll. Und so gehts:

Bei Facebook anmelden, dann die Seite www.facebook.com/sitetour/chat.php aufrufen und dort “Adium auswählen”. Schon wird euch der Loginname angezeigt. Das Passwort ist euer normales Facebookpasswort. Tragt diese Daten als Jabber-Login ein und schon werden die Facebook Kontakte wieder korrekt angezeigt.

via apfeltalk.de

statische Code-Analyse mit dem php code sniffer

Foto von Dennis Wegner

Programmierer machen, wie jeder andere Mensch, auch Fehler. Nun gibt es zum einen Fehler in der Syntax, auf der anderen Seite gibt es die Logik-Fehler. Beide verursachen, dass ein Programm entweder gar nicht oder nicht wie erwartet funktioniert. Normalerweise kann (und muss) man diese Fehler entdecken – manchmal geht das leicht, manchmal aber auch nicht. Syntax-Fehler stellen hier den einfachsten Kandidaten dar, da diese meist schon von der verwendeten IDE erkannt werden, spätestens aber bei der Ausführung des Programms ein Fehler auftritt. Logische Fehler sind da schon etwas kniffliger, da sie rein aus Programmiersicht fehlerfrei sind. Nur die Art und Weise, wie sie ein Problem behandeln entspricht nicht dem, was der Programmierer ursprünglich vor hatte.

Zu diesen beiden Kandidaten gesellt sich aber noch eine weitere Gattung, nämlich die Art und Weise, wie Code geschrieben wird. Jeder Programmierer hat – genauso wie jeder Mensch die eigene Handschrift – einen eigenen Programmierstil. Das ist zuersteinmal nichts verwerfliches und wird weder Probleme in der Syntax noch in der Logik hervorrufen. So gesehen gibt es aus betriebswirtschaftlicher Sicht keinerlei Notwendigkeit, sich darum zu kümmern. Problematisch wird es aber dann, wenn mehrere Entwickler mit einem Projekt beschäftigt sind. Spätestens hier treffen Welten auseinander und es kann durchaus vorkommen, dass völlig korrekter Code einfach nicht mehr bzw. nur sehr schwer lesbar ist. Bei geringem Umfang stellt das nicht das große Problem dar, wenn man allerdings mit komplexen Projekten zu tun hat kann dies zu einem großen Hindernis werden. Das fiese daran ist, dass man das Problem anfangs einfach nicht erkennt. Wenn es dann auftritt, ist es meist zu spät.

Um dem Herr zu werden, setzen viele Unternehmen und Entwickler auf Coding-Standards. Dabei handelt es sich um Regeln, wie Code formatiert werden muss und welche Lösungswege nicht verwendet werden sollten. Oder eben, welche Prioritäten bestimmte Lösungswege haben. Dabei geht es z.B. um die Art und Weise, wie Klammern gesetzt werden, die Variablen formatiert werden, wie Klassen und Kontrollstrukturen (Schleifen usw.) auszusehen haben usw. Gerade große Open Source Projekte mit mehreren hundert oder gar tausend Entwicklern müssen einfach derartige Regeln definieren, da sonst reinstes Chaos entsteht. Das würde dann dazu führen, dass Code zwar sehr gut, aber aufgrund von schlechter Lesbarkeit nicht mehr wartbar wäre. Und somit leider unbrauchbar sein würde.

Ok, nun haben wir die Theorie geschafft. Nun kann man die Regeln definieren und jeder hält sich dran, aber wie es so bei den Menschen ist, unterlaufen einem Fehler, man wird faul oder man hat einfach keine Lust auf die Regeln. Die gegenseitige Kontrolle von Code mag bei kleineren Mengen noch durch Menschen machbar sein, wenn ein Projekt aber aus mehreren zehntausenden Zeilen Code besteht, ist das auch nicht mehr machbar. Und an dieser Stelle setzt man auf statische Code-Analyse. Mit den entsprechenden Tools kann man Code analysieren und anschließend anhand definierter Regeln auswerten lassen.

Eines dieser Tools, und das sagt ja schon die Überschrift, befasst sich mit der statischen Analyse von php Code und nennt sich “php code sniffer”. Das Tool ist kostenlos und kann über PEAR geladen werden:

pear install PHP_CodeSniffer-1.3.0RC2

Die Version 1.3 RC2 ist die derzeit aktuelle Version, um auf dem neusten Stand zu sein schaut doch einfach mal hier nach, welche die aktuelle Version ist.

Über die Console ist das Tool nach erfolgreicher Installation mittels “phpcs” verfügbar. Der Aufruf ist dann ganz leicht:

phpcs --standard=zend class.php

In diesem Beispiel wurde die Datei class.php auf die Coding-Standards von Zend hin überprüft. Das Ergebnis sieht dann ungefähr so aus:

FILE: /.../class.php
--------------------------------------------------------------------------------
FOUND 3 ERROR(S) AND 0 WARNING(S) AFFECTING 3 LINE(S)
--------------------------------------------------------------------------------
1 | ERROR | End of line character is invalid; expected "\n" but found "\r\n"
9 | ERROR | Expected 0 spaces before opening brace; 2 found
11 | ERROR | Spaces must be used to indent lines; tabs are not allowed

Als kurze Erklärung: In Zeile 1 wurde ein falscher Zeilenumbruch verwendet (kann passieren, wenn man mit Windows und Linux/Unix im Wechsel am gleichen Code arbeitet), in Zeile 9 waren zwei Leerzeichen vor der öffnenden geschweiften Klammer und in Zeile 11 wurde mit Tabs an Stelle von Leerzeichen eingerückt. Die Datei an sich funktioniert tadellos, allerdings verstoßen diese Punkte eben gegen die Konventionen von Zend.

Wie ihr seht, ist es mit dem php code sniffer sehr schnell und vor allem sehr einfach möglich, euren Code auf Regeln hin zu untersuchen und Fehler dieser Art zu finden. Neben den Regeln von Zend gibt es noch einige weitere vorgefertigte Rules, die ware Stärke zeigt das Tool aber mit der Möglichkeit, eigene Regeln zu definieren. Da ich den Umfang dieses Beitrags nicht sprengen will, schaut euch doch einfach mal folgenden Beitrag auf “php hates me” an, der genauer auf dieses Thema eingeht: PHP Code Sniffer – Eigene Regeln erstellen.

Links:
php code sniffer
phphatesme.com

Tutorial: ESXi Server mit der HP Z400 Workstation

Heute gibt es mal einen Gastbeitrag von einem meiner Auszubildenden zum Thema VMware ESXi Server. Der ESXi ist die kostenlose Variante des ESX Servers, der für die Servervirtualisation eingesetzt wird. Dabei wird kein Betriebssystem als Unterbau benötigt, da der ESX direkt in eine kleine Linux-Umgebung integriert ist. Das bringt zum einen extreme zusätzliche Performance, zum anderen auch eine geringere Bug-Anfälligkeit des Host-Systems. Patrick hatte bei der Einrichtung einige Probleme, da die Treiber für die Netzwerkkarte seiner Workstation nicht richtig erkannt wurden. Doch lest selbst:

Ich habe mich in der letzten Woche, aufgrund meiner Ausbildungsstelle, mit dem ESXi Server auseinandergesetzt.
Ziel war es, den Server auf einer HP Z400 Workstation zum Laufen zu bringen. VMware stellt hierfür eine kostenlose
ISO-Datei auf ihrem Webserver bereit.

Mit dem gebrannten ISO-Image im CD-Laufwerk traten auch schon die ersten Probleme auf:
Zum einen wird der Netzwerkadapter (NIC) vom ESXi Server nicht unterstützt, zum anderen lädt der ESXi standartmäßig SCSI Festplatten-Treiber. Da in der HP Z400 in der derzeitigen Konfiguration nur SATA Platten verwendet werden (bisher nur eine, später wird ein RAID folgen), musste ich mich durch verschiedenste Foren und Lösungsvorschläge kämpfen.

Letztendlich konnten beide Probleme folgendermaßen gelöst werden:

Ich habe mir eine Ubuntu Live-CD erstellt und diese auf der Workstation starten lassen,
mir das ‘mkesxiaio’ Bash-Script runtergeladen und in den Ordner ‘/Downloads/tmp/’ kopiert. In den gleichen Ordner kamen jeweils noch die ISO-Datei des ESXi 4.1 Servers und eine, aus dem vm-help.com Forum,
modifizierte, oem.tgz.

Im Anschluss startete ich das Terminal und wechselte in den Ordner ‘/Downloads/tmp/’,
um das Script mit ‘sudo chmod +x mkesxiaio_3.x.x.sh’ ausführbar zu machen
und per ‘sudo ./mkesxiaio_3.x.x.sh’ auszuführen.

Das Script frägt dann auch gleich, welche ESXi Version man benutzt. In diesem Fall wählte ich die ‘3’ für die Version 4.1.

Nachdem überprüft wurde, ob die benötigte Linux Tools in der Distribution vorhanden sind, konnte ich auswählen,
in welcher Form (modifiziertes ISO-Image, Installation auf den USB laden, Server auf den USB installieren) das Image ausgegeben werden soll. Ich wählte “Server auf USB-Stick installieren”.

Als die Frage, ob die init.d editiert werden soll, erschien, wählte ich “ja” und fügte folgendes am Ende der Datei ein:
vmkload_mod tg3.o
vmkload_mod lvmdriver

Dadurch werden bei jedem Boot-Vorgang die fehlenden Netzwerktreiber nachgeladen.

Nachdem der Stick erstellt war, konnte ich von selbigem Booten und den ESXi einrichten.