Bei unserem aktuellen Projekt hoogoo.de kann man Scooter selber gestalten. Der erste Kunde hat nach dem Launch fünf Tage auf sich warten lassen, doch am 6 Tag (heute) ging es dann richtig rund. Schon Spannend, was die Leute sich alles einfallen lassen.
Sehr beliebt sind auch Bilder von Kindern, aber die können wir hier natürlich nicht öffentlich zeigen.
Seit geraumer Zeit veröffenlichen wir Software als OpenSource Wir haben das Thema aber immer etwas stiefmütterlich beehandelt.
Das wird jetzt mit github.com/hudora anders. Dort können interessierte alle unsere Entwicklungsschritte bei öffentlichen Projekten einsehen. Zur Zeit sind dies huTools, huImages, hd-munin-plugins, pyJasper, huDjango, huBarcode. Wir wollen in Zukunft auch öfter unsere Software auf http://pypi.python.org/ veröffentlichen, wie die Prozesse dazu genau aussehen sollen, ist noch zu klären.
Warum das ganze?
Der ganz übrweigende Teil der von uns entwickelten Software basiert auf OpenSource Software. Ich (und von Herrn Klein weiss ich das gleiche) wäre nicht annähernd so gut im Programmieren, wie ich bin, wenn ich nicht viele zehntausend Zeilen OpenSource Software, die von anderen Geschrieben wurde, hätte studieren können. Unter diesem Gesichtspunkt ist es einfach eine Frage der Anständigkeit, zur Wissensallmende beizusteuern, wenn man von den Beiträgen anderer so profitiert hat.
Aber wir profitieren auch direkt davon, dass wir unseren Code verbessern. Erfahrung lehrt, dass man sich bei öffentlichem Code mehr Mühe mit der Codequalität und und der Dokumentation macht. Auch ist man dazu gezwungen, dien code generischer und konfigurierbarer zu machen. Hardgecodedt Server-Namen und Passworte gehen bei öffentlichem Code nicht. Das alles ist zwar mehr arbeit, lohnt sich aber auf jeden Fall bei Software, die man noch lange einsetzen will.
Und natürlich kann es aich sein, dass andere unseren Code nehmen, daraus etwas besseres machen und wir direkt davon profitieren können. Das passiert bei OpenSource gelegentlich, aber man sollte sich nicht darauf verlassen.
Natürlich macht es nicht bei aller unserer internen Software sinn, diese zu veröffentlichen. Manche ist nicht zu generalisieren, manche sehen wir als Betriebsgeheimnis an, manche würde es Mittbewerbern zu leicht mache, sich einen Wettbewerbsvorteil zu verschaffen (oder uns einen zu nehmen) und manche Software ist so peinlich (xOvr) das wir uns nicht trauen, diese vorzuzeigen. Aber sehrt viel von unserem Software-Stack ist unproblematisch zu veröffentlichen.
Wir wickeln in der Firma seit Ende 2005 Endverbraucheranfragen über ein Ticketsystem namens “CuRM” ab (siehe hier und hier). Seit Anbeginn des Projekts stand der Wunsch, den Bearbeitern von Kundenanfragen halbautomatisch einen Antwortvorschlag vorzulegen, der z.B. aus unserer FAQ Sammlung generiert wird.
Und heute ist der Tag, an dem ich endlich angefangen habe, dass zu implementieren. Als ersten Schritt wollte ich zu FAQ Einträgen “ähnliche” FAQs herausfinden. Natürlich ohne manuelle Datenpflege.
Wie gehts?
Nach allerlei ‘rumsuchen und dem Studium von einem Duzend Wordpress “Similar Postings” plugins habe ich den TextRank Algorithmus von Mihalcea und Tarau implementiert. Mit diesen kann ich aus dem FAQ-Antwort Text recht zuverlässig Schlüsselworte extrahieren.
Nachdem ich aus allen Antworten die Schlüsselworte extrahiert habe, vergleiche ich jeden FAQ-Eintrag mit jedem anderen. Das geht gut, solange man nur wenig hundert FAQs hat, danach wird es zum Problem.
Ich prüfe:
(((modifizierte Levenshtein Distanz ist in etwa als distance(' '.join(sorted(text.split()))) implementiert, so dass reine Permutationen von worten, sich cniht auf die berechnete Distanz auswirken)))
Das ganze gibt einen “Ähnlichkeitsscore” der angibt, wie ähnlich zwei FAQs sind. Die 5 FAQs mit dem höchsten score werden dann als “Fragen, die Ihnen auch weiterhelfen könnten” zu einem FAQ Eintrag angezeigt.
Klappt erstaunlich gut. Eigentlich tue ich mich ich mit allen AI/NLP Programmierproblemen schwehr, aber wie so oft, am ende ist alles nur Software und tut schon was es soll, wenn man es mit fester Stimme fordert.
Die Funktionalität zum Extrahieren von Schlüsselworten kann man nun natürlich auch für andere Bereiche, Analyse von Kundenanfragen nutzen.
Wir haben heute in der Firma ein – wie ich finde – sehr gelungenes Experiment gemacht:
Eigentlich ist unsere Arbeit in Großen Teilen total unabhängig von dem Ort wo wir sind. natürlich kann man keine Kabel virtuell verlegen, aber Zugriff auf alle Server und Gedöns ist im Grunde auch über das Internet möglich. D.h. im Grunde muss man gar nicht zur Arbeit kommen.
Das stimmt natürlich nicht wirklich: unsere Arbeit besteht zu einem Großen teil aus Arbeit miteinander und das geht einfacher, wenn man beieinander ist. Aber mann muss ja nicht 40 Stunden die Woche beieinander sein.
Da war die Unwetterwarnung für Freitag Nachmittag eine gute Gelegenheit das ganze zu testen. Wir haben gegen Mittag die (VoIP) Telefone nach Hause umgestellt, uns alle auf den Heimweg gemacht uydn von da weiter gearbeitet.
Hat geklappt und uns die vollen Strassen voller Leute mit Sommerreifen erspart.
Derweil starren wir auf das aktuelle Wetter und hoffen auf mehr Schnee.
Die letzten Wochen war es bei uns immer mal wieder Thema, wie man Gabelstapler in einem Lagerhaus lokalisieren könnte.
Das ganze bringt jede menge Probleme mit sich, weil die Umgebung für die eingesetzte Lokalisierungstechnik doch recht rau ist.
Neben Vibrationen, Staub, Temperatur- und Feuchtigkeitsschwankungen sowie der Tendenz aller Einrichtungsgegenstände, die nicht mindestens aus 5 mm Stahlblech gefertigt sind, krumm gefahren zu werden, ist es gar nicht so leicht, etwaige Positionsmarker anzubringen.
Unterschiedliche Regalhöhen:
Wenig zusätzlicher Platz auf Regalträgern:
Unregelmäßige Oberfläche der Regelträger:
Herabhängende Verpackung:
“Freistehende” Lagerplätze:
Blocklager:
Leere Paletten sind einzusammeln
Herunterhängende Folie ist zu entfernen
Leergut ist einzusammeln
Mein Hang zu Modular Space ist Lesern dieses Blogs hinreichen bekannt.
Nach der Somemrpause gibt’s jetzt mehr davon:
In Märchen dreht sich viel darum, dass der, der etwas benennen kann, damit auch macht über das benannte Ding ausübt. Beispielsweise Rumpelstilzchen, das besiegt ist, nachdem sein Name bekannt wurde. Ein gezähmtes Tier binden die Märchenhelden für immer an sich, in dem sie Ihm einen Namen geben.
Mit Namen und Sprache darf man nicht schlampig sein. Wer das ist, verschenkt nicht nur Macht und steht dumm da, sondern erschwert auch Kommunikation. Wer nicht zu benennen weis, wird nie ein Märchenprinz.
Wir sind ständig in einem schöpferischen Prozess und müssen ständig Dinge benennen. Sei es Kopfleuchten, Touble Tickets, Variablen, Kundenprojekte oder Subversion Branches. Das ist jedes mal eine kreative Aufgabe und wie bei so vielen Sachen kann man das üben. Allerdings kommt die Übung nicht von selbst: man kann Dinge auch 10.000 mal immer gleich gut oder schlecht machen, wenn man sich nciht aktiv bemüht, besser darin zu werden.
Dinge zu Benennen ist immer Kommunikation.
Dass bedeutet, wann immer man etwas benennt, kommuniziert man mit anderen Menschen. Was will ich den anderen sagen? Wenn ich zwei Verzeichnise “huShop-4531″ und “hushop-4567″ nenne, was sage ich über die Software in diesen Verzeichnissen? Was sage ich über der Bedeutung, die ich der Tatsache beimesse, dass andere sich für das, was ich da Treibe interessieren könnten? Was sage ich über meine eigene Arbeit?
Wenn ich einen Terahertzpersonenscanner “Nacktscanner” nenne, was sage ich darüber, wie ich zu den Menschen, die dieses Gerät benutzen solle stehe? Wie wichtig ist es mir wohl, was die Nutzer beim Durchschreiten des Geräts denken?
Was sagt mir eine commit message wie “Added shop Revision 3968. Take care!”?
Was sagt ein Ticket Betreff wie “offener Auftrag”? Sind offene Aufträge ein Problem?
Was sage ich mit einer Mail wie “Hallo liebe Kollegen, unser treue Diener Drucker Printy braucht eine neue Trommel – DANKE.”? Danke wofür?
Was sagen Funktionsnamen wie do_the_thing() oder was sagt es über den Autor aus wenn ein Python Docstring zur Funktion add_fiive() lautet “This function adds five”?
All das ist Kommunikation und hat immer mit dem Autor und seinen Lesern zu tun. Und an all dem kann man meiner Meinung in sehr vielen Berufen sehr gut ablesen, wie gut jemand in dem ist, was er macht. Und natürlich, ob er daran arbeitet besser darin zu werden. Wenn jemand konstant Dinge schlampig benennt, dann ist es selten, dass der Rest der Arbeit gut ist.
Softwareentwicklung und Systemadministration sind neben dem Erstellen von “Rechenvorschriften” für Computer zu einem sehr großen Teil Kommunikation. Mit unseren Kunden – d.h. den Nutzern der Systeme – und untereinander. Mit den Leuten, die in 10 Jahren etwas, was wir gebaut haben, debuggen müssen. Mit den Leuten, die auf dem Fundament, was wir gelegt haben, etwas aufbauen sollen. Mit den Leuten, die eine Aussage darüber treffen müssen, ob unser Code dies und jenes kann. Mit den Leuten, die unseren Code lesen um besser programmieren zu lernen.
Jenen Namen, dem wir einem Ding geben ist etwas, der uns und dem Ding lange anhängen wird. Etwas, auf das wir stolz sein können, oder etwas das unser unüberlegtes Dahergetippe dokumentiert.
Donald Knuth hat vor 25 Jahren gut ausgedrückt, wie ein Wechsel der Blickrichtung auf das Programieren zu besseren Programmen führen kann:
Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. (Donald Knuth)
Aber anstatt mehr und mehr Programmieren als Kommunikation aufzufassen, werden wir auch in der klassischen Kommunikation immer schlampiger.
Es mag schwierig sein, klar zu sagen, was etwas ist und was man will, aber das ist kein Grund nicht ständig zu versuchen besser darin zu werden.
