About May 2009

This page contains all entries posted to /blog/wvk in May 2009. They are listed from oldest to newest.

April 2009 is the previous archive.

June 2009 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.31

« April 2009 | Main | June 2009 »

May 2009 Archives

May 5, 2009

Petition gegen Stoppschilder im Internet

Da surft man unschuldig im WWW und jede drite Seite, die man besucht, wurd durch ein großes STOPP-Schild gesperrt. Die IP-Adresse und diverse weitere Daten landen automatisch auf einer schwarzen Liste beim BKA und man muss im ständigen glauben leben, als Kinderschänder oder politischer Störer durchzugehen. Fiktion? Bald nicht mehr. "Da oben" im Bundestag überlegt man sich eine gesetzliche Grundlage für solche Zensurmaßnahmen.

Jeder sei hiermit aufgerufen, die entsprechenden Petition hiergegen mitzuzeichnen: https://epetitionen.bundestag.de/index.php?action=petition;sa=details;petition=3860.

Die eigene Freiheit wird es einem danken.

Nachtrag: man sieht wie kompetend die Onlineplattform des Bundestags an der Stelle implementiert ist: bei der unglaublichen Zahl von 2 Zeichnungen pro Sekunde arbeiten die Server am Anschlag, so dass noch nicht einmal Captchas angezeigt werden. Zwei Reloads waren nötig um mich anmelden zu können:

May 7, 2009

Buttons oder Links?

vs. Delete

Wenn wir alle vorgeben, das Prinzip von REST verstanden zu haben, warum taucht dann immer wieder die Frage auf, warum (besonders zu Zeiten von Javascript, Ajax und Web 2.0) Links als Verweise auf Aktionen ("lösche Blogeintrag", "sende Formular ab"...) so schlimm seien.

Dabei ist es doch nur eine Hilfe für den Benutzer UND den Entwickler:

  • Links kann man (noch!) ohne Gefahr zu laufen, unerwünschte Nebeneffekte zu erzeugen, folgen. In REST-Sprech: Links verweisen auf Repräsentationen von Ressourcen.
  • Buttons verweisen auf Aktionen, die per definitionem (?) Nebeneffekte aufweisen. In REST-Sprech: Ihre Betätigung leitet Veränderungen an Ressourcen ein.

Will ich einem Benutzer also zeigen, was er sich alles ansehen kann, so biete ich ihm eine Liste von Links an. Will ich ihm hingegen die Möglichkeiten zur Veränderung der dargestellten Ressource(n) anbieten, so biete ich ihm eine Sammlung an Buttons.

Dieses Prinzip konsequent angewendet nimmt dem Entwickler m.E. sowohl im UI-Design als auch bei der Umsetzung einer RESTful Webanwendung (Denk-)Arbeit ab. Dem Benutzer der Anwendung macht es die Interpretation der UI ebenfalls erheblich leichter.

Was die Implementierung selber angeht, also ob Buttons nun Formulare abschicken oder ob die Aktionen via JavaScript eingeleitet werden, ist bei dieser Betrachtung erst einmal unerheblich. Ersteres ist der Accessibility von Webanweniungen natürlich bedeutend zuträglicher, zweiteres ist für "flashy" Web 2.0-Anwendungen wohl das Mittel der Wahl. Den Königsweg zu beschreiten und die Formulare per "unobtrusive Javascript" nach dem Laden der HTML-Seite zu verändern, um sie durch Ajax-getriebenes Verhalten zu ersetzen, ist aber auch kein bedeutender Mehraufwand (der sich aber auszahlt).

Leider wird o.g. Verhalten durch gewisse Standardmethoden in Ruby on Rails nicht unbedingt gefördert: link_to_remote setzt per default einen POST-Request ab, link_to_function existiert und button_to_remote existiert erst seit Rails 2.0 oder 2.1.

Sieht das jemand anders? Was sind dafür die Gründe? Diskussionsbeiträge sind willkommen!

