Tag 272/2016: Never change a running system

Auch:

  • if it ain’t broke, don’t fix it
  • leave well enough alone

Never change a running system gehört zu den großen Weisheiten des systemadministrativen Berufswesens. Aber je nachdem, in welchem Zustand man sich gerade befindet, bzw., passiert es dann eben doch, dass man das laufende System verändert.

Und schon pustet man ein Kundenprojekt, das sich gerade in einer wichtigen Phase befindet, für eine halbe Stunde aus dem Internet. Ein trivialer Mausklick bringt Bugs und schlechte Kommunikation des Providers zum Vorschein, aber tröstlich ist es natürlich trotzdem nicht.

Notiz an mich: Vielleicht den Spruch mit Henna-Farben auf den Unterarm notieren.

Tag 270/2016: Links für 12 Wochen Urlaub

http://riemann.io/
Aggregation von Events

http://socket.io/
Bidirektionale ereignisbasierte Echtzeitkommunikation

http://speed.pypy.org/
Eine Implementation von CPython

https://falconframework.org/
Schnelles, minimalistisches Python-Framework

http://openresty.org/download/agentzh-nginx-tutorials-en.html

 

Tag 269/2016: Die heutigen Rutschen sind langsam

Wer hin und wieder eine Rutsche benutzt, um von einem höheren zu einem niedrigeren Punkt zu gelangen, hat es bestimmt schon bemerkt: Seit einiger Zeit gibt es statt Geschwindigkeitsrausch nur noch ein stockendes, schleppendes Erlebnis.

Ist es vielleicht eine EU-Norm, die vorgibt, dass Rutschen nur noch zum Betrachten da sein sollen? Oder wurde das Bondern zu teuer? Oder wollte man ein Material, das robuster gegen Streusalz ist und hat alle anderen physikalischen Eigenschaften hintan gestellt?

Probiert es bei der nächsten Gelegenheit mal aus. Und sollte wider Erwarten eine fantastische Highspeed-Rutsche dabei sein, bitte genauen Standort in die Kommentare. Danke.

Tag 268/2016: Die magischen Zehn

Heute auf dem Trimm-dich-Pfad (ein Rundkurs, auf dem sich etwa alle 200 Meter ein einfaches und robustes Turngerät befindet) hatte ich die Gelegenheit, Mitbrüder und Mitschwestern bei Eigengewichtübungen zu beobachten. Insbesondere bei den Klimmzügen.

Laut Wikipedia beteiligen sich die folgenden Muskeln an den Klimmzügen:

  • musculus latissimus dorsi (breitester Rückenmuskel)
  • musculus teres major (großer runder Muskel)
  • musculus pectoralis major (Größerer Brustmuskel)
  • musculus pectoralis minor (Kleiner Brustmuskel)
  • musculus biceps brachii (zweiköpfiger Muskel des Armes)
  • musculus brachialis (Oberarmmuskel)
  • musculus trapezius (Kapuzenmuskel)
  • musculus triceps brachii (dreiköpfiger Muskel des Armes)
  • musculus brachioradialis (Oberarmspeichenmuskel)

Das ist eine ganze Menge. Einfache Übung, viele Muskeln.

Jedenfalls klimmten innerhalb von etwa einer Stunde hintereinander verschiedene somatische Konstitutionstypen, tatsächlich zuerst ein Ectomorph (Smartphone mit Mucke dabei, In-Ear-Kopfhörer), gefolgt von einem Mesomorph (superlanges Aufwärmtraining gemacht) und final einem Endomorph (kam von irgendwoher und startete gleich los).

Ich zählte die Anzahl der Klimmzüge bei jedem und jeder hörte bei zehn Klimmzügen auf. Interessant. Keine Ahnung, was das bedeutet, aber es waren eben die magische Zehn.

Tag 267/2016: DDoS-Fluten

