Uni-Bremen » Fb3 » Dominik Menke

Google Wave

Mo., 2. Nov. 2009
Allgemein
2 Kommentare

Habe soeben eine Einladung zur Teilnahme am Closed-Developer-Beta-Programm zu Google Wave bekommen. In etwa einer Woche hat man mir auch meine Zugangsdaten ~~bekommen~~versprochen — ich bin ja mal gespannt

Wie ich daran gekommen bin? Es gibt (neben diesem) ein Formular zur Bewerbung, dessen Link mir aber abhanden gekommen ist, welches unter anderem nach dem selbst gesetzten Ziel fragte. Ich dachte mir — natürlich — dass eine Integration von TeX zum Formelsatz nicht verkehrt sei. Ein Bash-Skript, dass mir aus Formeln Bilder macht, sollte recht einfach in Java umzusetzen sein…

—Dominik

Update: Mittlerweile habe ich meinen Zugang, aber soooo berauschend wir im Video ist das noch nicht… Mir fehlen noch weitere Teilnehmer, eine Wave allein zu unterhalten ist wenig sinnreich

Software-Projekte

Mo., 12. Okt. 2009
Allgemein
Kommentar hinzufügen

Durch Zufall habe ich die SWP-Homepages der letzten Jahre gefunden, die (bis jetzt) nirgends verlinkt sind:

SWP 09/10 — Projekt (noch) unbekannt
SWP 08/09 — »Meeting Manager«
SWP 07/08 — Arbeitspaketverwaltung/Zeiterfassung
SWP 06/07 — Prüfungs- und Lehrveranstaltungsmanager
SWP 05/06 — »Online-Bibliographie«
SWP 04/05 — »Shopping Assistent«

Ich habe aber keine Ahnung, ob das jemandem nutzt. Schön ist es aber allemal mit zu verfolgen, welche Problemstellungen so über die Jahre bearbeitet werden mussten…

LCROSS - Lunar Impact Live Broadcast

09.10.2009, 12:15 Uhr, live bei NASA TV: Einschlag der LRO- und LCROSS-Module zur Bestimmung des Wassergehaltes auf dem Mond.

Video-Feed: 1200 kbps.

~~Hui, ist das aufregend~~

12:20: Hm, dass die Begrüßung des Publikums geskriptet ist, finde ich ja nicht weiter schlimm. Dass aber auch die Begrüßung eines Studiogastes ebenfalls völlig unauffällig vorbereitet wurde wirft ein interessantes Bild auf die Sendung. Und die läuft erst drei Minuten…

12:45: Ein paar Bilder aus dem Stream (alle Bilder © NASA):

12:55: Alle Systeme grün, 20 Minuten bis zum Einschlag.

13:09: 10 Minuten bis zum Einschlag. Die ungefähre Geschwindigkeit beträgt rund 1600 m/s.

13:16: Jetzt sind es noch 14 Minuten bis zum Einschlag. ~~Müssten die nicht recht genau wissen, wie lange das (noch) dauert? Mich schockiert das etwas~~ Offensichtlich kommt das Video bei mir ein paar Minuten später an…

13:24: Nun wirds doch noch spannend, »all systems go, preparing for observing impact«.

13:31: Noch 2 Minuten.

13:33: Noch 1 Minute.

~~13:37:27:~~ Gegen 13:37: LRO ist eingeschlagen. LCROSS folgt in 4 Minuten; die Auswertung der Daten braucht noch einige Stunden. Gegen 15 16 Uhr ist eine Pressekonferenz angesetzt.

So vom Gefühl her muss das auch 1969 gewesen sein. Jetzt bin ich gespannt, ob sich wirklich Wasser oder andere Hydrate in der Staubwolke fanden.

17:09: Die Analyse der ersten Ergebnisse, die auf der PK bekannt gegeben wurden:

es gab definitiv zwei erfolgreiche Einschläge, der LRO-Einschlag wurde durch einen Hitze-Blitz von LCROSS gemessen
es wurde eine Natrium-Wolke gemessen, dessen Herkunft untersucht wird
auf keinem Bild der ebenfalls auf den Krater gerichteten optischen Teleskope konnte bis jetzt einen Staubwolke erkannt werden
die aufgenommenen Spektrallinien vor und nach dem Einschlag unterscheiden sich
es ist noch nicht bekannt, ob Wasser (als kompaktes Eis oder als Hydrat) gemessen wurde
weitere Ergebnisse demnächst auf www.nasa.gov/lcross

Bilderrätsel

Do., 8. Okt. 2009
Allgemein
Kommentar hinzufügen

