XML

In the late 1990es there was a real hype about XML. Tons of standards evolved and it was a big deal to acquire sound knowledge of it.

It has been some success, because it is still around and very common almost 20 years later.

I would say that the idea of having a human readable and editable text format has mostly failed. Trivial XML can be edited manually without too much of a risk of breaking it, but then again simpler formats like JSON or even java-properties-Files or something along these lines would be sufficient and easier to deal with, unless it is the 1001st slightly different format that needs to be learned again. XML is different each time anyway, because it depends on the schema, so we have the problem on that side, but off course the general idea is well known.

For complex XML manual reading and editing becomes a nightmare, it is just so much harder to read for humans than any reasonably common programming languages of our time. It is text, but so involved that it feels like half binary. And who knows, maybe we can also edit binary files with a hex-editor. And real magicians, actually people with too much time in this case, can do so and keep the binary file correct and uncorrupted, at least for some binary formats. And they can do so in XML as well… But it is actually better to have a tool or a script to create and change non-trivial XML-configuration files.

Where XML is strong is for data exchange between systems. This is mostly transfer in space between different systems, but it can also be transfer in time, that is for storing information to be retrieved later. It gives a format that allows for some „type safety“, that is very versatile and that provides a lot of tool and script support around it. Even here we have to acknowledge that there are some drawbacks. Maintaining a XML interface involves some work for the schema files, adopting the software on the human side. It requires some CPU-overhead on the sending and mostly on the receiving side for creating and parsing XML. The libraries have been optimized but still they take a little bit of time. And then on the network size we transmit a multiple of the amount of data, if it is densely packed with tags.

But it is a format that is well understood, that works on pretty much any platform, over the network and also usually allows us to support different versions of the same interface simultaneously. For debugging it is good to have a format that is at least human readable, even if not very pleasant. Ideally the schema is defined in a way that is self documenting.

I wonder why approaches like in WML have not become more common. WML had a customized compressed format that was more friendly to low bandwidth cell phones.

XML is good for many purposes, but as always it is good to know other tools, like JSON and to decide when it is a case for XML and when not.

Some positive side effects of XML are that it helped some other standards to become more mainstream. UTF-8 was from the beginning the default encoding for XML and this is now a common standard encoding for any text. And with XML-schema it became common to encode dates within XML in the ISO-format, which helped this format in becoming generally known and commonly used for cases where one date format should work independently of the origin of the reader.

Share Button

Webseiten für Mobilgeräte

English

Viele Webseiten werden heute für Desktop-Geräte mit einem bestimmten Bildschirmformat optimiert und man versucht vielleicht noch nachträglich eine gewisse Mobiltauglichkeit ranzuflicken.

Dabei wird schnell vergessen, dass das Anschauen der Webseite mit einem Mobiltelefon kein Nischenfall mehr ist, sondern häufig vorkommt. Manche Webseiten funktionieren gar nicht auf Mobiltelefonen, man kann es einfach aufgeben, sie zu verwenden. Manche sind extrem unhandlich. Vertikales Scrollen ist allgemein akzeptabel. Wir sind es gewohnt, es harmoniert aber auch mit unserem Lesestil. Wenn man horizontal scrollen muss, um eine Zeile zu lesen, muss der Inhalt schon extrem interessant sein, damit man nicht aufgibt.

Was ist zu beachten?
* Font mus groß genug sein, damit man es lesen kann. Ideal wäre, wenn man die Font-Größe in vielen Stufen verstellen könnte und die Webseite sich immer anpassen würde.
* horizontales Scrollen ist eventuell für große Bilder o.ä. noch akzeptabel, für Text aber nicht.
* Man braucht die ganze Breite des kleinen Displays zum lesen, Navigationsbereiche rechts oder links müssen sich verschieben oder ausblenden lassen.
* Es ist problematisch, wenn Bedienelemente zu nahe beieinander liegen, weil man mit dem Finger nicht so genau trifft wie mit der Maus. Der Finger ist zwar sehr genau, aber es fehlt das Feedback vor dem Anklicken, weil man nicht sieht, was unter dem Finger passiert.

