Radschnellverbindung Mannheim – Heidelberg – eine Einschätzung

Vor etwa einem Monat gab es eine Befragung am Radweg in Mannheim. Genauer gesagt, an der Brücke von Neuostheim über die Schleuse in Richtung Neckarplatt. Abgefragt wurde dabei die Verwendung des Radwegs (Häufigkeit, Streckenlänge, Zweck der Fahrt). Hintergrund ist die geplante Radschnellverbindung zwischen Mannheim und Heidelberg. Da mich das Thema zumindest teilweise täglich betrifft habe ich mal nachgeschaut wie denn der aktuelle Stand ist und bin doch sehr erschrocken. Die wesentlichen Informationen hat man mittlerweile auf einer eigenen Website zusammen getragen. Ich werde die kommenden Tage und Wochen noch versuchen die Punkte mit Bildern anzureichern.

Ganz neu ist das Thema nicht, bereits 2018 gab es erste Untersuchungen zur Machbarkeit einer Radschnellverbindung zwischen Mannheim und Heidelberg. Warum wird hier von einer Radschnellverbindung geschrieben, nicht jedoch von einem Radschnellweg – das liest sich doch besser …  Leider steckt der Teufel hier im Detail: Für einen Radschnellweg (wie man in landläufig aus Kopenhagen oder auch in den Niederlanden kennt) gibt es in Baden-Württemberg spezielle Qualitätsrichtlinien – danach ist ein Radschnellweg das Äquivalent zu einer Autobahn für den motorisierten Verkehr: Exklusive Nutzung und mit 4m mehr als ausreichend breit. Alles andere darf schlichtweg nicht Radschnellweg genannt werden. Für die Verbindung Mannheim-Heidelberg wurden die Vorgaben ein wenig an die Realität angepasst: Damit die Strecke als Radschnellweg ausgewiesen und gefördert werden kann müssen diese Kriterien auf mindestens 80% der Strecke eingehalten werden. Soviel zu den technischen Details. Continue reading

Radschnellweg – Analyse Neuostheim bis Edingen Neckarhausen

Dieser Eintrag ist Teil der Serie zur Einschätzung des geplanten Radschnellwegs Mannheim-Heidelberg.

Der bereits vorhandene Radweg auf der Südseite des Radwegs führt ab Neuostheim ohne größere Umwege nach Seckenheim. Entlang des Neckars geht es an den OEG-Bahnhof und von dort weiter in Richtung Edigen-Neckarhausen. Dort trifft der Weg auch wieder auf die Kombitrasse. Eine Fehlstelle zwischen Neuostheim und der Autobahnbrücke wurde vor rund acht Jahren endlich geschlossen, seitdem ist der Weg durchgehend befestigt befahrbar. Im Bereich zwischen Seckenheim und Edingen-Neckarhausen wurde erst vor wenigen Jahren ein zusätzlicher Radweg neben die Straße gebaut um die noch bestehende Lücke von rund 500m Länge zu schließen. Es besteht also bereits eine mögliche und sehr direkte Verbindung in Richtung Heidelberg. Continue reading

Radschnellweg – Analyse Kurpfalzbrücke bis östliche Riedbahn (Neuostheim / Feudenheim)

Dieser Eintrag ist Teil der Serie zur Einschätzung des geplanten Radschnellwegs Mannheim-Heidelberg.

Wer die Umgebung kennt und mit dem Rad unterwegs ist hat mit sehr hoher Wahrscheinlichkeit den aktuell vorhandenen Weg auf der Südseite des Neckars genutzt: Von der Kurpfalzbrücke, vorbei am Collini-Center, unter der Ebertbrücke durch. Danach vorbei am Fernmeldeturm und immer weiter gerade aus, immer parallel zur OEG-Straßenbahnstrecke. An diesem Weg gibt es nicht viel zu verbessern: er ist nahezu schnurgerade, weißt keine Steigungen auf und ist sogar nachts bereits beleuchtet. Das man ihn sich mit den Fußgängern teilen muss, stellt aus meiner Erfahrung kein Problem dar. Wenn man hier noch eine Trennung wollte, gäbe es Möglichkeiten einen getrennten Weg im Neckarvorland anzulegen bzw. den bestehenden Pfad dort entsprechend zu ertüchtigen. Ob man dann die Radfahrer oder die Fußgänger näher am Wasser führt ist nahezu unerheblich. Der Weg ist in diesem Bereich aus meiner Sicht auch ausreichend breit. Continue reading

Frameworks in der Programmierung – wirklich so essentiell wie immer behauptet?

Wenn immer man sich aktuell umschaut auf dem Jobmarkt, dann sind im Softwarebereich immer Erfahrungen mit Frameworks gefordert oder zumindest gern gesehen. Nun habe ich ja auch einige Erfahrung und ich sehe das immer wieder etwas zwiegespalten.

Machen wir uns erst einmal ein Bild mit welchem Ziel Frameworks entstanden sind. Mehrheitlich ist ihr Ziel die Entwicklung von Software zu vereinfachen und zu beschleunigen. Der Entwickler soll sich weniger Gedanken machen müssen über einige technische Details und soll sich ganz und gar auf seine Applikation konzentrieren können. Das klingt ja erst einmal nicht schlecht. Wer möchte sich schon gerne mit den Details einer TCP/IP-Verbindung womöglich sogar noch Verschlüsselung beschäftigen müssen wenn er nur Daten von einem Server irgendwo im Netz abholen möchte. Das klingt doch schon insgesamt sehr verlockend, aber jede Medaille hat bekanntlich zwei Seiten. Jede Technologie bringt ihre Tücken und ggf. auch Einschränkungen mit. Eine dieser Einschränkungen ist es, dass ein Framework gewisse Regeln vorgibt an die man sich halten muss, wenn man es verwendet. Das muss noch nicht mal negativ sein, vermeidet es doch, dass man sich unfreiwillig irgendwo eine Bremse einbaut, die man ggf. später wieder ausbauen muss.

