[Quicktip] Mit OSX den Arbeitsspeicher aufräumen

Normalerweise sollte man in Sachen Speicherverwaltung OSX nicht in die Quere kommen, denn das macht es selbst ganz gut. Wem das nicht reicht, der sollte nicht rumspielen sondern einfach mehr RAM in das Gerät packen.

Aber was macht mein Mac OS denn so mit dem Arbeitsspeicher? Das System unterscheidet zwischen free, in-active und active RAM. Free erklärt sich selbst, active auch, aber was ist in-active? Das bedeutet einfach, dass wenn man ein Programm beendet, die Daten nicht aus dem Speicher gelöscht werden, sondern erstmal einfach drin bleiben. Startet man dieses Programm später wieder, dann besteht eine gewisse Möglichkeit, dass die Daten noch da sind und der Start somit wesentlich schneller durchgeführt werden kann.

Was ich in letzter Zeit beobachte: wenn viel Speicher als in-active markiert ist, dann dauern Programmstarts teilweise irgendwie länger. Um dem zu entgehen habe ich einfach öfter mal den Rechner neu gestartet, aber so eine richtige Lösung ist das auch nicht. Nun habe ich eben einen netten Hinweis gefunden:

purge

Einfach mal im Terminal “purge” eingeben, Enter drücken, kurz warten und schwups, schon ist der RAM aufgeräumt. Ob das nun sinnvoll ist werde ich beobachten, aber rein gefühlsmäßig ist das schon ein nettes Tool.

via electrictoolbox.com

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

[Quicktip] Passwort als Parameter an ssh übergeben

Als Erweiterung zu [Quicktip] ssh Verbindung ohne Known-Hosts Eintrag hier noch die Möglichkeit, das Loginpasswort für einen Server an den SSH Befehl zu übergeben:

Aus Sicherheitsgründen ist es nicht möglich, Passwörter an den ssh-Befehl unter Linux/Unix zu übergeben. Damit soll verhindert werden, dass Passwörter in Scripten hardcoded werden und somit nicht mehr sicher sind. Möchte man passwortlos per Script mit anderen Servern arbeiten, gibt es noch immer die Möglichkeit, die RSA Keys zu hinterlegen.

Nun gibt es aber auch einige wenige spezielle Anwendungsfälle, in denen das Passwort nicht wirklich Sicherheitsrelevant ist, man nicht die Möglichkeit hat den RSA Key zu hinterlegen und man immer mit wechselnden Rechnern zu tun hat. Für diese seltenen Fälle kann man sich mit dem “expect” Befehl behelfen. “expect” macht folgendes: man ruft ein Programm per “expect” auf und versieht das ganze mit einem Kontrollscript. Dann kann man mit einer Art regulärer Ausdrücke nach Ausgaben eines Programmes suchen und auf diese reagieren. Im Fall von ssh sucht man nach der Ausgabe “password:”. Findet expect dieses, soll es einen vorgegebenen Wert einsetzen und mittels Enter bestätigen. Wenn man nun noch ein bisschen Bash-Magie betreibt kommt dieses Script heraus.

Der Aufruf läuft dann so:

./sshlogin.exp password 192.168.1.11 who

In dieser Variante wird immer der Benutzer root verwendet, man kann das Script aber einfach noch um einen weiteren Parameter erweitern, schon ist der Benutzername auch variabel.

Und was war mein Anwendungsfall? Darüber gibt es demnächst einen Artikel… 😉

Links:
bash.cyberciti.biz

[Quicktip] ssh Verbindung ohne Known-Hosts Eintrag

Es gibt gute Gründe, warum ssh die Fingerprints (also die virtuellen Fingerabdrücke) der Server speichert, mit denen man sich verbindet. Tut man dies nämlich erneut, so kann ssh prüfen, ob sich hinter dieser IP bzw. hinter diesem Hostnamen noch immer der gleiche Rechner befindet. Wenn nicht, gibt’s eine Warnung.

Nun gibt es aber auch Fälle, bei denen will man diesen Schutz unterbinden – vornehmlich beim Scripting. Und das macht man so:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@server

Was passiert? Mit dem ersten Parameter wird das known-hosts-File “/dev/null”, also “nichts”, verwendet. Parameter 2 gibt an, dass die Überprüfung der Fingerprints deaktiviert werden soll. Lässt man den ersten Parameter weg, so werden trotzdem die Fingerprints in der normale known-hosts-File geschrieben.

Wenn DAUs zu Hackern werden – Jailbreaken ist nichts für kleine Jungs!