Vielleicht gibt es noch mehr Punkte.

Nartürlich ist mehr Bildschirmfläche immer besser und man sollte auch das ausnutzen.
Aber wir wissen alle, dass es Beispiele von Webseiten gibt, die auf Mobiltelefonen super funktionieren.
Und solche die es nicht tun.

Heute wird die Webseite im Browser aufgebaut. Eigentlich kommt sie als HTML und die Browsereinstellungen liefern dann Schriftgröße, Formatierungspräferenzen u.s.w.
Das sind die typischen Webseiten aus den 90er Jahren, die alle etwa gleich aussahen, aber einigermaßen gut funktioniert haben.

Aber darauf entstand dann auch so etwas wie ein kaputtes Web. Webdesigner wollten sich verwirklichen und es wurde mit Tricks wie geschachtelten Tabellen, transparenten 1×1-Bildern, Frames, Formatierungsinformationen im HTML, (z.B. Font-Tags) gebastelt, was das Zeug hielt. Die berühmten Webseiten „best viewed with BrowserXYZ“ entstanden. Und das HTML war unlesbar und nur mit Tools wie Frontpage oder Dreamweaver o.ä. überhaupt bearbeitbar. Mit dem falschen Browser waren sie leer.

Oder Müll. Mit Javascript konnte man noch tollere Sachen machen. Und noch browserabhängiger.
Toll, vor allem für die Rechnungen, die der Webdesigner stellen konnte, war dann der Weg, einfach verschiedene Varianten der Webseite anzubieten, die für verschiedene Browser optimiert waren. All das ist genau das, was das Web nicht sein sollte und ich denke, dass die Grundideen Anfang der 90er Jahre durchaus valide waren und eine Weiterentwicklung verdienen.

Ein guter Schritt war es, CSS einzuführen. Damit wurde die Formatierung auf eine saubere Grundlage gestellt, weil man Formatierungsinformation strikt in CSS halten konnte und vom Inhalt trennen konnte. Natürlich müssen HTML und CSS zueinander passen, aber das HTML bleibt lesbar und kann auch mit einem normalen Texteditor noch bearbeitet werden und das CSS kann wiederverwendet werden. Dass es Weiterentwicklungen von CSS gab, z.B. Sass und SCSS. Das ändert nichts am Grundprinzip.

Eine weitere Änderung kam auf, weil vermehrt Webseiten dynamisch beim Aufruf auf dem Server generiert wurden. Ich denke, dass wir heute überwiegend auf solche Webseiten unterwegs sind. Google, Wikipedia, Youtube, Facebook, Online-Shops, Fahrplanauskunft, Kartendienste, E-Banking… Fast alles, was wir so im Web machen ist heute dynamisch generiert, oft auf dem Server. Dieser Blog-Artikel auch. Ich denke, dass heute zu viel dynamisch generiert wird, was eigentlich statisch sein könnte, aber das ist ein anderes Thema. Man konnte schon in der Frühzeit des Web mittels CGI dynamisch Webseiten generieren aber das war damals eher der Spezialfall für die Anwendungsfälle, wo das unbedingt nötig war.

Eine andere Klasse von Web-Applikationen benutzt heute JavaScript und z.B. Angular-JS und ist eine Wiederbelebung der klassischen Client-Server-Architektur. Manche sehen das als den Nachfolger der Server-generierten Webseiten an. Ich sehe eher für beide Ansätze eine Existenzberechtigung. Vieles, was wir heute nutzen können, wäre ohne Rich-JS-Clients gar nicht denkbar oder nur sehr umständlich nutzbar. Google-Docs, modernere Wiki-Editoren, Moderne Web-Mail-Clients, Chats, Twitter, Facebook u.s.w. nutzen dieses Prinzip. Es gibt aber viele Vorteile, Applikationen, die mit serverseitig generiertem HTML gut funktionieren, auch auf dieser Technologie aufzubauen. Auch das ist ein interessantes Thema für einen anderen Artikel….