Na, wer findet den Fehler? (Quelle)

(Klicken, um zu vergrößern)

Dominik

Sprachlos

Diese Idee ist so bescheuert, dass mir glatt die Worte fehlen… Vielleicht Qualitätsjounalismus != Printjournalismus oder sowas. Wobei man ja nie generalisieren darf.

LG,
Dominik

Das IE6-Dabakel

Mi., 23. Sep. 2009
Allgemein
1 Kommentar

Da gibt es die Unternehmen mit zentraler IT-Verwaltung einerseits und (private) Update-Verweigerer auf der anderen Seite - letztere mal mit und mal ohne Kenntnis von Alternativen. Im Resultat kommt dabei heraus, das jeder achte noch mit der inzwischen zehn Jahre alten Version 6 das Internet entdeckt.

Für Webentwickler ist das ein ganz besonderes Ärgernis, jede auf Erfolg ausgerichtete Webseite, ob nun kommerziell oder nicht, in diesem Internet Explorer zum Laufen zu Bringen. Schlüsseltechnologien, wie guter CSS2.1- oder gar CSS3-Support, oder Javascript in fortgeschrittenen Versionen und entsprechenden Möglichkeiten das DOM im AJAX-Kontext zu verändern, fehlen hier. Entsprechende Javascript-Bibliotheken müssen also diese Funktionen nachbilden und wachsen so nochmal deutlich an, Layoutkrücken, hässliche »CSS-Hacks« und ähnliche Workarounds machen letztlich nicht nur die Fehlersuche zu einem Geduldsspiel.

Was also tun?

Viele Optionen gibt es nicht. Brachial sind sowohl die Möglichkeiten einerseits den IE6 gänzlich zu ignorieren (wie ich das hier anfangs auch tun wollte) oder andererseits tief in die Trickkiste zu greifen und mit sehr viel Mühen und Aufwand jedes Detail nachzubilden.

Eine weitere Variante ist die begrenzten IE6-Fähigkeiten so gut es geht zu unterstützen, aber moderne Ansätze ohne oder mit negativer Wirkung im IE6 ebenfalls zu verwenden (Beispiel: voll-transparente PNG32-Bilder, wie hier). Das mag dann im Internet Explorer an einigen Stellen komisch aussehen, aber der Inhalt an sich ist benutzbar. Möglichkeit vier besteht dann darin dem IE ein alternatives Stylesheet und/oder weitere Inhalte auszuliefern. Das Zauberwort hier heißt dann »Conditional Comments«.

Nahezu alle diese Herangehensweisen haben ein Problem: die im Grunde doppelte Arbeit. Abgesehen von purer Ignoranz kann man nicht einfach ein standardkonformes Layout/Skript schreiben und dann überall verwenden.

Von Google stammt nun eine neue Idee: Man tauscht bei Bedarf »einfach« die Rendering- und Interpreter-Engine des Browsers aus, realisiert dies als Plugin für den IE und alles ist gut. Das nennt sich dann Google Chrome Frame und scheint des Problems Lösung zu sein, wenn man so den Meinungen glauben darf:

Google hat etwas gemacht, was einem alten Traum jedes Webdesigners gleichkommt: Die Rendering- und JavaScript-Engine eines Browsers gegen eine andere zu ersetzen. […]

Wenn auch nur 20 Prozent der gezwungenen IE6-Nutzer mittels Chrome Frame Zugang zu modernen Webanwendungen zu erhalten, ist schon viel getan. Jeder einzelne protestierende Arbeitnehmer […] ist hier gefragt, das bei der IT für sich einzufordern. Dies ist also auch ein Aufruf an alle, die sich bisher vergeblich für alternative Browser am Arbeitsplatz abgerackert haben. Nun kann man über das Hintertürchen […] vielleicht was erreichen.

Dem ist nichts mehr hinzuzufügen.

—Dominik

Linktipp

(Mir graust es immer noch »Tipp« zu schreiben…)

Eine sehr Ruby-on-Rails-lastige Sammlung an Tutorials gibt es beim Anbieter virtueller Server Slicehost. Die Anleitungen zeigen einsteigerverständlich, wie z.B. ein Nginx-Thin-Rails-Stack eingerichtet werden kann. Aber auch die Einrichtung verschiedener Datenbanken und eines MTAs wird gezeigt.

Da ist doch der Wurm drin…

So., 20. Sep. 2009
Allgemein
Kommentar hinzufügen

Bis vor Kurzem habe ich mich gefragt, warum ich auf meinem lokalen System beim Starten einer Rails-Applikation diese Meldungen bekomme:

$ ruby script/server
/usr/lib/ruby/1.8/xmlsimple.rb:275: warning: already initialized constant KNOWN_OPTIONS
/usr/lib/ruby/1.8/xmlsimple.rb:280: warning: already initialized constant DEF_KEY_ATTRIBUTES
/usr/lib/ruby/1.8/xmlsimple.rb:281: warning: already initialized constant DEF_ROOT_NAME
/usr/lib/ruby/1.8/xmlsimple.rb:282: warning: already initialized constant DEF_CONTENT_KEY
/usr/lib/ruby/1.8/xmlsimple.rb:283: warning: already initialized constant DEF_XML_DECLARATION
/usr/lib/ruby/1.8/xmlsimple.rb:284: warning: already initialized constant DEF_ANONYMOUS_TAG
/usr/lib/ruby/1.8/xmlsimple.rb:285: warning: already initialized constant DEF_FORCE_ARRAY
/usr/lib/ruby/1.8/xmlsimple.rb:286: warning: already initialized constant DEF_INDENTATION
/usr/lib/ruby/1.8/xmlsimple.rb:287: warning: already initialized constant DEF_KEY_TO_SYMBOL 
...

Die Suche mit Google hat nicht wirklich geholfen, da die gefundenen Problemlösungen darauf abzielten, fehlerhafte Symlinks und somit Inklusionsprobleme zu beheben. Diese Hinweise und Anleitungen haben mir allerdings nicht geholfen.

Interessant ist in diesem Zusammenhang auch, dass ein Server in einer virtuellen Maschine dieses Verhalten nicht zeigt - obwohl es bis auf die fehlende Desktopumgebung ein nahezu identisches System ist.

Durch Zufall (lies: stumpfes Probieren) habe ich dann herausgefunden, dass

$ sudo apt-get install rails

und

$ sudo gem install rails

unterschiedliche Auswirkungen haben: Nur bei der Rails-Installation über die Paketverwaltung treten die obigen Fehler auf… Der entscheidende Hinweis gab mir übrigens ein Artikel über die konkurrierenden Debian-Tools apt-get und aptitude. Nein, mein Hirn funktioniert nicht logisch

Dominik

Programmierw{ahr|eis}heiten

So., 13. Sep. 2009
Allgemein
Kommentar hinzufügen

Mein Mantra für das Hauptstudiumsprojekt:

Wenn es kompiliert, funktioniert es,
Wenn es kompiliert, ist es korrekt.
Wenn es läuft, hat es keine Fehler.
Wenn es keine sofort offensichtlichen Bugs hat, ist es perfekt.
Wenn sich ein Bug nicht zeigt, existiert er nicht.
Wenn es so aussieht, als ob es funktioniert, funktioniert es.
Etwas richtig zu machen ist leicht. Nur Fehler zu vermeiden erfordert ein bisschen Konzentration.
Je kürzer der Code, desto schneller das Programm.
Es ist offensichtlich, wie man optimiert.
Programmierer machen keine Fehler.
Laufzeitfehler treten nicht auf.
Benutzer machen keine Fehler.
Ich mache keine Fehler.
Fehler jeglicher Art sind selten.
Fehlerbehandlung kann in Version 2 eingebaut werden.
Es ist OK, bei fehlerhafter Eingabe abzustürzen.
Es ist OK, auf fehlerhafte Eingaben mit fehlerhaften Ausgaben zu reagieren.
Wahrscheinlich ist es nicht nützlich.
Der Welt eine VAX. Oder, dieser Tage, eine MS-DOS-Box.
Die Länge der Funktionsliste ist wichtig.
Geschwindigkeit ist gut, Funktionen sind besser.
Langsamkeit kann durch Hardware ausgeglichen werden.
Je größer ein Programm ist, desto besser ist es.
Willkürliche Änderungen am Programm beheben Bugs.
Das Testen dauert nicht lange.
Bugs zu finden ist leicht. Bugs zu beheben ist trivial.
Bugfixes brauchen nicht getestet werden.
Kleine Änderungen jeder Art brauchen nicht getestet zu werden.
Die erste Annäherung, Idee oder Version zu einem gegebenem Problem ist die Beste.
Auch 1% Gewinn ist tatsächlich ein verdammt guter Schnitt.
Code ist selbsterklärend. Kommentare sind überflüssig.
Kommentare sind an andere Leute gerichtet, nicht für den Autor des Codes.
Undokumentierte Funktionen sind lustig und nütlich.
Es kann immer in der nächsten Version gefixt werden.
Überraschte Benutzer sind glückliche Benutzer.
Eine Demonstration vor dem Kunden ist die beste Debugging-Methode.