Glorf IT

Kai Kretschmann präsentiert auf seinem IT-Blog diesen wunderbaren Video-Clip, der ein Jahr entstand nachdem der Apple Lisa präsentiert wurde. Das gezeigte Modell hatte schon die damals brandneuen 3,5Zoll-Disketten. Ich kann mich noch gut daran erinnern als wir im Computerraum der Schule vor unseren Apple IIe (mit 48KBytes Hauptspeicher, das "e" stand für den um 16KB größeren Hauptspeicher als die anderen Modelle, ohne Festplatte, aber mit 2 dicken 5,25Zoll Floppies) saßen und von Lisa und später vom Macintosh träumten. Das war damals absolut unglaublich. Wir alle wollten damals mal eine Lisa in echt sehen. Davon eine zu besitzen träumte niemand, das war einfach zu astronomisch teuer. Das Arbeiten mit der Maus, Drag&Drop und Multitasking in dieser Form waren damals wirklich innovativ und völlig unbekannt.

Leider wurde das ja kein Erfolg für Apple. Auch der kleinere und "billigere" Nachfolger Apple Macintosh war zunächst ein Ladenhüter. Er war einfach zu anders. Das war Science-Fiction. Wir alle befürchteten damals Apple würde daran zugrunde gehen…

Jetzt ist es also wissenschaftlich erweisen: kurze E-Mails werden schneller beantwortet. Offenbar geht es nicht nur mir so: Wenn ich eine echt lange Mail bekomme, also länger als eine Bildschirmseite, womöglich noch in kleiner Schrift mit wenig Absätzen, dann mache ich die Mail erst mal wieder zu und kümmere mich später drum, wenn ich etwas Ruhe habe.

So steht es in dem Artikel "Neue Forschung: Kürzere E-Mails machen erfolgreich":

Die erfolgreichsten Mitarbeiter schrieben kurze E-Mails mit einem klaren, einzelnen Thema. Darauf erhielten sie schneller eine Antwort, und damit konnte die Arbeit schneller vorangehen.

Das finde ich ziemlich logisch. Dennoch tendiere ich dazu lieber etwas präziser zu formulieren und werde dann eben langatmig. Notiz an mich selber: zukünftig vorzugsweise kurz und pregnant prägnant. 😉

Na prima, da habe ich doch meinen ersten Trojaner entdeckt. Leider habe ich keine Ahnung wie er auf mein System kam. Da ich in letzter Zeit mit ziemlich vielen Programmen rumexperimentiert habe, ist das nicht so genau zu sagen. Vielleicht sollte ich mir mal die "Software Virtualization Solution" von Altiris ansehen, um Software in einer virtualisierten Umgebung zu testen ohne gleich jedesmal eine VM-Ware zu starten.

Gemeinerweise fand ihn mein Virenscanner nicht, auch auf der Virenscanseite von jotti.org erkannte ihn keiner der 15 als Schädling. Lediglich NOD32 merkte aufgrund der heuristichen Analyse an, dass dies möglicherweise ein Schädling sei.

Immerhin hat McAfee aufgrund meiner Einsendung gleich regiert. Im ersten Durchlauf schrieben die AVERT(tm) Labs, Aylesbury, UK bereits am gleichen Tag:

We have examined the file and didn't see anything suspicious. As an additional test, we tried to run it on a test system and observed no
suspicious behaviour.

If you still believe this is a virus or trojan file, please provide more
information on why you feel this is a suspect file.

Es ging um die Datei "C:\WINDOWS\system32\clipboard.exe". Sie behauptete von sich von Microsoft zu stammen, hatte aber eine ziemlich MS-untypische Versionsnummer, gehörte angeblich zu Windows 2000 (ich habe XP) und sei in "China (VR)" hergestellt worden.
Außerdem lief der Prozess permanent und hatte sich in der Registry eingetragen:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
"clipboard.exe"="C:\\WINDOWS\\system32\\clipboard.exe"


Nach dem Anmelden startete ein Browserfenster und leitete mich auf eine mir unbekannte Webseite (irgendwas unter www.coolsheep.com, aber die Seite konnte wegen eines JS-Fehlers nicht dargestellt werden). Nach dem Austragen aus dem AutoRun war das Verhalten weg.

Nachdem ich Avert das geschrieben hatte, wurde die Datei als "Generic Backdoor.b" klassifiziert und mir eine neue Signaturdatei zur Verfügung gestellt, die den Schädling einwandfrei identifizierte und löschte. Sie kommt mit dem nächsten Update an alle Kunden. Offenbar hatte ich Glück, weil kein weiterer Schaden entstand…