Interessant ist jetzt, wie man die Mobilgeräte sinnvoll unterstützen kann.

Schon Ende der 90er Jahre hatte man die Lösung. WAP. Man schrieb die Seiten in WML statt HTML (wireless markup language). Das war in mehrfacher Hinsicht für Mobilgeräte optimiert: Die Seiten brauchten wenig Übertragungsvolumen in Zeiten, wo die Bandbreite für Mobiltelefone noch winzig war. Es ließ sich auf einem Mäusedisplay anzeigen. Und die Navigation war mit wenigen einfachen Tasten möglich, noch ohne Touchscreen. Der war damals noch nicht ausgereift oder preislich nicht in der Reichweite des Massenmarkts. Eine ideale Lösung für die damaligen Geräte.

Nur machte sich kaum einer die Mühe, seine Webseite noch ein zweites Mal für WAP anzubieten und aktuell zu halten.
Heutige serverseitig dynamisch generierten Webseiten könnten das vielleicht leisten. WordPress oder Media-Wiki oder Google könnten ihren Inhalt auch im Wap-Format herausgeben. Aber zu der Zeit waren statische Webseiten noch häufig und dynamische Webseiten waren noch sehr spezifisch auf ein bestimmtes Ausgabeformat hin ausgelegt.

Die Erlösung waren also dann die Super-Smartphones, die von Nokia und Ericsson verkauft wurden und die einfach „normale“ Webseiten konnten. Plötzlich war man nicht mehr in der Wap-Nische eingesperrt und hatte Zugriff auf alles. Und Webseiten konnten diese wenig geliebte Zweitvariante endgültig streichen, wenn sie sie überhaupt hatten.

Dieselben Webseiten funktionieren für Mobilgeräte, aber eben nur manchmal befriedigend. Aus den Gründen, die oben erwähnt wurden.

Wie kann man Webseiten universell anbieten?

1. Nun, man kann den Wap-Ansatz auch heute mit für Mobilgeräte optimiertem HTML verfolgen. Es gibt dann zwei Webseiten, http://www.xyz.com/ und http://m.xyz.com/. Wer fleißig ist, kann die beiden Varianten immer parallel pflegen. Fleiß ist aber an dieser Stelle eine Untugend. Es gibt aber auch Varianten für faule. Man schreibt die Webseiten in irgendeinem Format und hat Werkzeuge, die die m-Variante und die www-Variante aus derselben Quelle automatisch generieren. Das kann ein Skript sein, das man laufen lässt und das einmal lauter statische Seiten generiert, in beiden Varianten. Oder sie werden bei Abfrage dynamisch generiert. Solange man nicht zwei oder drei oder vier Varianten parallel pflegen muss, ist das akzeptabel.

2. Ein weiterer Weg ist es, statische HTML-Seiten zu haben und nur das CSS in zwei oder mehr Varianten anzubieten. Ich finde diesen Ansatz eleganter und bin überzeugt, dass er auf längere Sicht besser und mit weniger Aufwand funktioniert. Und es ist gemäß der HTML-Philosophie der „richtige“ Ansatz. Dies kann durch Abbilden von Varianten im CSS geschehen, aber auch dadurch, dass man CSS dynamisch passend zum Endgerät generiert. Vielleicht etwas zu originell für die Realität, wenn man CSS mit CGI generiert, aber statisches HTML hat. Aber warum nicht. In der Regel geht es auch, im CSS Bereiche für verschiedene Kategorien von Endgeräten zu definieren und das kann auch reichen.

3. Noch radikaler ist die Idee des Responsive Designs. Man hat idealerweise ein HTML und ein CSS und die sind so gemacht, dass sie für ein breites Spektrum an Fenstergrößen richtig und sinnvoll funktionieren. Ich finde das schöner als den zweiten Ansatz, weil die Vielzahl der Geräte so groß ist und die stufige Einteilung in Kategorien immer ungenau und manchmal falsch ist.