Gestern hat sich ein lang von mir gehegter Verdacht bestätigt: Wenn man keine Ahnung hat, einfach mal sein lassen. Es geht um das Thema Jailbreak von iOS. Wenn ich mich so in meinem Bekanntenkreis umschaue, dann haben da sehr viele Leute ihr iPhone geknackt, um damit vornehmlich kostenlos an Bezahl-Apps zu kommen. Bei Azubis und Schülern kann ich das noch bis zu einem gewissen Grad nachvollziehen, wenn man jedoch normaler Arbeiter ist und sich schon so ein Gerät leisten kann, dann sollten auch noch die paar Euro für Apps übrig sein. Aber gut, das ist ein anderes Thema.

Der Jailbreak ist mittlerweile so idiotensicher gemacht, dass jeder, der sein Handy und einen PC bedienen kann, ihn durchführen kann. Diese Einfachheit birgt aber eine sehr große Gefahr: man hat keine Ahnung, was man da getan hat. Die wenigsten wissen, wie Unix arbeitet, was die Nutzerrechte bedeuten, was ssh oder sftp ist und vor allem welche Auswirkungen das alles hat. Diese Gefahr besteht oft, wenn sicherheitskritische Tools zu einfach zu bedienen sind. Man zieht Script-Kiddies an. Also Benutzer, die das Tool zwar starten und ausführen können, jedoch überhaupt nicht wissen, was da genau passiert. Und somit auch nicht die Folgen abschätzen können.

Ich hatte rein zufällig mein Macbook im Wlan aktiv, als ich per Growl darüber informiert wurde, dass ein Bonjour-Gerät mit einem offenen SFTP Server verfügbar ist. Ein Klick darauf öffnete den FTP Client, der mich nach den Logindaten fragte. Da ich am Namen sah, dass das Handy nem Kollegen gehörte, welcher einen Jailbreak durchgeführt hatte, machte ich mich kurz bei Google auf die Suche. Die Kombination aus Benutzer “root” und dem Passwort “alpine” war schnell gefunden und ich war mit vollen root-Rechten auf dem iPhone 4. Zugegeben, das war ziemlich leicht. Aber auf Nachfrage war dem Kollegen nicht klar, das sein Gerät offen für jeden war – er wurde nicht darauf hingewiesen. Wenn so einfache Sachen schon passieren, was ist dann noch so im System offen? Mir hat die Zeit für weitere Tests gefehlt – was ich aber sah hat mir bereits gereicht. Man gibt sein System in die Hände von wildfremden Tools und hofft, dass sie nichts schlimmes machen.

Was will ich mit diesem Beitrag sagen? Überlegt euch genau, ob ihr all die zusätzlichen Features braucht, die euch ein Jailbreak gibt. Ich persönlich sehe derzeit keinen Grund für einen Jailbreak, und nach diesem Ereignis stehe ich dem Thema noch skeptischer gegenüber. Und denkt beim kostenlosen saugen über den Cydia-Store auch dran: ein großer Teil der Entwickler verkauft seine Apps nicht zum Spass, sondern weil er davon leben will/muss. Ich möchte euch mal sehen, wenn eure Arbeit nicht bezahlt wird – die Leute schreien dann nämlich meist am lautesten.

Diaspora – das “freie” Social Network (+Invites)

In Zeiten des Web 2.0 sind Invite-Only Dienste kein großes Hindernis mehr. Und so hatte ich für den neuen Social Network Dienst Diaspora innerhalb weniger Minuten einen Invite. Aber kommen wir zum Thema…

Diaspora? Hat das nicht irgendwas mit Kirche zu tun? Nein, in diesem Fall nicht. Der dezentrale Dienst wurde von 4 Informatikstudenten entwickelt und soll geschlossenen Systemen wie Facebook entgegenwirken. Ob ihm das gelingt wird sich zeigen müssen, denn bisher befinden wir uns erst in der Alpha Phase.

Nach einem kurzen Rundumblick kann man sagen: Disaspora scheint eine Art Twitter zu sein, verfügt jedoch über die bisher coolste Freundeverwaltung, die in Social Networks zu sehen war. Ich bin jetzt erstmal am Freunde sammeln – was ja wohl der Sinn eines Social Networks ist, oder? 😉

PS: Hinterlasst einen Kommentar, dann bekommt ihr einen Invite. 4 hab ich noch zu vergeben…

Von Android zum iPhone

Korrekterweise müsste es natürlich “von Android zu iOS” lauten, allerdings bin ich mit dem iPad ja schon etwas länger aktiv, weshalb die Überschrift nicht mehr stimmen würde. Tja, was soll ich sagen, ich bin nun stolzer Besitzer eines iPhone 4. Warum das so lange gedauert hat? Das hat mehrere Gründe:

Zunächst war ich der Android Plattform mehr gesonnen, da ich es liebe, mich auf einem Handy austoben zu können. Man kann so ziemlich alles auf einem Android Gerät an Software austauschen, was allerdings auch eine gewisse Verantwortung mit sich bringt – das musste ich schmerzlich feststellen. Das ganze Konzept hinter dem System ist echt klasse, nur leider harpert es teilweise an der Umsetzung. Ich muss aber darauf verweisen, dass es sich lediglich um Details handelt. Nach wie vor ist Android für mich eine tolle Plattform, die locker im 3er-Gespann zwischen iOS und Web-OS locker mithalten kann.

Updates

Aber bekanntlich können auch Details irgendwann nerven. Da wäre für mich z.B. die Updatepolitik aller Hersteller, die auf Android setzen. Sie versuchen sich nicht durch Hardware zu differenzieren, sondern durch irgendwelche obskuren alternativen Homescreens. Ähnliches kennen wir bereits von Windows Mobile, wobei es sich da um Overlays und nicht um Replacements handelte. Diese alternativen Homescreens an sich sind ja sogar gewollt, nur kommen die Hersteller nicht hinterher, all ihre zusätzlichen Features an die immer neuen Android-Versionen anzupassen.

Was passiert? Es werden mehrere Updates übersprungen bzw. es erscheint für die meisten Geräte gar kein Update mehr. Einzig Google selbst bringt die neuen Android Versionen für sein eigenes Flaggschiff, das Nexus One, zeitnah. Für alle anderen Hersteller gilt: neues Handy kaufen, dann gibt’s auch die nächste Android-Version.

Für Apples Seite muss man hier ganz klar ein Lob aussprechen. Bisher haben alle Geräte, die iOS verwenden, regelmäßig Updates erhalten. Mit iOS 4.0 sind nun erstmals das iPhone 2G sowie der erste iPod Touch rausgefallen, und das rein aus Gründen mangelnder Hardware. Hier können sich eigentlich ALLE Handyhersteller eine Scheibe von abschneiden. Denn meines Wissens gab’s das bisher in dieser Form noch nie.

Apps

Ein weiterer sehr unangenehmer Punkt ist der Android Market. Ja, alle schimpfen über den Apple App Store und die “Bevormundung”, ich muss allerdings dazu sagen, dass ich diese wesentlich lieber in Kauf nehme, als mich durch Schrott zu wühlen. Apps, die nur auf Handys bestimmter Hersteller laufen, Apps, die überhaupt nicht funktionieren, und Apps, die noch nicht mal die Bezeichnung Applikation verdient haben. Offenheit hat viele Vorteile, aber für mich als Endverbraucher sehe ich da leider zum größten Teil Nachteile.

Pluspunkte sammelt der Android Market aber auf der technischen Seite. Sowohl die Installation neuer Software als auch das Einspielen von Updates ist hier wesentlich besser als beim Appstore gelöst. Sofern man sich auf die Apps großer Hersteller verlässt fährt man mit Android also ziemlich gut. Der Apple Appstore ist leider komplett auf “Geld verdienen” ausgelegt, was man ihm auch anmerkt. Ich verstehe natürlich, dass diese Einnahmequelle sehr wichtig ist, auf mich wirkt der Aufbau des Stores aber eher anstrengend. Also hier nochmal wirklich deutlich Minuspunkte für Apple.

Betriebssystem

Der dritte und für mich wichtigste Punkt ist der Umgang mit Multitasking bzw. dem Betriebssystem selbst. Rein von der Gui und den Funktionen her liegt Android hier wesentlich vorn (ich sag nur Homescreen und Widgets), verspielt diesen Vorteil jedoch, zumindest meiner Meinung nach, durch das “echte” Multitasking. Klar, die Programme laufen wirklich parallel, die Frage ist nur, ob man das wirklich will und wie Hardware + Software darauf regieren. Meine personliche Erfahrung ist hier ganz klar: geht überhaupt nicht. Sowohl mein HTC Magic als auch das (zumindest vor einem halben Jahr noch) als Flaggschiff bezeichnete Motorola Milestone haben nicht meinen Ansprüchen vom “flüssigen Arbeiten” genügt.