Auf die Schliche kam ich dem Fießling übrigens mit der Werkzeug HijackThis.

Ich kann es schon langsam nicht mehr hören: Jeden Tag trudelt eine neue Nachricht zum Thema "Microsoft und Patente" ein.

Mal geht es darum, dass Herr Balmer behauptet Linux verletze geistiges Eigentum von Microsoft. Mal darum dass Microsoft mit jemandem ein Patent-Stillhalte-Abkommen geschlossen hat, mit dem Microsoft behaupten kann, jemand aus der Open-Source-Szene hätte anerkannt, dass Microsoft viele für Linux wichtige Patente halte und Patente generell richtig und wichtig seien….
Immerhin scheint Microsoft mit Novell als Partner besser zu fahren als mit SCO… 😉

Aber das hat ja auch noch eine andere Seite, die auch nicht verborgen bleibt… Und trotz des schlechten Eindruckes den diese MS-Kampagne auf mich macht, kommt bei mir keine rechte Schadenfreude auf, wenn ich lese, dass Microsoft erneut verurteilt wurde, weil es geistiges Eigentum von anderen missbraucht hat. (Gibt es eigentlich ein Wiki was die ganzen Gerichtsverfahren wegen erwiesenem Abkupferns gegen MS sammelt?)
Für den "armen" Software-Entwickler, der seit 1996 gegen MS klagt, kann ich sogar noch gewisse Sympatien aufbringen. Die Klage gegen die Sprachumschaltung von Koreanisch auf englisch ist für mich nur ein weiterer Beweis für die Sinnlosigkeit Innovationsschädlichkeit von Patenten. Sie haben allenfalls den Sinn Geld aus anderen Firmen herauszuquetschen oder Mitbewerber zu behindern.

Als ich bei tecCHANNEL.de den Artikel "Wer zu spät testet, verschleudert Geld" las, fand ich so viele Dinge wieder. Theoretisch ist ja wohl jedem Software-Entwickler klar, dass Testen nicht nur sinnvoll, sondern auch wichtig ist, aber…

Warum wird trotzdem noch so wenig getestet? Das folgende Statement aus dem Artikel finde ich sehr wahr:

Doch genau darin scheint das Problem zu liegen. "Mit Testen ist kein Blumentopf zu gewinnen, deshalb reißt sich auch niemand um diese Aufgabe", beobachtet Andreas Golze, Director Global Practice für Application Delivery bei Mercury. […] Testen ist da eher ein Störfaktor. Schließlich bedeutet es nur nachzuweisen, dass etwas so funktioniert, wie man es ohnehin haben wollte.

Meine Erfahrung ist, dass es nur wenige Leute gibt, die sich so richtig ins Testen reinhängen. Ich wäre schon froh, wenn alle Entwickler halbwegs vollständige automatisierte (Unit-)Tests gleich mit der Implementierung machen würden. Interessanterweise werden so Dinge wie Dokumentation und Test gerne als erstes auf der Altar des Termindruckes geopfert, um keine Funktionen streichen zu müssen. Das ist aber auch klar: Wenn man vom Ende der Geschichte bewertet wird, dann hält man sich eher an seine Erfahrungen als an die aktuelle Stimmung im Projekt.
Nur wenn die Projektleitung schon mal in so einer Situation beweisen hat, dass eine dokumentierte und ausführlich getestete Funktion wichtiger ist als zwei schlecht dokumentierte und getestete, dann ziehen die Entwickler beim nächsten Mal mit. Und was in der PC-Software in den letzten Jahren wichtiger war, ist ja wohl klar…

In win-insight.de wird beschrieben, wie man laufenden Prozessen eine höhere oder niedrigere Priorität geben kann. Das ist schon nicht schlecht, aber ziemlich unpraktisch, wenn man erst die Anwendung starten muss, dann in den Task-Manager wechseln muss, usw.

Man kann auch beim Start einer Anwendung festlegen, dass die Anwendung eine andere als die Priorität "normal" haben soll. Wenn man dem SQL-Management-Studio zu mehr Saft verhelfen will, dann startet man es einfach so:

start "Fenstertitel" /high "C:\Programme\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\SqlWb.exe"

oder wenn man den Virenscan im Hintergrund mit niedriger Priorität laufen lassen will, dann geht das mit McAfee zum Bleistift so:

start "Virenscan" /low "C:\Programme\Network Associates\VirusScan\scan32.exe" /NoSplash /AutoScan

Tipp: Wenn man die Anwendung über eine Verknüpfung startet, dann in die Eigenschaften dieser Verknüpfung gehen (rechte Maustaste -> Eigenschaften) und dort bei "Ziel" vor den eigentlichen Eintrag einfach Folgendes setzen:

start "xy" /low

PS: Bitte daran denken, dass man keinem Prozess die Priorität "REALTIME" gebe sollte, wenn man nicht ganz genau weiß was man tut. Damit hat man ratzfatz das System lahmgelegt.

Ich liebe Blogs – jeder kann seine Meinung schreiben, im vertretbaren Rahmen aus dem Nähkästchen plaudern und auf die Beiträge anderer reagieren.

Letzte Woche kritisierte beispielsweise Joel Spolsky das neue Windows-Vista Shutdown-Menü. Ich habe es noch nicht in echt gesehen, aber der Screenshot liegt bei: Die Vielfalt ist wirklich unnötig verwirrend.

Drei Tage später greift Moishe Lettvin das Thema in seinem Blog auf. Er war bis vor kurzem Entwickler bei Microsoft (jetzt bei Google) und war mit 8 weiteren Kollegen ein Jahr lang mit dem Thema beschäftigt. Er beschreibt sehr deutlich, wie es sein kann, dass man mit so einem Menü 1 Jahr lang 8 Leute beschäftigt.

But here's how the design process worked: approximately every 4 weeks, at our weekly meeting, our PM would say, "the shell team disagrees with how this looks/feels/works" and/or "the kernel team has decided to include/not include some functionality which lets us/prevents us from doing this particular thing". And then in our weekly meeting we'd spent approximately 90 minutes discussing how our feature – er, menu – should look based on this "new" information. Then at our next weekly meeting we'd spend another 90 minutes arguing about the design, then at the next weekly meeting we'd do the same, and at the next weekly meeting we'd agree on something… just in time to get some other missing piece of information from the shell or kernel team, and start the whole process again.

In dem Blog-Beitrag gibt es so unglaublich viele unglaubliche Dinge, dass ich dringend empfehle auch das Original zu lesen. Hier ein paar Highlights und meine Kommentare dazu:

• Im Team hatten sie einen Mac als Vorbild für eine gute Benutzeroberfläche. Jeder weiß, dass Windows immer wieder den Mac nachmachte, und jeder weiß, dass Apple diesen legendären benutzerfreundlichen Ruf hat, aber dass Microsoft-Mitarbeiter sich so sehr davon inspirieren lassen, finde ich schon krass.
• Die Art des Software-Zusammenbau finde ich interessant. Vom Konzept ist das schon ziemlich schlau: hierarchische Integration zuerst nach oben und dann nach unten. Wenn es sonst keinen Austausch gibt, dann verursacht der mangelnde Informationsfluss natürlich "Reibungsverluste".
  Dagegen haben wir bei uns auch noch kein gutes Mittel gefunden. Immerhin probieren wir an dieser Stelle ab uns an mal etwas aus und haben so auch schon Doppelarbeit vermieden.
• Der Abstimmprozess bei Microsoft wird als so schlecht dargestellt, dass kann ich kaum glauben. Aber es ermutigt mich. Wir verwenden in unserer Firma Reviews, die ich erst in den letzten Jahren schätzen lernte: Sie verursachen unheimlich viel Aufwand, aber bewirken, dass alle beteiligten Personen zur gleichen Zeit mit in die Abstimmung involviert werden. Sie sind für die "Autoren" so aufreibend, dass ich zuerst immer nur genug habe. Damit wird aber sehr wirksam das beschriebene Hin und Her verhindert. Die relevante Bedenken/Probleme/Ideen/Einwände kommen rechtzeitig auf den Tisch und können berücksichtigt werden. Das ist wirklich wertvoll!
  Ich beschreibe demnächst mal wie das bei uns abläuft.

Ich habe jedenfalls den Eindruck, dass Microsoft diesen Kollegen regelrecht vergrault hat…

In letzter Zeit sind ja etliche Firmen ganz schön in den Negativ-Schlagzeilen, weil Produkte floppen oder die Marktlage falsch eingeschätzt wurde. Da fiel mir ein Oktober-Artikel aus heute.de wieder ein. Darin geht es um die Bereitschaft von Unternehmern Fehler zu machen.