Elemente von Responsive Design sind einfach und für sich genommen schon nützlich:
* im Header-Bereich
* keine absoluten Größenangaben im CSS
* nur äußerst sparsam minimal- und maximal-Werte mit einem möglichst großen Bereich
* bei großen Bildern max-width: 100%; height: auto;
* bei großen Bildern von den Größenangaben im img-Tag, die man zur Optimierung des Rendering gelernt hat, wegkommen.

Es gibt noch mehr, was man tun kann. Wenn man es richtig gut machen will oder eine vorhandene Seite auf Responsive Design umbauen will, kann es schon aufwendig werden.

Wenn man ein CMS wie Joomla, Drupal, Typo3, WordPress o.ä. verwendet, sind diese Dinge „wegabstrahiert“. Es ist aber interessant zu schauen, ob das funktioniert oder ob man da etwas tun muss und was.

Share Button

Responsive Design

Neu ist dieser Blog mit „responsive design“ ausgestattet. Das bedeutet, daß das Layout sich von selber kleinere Bildschirme von Mobiltelefonen anpaßt.

Auch die Seite IT Sky Consulting GmbH hat responsive Design. Dies ist nur mit CSS umgesetzt, die HTML-Seiten existieren nur einmal.

Share Button

Security: physikalische Trennung

Für viele Aktivitäten im Internet ist die schwächste Stelle der Weg durchs Internet, da dieser oft unverschlüsselt erfogt, zum Beispiel über http oder über EMail. Auch ein verschlüsselter Kommunikationspfad (z.B. https oder skype) hilft natürlich nur so weit, wie man dem Betreiber des Servers traut, auf den man dabei zugreift. Durch Umstellung der Kommunikation auf sicherer Mechanismen (z.B. https) wird der Kommunikationspfad sicherer. Dabei finden solche Zugriffe über das Web heute nicht nur sichtbar über die mit dem Browser angesurften Seiten und deren Ergänzungen (Bilder, CSS, JavaScript) statt, sondern auch durch Programme, insbesondere JavaScript-Programme, die im Browser laufen und sich einzelne Informationsstücke vom Server holen und diese in die Seite einbauen.
Das heißt u.a.:

  • Ein Angreifer im Netz kann nur mit sehr großem Aufwand oder gar nicht abhören, was der Inhalt der Kommunikation ist. Das betrifft beide Richtungen, also auch die Frage, welche URLs man auf dem betreffenden Server anspricht. Sehr nützlich ist das auch beim Einloggen für die Übermittlung des Passwords.
  • Ein Angreifer kann die Nachricht nur mit sehr großem Aufwand oder gar nicht ändern oder verfälschen. Da ist man gerade beim e-Banking froh, wenn das nicht so einfach ist.

Eine Schwachstelle bleibt aber der Rechner des Benutzers selbst. Den hat man ja bei sich im Haus stehen und da kommt kein Einbrecher durch die Tür und macht damit was Ungewünschstes, außer es ist ein Laptop oder ein Rechner im Großraumbüro. Aber wir wissen ja, daß der Einbrecher unsichtbar durch das Netz kommt. Sobald man einen Rechner direkt ins Netz hängt, kann man beobachten, daß Angreifer ihn nach kurzer Zeit entdecken und alle möglichen Attacken probieren, die auf häufige Schwachstellen aufsetzen. Das geht heute natürlich alles vollautomatisch. Auch sonst gibt es viele Wege für Schadsoftware auf den Rechner und Al Capones heutige Berufskollegen haben ganze Botnetze aus Rechnern anderer Leute aufgebaut, die ihnen zwar nicht gehören, aber gehorchen. Solange diese kriminelle Nutzung des Rechners im Hintergrund bleibt, merken das viele Benutzer gar nicht, weil das, was sie selber machen, ja noch funktioniert, nur vielleicht etwas langsamer. Wenn es zu langsam läuft, hilft bei MS-Windows-Anwendern oft das „Windows neu installieren“, dann ist nebenbei die Schadsoftware auch wieder weg, wenn man Glück hat. Anscheinend sind auch staatliche Stellen mancher Staaten in diesem Bereich unterwegs. Heutige Mobiltelefone sind natürlich auch fast vollwertige Rechner, also von solchen Überlegungen auch betroffen. Nun ist schon an sich ärgerlich, Teil eines Botnetzes zu sein, weil man dadurch letztlich ungewollt daran beteiligt ist, wieder andere Rechner anzugreifen oder andere kriminelle Aktivititäten des Botnetzbetreibers zu alimentieren. Interessant ist aber auch der Gedanke, daß der Botnetzbetreiber den vollen Zugriff auf den Rechner hat, also zum Beispiel beim e-Banking im Browser die unverschlüsselten Daten sehen und ändern kann. Das ist schwierig, aber prinzipiell möglich.

