All posts by Rene

Korrekte Telefonnummern sind nicht falsch

Ich finde es immer wieder sehr nervig, wenn Programmierer einfach nicht mit Telefonnummern und ihren korrekten Ausprägungen umgehen können. +491727900000 ist nun mal eine 100% korrekte Nummer, aber die meisten Internetläden nehmen sowas nicht an und nerven mit Korrekturaufforderungen.

Bitte klicken Sie auf zurück und geben Sie eine korrekte Telefonnummer ohne Sonderzeichen ein.

Die Nullen sind von mir fürs Posting eingesetzt. Soll mich ja nicht jeder gleich anrufen.

Amateure

Heute ist mir diese Fehlermeldung bei einer ultra-einfachen Bestellung auf einer Webseite über den Weg gelaufen.

Parse error: syntax error, unexpected $end in
/home/www/murdermystery/booking/system/selectdatum2.php on line 178

Hier hat sich mal wieder jemand das Testen und die einfachsten Überprüfungen geschenkt. Sowas ist peinlich und mega-unprofessionell.

Webseiten schneller machen – Teil 1

Photo by 96dpi

Wenn man über Webseiten-Performance spricht, dann denken die Meisten sofort an die Leistung des Servers bei der Auslieferung der Inhalte. Das ist im Prinzip auch nicht falsch, aber nur die halbe Wahrheit. Natürlich kann man eine Seite nicht schneller anzeigen, als sie ausgeliefert wird, so dass eine gute Leistung des Servers Grundvoraussetzung ist, aber es geht halt ohne grosse Anstrengungen langsamer.

Wie? Langsamer?

Moderne Webseiten bestehen aus vier Hauptkomponenten: Html, CSS, Javascript und statischen Inhalten, wie zum Beispiel Bildern und Flash. Die endgültige Webseite kommt nur im Browser zu Stande, wenn alle diese Einzelteile zusammengefügt wurden. Diese finale Schritt wird als Rendern bezeichnet.

Jede Einzelkomponente muss über das Netz geladen werden und die Komponenten werden in einer gewissen Reihenfolge geladen. So ist zum Beispiel immer zuerst die HTML-Hauptseite dran, dann Frames, dann CSS und Javascript aus dem Header, dann Bilder, dann anderer Content und irgendwo mittendrin wird noch das Javascript ausgeführt (denn Laden und Ausführen sind nicht das Gleiche). Um es kompliziert zu machen, macht es jeder Browser etwas anders.

Sollte ein Teil klemmen bzw. langsam sein, so können oder werden nachfolgende Teile nicht geladen und die Seite nicht bzw. unvollständig angezeigt. Oft fällt das beim Spiegel-Online, Welt-Online oder ähnlichen Angeboten auf, denn dort sieht man oft nur den Header und dann kommt einen Moment nichts… oder mehrere Momente nichts und endlich macht es Pling.

Da ich hier nicht alle Teile aus dem Yahoo-Performance-Guide kopieren möchte, wie man das Pling vermeiden kann und wie alles viel schneller geht, hier noch etwas erklärende Theorie für das Grundverständnis. Hier meine Favoriten und die bildliche Erklärung. Zuerst sei noch ein Missverständnis erklärt.

Meine Kunden haben doch Breitband, wo ist das Problem?

Breitband ist schön, Breitband ist toll, aber ein LKW mit Ladung ist auf einer 10-spurigen Autobahn nur unwesentlich schneller als auf den traditionellen zwei Spuren. Warum? Wenn ich Ware nach von A nach B bringe, dann muss ich den LKW be- und entladen, sowie der LKW muss auf die Autobahn auf- und abfahren. Egal wie breit die Autobahn dazwischen ist, diese Grundschritte sind immer dabei und immer gleich schnell. Eventuell haben wir nur weniger Stau unterwegs bzw. ich kann vier LKWs schicken, statt einem… sofern ich etwas zu transportieren habe und sich die LKWs nicht am Verladezentrum stauen.

Genauso verhält es sich mit Anfragen an einen Webserver. Das Datenpaket wird gepackt, versendet und ausgepackt, danach beantwortet, die Anfrage eingepackt, versandt und wieder ausgepackt. Nur die beiden Versandschritte gehen schneller mit einer dicken Leitung, der Rest bleibt.

Und wo ist nun das Problem?

