Städteportal für Berlin und Hamburg veröffentlicht 👍 👎

Nach langer Planungs- und Implementierungszeit habe ich BitStadt.de, ein Portal für die beiden Stadtstaaten Berlin und Hamburg, fertiggestellt. Du findest dort viele Informationen zu beiden Städten.

Ich würde mich natürlich sehr über einen Besuch freuen!


» BitStadt.de besuchen

Domaingrabbing 👍 👎

Wer schon einmal eine Domain für ein neues Projekt gesucht hat, kennt das Problem natürlich: Die gewünschte Domain ist leider bereits vergeben. Dann denkt man sich, da war wohl – offensichtlich – jemand schneller, möchte es sich mal ansehen und sieht, was irgendwie klar war: Die Domain ist "geparkt", mit zumindest gefühlten 500 Links versehen und steht zum Verkauf.

D. h. es schaltet sich hier ohne Not und Auftrag jemand zwischen Registrar und Kunde, um auch noch daran mitzuverdienen. Wobei "verdienen" hier mehr als fraglich ist, es wird schließlich keinerlei Mehrwert erbracht, sondern im Gegenteil völlig unnötiger Umstand verursacht.

Letztlich nichts Neues, aber das nervt mich immer wieder und wollte mal hier festgehalten werden. Leider habe ich auch bisher keine praktikable Idee, wie sich das verhindern lässt. Nicht zuletzt ist natürlich problematisch, dass man als Domain-Anbieter schließlich erst einmal daran verdient, wenn hunderte oder gar tausende Domains "einfach nur so" registriert werden.

SSL-Zertifikate 👍 👎

Ohne nun genauer auf die Grundsätze der SSL-gesicherten Verbindungen eingehen zu wollen, so stört mich eine Sache an diesem ganzen Konstrukt dennoch sehr.

Genauer gesagt geht es mir um die Ausstellung dieser Zertifikate. Technisch ist das alles natürlich kein Problem und in wenigen Sekunden sowohl erzeugt, als auch z. B. für IIS eingebunden. Nun kennt aber vielleicht der eine oder andere die Entrüstung der Browser, wenn er ein derartiges (selbstsigniertes) Zertifikat vorgesetzt bekommt.

Die Browser besitzen jedoch eine mehr oder weniger umfangreiche List von "vertrauenswürdigen" Stellen, bei denen man entsprechende Zertifikate käuflich erwerben kann, um diese Meldungen der Browser zu verhindern. Auf die Verschlüsselung der Verbindung hat dies im Übrigen keinerlei Einfluss.

Warum diese Stellen nun besonders vertrauenswürdig sein sollen sei dahingestellt, aber es geht ja auch um die Prüfung der Identität des (zukünftigen) Inhabers. Hier fände ich es weitaus sinnvoller, wenn diese von einer Stelle geprüft würde, die das eher beurteilen kann – im einfachsten Fall: Die Stelle, die mir meine bürgerliche Identität quasi verliehen hat.

Ich könnte mir sehr gut vorstellen, dass man mit Personalausweis und Domain-Inhabernachweis zum nächsten Bürgeramt geht, die halten das kurz gegeneinander und man bekommt sein Zertifikat, von Deutschland bescheinigt und im Idealfall sogar kostenfrei. Zumindest ist nicht notwendig, dass Firmen daran Geld verdienen.

Schnittstellenbeschreibungen 👍 👎

Vor Kurzem war ich damit beschäftigt, die Schnittstellen zweier externer Anbieter zu implementieren. Es handelte sich um eine REST- und eine SOAP-basierte Schnittstelle ähnlichen Umfangs, die per PHP angesprochen werden sollte. Dabei fielen mir jedoch erhebliche qualitative Unterschiede der Schnittstellenbeschreibungen auf.

Die REST-basierte Schnittstelle wurde wohl eher von der Marketing-Abteilung zur Bewerbung des Produktes geschrieben, als von Entwicklern für Entwickler. Nicht nur die technische Inkonsistenz, sondern vor allem auch der Schreibstil waren mehr verwirrend als hilfreich. Nicht zuletzt fehlten einige wesentliche Informationen zur Verwendung (u. a. Wertebereiche), die sich schließlich erst durch einige Versuche ergaben, die in diesem Fall zu allem Überfluss auch noch jeweils kostenpflichtig waren. Der relevante Abschnitt des Dokumentes belief sich auf etwa 25 Seiten, die man sich aber auch erst einmal zusammensuchen musste. Fehlermeldungen und Hinweise hätten an der ein oder anderen Stelle ebenfalls nicht geschadet.

Auf der anderen Seite war die Beschreibung der SOAP-Schnittstelle des anderen Dienstes mit unter 10 Seiten knapp gehalten. Die zur Verfügung stehenden Methoden und deren Parameter wurden ohne große Umschweife erwähnt und mit allen notwendigen Informationen beschrieben. So ergab es sich, dass der eigentlich als schnell implementierbar gedachte erste Dienst auf REST-Basis etwa 3-4 mal so lange zur Umsetzung bedurfte, als der als umfangreicher eingeschätzte SOAP-Dienst.

Insofern möchte ich gerne Anbieter von Webdiensten, die das hier evtl. lesen, dazu ermuntern, ihre Schnittstellenbeschreibung vor der offiziellen Veröffentlichung mit einem externen Entwickler im Rahmen einer vollständigen Implementierung durchzugehen, um derartige Schwachstellen schnell aufdecken zu können. Insbesondere sollte es auch immer eine Testumgebung geben, die sich nach Außen wie die eigentliche Schnittstelle verhält, jedoch keine Auswirkungen (insbesondere keine Kosten) verursacht.

Magische Zahlen 👍 👎

Immer wieder sehe ich in diversen Projekten Zahlen im Quelltext, die sich nicht ohne Weiteres zuordnen lassen und nicht selten sogar einer Erklärung des Entwicklers bedürfen. Dies ist üblicherweise schlechter Programmierstil.

Es ist immer besser, derartige Zahlen – je nach Unterstützung der verwendeten Programmiersprache – als Enumeration oder Konstanten einer Klasse mit sprechendem Namen abzulegen. Dies hat neben der verbesserten Verständlichkeit auch den Vorteil, dass Änderungen am Wert ggf. zentral durchgeführt werden können.

Nebenbei bemerkt wird die Begrifflichkeit "magische Zahl" in der Informatik auch als Bezeichnung für spezielle Werte zur Kennzeichnung von Dateiformaten verwendet.

Projektverweise

Kategorien / Archiv  |  Übersicht RSS-Feed

Schlagworte

Suche