Ein recht drastischer Ansatz wäre nun, in einem Laptopgehäuse oder sogar in einem Mobiltelefongehäuse physikalisch mehrere Rechner unterzubringen. Der Raspberry Pi zeigt, daß es möglich ist, kostengünstig sehr kleine (Linux-)Rechner zu bauen. Wenn das Gehäuse eines neuen Laptops nur etwas größer ist, bringt man zusätzlich noch so einen kleinen Rechner darin unter, der keine oder nur sehr wenige lokale Benutzerdaten speichert und nur für e-Banking und andere sicherheitskritische Aktivitäten benutzt wird. In Desktoprechner wird der zusätzliche Platzbedarf im Gehäuse kaum auffallen. Ich stelle mir ein speziell schlankes Linux vor, das als einzige Applikation einen Browser hat, der für diesen Zweck optimiert ist. Mit einem Schalter wird physikalisch umgeschaltet, welcher Rechner Display, Tastatur und Maus hat.

Ein ähnlicher Effekt ließe sich natürlich auch erreichen, wenn man seinen Rechner voll virtualisiert, so daß das direkt auf dem Rechner laufende System nur dazu dient, virtuelle Umgebungen für die Systeme bereitzustellen, in denen man dann arbeitet. Wenn das gut gemacht ist, hat man auch eine recht gute Trennung zwischen dem e-Banking-System und den anderen virtuellen Sytemen auf dem Rechner, aber man hat in diesem Fall immmer die Performance-Einbuße durch die Virtualisierung hinzunehmen. Das läßt sich alles auch für Mobiltelefone umsetzen, nur muß man dann natürlich ein paar Gramm mehr und ein dickeres oder größeres Telefon mit sich herumschleppen, weil diese ja schon recht vollgepackt sind.

Ich habe mal eine Startup-Firma gesehen, die Desktoprechner nach diesem Prinzip gebaut hat, sogar mit mechanischen Schaltern und drei separaten Rechnern in einem Gehäuse. So etwas kann man aber trotzdem heute noch kaum kaufen, aber ich denke, daß es vielleicht eine gute Idee ist, die sich in ein paar Jahren etablieren könnte.

Share Button

Apps oder HTML5

English

