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.
.Beim Bau des “aquafun” wurde die Brunnenkopfabdichtung entfernt. Diese Abrlichtung diente Zum Schulz von Eindringen von Oberflächenwasser in den Grundwasserleiter. Damit stand der Brunnenrohr über Jahre hinweg offen, so dass Oberflächenwasser und Wasseer aus dem Schwimmbecken über den Brunnen in den Grundwasserleiter eindringen konnte. (Sitzungsprotokoll eines Radevormwalder Ausschusses)
Beunruhigend.
Dies ist kein PR Blog und soll auch keins werden. An vielen stellen haben viele Leute viel klug klingendes zum Thema geschrieben. Hier Eckpunkte meiner Gedanken zum Thema.
Gehen wir von einer starken, aber nicht überwältigend präsenten Marke mit ein paar Millionen Kundenkontakten pro Jahr. Ein Beispiel wäre Krüger, die Firma mit den Brausetabletten.
Eine Marke bloggt oder twittert (wird im weiteren gleichgesetzt) um den Wert der Marke zu steigern. Ziel ist es, dass die Öffentlichkeit positive Werte, Erlebnisse und Gefühle mit der Marke verbindet.
Ein Marken-Twitterer ist nicht dazu da, zu unterhalten, zu schockieren, aufzurütteln, die Wahrheit zu verbreiten oder die Konkurrenz schlecht zu machen. Er ist nicht mal dazu da, Menschen davon zu überzeugen Produkte der Marke zu kaufen. Viel mehr geht es darum, die Menschen davon zu überzeugen, das die Marke eine gute Wahl ist, wenn eine entsprechende Kaufentscheidung ansteht.
Das hat ein paar unmittelbare Folgen:
Ich hoffe, das klar wird, dass es nicht darum gehen kann, in das Lalaland abzutauchen, wo alles bunt und schön ist oder einen Propagandasender stalinistischer Prägung zu betreiben. Aber gleichzeitig sollte ein Marken Titterer schon versuchen für möglichst beriete Kreise akzeptabel zu sein.
Eigentlich cniht verwunderlich, aber dann doch überraschend: Wenn man Deutschland danach einfärbt, wie viele unserer Artikel jeder Deutsche hat, dann gibt es sowas wie Kornkreise:
In den Hochverdichteten Innenstädten werden ehr weniger Sportartikel verkauft, im Umland hingegen, wo mehr Leute einen Garten oder das Waldstück um die Ecke haben, sind es mehr.
Die Grafiken wurde mit pyGeoDb erstellt, nachdem ich von @johl eine Inspiration zum Thema Business Intelligence mit Karten und Postleitzahlen bekommen hatte.
Seit etwa 10 Jahren setzen wir Subversion zur Versionsverwaltung unserer Software ein.
Vor einigen Tagen sind wir aufGit umgestiegen. Was man schon auf jeden Fall sagne kann, ist dass wir damit die Komplexität unserer Entwicklung schöner grafisch darstellen kann ;-)
Im Herbst musste ich – ganz überraschend – feststellen, dass unsere IT mit immer mehr Leuten immer weniger geschafft bekam. In manche Probleme muss man vielleicht selber machen, auch wenn man sehenden Auges hineinläuft.
Also steht eine grosse Entschlackung an. Wir machen nur noch selber was a) andere nicht können oder b) andere nur deutlich teuerer und/oder schlechter als wir können.
Das läuft den Geek instinkten sehr zuwieder. Ist der Service, den man da Zukauft nicht überteuert? Wie ist der Integrationsaufwand? Hat man so was nicht schneller Selbstprogrammiert, als es dauert, die Dokumentation des Dienstes zu lesen und deren APIs zu debuggen? Wird man nicht unnötig abhängig von dem Dienstleister, wenn es mal nicht so läuft, wie gedacht?
Die Antwort ist in den meisten Fällen: Nein! Denn bei den Diensten die man zukauft kauft man ja nicht nur die Entwicklung, sondern auch die Dokumentation, den Serverbetrieb, den Speicherplatz, die Backups und den Support. Wenn man das alles Selber machen will, verschlingt das in Summe doch erhebliche Personal-Ressourcen. Und Personal ist in vielerlei Hinsicht teuer: Mehr Leute kosten mehr Gehalt, das ist offensichtlich, aber eigentlich gar nciht so interessant. Mehr (gute) Leute zu finden ist sehr teuer. Mehr Büros sind sehr teuer. Mehr Accouns, Server, Rechner, Lizenzen, Switchports, Backups, Viren, Konfigurationen, Schreibtische, Parkplätze, Plätze auf der Weihnachtsfeier, Sitze im Besprechungsraum, Gradrobenhaken, Klos, Urlaube, Geburtstage, Krankentage, Befindlichkeiten, Liebeskummer, Personalgespräche, Lohnpfändungen und Personalfluktuation bedeuten alle erheblichen Aufwand. Aber am schlimmsten ist: mehr Leute bedeuten mehr Managment, mehr Kommunikationsverluste, mehr Missverständnisse und alles in allem viel mehr Energie, die in Dinge investiert werden müssen, die nicht dem Kunden nutzen.
Neben allen finanziellen Betrachtungen, bedeutet das vor allem: mit mehr Leuten verbringt man weniger Zeit damit, das zu tun, was das Unternehmen eigentlich tun soll.
Als ist es vielleicht nicht so gut, die IT-Abteilung stetig wachsen zu lassen.
Da man in den letzten Jahren immer mehr Aufgaben zukaufen kann, gibt es einige Beispiele von hochfokussierten Unternehmen, bei denen eine Hand voll Leute, sehr vielen Kunden ein sehr gutes Produkt anbieten. 37signals, github und besonders Plenty of Fish sind ein paar Beispiele für diesen Ansatz.
Ein weiterer Punkt ist, das man sich mit den unzulänglichkeiten von zugekauften Projekten viel besser abfinden kann. Bei selbstgeschriebenen Projekten, hat man immer im Kopf, dass man “dass mal ordenlich machen” und dieses oder jenes Feature noch zufügen muss “wenn mal Zeit ist”.
Mit Basecamp haben wir seit Jahren Erfahrung mit gehosteten Applikationen. Vor geraumer Zeit sind wir auch von unserer eigenen Asterisk Lösung auf eine fremd gewartete VoIP Telefonanlage umgestiegen. Also: Weg mit dem, was weg kann!
Erster Schritt war die Nutzung von Shopify für einige Sparten-Webshops. Plötzlich musste das eCommerce Team nicht mehr warten, bis die Programmierer aus dem Quark kamen und die Programmierer hatten nicht dauernd Feature Wünsche aus der eCommerce Ecke am Bein. Unterdessen importiert ein kleines Skript die Shopify Aufträge in unserer eigenes Fullfillment Backend.
Sehr gut lief auch der Wechsel von selbstgehosteten Zimbra-Mailserver zu Google Apps. Bei Zimbra hat sich nach der Übernahme durch Yahoo recht wenig getan und wir wollten zum einen mehr Features, zum anderen ist Backup und Betireb von der sehr grossen Hardware, auf der Zimbra lief schon eine Sache für sich. Ausserdem bereitete das Thema Spamfilter erhebliche Mühe. Dauernd sollten wir nach irgendwelchen abhanden gekommenden Mails verhanden. Das hat jetzt ein Ende. “Fragen Sie doch mal bei Google”.
Unser eigenes Subversion/Trac Setup war fürchterlich langsam. Wir sind von Subversion, auf GIT gewechselt, was sozusagen jede Entwicklermaschine zum Backup-Server macht. Die server-Dienstleistung kaufen wir bei Github ein.
Das macht es uns auch einfacher, unsere Open-Source software zu veröffentlichen. Git macht Branching sehr viel einfacher und GitHub hat ein riesiges Ökosystem aus Tools und APIs. Das war der ausschlaggebende Grund nicht (Mercurial und BitBucket zu nutzen).
Gleichzeitig kann http://github.com/search unsere Gonzui Programmcodesuche ersetzen.
FogBUGZ mit seinen blöden PHP binary only modulen hatten wir schon im Frühjahr abgeschafft und durch eine Kombination aus jutda-helpdesk und Trac ersetzt. Das war aber mehr recht als schlecht. Trac war langsam und Jutda Helpdesk war nciht grade, was man ein “polished Product” nennt.
Jetzt nutzen wir Tender für den internen Support und für die interne Dokumentation.
Für das Bug-Tracking udn die Software-Entwicklung nutzen wir Lighthouse. Das ist sehr schön mit GitHub und Tender zu integrieren.
Die Hoffnung bei der Trennung von Support und Entwicklung ist auch, dass wir nicht immer durch Alltagswehwechen (”druckt nicht”) vom eigentlichen Entwickeln abgehalten werden.
Unsere interne reviewboard installation ersetzen wir durch how’s my code? Beide Applikationen machen nicht genau das gleiche, aber how’s my code ist schön mit Github integriert und macht viel mehr Spass zu benutzen.
Diverse kleine Applikationen haben wir durch das Wufoo Formularsystem abgelöst.
Diverse Fehler Melde- und Sammelskripte ersetzen wir durch Hoptoad.
Spezialisierte Hardware, wie unseren selbstgebauten Terminals zum Einsatz auf Gabelstaplern, inklusive selbstentwickelter (Lua) Software, ersetzen wir stück für Stück durch standartproduckte, z.B. iPod Touch mit Webapplikation.
Unsere LDAP basierte Login-Infrastruktur wersetzen wir durch Single-Sign-On mit Google Apps. (Z.B. so.)
Unser externes Wiki wandert zu GitHub.
Bei den Servern verschieben wir diverse komplexe Speicher-System zu Amazon S3. Anstatt eine CouchDB mit 50 GB zu managen, lagern wir einen Teil der Daten bei Amazon und haben nur noch 45 MB in der CouchDB zu verarbeiten – für die Replikation und Backups eine unschätzbare Erleichterung. Auch Backups können bei Amazon S3 bequem untergebracht werden.
Statt Serverüberwachung mit Nagios, lassen wir das durch Pingdom erledigen.
Auch bei den Servern kaufen wir mehr zu. Klassisch hatten wir immer Kopfschmerzen mit dem Betrieb von PHP-Webservern. Nun mieten wir per Infrastructure as a Service einfach einen vorkonfigurierten server mit LAMP-Stack und installieren darauf nur noch die eigentlichen Applikationen, die wir nutzen wollen.
Die Administration der Server selbst kann mit Anbietern wie Rightscale & Co voll automatisiert werden.
All das sollte uns von sehr vielen kleinen Baustellen entlasten und dazu führen, das wir uns im Support ganz darauf konzentrieren können, unseren internen Nutzern weiterzuhelfen und den effizienten Betrieb des Warenwirtschaftssystems sicherzustellen. In der Entwicklung können wir uns darauf fokussieren, Lösungen zu erarbeiten, die das Unternehmen nach vorne bringen und nicht ständig das Rad neu zu erfinden, nur weil uns der Farbton der am Markt erhältlichen Räder nicht passt.
Seit etwa 15 Monaten betreibe ich eine Wetterstation in Radevormwald und inzwischen kann ich das erste komplette Jahr auswerten:
Die Monate April-September waren frostfrei. Im Januar und Dezember war es knackig kalt, jeweils mit Tiefstemperaturen unter -15 °C. Der Rekord waren -15.9 °C am 2009-12-19. Da die Messung bei uns auf dem Dach erfolgt, kann man vermutlich 1-2 Grad zusätzlich für die Wärmeabstrahlung des Gebäudes abziehen. D.h. es war vermutlich -18 °C “auf dem “freien Feld”.
Mein Regenmesser war mehrvach veralgt, verstopft oder verfrohren, so dass ich den Werten nicht so ganz traue.
Aber ein trockender Juli ist durchaus, was ich auch beobachtet hab. Im Febuar gab es angeblich einen Tag mit 1000 mm/h Niederschlag, das fällt mir dann doch schwer zu glauben …
Interessant, dass es im September tage mit deutlich mehr Niederschlag, als in den Folgemonaten gegeben hat, aber die Gesammtmenge Niederschlag ehr gering war.
Wir liegen relativ windgeschützt und der Windmesser ist nicht and der höcsten Stelle des Hauses. Deshalb wundert es nicht, dass wir im Schnitt unter 5 km/h windgeschwindigkeit sehen. Interessanter finde ich, dass wir auch bei den Böhen relativ wenig Veränderung sehen. Das mag auch an der geschützten LAge liegen.
Der Wind kam überwiegend aus süd-westlicher Richtung. Interessant ist, dass die Bühen meisstens aus den anderen Richtungen kamen. Mag an der Lage liegen.
Nun zur Frage, welche die Anschaffung einer Wetterstation motiviert hat: Lohnt sich eine Solaranlage? In den Monaten April-August haben wir im Schnitt etwa 200 W/m² Sonneneinstrahlunbg gehabt. Bei 10% Wirkungsgrad von Solaramlagen nicht grade berauschend.
Unerwarted finde ich, dass das UV/Sonnenbrand Risiko im September mit Abstand am schlimmsten war.
Und? War es ein gutes Jahr?
Ich finde schon. Ich bin viele Tage in der Sonne spazieren gegangen.Wir hatten etwa 26 Sommertage (Temperatur > 25 °C) und nur einen unangenehm heissen tag (Temperatur > 30 °C).
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.
Ich habe 2007 bei der Einführung von Zimbra in der Firma versprochen, dass man “nie wieder Mail löschen” müsste. Das hat bei einigen Usern dazu geführt, dass einige Heavy User Inzwischen die 50 GB Marke Durchbrochen haben.
Für diese User ist E-Mail das zentrale Archivsystem. Wenn wir jetzt aber auf eine anderes Mailsystem, wie Google Apps umsteigen, wo wir “nur” 25 GB Mail pro user speichern können, haben wir ein Problem.
Bei näherer Betrachtung stellt sich heraus, dass die User mit sehr vielen Mails, relativ wenig Speicher (2 GB oder so) verbrauchen. Die User, die so viel Speicher verwenden sind die, die viele Attatchments haben.
Ein alter Plan von mir (noch aus Exchange Zeiten) war es, einfach die Attatchments von den Mails zu entfernen. Die Mails selber kann man sogar auf dem Server lassen und das Attatchment durch einen Link, wo die Datei jetzt herunter geladen werden kann, ersetzen.
Ich hab das mal bei Rent-A-Coder ausgeschrieben:
We need an Python Command Line Application which connects to an IMAP4 server and scans all messages (in all subfolders) of a certain account. If the messages are older than a certain date and have Attatchments bigger than a certain size the attatchmens should be extracted from the Message.
In addition there should be an option to remove the attatchment from the message (but keep the message) on the server (to save space on the server).
Output Should be put in CouchDB (see http://code.google.com/p/couchdb-python/#) where you should put To:, From:, Date:, Subject, In-Reply-to, References and Message-Id in the document. The Attatchment should be added as couchdb Attatchment conserving the mime type and file name.Command line invokation might look like this:
remove-attachments --server=myserver.example.com # IMAP hostname --user=username # IMAP user --password=pass # IMAP password --couchdb=http://localhost:5984/maildb # save to couchdb running here --mindate=2009-03-01 # only check messages send befor this date --minsize=1500 # only check messages bigger than 1500 KB --remove # remove attatchmentsIf an Attatchment is removed instead of it there should be put a note in the message that an attatchment has been removed.
Since we will have extremely big (> 50GB) Mail Folders the tool must be able be run several times on the same account without generation duplicates in CouchDB.
Things to keep in Mind when writing code for me:
* Follow PEP 8, verify with pep8.py
* Follow PEP 257 for docstrings. Always use Docstrings.
* No tabs. Not anywhere. Always indent with 4 spaces.
* Wrap at Column 109
* Use pylint aim for a score of at least 8.
* Add a Header to each file stating that the file is utf-8 encoded and add creation date and your name.
* Write doctests where possible. Always write unittests. Aim for a test coverage of at least 80%
* Code should be targeted at Python 2.6 on FreeBSD/Linux
* if you need a Javascript Library, use jQuery 1.3.x
* Make your code Unicode clean. Suggested Test-Data: Iñtërnâtiônàlîzætiøñ
* Avoid non-native Python extensions where possible
* add a reqirements.txt file for use with pip and a setuo.py for the use with distutils
* Add CHANGES and README file with appropriate content. Target Audicnce are experienced developers and administrators.
* Add a Makefile with the targets test, coverage, check (pylint, pep8), install
* Webpages should be plain white HTML pages containing the needed forms/UI unless otherwise stated
* Use PostgreSQL and SQLite. If you prefer you can use CouchDB instead.
* Use OpenSource Libraries where they are available. If you copy OpenSource code please mark it clearly and mention the License of the the included code.
* Copyright of the Code written by you for the project will be assigned to us. We might OpenSource the code if we consider it of general interest.
* During development you will not get access to our servers, accounts, resources. Installation will be handled by us according to the documentation we provided.
* Classes/Variables which reference Objects specific to our ERP/our Industry/german trade should be in german as technical terms. Generic Objects should be named in english: Lieferscheinnummer, Kundenauftragsnumer, Rechnung but TransportEndpoint and DataStore. This line is very blurry. Comments in the code should be in english or german.
~/.pylintrc:
[FORMAT] max-line-length=110