Das hat natürlich damit zu tun, dass ich als “Poweruser” die Geräte anders verwende als vielleicht ein “normaler” User, was für mich aber keine Rolle spielt. Bietet mir ein System bestimmte Möglichkeiten, dann möchte ich die auch zu einem gewissen Grad nutzen. Erlebe ich dann jedoch, dass ein Gerät aufgrund dessen öfter mehrere Sekunden lang hängt, läuft meiner Meinung nach etwas falsch. Mag sein, dass das bei den neuen Sternen am Himmel wie dem Desire oder Galaxy anders ist, aber das interessiert mich nicht mehr. Nach ca. eineinhalb Jahren Android habe ich das Vertrauen verloren und versuche es nun am nächsten Stand.

Apple hat hier genau den richtigen Weg gewählt, indem auf ein simuliertes Multitasking gesetzt wird. Effektiv wird jede App, die nicht im Vordergrund läuft, pausiert – sie kann aber weiterhin auf Events reagieren, Töne/Musik abspielen usw., was der User so effektiv nicht bemerkt. Meiner Meinung nach ist das der derzeit einzig wahre Weg, auf mobilen Geräten Multitasking zu ermöglichen.

Der Homescreen auf iOS ist echt schwach, wenn man von Android kommt. Ich hoffe wirklich sehr, dass Steve sich da was einfallen lässt. Aber auch hier könnte ich mir vorstellen, das man mit der derzeitigen Oberfläche einige wesentlich Performance-Probleme umgehen will.

Fazit

Ich bin nach den drei Tagen Nutzung schon sehr zufrieden mit meinem neuen iPhone 4. Es fühlt sich einfach super an, die anti-Fettfinger-Schicht auf dem Display ist Gold wert und es ist vor allem eins: super schnell. Die Akkulaufzeit überzeugt mich derzeit noch nicht, wobei man das natürlich erst nach ein paar Ladezyklen wirklich beurteilen kann. An die Gui und das System an sich muss ich mich erst noch gewöhnen, denke aber, dass ich mich schnell umstellen kann. Einzig das Tastaturlayout bereitet mir wirklich Probleme, da ich wahrscheinlich einer der wenigen Menschen bin, die auch mal einen Punkt oder ein Komma setzen wollen. Usability ist in der Hinsicht leider null. Dafür entschädigt die Tastatur mit ihrem exzellenten Touch-Verhalten.

Skype 5.0 beta – wie zerstöre ich ein UI

Manchmal fragt man sich wirklich, was Designer und Entwickler etablierter Programme wie z.B. iTunes (neue Icons/Farben), Winamp (völlig überladene neue UI seit Version 5.0) und eben nun auch Skype den lieben langen Tag machen. Einfach mal eine neue UI rauswerfen, in der Hoffnung, dass sie nun super hipp ist und gut ankommt?

Eine UI dient an erster Stelle der möglichst unkomplizierten Interaktion des Users mit seinem Computer, erst im Anschluss kommt die Politur. Es scheint aber derzeit wirklich der Trend zu herrschen, dass es nur schick aussehen muss, denn die Usability kommt dann schon von allein. Mag sein, dass das ab und zu zutrifft, aber es macht wenig Sinn, dies bei einem langjährig bewährtem Interface zu tun. Denn heraus kommt dann z.B. so eine unbrauchbare Oberfläche, wie sie Skype in der neuen 5.0 Beta für den Mac präsentiert:

Vielleicht hab ich echt einen sehr komischen Geschmack, aber für mich hat eine Applikation, die ich primär zum Chatten verwende, eine möglichst schmale Liste mit meinen Kontakten zu sein, evtl. Konversationen führe ich dann in extra Fenstern. Skype will nun das ein-Fenster-Prinzip etablieren, welches meiner Meinung nach völlig am Ziel vorbei schießt. Wenn ich bedenke, dass ich nun für Skype einen extra Bildschirm reservieren muss, dann kommen mir nur noch Fragen. Derzeit passen Skype, Tweetie und Adium wunderbar nebeneinander auf einen Bildschirm, was wohl nun in Zukunft so nicht mehr funktionieren wird.

Hinzu kommt die Fokussierung auf die Konversationen. Vielleicht verwendet jeder Skype anders, aber primär öffne ich es, wenn eine Nachricht reinkommt oder ich jemanden anschreiben will. Alte Konversationen interessieren mich da erstmal nicht. Auch nicht die Konversationen des heutigen Tages, die da so prominent unten links platziert sind. Wenn ich alte Sachen sehen will, dann werde ich den entsprechenden Menüpunkt aufrufen, und sonst will ich davon nichts wissen.

Da es sich noch um eine Beta handelt kann man noch die Hoffnung haben, dass es viele Leute ähnlich sehen wie ich und Skype entsprechend abstrafen.

Setzen, Sechs!