Die Idee mit den Apps für Mobiltelefone ist nicht sehr neu. Schon recht einfache Telefone konnten so etwas und man entwickelte die Apps oft mit Java ME, einem verkleinerten Java. Das ist vielleicht nicht die beste Lösung, aber hatte immerhin den Vorteil, daß man eine Entwicklung für eine Vielzahl von Mobiltelefonen machen konnte und nur beim Testen dann alle möglichen Geräte durchprobieren mußte.
Dann kam bei den Nokia-Smartphones Qt mit C++ als Basis für die Entwicklung von Apps auf. Das versprach immer noch geräteunabhängig zu sein, weil Qt OpenSource ist und auf verschiedene gängige Desktop-Betriebssysteme sowie Symbian und Maemo/Meego portiert worden ist. Wirklich verbreitet waren die Qt-Apps auf Symbian und Maemo/Meego. Heute wird Qt von Digia entwickelt und soll in Zukunft unter anderem auch für Android verfügbar sein.
Nun kamen mit der Verbreitung von Apple-iphone und Android neue Varianten auf, deren Apps man mit Dalvik schreiben soll. Microsoft versucht auch noch ein Mobiltelefon-OS zu verbreiten, das dessen Apps wieder anders, vielleicht mit C#, entwickelt werden sollen.
So stellt sich für App-Entwickler heute das Problem, daß man Apps mit einer bestimmten Funktionalität wirklich ca. 6-8 Mal komplett neu entwickeln muß, wenn man einen großen Teil der Anwender erreichen will. Für sehr wichtige Apps mag das schon eine vertretbare Investition sein, aber es stellt sich doch schnell die Frage, ob der Aufwand vertretbar ist. Außerdem wissen wir nicht genau, welche Systeme außer Android in ein paar Jahren verbreitet sein werden oder zumindest relevante Nischen besetzen. Vielleicht wird sich bei neuen Systemen zumindest eine Android-Kompatibilität durch eine angepaßte Dalvik-Umgebung für diese Systeme etablieren, aber sicher ist auch das nicht. Mit Web-Applikationen ist man aber schon ab dem ersten Tag auf dem neuen Smartphone, von dem man heute noch nichts weiß. Den Browser wird niemand weglassen wollen.

Die Idee, mit den Prozenten aus dem Verkauf von Apps über die jeweiligen App-Stores Geld zu verdienen war sicher vor ein paar Jahren mal Gold wert. Heute gibt es aber für viele Systeme eine riesige Vielfalt von Apps und wenn da noch eine dazustellt, ist es schon ungewöhnlich, noch auf so hohe Download-Zahlen zu kommen, daß die paar Cent pro Download alleine schon den Aufwand finanzieren könnten.
Bis vor gar nicht so langer Zeit hatten die Apps noch eine Existenzberechtigung alleine schon wegen der Möglichkeiten Client-seitig, also auf dem Mobiltelefon, bessere interaktive Funktionalität aufzubauen als dies mit HTML und einer Webapplikation möglich wäre.
Das hat sich aber inzwischen sehr relativiert. Mit HTML5, JavaScript, Ajax, Websockets und einigen anderen Neuerungen der klassischen Web-Applikations-Technologie kann man heute praktisch alles machen, was diese Apps konnten. Und man muß es nur einmal entwickeln. Ich gehe daher davon aus, daß sich diese Apps nur für einige wenige spezielle Anwendungen halten werden, die so bedeutend sind, daß die Mehrfachentwicklung nicht weh tut und die mehr Interaktion brauchen als mit Web-Applikationen üblich ist. Es wird immer schwieriger, solche Fälle zu finden. Was einem spontan einfällt:

  • Anwender soll für Verwendung der Funktionalität bezahlen. Das gibt es im Internet an viele Stellen. Die Bezahlmechanismen sind noch nicht optimal, aber weit verbreitet und etabliert, wenn es um Einkaufen im Web geht. Sogenannte „Paywalls“ für Bereiche einer Webseite oder -applikation, die nur zahlenden Kunden zugänglich sind, gibt es. Vorteil: Kein app-Store zieht seine Prozente ab.
  • Spiele sollten doch auch offline funktionieren, zum Beispiel im Ausland (solange Dataroaming teuer ist) oder im Tunnel. Das verspricht HTML5 mit dem lokalen Speicher („local storage“) aber zu lösen
  • Aussehen: Kann man mit HTML5 ziemlich beliebig schaffen.
  • Interaktivität: Mit JavaScript, Ajax und HTML5 kann man sehr gute Applikationen bauen.

Kurz gesagt, das Geschäft mit den App-Stores dürfte in ein paar Jahren zum Auslaufmodell werden oder als Nische für eine kleine Anzahl von Apps überleben.

Share Button

Über meine Webseiten

Heute sind dynamische Webseiten häufig geworden und einge davon, wie zum Beispiel Wikipedia, Google, Yandex, Twitter, youtube, Facebook, Amazon, ebay, google+ u.s.w. bewältigen in jeder Minute riesige Datenmengen.