Die Konkurrenten zittern, wenn Suchmaschinenfirma Google neue Programme und Dienste auf den Markt wirft. Doch mehr als die Hälfte davon floppt. Man teste eben vieles und übernehme nur, was der Kunde haben wolle, erklärt Marissa Mayer, Ideen-Scout bei Google.

Die Mentalität bei den "etablierten" Firmen scheint mir eher zu sein: "Entweder machen wir es richtig oder gar nicht." Einerseits wird sich gerne mit bewährten Strategien auf das Kerngeschäft konzentriert, andererseits das Handtuch geschmissen, wenn der Unternehmensteil nicht "performt". Das verstehe ich nicht. Die Google-Strategie erscheint mir sinnvoller: Aus einer sicheren Position benachbarte Produkte anbieten, selbst wenn sie zunächst nur die "kleinen" Zielgruppen erreichen und dann ggf. nur das Projekt einstampfen, nicht gleich die ganze Firma. Ich bin sicher, dass Google mit dieser Strategie irgendwann den nächsten Knüller landen wird.

Kann man diese Strategie wirklich nicht auf andere Wirtschaftzweige übertragen?

Im Microsoft TechNet gibt es übrigens eine Seite mit
Best Practices zum SQL-Server, bislang vorwiegend zur Performanceanalyse. Das ist eine Seite mit einer kleinen Sammlung an Links auf

Whitepapers, z.B.:

• Tom Davidsons Klassiker: SQL Server 2005 Performance Tuning using Waits and Queues – Ein Muss für jeder angehenden Tuning-Fachmann
• DBCC SHOWCONTIG Improvements and Comparison between SQL Server 2000 and SQL Server 2005 – Die Fragmentierung einer Tabelle untersuchen

SQL-Code-Snipets, z.B.:

• List Rarely-Used Indexes – Welche Indexe kosten Pflegeaufwand, aber bringen nichts?
• List Recompiled Statements – Damit kann man sich anzeigen lassen, welche Statements erneut kompiliert werden mussten. Gerade wenn man viele "kleine" Statements hat, dann bekommt die für einen Recompile benötigte Zeit starkes Gewicht.
• List Real Time Tempdb Task Usage – Damit kann man sich die aktuelle TempDB-Nutzung ansehen. Besonders nützlich, wenn man das eine ganze Zeit in einer Schleife abfragt und die Ergebnisse speichert.

und noch ein paar andere Dinge.

Insgesamt gesehen ist das schon mal ein Anfang. Mal abwarten wie sich das entwickelt…

Heute wurde ich durch einen Blogeintrag im Sqlservercode-Weblog auf die Datenbank-Option AUTO_UPDATE_STATISTICS_ASYNC aufmerksam. Dort wird aus den Books Online zitiert:

In SQL Server 2005, the database option AUTO_UPDATE_STATISTICS_ASYNC provides asynchronous statistics updating. When this option is set to ON, queries do not wait for the statistics to be updated before compiling. Instead, the out-of-date statistics are put on a queue for updating by a worker thread in a background process. The query and any other concurrent queries compile immediately by using the existing out-of-date statistics. Because there is no delay for updated statistics, query response times are predictable; however, the out-of-date statistics may cause the query optimizer to choose a less-efficient query plan.

Das ist interessant für Datenbanken deren Inhalte sich häufig ändert, z.B. regelmäßig viele Datensätze eingegeben oder gelöscht werden. Ich kann mich durchaus an mehrere Fälle in der Vergangenheit erinnern in denen unregelmäßig die Ausführung von Statements viel länger dauerte als es erklärbar war. Im Nachhinein deutet vieles daraufhin, dass da die Statistiken nicht mehr aktuell waren und vor der Zusammenstellung des Zugriffsplans aktualisiert werden mussten. Das wird mir aber erst jetzt klar.

Statistiken werden für jeden Index angelegt, man kann sie manuell anlegen (auch für indexierte Views) und manchmal werden sie automatisch angelegt, wenn zu wenige Indexes auf der Tabelle liegen. Das Verhalten kann also jeden treffen. Die Option einzuschalten ist aber nur dann sinnvoll, wenn auch ein Zugriffsplan basierend auf veralteten Statistiken noch eine akzeptable Performance bietet. Ich würde vermuten, dass dies bei sinnvoll vergebenen "clustered indexes" meist der Fall ist und die "dicksten" Abfragen den Clustred-Index verwenden. Da muss man aber jeweils genauer hinsehen.

