Von OpenStreetMap habe ich wohl vor 3 oder 4 Jahren zum ersten Mal gehört. Mir gefiel die Idee, freie Geodaten zu erfassen um daraus alle möglichen Karten zu generieren. Allerdings war ich damals sehr skeptisch, ob diese riesige Aufgabe umsetzbar wäre.
Ilker Cetinkaya bloggte zu dem Thema und kam zum Schluss, dass Bugtracking heutzutage unnötig sind. „Aber sicher braucht es dies noch!“ war mein erster Gedanke. Ich las darauf hin nochmals seinen Beitrag und dachte ein wenig länger über seine Argumente nach.
Nach dem Upgrade auf Fedora 11 dauerte der Verbindungsaufbau ewig. Vom absenden des ssh-Befehls bis zur Aufforderung zur Passworteingabe dauerte es meistens 50 Sekunden. Vom gleichen Rechner aus dauerte der Aufbau der Verbindung zu einem Debian-Server weniger als eine halbe Sekunde. Erst dachte ich an eine Überlastung des Rechners, da dieser nach dem Start jeweils zahlreiche Programme startet. Aber die Verbindung wurde auch dann nicht schneller aufgebaut, als der Rechner nichts zu tun hatte.
Wer kennt es nicht: ein neues Projekt startet und man darf die neusten Version einer Software einsetzen. So weit so schön. Nur ist die Online-Doku nichts für Einsteiger und die Bücher zum Thema entweder veraltet oder noch nicht erschienen. Was soll man nun machen? Das Buch zur alten Version kaufen oder abwarten? Warten ist meistens nicht möglich - der Einführungstermin steht schon fest. Wäre es nicht toll wenn man die bereits fertig geschriebenen Kapitel des noch nicht erschienenen Buches bekommen könnte?
Beim editieren von Source Code kommt die Formatierung schnell durcheinander. Man hat natürlich die Möglichkeit die von Hand wieder herzustellen. Allerdings ist das mühsam und man verschiebt es auf später. Nach weiteren Änderungen und noch mehr Vorsätzen für später hat man dann etwas, was man erst recht nicht mehr anpassen will.
Dies alles kann man sich ersparen, wenn man die in der IDE eingebauten Funktionen nutzt.
Performance ist an sich ja immer ein Thema. Speziell vor einem Release gewinnt dies aber immer an Wichtigkeit. Und wenn man dann etwas messen soll, misst man häufig Mist. Wieso? Man misst entweder nicht das Richtige, man nutz falsche Werkzeuge oder geht von falschen Annahmen aus.
Für mich sind diese Punkte bei der Performance-Messung wichtig:
"Test Driven - Practical TDD and Acceptance TDD for Java Developers" von Lasse Koskela ist Ende 2007 bei Manning erschienen. Bei Test Driven geht es um die testgetriebene Software-Entwicklung in Java.
Der Debugger von VisualStudio zeigt einem einen Tooltip an, sobald man mit der Maus über eine Variable oder eine Klasse fährt. Je nach dem ist dieser Text mehr oder weniger hilfreich. Man hat zwar immer die Möglichkeit, die einzelnen Felder und verschachtelten Werte durchzuklicken, bis man die gewünschten Werte angezeigt bekommt. Je grösser die Klasse und je mehr Felder diese beinhaltet, desto unübersichtlicher und mühsamer wird es.
„Produktivität ist das Verhältnis zwischen einer Menge nützlicher Arbeit und der dafür benötigten Zeit.“
Letzte Woche kam eine interessante Frage auf: welche Version bekommt man in SVN, wenn man auf ein Tag wechselt, auf dies jemand einen Commit ausführte? Ist es die Version bei der man den Tag erstellte oder die letzte Änderung darin?