Anmerkungen zu Michaels Kommentar (Danke dafür!): Ich gebe dier zu 100% recht, dass einen die richtige technische Lösung nicht davon entbindet, das Interface-Design derart zu gestalten, dass der Benutzer klar sieht wo er ohne Nachzudenken hinklicken darf und wo Vorsicht angebracht ist. Jedoch führt meines Erachtens die o.g. Regel, konsequent umgesetzt, automatisch zu besserem Interfacedesign: einfach nur deswegen, weil man eine einfache Regel umsetzt, an die sich der Benutzer gewöhnen kann. Siehe dazu auch die immer wieder geführte Diskussion, ob in einem Dialog der mit einem [OK] und einem [Abbrechen]-Button [OK] links oder rechts von [Abbrechen] angebracht werden sollte: es spielt keine Rolle, Hauptsache man wendet ein einziges Schema konsequent an.

Ich behaupte jedenfalls, dass es keinem Entwickler weh tut, konsequent Buttons für Aktionen und Links für "Ansichten" zu verwenden. Spätestens seit CSS 2.0 lassen sich beide ohnehin beliebig stylen. Und dann gibt's ja noch die Textbrowser... (nein, die sind beileibe nicht tot ;-))

May 15, 2009

Neue USV

Langsam füllt sich der Serverschrank: Heute um 11:20 MESZ wurde die vorgestern bestellte neue USV geliefert. Es handelt sich dabei um ein 2U-1500VA-Modell von APC (SC1500I) mit RS232-Anschluss zur Überwachung, 4 Last-Ausgängen sowie je einen RJ11- und RJ42-Ein- und Ausgang für Netzwerk-Überspannungsschutz.

Wider meiner schlimmsten Befürchung ist der eingebaute Lüfter nur dann in Betrieb, wenn die Kiste wirklich warm wird -- bislang also noch nicht. Mit der vierfachen Kapazität und dreifachen Leistung der bisherigen USV können nun endlich alle angeschlossenen Rechner gleichzeitig betrieben werden, die Überbrückungszeit dürfte dabei rund 30 Minuten betragen.

Das beigelegte Zubehör kann sich sehen lassen: neben zweier Anschlusskabel lag ein RS232/USB-Konverter, Montagewinkel für alle möglichen Rackmonunt-Variationen, Käfigmuttern und (unerwartet und sehr sympathisch) ein loser C14-Stecker. Die mitgelieferte Software ist zwar nur für SuSE und RH- Linuxe ausgelegt, aber dafür hat Debian ja seinen eigenen apcupsd.

So, jetzt dreht mir den Saft ab! ;)

Nachtrag: Wie zu erwarten war, funktionierte die standard-Konfiguration für apcupsd nicht auf Anhieb, was auf den USB-nach-RS232-Konverter zurückzuführen war.

Hier meine Einstellungen, die den erhofften Erfolg brachten:

modprobe usbserial pl2303

in /etc/apcupsd/apcupsd.conf:

UPSCABLE smart # NICHT usb
UPSTYPE apcsmart # ebenfalls NICHT usb
DEVICE /dev/ttyUSB0

Nach einem Neustart von apcupsd erschien keine Fehlermeldung mehr und beim Ziehen des Netzsteckers erschien ganz selbstverständlich ein 'Power Failure' und 'Running on UPS Batteries' in /var/log/apcupsd.events. Damit einher gehend wurde eine entsprechende Broadcast-Nachricht übers Netz geschickt.

/me wartet nun auf ein schweres Unwetter

May 26, 2009

Live von der RailsWayCon Berlin

Nach einem frühen aber entspannten Flug nach Berlin gibt's jetzt im Laufe des Tages immer mal das eine oder andere Bild von der RailsWayCon im BCC am Alexanderplatz. Natürlich ist die innoQ mit einigen Rails-Spezialisten vor Ort vertreten:

Raum und Zeit für Diskussionen mit den "üblichen Verdächtigen":

Einen sowohl abgedrehten als auch außerordentlich kompetenten Vortrag über Ola Binis neueste Programmiersprachenkreation namens "Ioke" gab's vom Meister persönlich:

Mehr gibt's später!