Generell begeistert mich der Gedanke, dass der SQL-Server-2005 diese zeitaufwändige Aktion dann macht, wenn er gerade wenig zu tun hat. Aber logischerweise bringt die Option nur dann einen Vorteil, wenn die (mehrfache) Ausführung eines Statements mit einem "alten" Zugriffsplan immer noch schneller ist als die Aktualisierung der Statistik(en) und die anschließende (mehrfache) Ausführung des Statements.

Das Online-Netzwerk-Lernen.de stellt das eBook "Aktive Lernmethoden" zum kostenlosen Download zur Verfügung. der Preis ist, dass man Ihnen seine E-Mailadresse geben muss, der Link kommt dann per Mail.

Ich finde das Buch bietet einen guter Überblick über das Thema "Wie lerne ich am besten?". Es ist im Methodenteil recht knapp gehalten, dennoch sind die einzelnen Methoden verständlich. Insgesamt sind sehr viele Informationen auf kleinem Raum zusammengestellt. Ich würde das Buch für alle empfehlen, die sich auf eine Prüfung vorbereiten, Schüler oder Student sind.

Übrigens kommen auch recht krasse Ansichten zu Wort:

Und das beste aus der Lernbiologie: Der amerikanische Hirnforscher Gottmann behauptet sogar: "Lernen ist wie Sex. Bei erfolgreichem Lernen werden vom Gehirn Botenstoffe ausgeschüttet, die das körpereigene Belohnungszentrum anregen!"

Auf jedem Stockwerk unserer Firma gibt es ein oder zwei Tee-Küchen. Dort können wir uns (auf eigene Kosten) mit den dort stehenden Kaffeemaschinen Kaffee kochen. OK, und natürlich auch Tee. Dazu stehen auf der langen Arbeitsplatte dicht an dicht jeweils massenweise Kaffeemaschinen, Teekocher und Wassererhitzer, für jedes Team natürlich jeweils eigene Exemplare. Die Firma sponsert sogar für jedes Team eine oder mehrere Warmhaltekannen. Alle paar Jahre kommt ein Elektriker, untersucht die Maschinen auf Gefährdungspotentiale und zieht nötigenfalls welche aus dem Verkehr. Deswegen steht auf jeder Maschine der Name des "Ansprechpartners" aus dem Team, damit klar ist, wer die Bedarfsmeldung für ein Ersatzgerät ausfüllen darf.
Das kenne ich so seit 11 Jahren, (noch) ältere Kollegen sagen, dass sei schon immer so gewesen. Ärger gab es meines Wissens damit noch nicht. Das ist eigentlich schon verwunderlich, denn Kaffee scheint für viele Kollegen die wichtigste Ressource zu sein.

Neuerdings darf das nicht mehr so sein, denn elektrische Geräte dürfen laut einer Verordnung nicht auf brennbaren Unterlagen stehen. Die normalen Küchenarbeitsplatten haben daher vor ein paar Wochen einen Upgrade bekommen. Auf die Arbeitsplatten wurde jeweils mittig eine lange Reihe 40x40cm-Granitplatten geklebt (ergibt vorne und hinten einen 10cm schmalen Rand). OK, es könnte auch billiger Marmor sein, das ist nicht mein Fachgebiet… Darauf stehen die Kaffeemaschinen jetzt. Das sähe ziemlich edel aus, wenn der Rand vorne und hinten nicht so lächerlich wäre… 😉

Ich vermute mal zu unseren Gunsten, dass an diesem Aufwand nicht die firmeninterne Bürokratie schuld war, sondern auf dem Mist von irgendeinem Gesetzgeber gewachsen ist. Jetzt frage ich mich natürlich, warum normale Küchen immer noch mit ganz normalen Arbeitsplatten verkauft werden. Oder ist das eine Verordnung, die nur für Firmen gilt?
Wie es der heilige Murphy bestimmt hat, haben wir uns privat ebenfalls neue Küchenarbeitsplatten angeschafft, kurz vor der Montage in der Firma. Ich habe sogar zu der Zeit sogar noch überlegt, ob wir eine mit Fliesen drauf nehmen. Aber wir wollten dann doch keine Fugen haben.
Jetzt haben wir eine aus massiver Buche. Sie ist recht dick, sieht gediegen aus, ist aber mit Sicherheit nicht feuerfest. Dafür sorgt schon alleine das viele Öl, dass wir drauf gekippt haben…. 🙁