Ja, ich habe es immer noch nicht richtig verraten, aber das Problem der meisten Webseiten ist, dass sie aus vielen vielen Einzelteilen zusammengesetzt werden und je mehr Teile es sind und je mehr Teile von unterschiedlichen Servern stammen, desto langsamer wird die Sache.

Das führt zum lustigen Effekt, dass das Laden von 5 Bildern a 50kB schneller geht, als das Laden von 10 Bildern a 15kB, obwohl die Gesamtgrösse der 10 Bilder deutlich geringer ist. Leider führen 10 Bilder zum Zweifachen Overhead im HTTP-Protokoll, in der DNS-Auflösung, in der Bestimmung der Serverantwort und und und.

Regel Nummer 1 heisst deswegen – Weniger HTTP-Anfragen

Diese Regel ist die absolut goldene Regel und lässt sich durch das Zusammenlegen von Einzel-CSS in ein CSS-File erreichen, durch das Zusammenführen von Javascript-Dateien und statt den Seiten-Header in 8 Bilder zu zerlegen, schickt man lieber nur 2 Bilder.

Man darf dabei auch nicht aus den Augen verlieren, dass diese Inhalte auch gecacht werden sollten, damit der Browser beim Weiterklicken nicht nochmal alles von vorn alles laden muss. Hier ist also zwischen Zerlegung, Grösse, und Wiederverwendung abzuwägen.

Regel 8 – Javascript und CSS gehören in Einzeldateien

Man sollte niemals CSS und Javascript in grossen Mengen in das HTML einbetten. Dieser Teile gehören extern und so aufbereitet, dass sie wiederverwendbar sind. Das macht die Pflege einfacher und die eigentlichen HTML-Seiten kleiner.

Regel 19 – Die Anzahl der DOM-Elemente reduzieren

Was der Browser nicht lesen muss, dass kostet keine Zeit und keinen Speicher. Jedes HTML-Element und vor allem jede Zeile Javascript-Code muss interpretiert und verwaltet werden. Damit ist eigentlich schon einleuchtend, dass der HTML-Code sauber und einfach strukturiert sein sollte.

Als Beispiel lässt sich bei

locker das span einsparen, denn a ist bereits ein Inline-Element und span fügt hier keine Struktur hinzu. Das ist aus der Praxis, das habe ich mir nicht gerade ausgedacht.

So, dass war eigentlich schon recht viel für den Anfang und deswegen gibt es demnächst mehr zu den anderen Tipps von Yahoo. Wer es eilig hat, der kann auch direkt nachlesen: Best Practices for Speeding Up Your Web Site.

Photo by 96dpi under CC-BY-2.0

JUnit 4.5

JUnit 4.5 wurde heute veröffentlicht. Es gibt keine Features auf der Liste, die uns sofort wechseln lassen, aber gut zu wissen ist es immer.

JUnit 4.5 focuses on features that make life easier for JUnit
extensions, including new public extension points for inserting
behavior into the standard JUnit 4 class runner.

UUID gefällig?

Wenn jemand mal Bedarf an UUIDs hat und gerade keinen Generator zur Hand hat bzw. etwas mehr über das Thema wissen will, dann ist www.uuidgenerator.com ein Anlaufpunkt, um sich zumindest einiger UUIDs zu bemächtigen.

A Universally Unique Identifier is an identifier standard used in software construction, standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination.

Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labelled with UUIDs can therefore be later combined into a single database without needing to resolve name conflicts.

(Wikipedia.com)

Nach dem Lasttest

Ein Blick in die Lasttest-Mailbox

Nach vielen Lasttests in den letzten Tagen habe ich mal in meine Spezialmailbox geschaut und war ja etwas überrascht, dass es doch schon so viele Emails waren, die in der Zeit eingetrudelt sind. Man stelle sich mal vor, das wäre alles als auf dem Server hängen geblieben bzw. mit Beschwerde an den Admin gegangen.

Wobei ein Test mit Unzustellbarkeit auch ein schönes Testszenario ist…

Captchas brechen durch pure Masse

Ich habe einen interessanten Artikel über das bezahlte Knacken von Catchas gelesen: Inside India’s CAPTCHA solving economy

Bisher wusste ich nicht mal, dass es sowas schon kommerziell gibt. Schon unheimlich, wie sich billige Arbeitskräfte nutzen lassen. Statt mit Rechenpower und Algorithmen löst man Probleme einfach durch pure Masse. Leider wird dadurch das ganze Sinn von Captchas gebrochen und man kann sich quasi nur noch durch ganz doofe Rätsel vor Spam schützen.