Da ich relativ viel im Bereich Webentwicklung mache, beschränke ich mich im Folgenden bei den Beispielen auf dort häufig anzutreffende Frameworks und meine Erfahrungen mit Ihnen.

Eines der für mich wichtigsten Frameworks ist und bleibt JQuery und es ist eines der wenigen Frameworks, das ich schätzen gelernt habe. Warum das so ist? JQuery schreibt mir als Entwickler nicht irgendein Gerüst vor, vielmehr gibt es eine Reihe von best-practices und jede Menge Beispiele. Brauche ich aber nur eine simples Ein- und Ausblenden eines Formularelements dann muss ich mich nicht erst mit dem Bauen und Administrieren von Formularen im Sinne des Frameworks beschäftigen. Stattdessen kann ich es einfach aus und einblenden wie es gerade nötig ist. Minimaler, schlanker Code mit dem ich das Element finden und damit etwas machen kann. Derartige Abstraktion (noch dazu über Browser-Grenzen hinweg) finde ich sehr hilfreich. Auch wenn sich JQuery selbst als Framework bezeichnet – für mich hat es eher den Charakter einer umfangreichen Library (aber Library klingt natürlich so altbacken, das kannten ja schon die Entwickler aus C … daher kann man das natürlich in einem modernen Umfeld nicht offiziell so nennen).

Das nächste Framwork, mit dem ich auch immer noch arbeiten darf, ist ZendFramework. Mittlerweile ist davon die Version 3 auf dem Markt, vor allem nachdem die Version 2 reichlich wenig Akzeptanz gefunden hat. Im Arbeitsumfeld sind wir noch größtenteils mit Zend1 unterwegs. Das wird mittlerweile definitiv nicht mehr weiter entwickelt, aber wenn es läuft und es keine sicherheitskritischen Probleme gibt gilt die alte Weisheit: “never touch a running system”. Leider muss ich sagen, dass mir das Framework häufig mehr Arbeit verursacht als es je einsparen könnte. Vieles ist einfach nur sehr umständlich, trotz oder gerade wegen der vorgegeben Struktur. Auf der einen Seite ist sie recht starr – es gibt nur eine Möglichkeit bestimmte Ergebnisse zu erreichen. Auf der anderen Seite sind die Funktionen dann doch recht häufig wachsweich – nahezu an jeder Stelle kann (oder muss) man Parameter als indiziertes Array übergeben.

Richtig enttäuscht hat mich das Framework dann bei der Umsetzung von Commandozeilen-Parametern. Im Quellcode des Framworks stehen noch jede Menge offene Todo-Punkte. Die Funktion an und für sich kann man “out of the box” fast nicht gebrauchen, denn unbekannte Parametern führen zwangsweise zu einem Abbruch der Verarbeitung. Man kann natürlich dann kurzerhand die Framework-Klasse als Basis hernehmen und die notwendigen Routinen in einer eigenen Klasse überschreiben. Aber so wirklich prickelnd ist das nicht, noch dazu bindet man sich damit sehr stark an das Framework – will man die Funktionalität in einem anderen Projekt wieder verwenden, so muss man die dort mit hoher Wahrscheinlichkeit neu implementieren. Ich habe mich in diesem Falle dazu entschieden, es dann gleich selbst zu machen, PHP bietet von Haus aus bereits recht umfangreiche Funktionen, unter anderem sei hier Getopt genannt.

Natürlich wollte ich auch mal schauen was aktuelle Frameworks so können und vielleicht machen die es ja besser. Also habe ich mir Symphony angeschaut. Auf den ersten Blick ist wieder alles “nice and shiny”. Sobald man aber etwas damit arbeiten möchte, musste ich feststellen: Die Doku und die Beispiele sind einfach nur sehr akademisch gehalten. Ich habe das Framework nach einigen Versuchen ad acta gelegt, weil es ein verdammt hoher Aufwand ist, einen recht simplen Fall abzubilden: Man nehme eine einfache 1:n-Relation wie sie jede Datenbank ohne Probleme abbildet: Eine Art News-Artikel wird einer Kategorie zugeordnet. Ein priviligierter Nutzer ist in der Lage die Tabelle der Kategorien bei Bedarf zu erweitern. Ein klassischer Fall, den man im User-Interface gerne und effizient mit Drop-Down-Menu realisiert. In Symfony ist das ein echter Krampf, spätestens bei der Verwendung der Anzeigenamen als Array-Indizes und der eindeutigen Werte als Array-Werte habe ich mir nur noch an den Kopf gelangt. Das funktioniert zwar dank UTF-8-Unterstützung aber es widerspricht sämtlicher Intuition. Die Beispiele zu Formularen sind da auch keine wirkliche Hilfe – da wird einfach darauf gesetzt, dass man es ja doch per Text umsetzen könnte. Das mag für schnelle Projekte sinnvoll sein, aber im Businessumfeld sind die Regeln dann doch etwas strikter. Man kann es natürlich auf der Server-Seite dann wieder prüfen und eine Fehlermeldung ausspucken – aber warum muss der Anwender erst Tippfehler machen und ggf. raten wenn es nur wenige valide Auswahlen gibt?

Das ist jetzt sicherlich keine umfassende Evaluation, aber in vielen Punkten gleichen sich die Frameworks dann doch. Ich werde mir auch noch weitere anschauen. In einem der nächsten Posts werde ich einige generelle Kritikpunkte die mir bisher bei nahezu jedem “Backend-Framework” aufgefallen sind näher ausführen.