Auch für Webseiten, die eigentlich einen statischen Inhalt darstellen, der nur gelegentlich geändert wird, sind dynamische Webseiten nicht selten. Meistens wird dafür ein Content-Management-System verwendet, z.B. Drupal, WordPress, Typo3, Joomla, Silverstripe oder eine Wiki-Engine. Dies hat ein paar Vorteile. Man kann sehr schnell Änderungen durchführen, ohne HTML-Kenntnisse zu haben, und man kann diese auch vorbereiten und zu einem Zeitpunkt in der Zukunft freischalten lassen. Hier findet sich ein Vergleich der vier erstgenannten Systeme.

Ich habe mich dennoch entschlossen, statisches HTML für die Webseite http://www.it-sky-consulting.com/ zu verwenden. Für diesen Blog habe ich allerdings WordPress genommen. Da ich mich unter anderem mit der Entwicklung von Web-Applikationen beschäftige, ist es essentiell, HTML zu kennen, insbesondere auch Wege der Zusammenarbeit mit Web-Designern, die sich nicht wirklich mit der Entwicklung von Web-Applikationen auskennen. Das funktioniert am besten, wenn die Design-Arbeit überwiegend in CSS einfließt und auf HTML-Seite nur soweit die Struktur vorgegeben wird, wie das nötig ist, um die CSS-Dateien einzubinden. Das verringert schon den Kreis der möglichen Web-Designer erheblich.

Da die Seite also aus relativ übersichtlichem HTML besteht, kann ich das leicht editieren, um Texte zu ändern. Um Teile einzubinden, die in mehreren Seiten gleich sind, gibt es einen einfachen Präprozessor.

Dieser Blog wird mit WordPress betrieben und ist damit dynamisch.

Share Button

Links automatisch überprüfen

English

Bei einer Webseite mit hunderten oder tausenden von Links ist es sehr hilfreich, wenn man diese automatisiert überprüfen kann. Dafür gibt es viele Hilfsmittel. Ich verwende die Perl-Library LWP.  Ja, www.it-sky-consulting.com hat heute nur etwa 130 verschiedene Links, aber ich möchte natürlich auch dafür Prozesse haben, die skalieren.

Ein Problem ist aber, daß einige Webseiten auf solche Testskripte anders reagieren als auf einen Browser. Ein paar Beispiele:

  • Spracheinstellungen des Browsers führen dazu, daß zu einer sprachspezifischen Seite weitergeleitet wird.  Man müßte also mit etlichen Spracheinstellungen testen.
  • Manche Seiten ergeben beim automatisierten Test einen Fehler, z.B. Fehlercode 500, funktionieren aber im Browser.
  • Manche Server geben bei längst nicht mehr vorhandenen Seiten nicht den Fehlercode 404 (oder eventuell 403), sondern leiten an eine Seite weiter, auf der freundlich auf die Fehlersituation hingewiesen wird.  Wenn man die Sprache der Seite versteht, ist das gut.  Für ein Skript relativ schwierig zu lernen, auch wenn man gewisse Muster beachten kann:  Die Weiterleitung geht häufig auf die Home-Seite des Servers oder auf eine Seite, in deren Dateiname „404“ vorkommt.
  • Es wird immer mal wieder eine Domain aufgegeben.  Meistens wird die dann sofort von einer Firma übernommen, die dort ihren Content, z.B. Werbung, plaziert, in der Hoffnung den Traffic der etablierten Seite erben zu können.

So bleibt die automatische Überwachung der Links immer noch schwierig und erfordert gewisse manuelle Tätigkeiten.  Nicht die 80-20-Regel gilt hier, sondern es ist eher so, daß 5% der Links etwa 95% der Arbeit machen.

Ich interessiere mich dafür, diese Prozesse weiter zu verbessern, also die Qualität der Überprüfungen zu erhöhen und den Aufwand zu verringern.

Share Button