Ja liebe Leser, ich brauch schon wieder ein T-Shirt, denn eins alleine ist ein bisschen mager 
Und so mach ich bei der “500 WM Shirts gegen Link!” Aktion vom Shirtblog mit. Zu gewinnen gibts ein WM-Shirt, welches die t-shirt-drucker spendieren. Wie ihr euch denken könnt, finde ich solche Aktionen extrem klasse
Gestern Abend war mal wieder Kino angesagt und es lief – wie ihr unschwer an der Überschrift erkennen könnt – Robin Hood. Im neuesten Streifen von Ridley Scott schwingt Russell Crowe Schwert und Bogen, um nicht wie erwartet die bekannte Robin Hood Story zu erzählen, sondern seine Vorgeschichte. Und das hat richtig gefallen.
Zum einen hab ich mich wirklich ins 12. Jh. versetzt gefühlt, zum anderen wussten die gesehenen Bilder zu begeistern – der Film sieht einfach richtig geil aus. Storymäßig kann man auch nicht meckern, wird man doch mit Witz und kleineren Wendungen immer gut unterhalten. Eine epische bzw. wirklich packende Story á la Herr der Ringe oder Gran Torino sollte man aber nicht erwarten. Als Ersatz dafür bekommt man aber echt gutes (und kein stumpfes) Popcorn-Kino.
Bisschen lächerlich fand ich allerdings die starke Anlehnung an der Soldat James Ryan. Bei manchen Szenen könnte man meinen, dass sie 1:1, nur mit Pfeil und Bogen, nachgestellt wurden. Richtig gelungen ist dagegen der Abspann im Skizzen-Look.
Bäm! Als ich gestern den Tweet von Caschy las, befand ich mich auch schon in der Testphase. Und ich muss sagen: Carsten hat zu 100% Recht!
LauncherPro ist ein extrem getunter Android-Homescreen (basiert auf dem original Homescreen) mit Exposé – einfach erneut auf die Hometaste drücken und schon sieht man alle seine Bildschirme gleichzeitig. Und das Teil rennt, das glaubt man gar nicht. Das ganze Handy läuft gefühlte 50% schneller. Ich krieg mich gar nicht mehr ein. Und das Beste: kostenlos! Habt ihr ein Android-Handy, dann macht euch sofort in den Market und testet LauncherPro, solange er noch in der Beta-Phase ist. Vielleicht wird daraus noch eine Bezahl-App
[Update]
Für User, die zu faul zum Tippen sind oder ganz lieb in den Kommentaren weinen hier nochmal der Link direkt in den Market:
Programmierung besteht nicht nur aus dem Aneinanderreihen von Codezeilen – in der Hoffnung dass es funktioniert. Dazu gehört sehr viel Überlegung und Theorie. Aus diesen Überlegungen entstanden (bzw. entstehen immernoch) sog. Design-Patterns. Das sind Mustervorlagen, wie man eine Klasse oder ein ganzes System aufbauen kann, um bestimmte Optimierungen oder effizienteren Code erreichen kann – losgelöst von einer bestimmten Programmiersprache. Die Patterns sind fast immer allgemeingültig.
Bereits vor einiger Zeit hatte ich das Registry Pattern vorgestellt, welches ich aktiv nutze. Während der letzten Projekte setze ich auf ein neues System, welches eher als Mischform zu bezeichnen ist: Im Kern verwende ich Techniken der event-driven-Entwicklung, das Observer- sowie das Singleton-Pattern. Damit ist es mir möglich, große Teile der Programmlogik auszulagern und – das ist der eigentliche Vorteil – das System wird sehr leicht erweiterbar, da sich neue Funktionen einfach einklinken können. Aber wie funktioniert das nun genau?
Nehmen wir uns als Beispiel ein einfaches Blogsystem: Man kann Artikel schreiben (natürlich nur nach einer Passwortabfrage) sowie die Artikel lesen. Ich möchte nun, dass all diese Vorgänge geloggt werden, mein Twitter-Account automatisch auf neue Artikel hinweist, ich über fehlerhafte Logins per Mail informiert werde und ein Visit-Counter über die Artikel läuft (ich also sehen kann, welche Artikel wie oft gelesen wurden). Das stellt natürlich keine große Schwierigkeit dar und kann so direkt in den bestehenden Code implementiert werden. Es geht aber auch anders.
Zuallererst benötigen wir unseren Observer. Dieser bietet Methoden, mit denen man sich für Events registrieren kann (per Listener) und über die man aber auch Events auslösen kann (Fire Event). Da der Observer als Singleton aufgebaut ist, kann man alle Kommandos jeweils mit einer Zeile Code erledigen. Man spart sich die Instanzierung und das Observerobjekt wird nur ein einziges Mal erstellt – was für seine Funktion essenziell ist.
Im ersten Schritt werden also die Listener registriert, was möglichst am Anfang eures Programmes passieren sollte, damit die Listener alle Events hören können. Mein Observer nimmt dazu folgende Daten für einen Listener entgegen: Event, Klasse und Methode. Das Event ist ein einfacher String, wie z.B. “NewArticleCreated”, “Fail_UserLogin” oder “PageVisit” – kann aber auch ein “*” sein. In diesem Falle lauscht der Listener auf jedes Event, was z.B. für das Logging oder Debugging interessant sein könnte. Die “Klasse” ist eine von mir frei wählbare Klasse, die auch die angegebene “Methode” enthält. Der Observer speichert diese Angaben nun in einem Array und behält sie während der gesamten Laufzeit
Im zweiten Schritt benötigen wir nun noch die Events. Der Observer kennt die Methode “fireEvent”, welche zusätzlich die Parameter Eventname sowie Eventdata enthält. Beispiele für die Eventnamen gab’s weiter oben schon, interessant ist hier eher der Parameter eventData. In diesem kann ich nämlich weitere Infos zum Event mitgeben – sei es als String oder als Array. Das Datenformat sollte natürlich vorher definiert werden.
Und was passiert nun, wenn ich ein Event abfeuere? Der Observer nimmt das Event entgegen und vergleicht es mit seinem Listener-Array. Trifft er eine Übereinstimmung, instanziert er die gegebene Klasse und ruft anschließend die Methode auf. Der Methode wird das Event sowie die eventData übergeben. Klingt alles etwas wirr, deswegen versuchen wir uns wieder an unserem Blog-Beispiel.
Im Initbereich meines Blogsystems registriere ich erstmal folgende Events:
Observer.addListener("*", "Logger", "logEvent");
Observer.addListener("Fail_UserLogin", "Informer", "noticeAdmin");
Observer.addListener("PageVisit", "Visitor", "countVisit");
Observer.addListener("NewArticleCreated", "TwitterTools", "sendNewArticleTweet");Ab sofort sollten wir an allen relevanten Stellen im Code Events feuern. Ganz wichtig an dieser Stelle: Auch Events feuern, auf die ihr noch gar nicht regieren wollt. Das macht es euch, aber auch anderen Programmierern später leicht, neue Programmlogik hinzuzufügen.
Observer.fireEvent("NewArticleCreated", articleID);
Observer.fireEvent("ArticleUpdated", articleID);
Observer.fireEvent("ArticleDeleted", articleID);
Observer.fireEvent("PageVisit", pageID);
Observer.fireEvent("Fail_UserLogin", userID);Die Events werden natürlich nicht direkt hintereinander abgefeuert sondern an den entsprechenden Codestellen hinterlegt. Der Observer geht bei jedem fireEvent seine Liste durch und aktiviert die Listener:
NewArticleCreated --> Logger.logEvent(eventName, eventData),
TwitterTools.sendNewArticleTweet(eventName, eventData)
ArticleUpdated --> Logger.logEvent(eventName, eventData)
ArticleDeleted --> Logger.logEvent(eventName, eventData)
PageVisit --> Logger.logEvent(eventName, eventData),
Visitor.countVisit(eventName, eventData)
Fail_UserLogin --> Logger.logEvent(eventName, eventData),
Informer.noticeAdmin(eventName, eventData)Der Vorteil an dem System ist, dass ich beliebig viele Listener auf bestimmte Events lauschen lassen kann, aber auch beliebig viele Events abfeuern kann. Das System ist also extrem dynamisch.
Möchte ich später z.B. Abonnenten darüber infomieren, dass es einen neuen Artikel gibt oder dass ich einen Artikel geändert habe, erweitere ich die Klasse Informer um die nötigen Methoden (oder bau mir eine neue Klasse) und registriere diese als Listener:
Observer.addListener(“NewArticleCreated”, “Informer”, “noticeUser”);
Observer.addListener(“ArticleUpdated”, “Informer”, “noticeUser”);
Da mir das Event gleich mit übertragen wird, kann ich innerhalb der Methode unterscheiden, welchen Mailtext der User erhalten soll – “Neuer Artikel in meinem Blog” oder “Ich habe einen Artikel bearbeitet”.
Ich hoffe, dass das Prinzip nun etwas verständlicher war…
Jahrelang war ich AMD Verfechter, musste mir dann aber vor einiger Zeit eingestehen, dass Intel im CPU Markt doch die Nase vorn hat. Und so präsentierte der Chip-Hersteller während des “Research @ Intel Day” in Brüssel einen Forschungschip namens “Palisades” vorgestellt, der sogn. Resilient Computing – also fehlertolerante Berechnung – ermöglicht. Im Kern geht es darum, dass moderne Prozessoren eigentlich weit unter ihrem eigentlichen Potential gefahren werden, weil sie sonst Fehler produzieren und unnütz sind. Die Fehler entstehen z.B., wenn man zu viel Spannung in den Chip gibt – bei solch extrem feinen Datenleitungen kann es dann schonmal passieren, dass der Strom von einer auf die nächste Leitung überspringt, da sie ja nur wenige Mikrometer voneinander entfernt sind.
Die Betonung liegt auf “kann”. Intel hat nämlich nun ein Verfahren entwickelt, welches derartige Fehler entdeckt. Wenn man bedenkt, dass ein Prozessor pro Sekunde mehrere Milliarden Operationen durchführt und beispielsweise “nur” 7 Millionen davon fehlerhaft sind, dann ist das eigentlich ein guter Schnitt. Die neue Technologie erkennt nun also, wenn sich die CPU verrechnet hat und lässt sie in diesem Falle die Operation erneut durchführen. Ein einfaches Prinzip, aber es scheint zu funktionieren.
Derzeit ist der Prototyp auf RISC basierend, also noch kein vollwertiger x86 Prozessor. So wie es aussieht wird der aber bald folgen.
PS: ich finde diesen “Beatbox”-Intel Sound geil
via golem.de
Apple hat mal wieder etwas geschafft, was nur wenige Firmen schaffen – dem Nerd die Tränen in die Augen treiben. Und zwar die Freudentränen. Mit dem iPad ist dem Unternehmen – allen Unkenrufen zum Trotz – mal wieder ein Meilenstein gelungen. Und auch wenn ich das Teil noch nie live gesehen habe, reichen mir bereits die Erfahrungsberichte aus dem Netz. Das Ding rockt einfach.
Jetzt haben wir es zwar bereits für die Firma bestellt und es wird auch voraussichtlich pünktlich zum 28.5. da sein, aber dann kommt da auf einmal padmania.de daher. Die bieten doch tatsächlich ein Gewinnspiel, bei dem man ein 16GB Wifi iPad bereits am 24. gewinnen kann und es somit als einer der ersten Deutschen in der Hand halten kann. Da ich nun bereits 2x Glück bei solchen Blog-Gewinnspielen hatte, will ich auch hier nochmal einen Versuch wagen…auch wenn ich damit 2-3 Leser vergraule – das iPad ist mir das wert. So, und nun Daumen drücken…ich belohne euch auch mit ausführlichen Blog-Artikeln darüber!
Im Internet gibt es ein Kommen und Gehen – Blogs, Podcasts, Twitter, Facebook usw. Und es gibt immer wieder etwas neues zu entdecken. In dieser Woche habe ich sysops.tv entdeckt – ein VBlog, der sich mit sehr systemnahen Themen im Bereich Linux/Unix, Windows und auch Hardware beschäftigt. Und das auch noch in deutscher Sprache. Ich finde das Format sehr erfrischend und vor allem der Moderator macht seinen Job sehr gut: er stellt “dumme” Fragen. Das macht die Folgen sehr verständlich und man kann sich leicht neues Wissen aneignen.
Besonders interessant finde ich derzeit Folge 69, in der es um ZFS unter Open Solaris geht:
Falls ihr mal lange Weile habt: schaut rein!
Links:
sysops.tv
Frauen telefonieren ständig mit ihrer Mutter, und so fragte ich gestern mal wieder mein Hasi, warum das denn sein müsse – von einem Tag auf den nächsten ändert sich doch nicht viel. Heute, einen Tag später, wurde mir mal wieder gezeigt, wie unrecht ich hatte.
Mein Morgen begann mit einem Anruf meines Bruders, der per Radio informiert wurde, dass heut morgen ein 23-Jähriger tot am Straßenrand nahe meines Heimatortes aufgefunden wurde. Kurz darauf – das Internet ist wie immer ein sehr schnelles Medium – war mir bekannt, um wen es sich handelte. Ein guter Bekannter, mit dem ich zwar nicht oft, aber immer gerne zu tun hatte. Und ist das noch nicht schlimm genug, so gibt es deutliche Anzeichen, dass er Opfer eines Autounfalls mit Fahrerflucht wurde – als Fußgänger.
Ja, ich habe ihn sicher nicht so gut gekannt wie seine Familie oder die engen Freunde, aber ich weiß ganz genau, wie sich das anfühlt. Vor etwas mehr als einem Jahr ereilte mich genauso unvermittelt die Nachricht vom vorzeitigen Tod meines Vaters – auch völlig ohne Vorahnung. Man fühlt sich machtlos – und doch muss das Leben weiter gehen. Diese Worte konnte ich in dieser Zeit nie verstehen und betrachtete sie eher als Durchhalteparolen. Nach langer Zeit erkennt man dann aber doch, dass sie wahr sind.
Nur eins stimmt nicht: Die Zeit heilt alle Wunden – einige bleiben immer, und das ist auch gut so. Sonst würden wir all die Lieben vergessen, die uns bereits verlassen haben. Ich schließe mich den Trauernden an und wünsche besonders seiner Familie unendlich viel Kraft in dieser schweren Zeit.
Nachdem ich vor ein paar Tagen ein sehr interessantes Chaosradio Express über das Thema verteilte Versionskontrollsysteme gehört hatte, hab ich mir nun mal GIT angeschaut. Die Hauptvorteile gegenüber zentralisierten Systemen sind:
Kurz gesagt: GIT macht fast alles besser als SVN.
Seinen Ursprung hatte das System in der Linux Welt. Linus Torvalds, der Erfinder von Linux, war mit den vorhandenen Versionskontrollsystemen nicht mehr zufrieden und entwickelte kurzerhand sein eigenes, welches die Vorteile aller Systeme zusammenführen sollte. Und es scheint ihm gelungen zu sein – GIT war geboren.
So, das erstmal als Vorgeplänkel. Wie ihr im Titel sehen könnt, geht es ja hier mehr um GIT in Verbindung mit SVN. Die Problematik ist nämlich, dass man bei sehr vielen Projekten auf Subversion gesetzt hat. Nun kann es zum einen sein, dass die Admins oder die Teammitglieder kein Interesse an GIT haben, die Zeit für eine Umstellung nicht vorhanden ist, oder der Chef einfach keine Lust auf Experimente hat. Genau für diese Fälle bringt GIT eine Sammlung von Tools mit, die z.B. als Brücke zwischen dem lokalen GIT Repository und einem entfernten SVN kommunizieren.
Tja, bei mir ist der Weggang von SVN vorerst auch keine Option, sodass ich mich genau mit diesen Tools beschäftigt habe. Ich möchte euch hier nun kurz zeigen, wie ihr euer Repository einrichtet, einen Checkout von SVN macht, etwas mit Eclipse ändert und das Ganze dann wieder ins SVN commited. Im speziellen befasse ich mich hiermit PHP Projekten, jedoch ist das GIT-Plugin für Eclipse universell einsetzbar – es ist also egal, welche Projektart ihr verwendet.
Zuallererst solltet ihr natürlich GIT installieren. Unter git-scm.com findet ihr die nötigen Installationsdateien. Für Mac gibt’s das obligatorische DMG Image, welches den Installer enthält. Nach erfolgreicher Installation seht ihr – nichts. GIT ist nämlich ein reines Kommandozeilentool. Also öffnet ihr zuerst das Terminalfenster.
Anschließend bewegt ihr euch in den Ordner, in dem ihr das Repository ablegen wollt bzw. den Checkout machen wollt. In meinem Fall ist es der “Sites” Ordner in meinem User-Verzeichnis – schließlich will ich mit versionierten PHP Projekten arbeiten. In SVN sind die Projekte ja meißtens in Unterordnern abgelegt, sodass der SVN-Pfad so aussieht:
svn://server/projektname
Ist dies der Fall, bewege ich mich also direkt in den “Sites” Ordner meines User-Verzeichnisses und erstelle keinen Projektordner. Durch den Checkout eines Projektes wird automatisch die Ordnerstruktur übernommen, sodass ich keinen Ordner für das Projekt anlegen muss. Wichtig: GIT arbeitet immer im aktullen Verzeichnis – achtet also darauf, dass ihr im richtigen Ordner seid.
Ok, also machen wir uns mal an den Checkout von SVN:
git svn clone svn://[server]/testprojekt
GIT legt nun automatisch den Ordner “testprojekt” an, erstellt darin das GIT Repository mit der kompletten SVN-History und kopiert sich anschließend die Base-Revision, also die aktuellste Version des Projekts, in diesen Ordner. Das GIT Repostitory liegt im Unterordner “.git”, welchen es, anders als bei SVN, nur einmal im Hauptordner gibt.
Das Repository steht, nur wird es ja sicherlich trotzdem im SVN hin und wieder neue Versionen von Dateien geben. Wir sollten also ab und zu an ein Update unserer Dateien denken. Das Update führt man einfach direkt im Projektordner, in unserem Fall “/Users/[Benutzername]/Sites/testprojekt”, durch:
git svn rebase
GIT findet nun alle nötigen Daten in seinen Einstellungen, die sich unter “testprojekt/.git” befinden – also auch, wo der SVN Server zu finden ist – und führt ein Update der geänderten Daten durch. GIT verhält sich an dieser Stelle wie ein normaler SVN Client.
So, damit haben wir schonmal den Hauptteil erledigt. Nun kümmern wir uns erstmal um Eclipse, bevor wir dann mal einen Commit ins SVN wagen.
Ich habe mich für das Plugin “eGit” entschieden. Ihr findet es unter eclipse.org als Eclipse Plugin. Nun wird es etwas schmutzig, da ich ehrlich gesagt nicht genau weiß, wie der Checkout von GIT mit dem Plugin funktioniert. Ich habe da echt ne Weile rumprobiert, bin aber nicht zum gewünschten Ergebnis gekommen – auch nicht über direkte Pfadangaben. Vielleicht kann mir ja hier jemand auf die Sprünge helfen.
Durch Zufall hab ich dann aber einen Trick gefunden, das Repo doch ganz leicht zu laden. Im Eclipse importiere ich erstmal “testprojekt” als bestehendes Projekt (geht natürlich nur, wenn das Projekt ein Eclipse Projekt ist – sonst müsst ihr erst eins anlegen!). Anschließend geht ihr auf “Team” –> “Share this projekt” und wählt da GIT aus. Anschließend wird euch direkt präsentiert, dass das Plugin an dieser Stelle bereits ein GIT-Repository gefunden hat, was man mit Finish bestätigt. Anschließend hat man das Projekt inklusive GIT Funktionen im Eclipse.
Ab dieser Stelle könnt ihr nun wie gewohnt commiten, nur das Updaten fällt weg, da GIT ja komplett auf eurer Platte liegt. Falls es in eurem Repository eine neuere Dateiversion geben sollte, klickt einfach mal auf Refresh und sie ist drin.
Nun führt ein paar Änderungen an den Dateien durch und speichert. Ihr seht, dass diese Dateien im Projektbaum mit einem vorgestellten “>” markiert werden. So seht ihr gleich, welche Dateien noch nicht commited sind. Führt nun einen Commit durch, anschließend geht es wieder in die Console.
Mit
git svn dcommit
führt ihr nun einen commit in euer SVN Repository durch. Das Tolle dabei ist, dass alle einzelnen Commits, die ihr in GIT getätigt habt, auch als einzelne Commits ins SVN wandern. Wenn ihr also eine Datei 3x bearbeitet und im Anschluss immer commited, dann werden diese 3 Änderungen auch 3x einzeln ins SVN gepostet. Ihr verliert also keinerlei History-Funktionen.
Bei mir kam es immer wieder vor, das GIT sich beschwerte, dass irgendwas mit dem Repository nicht stimmt bzw. nicht korrekt commited wurde und ich so das dcommit nicht ausführen konnte. In diesem Fall führt
git stash
aus. Damit reinigt ihr das Repository. Wichtig: vorher commiten, sonst sind eure Änderungen weg. “stash” bringt euer Working Directory wieder in Einklang mit der Head-Revision, also dem aktuellen Stand eures Repositorys.
Unter Windows wird der Vorgang wahrscheinlich sehr ähnlich sein, ich hab es mir aber noch nicht angesehen. Die GIT-Kommandos sind auf jeden Fall die gleichen.
Links:
Chaosradio Express 130 – verteilte Versionskontrollsysteme
GIT
SVN
eGit
Will haben!
via Engadget.com