Heute gemeldet: DDoS-Angriffe auf den unabhängigen Journalist Brian Krebs (krebsonsecurity.com). Bis zu 620 GBit/s. CDN-Anbieter Akamai hatte den Blog von Krebs Pro bono unterstützt, dann aber nach anhaltenden Angriffen vorerst offline genommen (Link 1 von Heise.de, Link 2 von Heise.de).

Snapshots seiner Seite bzw. einzelner Artikel kann man aktuell z.B. noch über archive.org einsehen, hier der Link.

Bizarre Größenordnungen.

[Update 28.09.2016] Mittlerweile hat Google die Seite von Brian Krebs unter sein Schutzschild gestellt („Project Shield“). Brian schildert die Problematik, dass unliebsame Informationen mittlerweile gezielt unterdrückt werden können, in einem aktuellen Blog-Post.

Tag 266/2016: Abkürzung statt Fehlermeldung

Benutzerdaten aus Web-Formularen auf Plausibilität, Korrektheit oder Gültigkeit zu überprüfen, gilt vielen Programmierern als eher langweilige, jedenfalls immer lästige Aufgabe. Zu Unrecht eigentlich, weil selbst auf den ersten Blick einfache Felder wie Geburtsdatum, E-Mail-Adresse oder Postleitzahl immer wieder ihre ganz eigenen, hinterhältigen Herausforderungen haben können, an denen man wachsen kann.

Sowohl was die Art der Eingabe betrifft (einfaches Texteingabefeld versus komplexes Javascript-Widget), clientseitige Validierung, serverseitige Validierung bis hin zur Entscheidung, wie spezifisch man Rückmeldung an den/die Anwender/in geben will (von „Überprüfen Sie Ihre Angabe“ bis „Ihre Angabe enthält ein unerlaubtes Sonderzeichen und ist zu lang“). Manche Dinge ändern sich auch mit der Zeit: Bei E-Mails können neue ungewöhnliche Top-Level-Domains hinzukommen, Internationalisierung muss berücksichtigt werden usw.

Bei Feldern, die im jeweiligen Anwendungsfall zur Änderung vorgesehen sind, wird immer auch geprüft, ob sich überhaupt etwas geändert hat. Kann ich beispielsweise meine E-Mail-Adresse ändern, muss geprüft werden, ob ins Formular überhaupt eine neue Adresse eingetragen wurde. Was tun, wen der/die Anwender/in wieder die gleiche Adresse eintippt?

Diesen Fall ignorieren und nach dem Absenden und der Validierung einfach keine Rückmeldung geben? Stoisch „Bitte geben Sie eine neue E-Mail-Adresse an“ ausgeben oder belehrend/spöttisch „Sie müssen an dieser Stelle schon eine neue E-Mail-Adresse angeben…“? – Aber, was ich in all den Jahren noch nie gesehen habe, ist in so einem Fall einfach sofort die Ausgabe: „Ihr E-Mail wurde soeben erfolgreich geändert!“. Sozusagen mit begleitendem aber unhörbarem Programmiererkichern.

Eine Win-Win-Situation für Programmierer und Anwender: Der eine musste nichts programmieren und der andere ist auch glücklich: „Ich hab meine E-Mail beispiel@example.com erfolgreich auf beispiel@example.com geändert“.

Tag 265/2016: Wo rohe Kräfte sinnlos walten

Wo rohe Kräfte sinnlos walten, das wusste schon Friedrich S., da ist die IT-Branche nicht weit.

Die Festplatte läuft voll? Das Backup lässt sich nicht rückspielen? Die Auftraggeber blockieren den Support mit sinnlosen Fragen? DNS-Probleme? IP-Telefonie hat ’nen Schluckauf? Nach drei Stunden Debugging steht fest, es ist ein Browser-Bug?

Ist die Tür bzw. die Wand dahinter der Sündenböck für all das Leid, mit denen sich die Männer und Frauen täglich konfrontiert sehen? Entlud sich an der Tür all die aufgestaute Wut?

Oder ist es die Toilette am Ende des Ganges, die naturgemäß in großer Hast aufgesucht wird?

Who knows…