Bei scouter.de gibt es bereits seit dem Start der Marke im Jahr 2014 vier Hauptbereiche umzusetzen:
Beim ersten Punkt waren wir technologisch stets unabhängig, aber bei den Punkten 2 - 4 musste natürlich eine API zum Systemdienstleister (DB Flinkster Netzwerk) eingebunden werden, welche die eigentlichen Daten liefert und verwaltet.
Es gab in den vergangenen zehn Jahren dann eine stetige Evolution am laufenden Projekt (a.k.a. Feature Creep) mit immer komplizierterem PHP/jQuery-Code. Wir bauten eine eigene Middleware zum Glätten der „Ein-bisschen-RESTful“-API. Im Jahr 2021 kam dann für den Buchungsbereich eine SPA (Single Page Application) hinzu, die auch als Multiplattform-App in die nativen Stores wanderte, sowie auf, äh, abenteuerliche Weise1 in den CMS-basierten Marketingteil der Website eingebettet wurde.
Anfang 2023 war scouter.de ein Sammelsurium an Technologien, die man beim besten Willen niemandem mehr hätte erklären können. Aber nun ja: Es hat funktioniert. Wenn es Ausfälle gab, war das (meistens) nicht meine Schuld.
Der technische Anlass für die ganz große Reform war dann der Wechsel des Carsharing-Systemanbieters hin zu Cantamen. Für mich ein echter Befreiungsschlag! Und weil abzusehen war, dass es mit einem simplen Austausch der API-Syntax nicht getan war, grübelte ich einige Wochen lang über die geeignete Basis-Technologie für den Relaunch nach.
Kernstück von scouter.de ist für die fünfstellige Anzahl an Bestandkunden ganz klar die native App bzw. der Buchungsbereich der Website, die auch als PWA funktioniert hat2. Diese war technologisch einigermaßen frisch, nämlich mit Vue.js umgesetzt, und mit Ralfs Hilfe waren wir tatsächlich gerade dabei, alles auf die Composition-API umzustellen und TypeScript einzuführen.
Wir haben also kurzerhand beschlossen, alle anderen scouter.de-Bestandteile in die Architektur der Web-App zu überführen: von PHP/jQuery zu Vue.js! Und weil man mit einer ultrafetten SPA keinen SEO-Blumentopf gewinnt, sollte das Ganze dann in eine statische Multi-Page-Applikation (oder auch Hybrid-App) überführt werden, die von jedem beliebigen Webhosting ausgeliefert werden kann.
Und hier kommt dann endgültig Nuxt ins Spiel, da hier das Zusammenspiel mit den vorhandenen Vue.js-Fragmenten mutmaßlich am besten funktionieren würde. Denn Nuxt ist zwar nicht offiziell Bestandteil des Vue.js-Projektes, aber es fühlt sich in der Praxis durchaus so an.
Warum nur statisches Hosting und kein serverseitiges JavaScript – das ist ja einer der großen Versprechen von Nuxt und Co.? Ganz ehrlich, weil ich den ganzen Node.js-Hostern wie Vercel oder netlify nicht über den Weg traue. Wenn wir schon die Website statisch rausrendern und dann „hydrieren“, dann muss der Server maximal dumm sein. Und das klappt mit Nuxt eigentlich auch ganz gut. Der vorgerenderte HTML-Code ist maximal schnell, zumindest beim Anzeigen der Einstiegsseite (egal, welche das sein mag). Sobald diese Einstiegsseite sich per JavaScript hydriert hat, verwandelt sich die MPA wieder zu einer SPA. Da sind wir dann übrigens gerade noch beim Finetuning unserer Matomo-Events.
Ein bisschen fummelig wird es leider in der Inhaltspflege. Hier setzen wir auf ProcessWire als Headless CMS und ein paar nicht so elegante Verrenkungen im Nuxt-Code, so dass wir zur richtigen Zeit (buildtime oder runtime?) die richtigen Daten (mit oder ohne Caching?) zur Verfügung haben.
Auch die Authentifizierung von CMS-Nutzern lösen wir manuell und nicht wahnsinnig elegant – hier wäre ein kleines bisschen Serverlogik nicht übel gewesen, aber es betrifft nur einen Spezialanwendungsfall, nicht etwa alle Carsharing-Kunden.
Wenn man schon mal dabei ist, einen großen Relaunch zu machen, gibt es natürlich immer noch Ideen. Denn statt einfach den Systemdienstleister auszutauschen und die Website in Nuxt statt in PHP zu bauen, kann man auch gleich alles neu machen, oder?
Neben der „großen“ Umstellung aller Komponenten zu Nuxt, könnte man noch einen ganzen Blumenstrauß an Technologien erwähnen, die wir entweder endlich mal zum Einsatz bringen wollten, oder die wir on-the-fly während des Projektes erlernen mussten. Als da wären:
Bereits seit 2021 nutze ich für die Buchungsfunktion eine SPA, die über das Capacitor-Framework in eine native iOS- und Android-App gegossen wird und somit ihren Weg in die App-Stores findet. Das Schöne für uns und die Kunden: Die Buchungsfunktion auf der Website scouter.de/buchen ist absolut identisch und kommt aus der gleichen Codebasis. Lediglich ein paar Conditionals beim Build sorgen dafür, dass unten eine Tabnavigation statt einer Burger-Navigation erscheint, und im Headerbereich die Farbflächen auch die diversen Notches und Safe Areas ausfüllt.
Das funktioniert wirklich gut, und ich bin großer Fan davon. Selbstverständlich kann es eine solche App nicht mit einer ausgereiften echten Nativ-Entwicklung aufnehmen. Aber dafür wäre absolut keine Zeit gewesen. Wir haben noch in den Tagen um den Launch herum relativ fundamentale Dinge geändert, die Dynamik war atemberaubend. Wenn man das jeweils alles dreifach (Web, iOS, Android) hätte implementieren müssen – keine Chance! War haben uns schnell bewegt und Dinge zerbrochen. Dafür ist Webtechnologie dann halt doch ganz geil.
Für genau dieses Projekt ist die gewählte Jamstack-Architektur genau das Richtige: Der pfeilschnelle statische Einstieg erfreut das Besucher- und SEO-Herz, aber gleichzeiig ist die komplexe JavaScript-Clientlogik überall auf der Website verfügbar und nicht in eine einzelne Vue-Insel eingesperrt. Das hat schon was.
Ideal zur Inhaltspflege ist es aber definitiv nicht – man kann keine frei gestaltbaren blockbasierten Seiten aufbauen oder pflegen, neue Pressemitteilungen erfordern einen Rebuild/Deployment des ganzen Projektes (dauert derzeit 7–8 Minuten). Aber es handelt sich eben nicht um eine redaktionelle Website, sondern um Marketing-Inhalte, die sich eher im Monats- oder Quartalsrhytmus ein wenig ändern, und dann auch meist sowieso noch einmal durch die Hand des Webentwicklers gehen müssen.
Das ist aber alles – zugegeben – ein bisschen Zufall, dass es hier insgesamt so gut passt. Auch in Zukunft wird ein Großteil der kleinen und mittelgroßen Websites mit einem serverseitig-dynamischen System wie Kirby oder ProcessWire am besten bedient sein.
]]>Auf der Suche nach einer Nachfolgelösung bin ich schon vor Monaten auf papierkram.de gestoßen, was weniger bekannt als lexoffice sein dürfte, aber nicht weniger nützlich für Freiberufler. Nach zwei Tagen Rumtesten bin ich ziemlich beeindruckt vom Funktionsumfang und der Übersichtlichkeit.
Die letzten zwei Jahre hatte ich eine Kombination aus
Dass dabei teilweise Zahlen abgetippt und Fehler entstanden sind, ist irgendwie naheliegend. Dafür habe ich alles genau verstanden, was da vor sich geht. Papierkram erledigt das jetzt aber alles für mich, hübsch integriert und sogar mit Smartphone-App. Ich kann nur empfehlen, sich das mal anzuschauen.
]]>Kann also sein, dass meine alltägliche Arbeit beim Neuaufbau von Websites und Apps sich in den nächsten Monaten ganz schön anders anfühlt. Und dabei habe ich noch gar nicht alle neuen CSS-Features der letzten 2 Jahre so richtig systematisch begriffen. Ich fange gerade erst an, Grids als selbstverständlich wahrzunehmen und nicht mehr als gefährliche Blutkante :-)
]]>Begonnen hat wahrscheinlich alles mit der Einführung von Node.js (2009) und npm (2010), mit deren explosionsartiger Ausbreitung und Erfolg die ganze Webdev-Welt umgekrempelt wurde. Es gibt heute kaum noch moderne Softwareprojekte fürs Web, die nicht Node als Basis verwenden, und sei es nur für Installation und Einbindung in den Buildingprozess.
Was die grundsätzliche Website/Webapp-Architektur angeht, gibt es gleich zwei parallel laufende Modelle, die beide nicht viel mit dem traditionellen WordPress/Joomla/Drupal-Ansatz zu tun haben.
Zum einen wäre da natürlich die Single-Page-Application (SPA), welche insbesondere mit dem Erscheinen von React (2013) und seinen jüngeren „Geschwistern“ Vue.js (2014) und Svelte (2016) für Aufsehen sorgte. Hier passiert quasi alles auf dem Gerät des Nutzers, welches sich erst einmal einen großen Batzen JavaScript herunterladen muss.
Zum anderen haben wir das Ideal des Jamstack aus dem Jahr 2016. Die Idee besteht darin, dass der Server nur noch stupide statische Seiten ausliefern muss. Bei Bedarf werden dann über Laufzeit-Javascript ganz präzise nur die gerade benötigten aktuellen Daten in die statischen Basis-Strukturen hineingeklebt – entweder über eine JSON-API, oder sogar gleich als HTML vorgerendert über SSR (Server-Side-Rendering).
Gerade das Thema Jamstack boomt seit 2022 extrem, und man kann das gut an der unfassbaren Anzahl von statischen Site-Generatoren erkennen, die auf Jamstack.org aufgelistet werden: Neben den Platzhirschen Next.js (2016), Nuxt (2016), Eleventy (2017) und Astro (2021) tummeln sich hier 350(!) weitere Softwareprojekte, die aus einer Dateistruktur eine statische Website generieren können. Manche sagen, dass dies insbesondere auf das Erscheinen von Vite (2020) zurückzuführen ist, mit dem das Builden und Serven so viel einfacher und schneller durchgeführt werden kann, dass sich ein Website-Framework quasi von selbst schreibt. Naja.
Ich blicke auf diese ganze Entwicklung mit dem Erstaunen eines Webentwicklers, der bisher ziemlich gut mit dem traditionellen LAMP-Stack zurechtgekommen ist. Ich kann natürlich verstehen, was der Reiz ist:
Es gibt aber eine ganze Reihe von Aspekten, die ich durchaus kritisch sehe. Vieles davon ist natürlich Gewöhnungssache, aber ein paar Punkte meine ich doch ansprechen zu können.
Da wäre zum einen die Sache mit der Performance. Ich glaube nicht, dass eine gut gecachte Website, die von einem traditionellen serverseiten CMS ausgeliefert wird, spürbar langsamer ist als eine superoptimierte Jamstack-Website. Die von mir bevorzugten CMSe ProcessWire und Kirby bieten in der Basisversion sehr ordentliches Caching an. Es besteht aber auch die Möglichkeit, die Seiten tatsächlich statisch herausrendern zu lassen, damit wären diese CMSe nichts anderes als PHP-basierte Static Site Generatoren, jedoch mit dem entscheidenden Vorteil, dass ich ein sehr komfortables Backend für die Inhaltspflege bekomme.
Gerade dieser Punkt ist meines Erachtens das Hauptproblem bei sehr vielen der modernen dateibasierten Website-Frameworks: Der Aspekt der Inhaltspflege wird fast nicht besprochen. Man solle halt diese geilen Front Matter-Dateien anlegen, die dann per Git ins Repo pushen, und dann wird das von einem Buildingprozess auf die Livedomian deployed. Alles klar, damit können nur absolute Webnerds ihre Inhalte pflegen.
Normale Redakteure brauchen aber ein gutes CMS. Also sind wir gezwungen, ein sogenanntes „Headless CMS“ zu nutzen, welches Inhalte über eine schicke GUI pflegbar macht, und dann über eine Schnittstelle in strukturierter Form an die statische Jamstack-Website weitergibt. Theoretisch fein, aber so richtig komfortabel fühlt sich das dann nicht mehr an, wenn man damit auf agile Weise „On-the-fly-Templating“ betreiben will, wie ich das meistens bei meinen Kundenwebsiten tue: Hier mal schnell ein paar Felder im CMS ergänzen, flott das Template für die Ausgabe anpassen, schon beherrscht die Website ein paar neue pflegbare Datenstrukturen, und das alles quasi im laufenden Betrieb, wenn man möchte.
Meine Hauptsorge bei Nuxt & Co. ist aber etwas ganz anderes. Es gibt bei fast allen Website durchaus noch Stellen, wo die dynamischen Fähigkeiten eines Servers gefragt sind: Kontaktformulare, Volltextsuche und passwortgeschützte Bereiche, um nur drei Beispiele zu nennen. Für die braucht man neuerdings dann einen Node.js-Webserver. Und die sind durchaus nicht so allgegenwärtig, standardisiert und erprobt wie LAMP-Hosting, was man ja in akzeptabler Qualität als Shared Hosting für sehr kleines Geld überall bekommen kann.
Doch damit nicht genug, und hier wird es ein bisschen gruselig: Viele der neuen Frameworks werden von großen Hosting-Dienstleistern mitfinanziert. Next.js ist ein Vercel-Produkt, Astro nennt netlify als offiziellen Hosting-Partner, und Gatsby hat sich erst kürzlich komplett von netlify einverleiben lassen. Somit kann man sicher sein, dass die coolsten Funktionen (oder die einfachsten Methoden, bestimmte Funktionen zu nutzen), den Kunden dieser Hosting-Providern vorenthalten sind. Wenn ich also in Astro ein funktionierendes Kontaktformular haben möchte, werde ich selbstverständlich aus Bequemlichkeit die speziellen Formular-Funktionalitäten von netlify nutzen. Und damit meine Seite kaum noch zu einem anderen Hosting-Anbieter transferierbar machen.
Somit werden die neuen Webframeworks, wenn man nicht aufpasst, immer mehr zu proprietären Baukasten-Systemen der modernen Hosting-Provider. Und irgendwie habe ich da keine Lust drauf. Nichts gegen hochperformant ausgelieferte statische HTML-Seiten, die aus einem coolen Static Site Generator rausfallen, gerne auch partiell hydriert und mit scharf. Aber für die Art von Websites, die ich bisher gebaut habe, mit viel Inhalt, der von Laien gepflegt wird, und die auf einem Standard-Hoster läuft, bei dem ich auch mal mit der deutschen Hotline telefonieren kann, fühlt sich der moderne Weg, Websites zu bauen, ganz schön umständlich an.
Aber ich bin auch neugierig, mehr zu erfahren. Insbesondere wie alltagstauglich das alles ist, und welche Art von Websites total profitiert von den aktuellen Hype-Systemen? Erleuchtet mich gerne mit euren Kommentaren auf Mastodon!
]]>An dieser Stelle herzlichen Dank an die Firma eShare.one für das Zurverfügungstellen des Fahrzeugs. Unsere Webagentur entwickelt im Auftrag von eShare.one verschiedene Carsharing-Websites für Kommunen und Stadtwerke – doch es gibt auch einen vollelektrischen Fuhrpark, den man im Rahmen der sogenannten Schnuppermiete nutzen kann. Wer also Interesse hat, und aus dem Raum Dortmund kommt, kann dort gerne für ein paar Tage eine kleine oder große Elektrokarre mieten!
Zurück zum Auto. Vor ein paar Tagen wurde bekannt, dass Tesla möglicherweise in Zukunft gar keine Autos mehr an Privatpersonen verkaufen möchte, sondern sich ausschließlich auf Flotten und Sharing-Konzepte konzentrieren möchte. Und mit den Erfahrungen, die ich gemacht habe, deckt sich das ganz gut: Das Model X ist kein Fahrzeug, welches man unbedingt besitzen möchte. Es ist irrsinnig teuer, dafür gar nicht mal so geschmackvoll gestaltet und hat viele kleine Probleme, wie beispielsweise die umständlichen und ein bisschen lächerlichen Falcon-Wing-Doors, die bei jedem dritten Öffnen aus nicht nachvollziehbaren Gründen nur zur Hälfte aufgehen, und bei denen Regenwasser auf dem Dach beim Öffnen ins Fahrzeug hineinfließt (kein Scherz).
Gleichzeitig ist das Model X aber ein fantastisches Reisemobil, weil es wirklich viel Stauraum bietet und sich absolut stressfrei fahren lässt. Kurz gesprochen: Das Fahren ist besser als das Besitzen. Klarer Vorteil für Miet- und Sharing-Konzepte!
Die Reise von Dortmund nach Würzburg (Tag 1), dann von Würzburg nach Österreich (Tag 2), und dann von Österreich nach Kroatien (Tag 3) gestalteten sich außerordentlich reibungslos, und das liegt an zwei Faktoren: Zum einen steht etwa alle 100 km ein Supercharger in direkter Autobahnnähe, zum anderen kennt das Auto diese Supercharger und plant eine idiotensichere Route, die man garantiert auch wirklich genauso fahren kann.
Natürlich gibt es etwas zu meckern! Manche Supercharger-Locations sind an etwas verlassenen oder schrottigen Raststätten bzw. Industriegebieten, was den Aufenthalt mit einem Kleinkind erschwert. Die eingeblendete Maximalgeschwindigkeit (gemäß Google Maps) ist zu 80 Prozent der Zeit totaler Humbug, weil real aufgestellte oder eingeblendete Verkehrsschilder nicht beachtet werden. Der vieldiskutierte Autopilot ist aus meiner Sicht nicht vertrauenswürdig und keine echte Erleichterung, weil man trotzdem ständig aufpassen muss, wenn ein bisschen Verkehr auf der Straße ist. Insbesondere wenn man sich die wackelige Schema-Darstellung der umgebenden Fahrzeuge im Display anguckt, wo lustig die Fahrzeugtypen hin- und herspringen und die auch immer gefühlt ein paar Sekunden hinterherhängt.
Dennoch: Es ist vor allem die Zuverlässigkeit der Infrastruktur, und erst in zweiter Linie die große Batterie, die das Langstreckenfahren mit Tesla so entspannt macht. Man weiß einfach, dass das Aufladen in akzeptabler Zeit funktionieren wird. So banal, so wichtig! Inzwischen gibt es auch auf der besprochenen Strecke so manche Nicht-Tesla-Ladesäule, die man mit jedem Auto nutzen kann. Allerdings bleibt dabei immer eine Restunsicherheit, ob diese Säule überhaupt in Betrieb ist, und ob ich den Ladevorgang auch starten kann, ohne Mitglied bei irgendeiner Plattform zu werden. Und was es dann letztlich kostet.
Bei unseren jeweiligen Übernachtungsmöglichkeiten konnte ich dann schön über Nacht per Typ2-Kabel mit 16 kW aufladen. Im österreichischen Altenmarkt per kostenpflichtiger Website-Freischaltung an einer öffentlichen Ladesäule im Dorf. In Kroatien kostenlos direkt am Ressorthotel – sehr aufmerksam. Diese Ladesäulen habe ich aber spontan vor Ort ausfindig gemacht – es wäre auch ohne gegangen.
Für die vielen gefahrenen Kilometer war die Reise im Model X wirklich sehr angenehm. In der Stadt wäre ein solches Monsterauto ein echtes Hindernis. Es hat also für mich als Vorort-Bewohner schon einen Sinn, kleine bis mittelgroße Autos für die täglichen Besorgungen zu besitzen, und für längere Strecken ein größeres Auto zu mieten. Und derzeit muss das tatsächlich noch ein Tesla sein. Mit einem e-Niro von Kia wäre das alles zwar auch denkbar gewesen. Ich hätte es mich aber schlichtweg in diesem Sommer noch nicht getraut.
]]>Die alte ZOE hat 22 kWh, der eGolf 32 kWh, der Leaf 2 kommt derzeit mit 40 kWh, der Hyundai Kona mit 64 kWh, Tesla-Fahrzeuge gar mit 75 bis 100 kWh. Eine große Batterie ist schon was Feines – allerdings auch mit Abstand der größte Kostenfaktor und der größte Energierucksack, den ein E-Auto bereits mit 0 Tachokilometern mit sich führt. Li-Ion-Batterien sind in der Herstellung ziemlich energieintensiv, und längst nicht alle Zellen-Hersteller setzen auf Ökostrom. Besser für Geldbeutel um Umwelt also, man entscheidet sich für eine Batterie, die ausreichend groß ist, nicht maximal groß!
Je schneller ich am Autobahn-Schnelllader Strom tanken kann, desto langstreckentauglicher wird mein Fahrzeug. Und da ist es dann schon entscheidend, ob ich nur maximal 22-kW-Wechselstrom nuckeln kann (wie die aktuelle ZOE), ob ich mit 70 kW an der Gleichstrom-Säule schlürfe (wie mit einem Hyundai oder Kia), oder ob ich gar mit über 100 kW am Supercharger mein Model S von Tesla druckbetanke. Lieber drei Ladestopps mit je 15 Minuten Wartezeit als ein Ladestopp mit zwei Stunden Wartezeit – oder so ähnlich. Große Akkus alleine helfen nicht, wenn man nur langsam laden kann. Es sei denn, man schafft die Wunschstrecke am Stück und(!) kann am Zielort bequem vollmachen.
Ein sparsames E-Auto braucht weniger Akkukapazität für die gleiche Einzelreichweite. Eine Binsenweisheit. Doch kaum jemand weiß, was die einzelnen Fahrzeuge so verbrauchen. Sagen wir es vereinfacht: Unter 100 km/h hängt der Verbrauch vor allem von Antriebs- und Klimatechnik ab (z. B. Wärmepumpe). Über 100 km/h wird dann die Windschnittigkeit wichtiger. Das sparsamste E-Auto ist derzeit der Hyundai Ioniq mit seiner tiefgelegten Tropfenform. Die ganzen ach so modernen SUV-ähnlichen Fahrzeuge schneiden hier merklich schlechter ab. Und auch die fetten Tesla-Schiffe S und X bekleckern sich nicht gerade mit Ruhm, was den Verbrauch angeht, gleichen das eben über die riesigen Akkus und damit teuren Anschaffungskosten wieder aus. Für Einsteiger: Ein sehr guter E-Auto-Verbrauch liegt bei 11–14 kWh auf 100 km, ein schlechter bei 25–30 kWh.
Also, Leute: Bevor ihr zum riesigen Akku greift, checkt erstmal die anderen Faktoren, wenn es um die Langstreckentauglichkeit geht. Der Hyundai Ioniq hat sich da bereits entschieden, kommt mit nur 28 kWh aus, lädt dafür schnell und verbraucht wenig. Ein guter Deal. (Und ja, natürlich kommt bald das Facelift mit 39er-Akku. Dann wird das Ding noch mehr rocken.)
]]>Als reine Stadtfahrzeuge sind die drei baugleichen Fahrzeuge Citroën C-Zero, Mitsubishi EV (ehemals i-MiEV) und Peugeut iOn im Grunde nicht verkehrt. Sie kamen 2011 auf den Markt, sind allesamt ein bisschen hässlich, aber für ganz viele Anwendungsfälle reichen sie dicke! In Berlin konnte man den C-Zero einige Jahre im Multicity-Carsharing nutzen, was vielen die E-Mobilität erstmals nahe gebracht hat (unter anderem mir). Wenn das Budget knapp und der Anwendungsfall ganz klar ist, kann man hier durchaus ein Schnäppchen machen. Vom Aufladen mit CHAdeMO sollte man sich nicht zuviel versprechen – dieser Standard hat kaum Zukunft in Deutschland und ist auch fast nur auf Autobahnen zu finden, wo die Drillinge nichts verloren haben.
Technisch gesehen steckt im aktuellen smart EQ eine ganze Menge von Renault – der smart EQ ist im Grunde eine merklich günstigere ZOE, aber mit geringerer Reichweite und ohne Mietoption bei der Batterie. Kurioserweise kostet der Viersitzer nicht wesentlich mehr als der klassische smart- Zweisitzer (Unterschied sind nicht einmal 700 Euro) – es ist also reine Geschmackssache, welches Modell man nimmt – das fetzige Zweisitzer-Cabrio ist allerdings dann doch über 3.000 Euro teurer. Wen die überschaubare Reichweite nicht stört und Lust auf urbane Hipness hat, kann hier gerne zugreifen. Die Batterien scheinen bei smart die Wucht zu sein: Man hörte jüngst von Fahrzeugen mit 200.000 km und noch 90% Batteriegesundheit.
Die ZOE ist nicht brutal hochwertig, dafür aber stylisch und minimalistisch in der Ausstattung. Die Gretchenfrage ist: Fahre ich mit dem Wagen auch Strecken, bei denen ich zwingend einen (Autobahn)-Ladestopp benötige? Falls ja: Finger weg! Falls nein: Die ZOE lässt sich ideal zuhause oder am Zielort aufladen, innerhalb von 2–3 Stunden am 22kW-Lader oder in 10–18 Stunden an der Schuko-Steckdose. Wer maximal 40 km einfachen Pendelweg hat, kommt mit dem kleinen Akku sehr gut zurecht, auch im tiefsten Winter. Wer mehr Strecke benötigt, greift zum großen Akku. Unlimitierte Kilometer für 119 Euro im Monat. Der Kauf der Batterie lohnt sich ggf. erst nach 10 oder 12 Jahren, allerdings ist eine ZOE mit Batteriemiete komplizierter zu verkaufen.
Wer des öfteren Strecken zwischen 130 und 300 Kilometern fährt, und keine Lust auf Reichweitenangst hat, lädt unterwegs mindestens ein- bis dreimal auf. Damit diese Ladestopps zügig voran gehen, muss die Ladegeschwindigkeit stimmen, und der Stecker muss passen. In Deutschland kommt man an CCS demnach nicht vorbei, und folgende Fahrzeuge sind dafür besonders gut geeignet: Hyundai IONIQ (28 kWh) und ab Mitte 2019 der Kia e-Niro (39 kWh). Ersterer hat (noch) einen relativ kleinen Akku, verbraucht aber aufgrund seiner flachen Bauform sehr wenig Strom. Der Kia kommt erst Mitte 2019 auf den Markt, dürfte aber vom Preis-Leistungsverhältnis hochgradig interessant sein. Der „kleine“ Hyundai Kona mit 39er Batterie ist übrigens nicht zu empfehlen, da er aus Gründen, die niemand verstehen kann, die versprochene Ladegeschwindigkeit nahezu niemals tatsächlich erreicht und de facto bei ca. 40 kW dümpelt.
Wenn es unbedingt ein deutscher Hersteller sein soll, kommt eigentlich nur der i3 von BMW in Frage. Die Batteriekapazität wurde hier immer mal wieder angepasst, aktuell sind 35 kWh verbaut, was für gelegentliche Fahrten auf der Autobahn voll okay ist. Leider kann die Batterie auch beim neuesten i3-Modell nur bis zu 50 kW per CCS aufnehmen, hier bieten Hyundai und Kia derzeit mehr!
Nach dem de facto nicht erhältlichen Opel Ampera-e ist der Hyundai Kona das erste halbwegs erschwingliche Elektrofahrzeug, bei dem man auch im Winter so lange auf der Autobahn fahren kann, wie man es ohne Pause auch durchhält. Strecken bis 500 km können also in einer ähnlichen Geschwindigkeit realisiert werden wie mit einem Verbrenner – schnelle CCS-Lademöglichkeiten vorausgesetzt – der Kona kann bis zu 80 kW vertragen, am praktischen Nasenlader vorne. Der 2019 erscheinende Kia e-Niro teilt sich viele Komponenten mit dem Kona, ist etwas weniger hochwertig im Innenraum, dafür etwas geräumiger vom Platzangebot, und ein kleines bisschen günstiger.
]]>Es folgte ab ca. 2010 unter dem Codenamen Adobe Edge eine Reihe von halbherzig-experimentellen Softwareprodukten für Webentwickler*innen, die nie so richtig gezündet haben (Animate, Reflow, Code, Inspect). Spätestens zu dieser Zeit begann Adobe auch immer stärker, sich an die inzwischen cool gewordene Webentwicklungs-Szene ranzuwanzen, entsprechende Events zu sponsoren, Blogger*innen mit Geld zu bewerfen und einen Image-Wandel zu versuchen. Selbst ein paar Vorschläge zur Erweiterung von CSS-Eigenschaften kamen in dieser Zeit von Adobe.
Im gleichen Atemzug verleibte Adobe sich 2011 den noch jungen Webfont-Service Typekit ein, und gliederte ihn vor wenigen Wochen nun komplett in die eigene Produktmietwelt CreativeCloud ein, wo das einst coole Startup leider nur noch ein Schattendasein fristen wird.
In den Adobe Labs köcheln zusätzlich seit Jahren jede Menge Kuriositäten fürs Web, beispielsweise Adobe Muse, mit dem man ohne Code-Kenntnisse halb-responsive Websites basteln kann, welche nach meinem Dafürhalten aber lediglich Prototypen-Qualität besitzen. Nichtsdestotrotz wird das Tool unter Designer*innen als legitimer und schlanker Dreamweaver-Nachfolger gefeiert. Das kürzlich bekannt gegebene Muse-Sunsetting hat zu vielen traurigen Reaktionen geführt.
Derzeit wird aber vor allem Adobe XD gepusht, ein codefreies Web-Prototypen-Tool, allerdings vernünftigerweise ohne die Möglichkeit, die Ergebnisse auch tatsächlich als Website zu exportieren, wie das in Muse der Fall war.
Und diese Aufzählung ist beileibe noch nicht komplett.
Weite Teile dieser mannigfaltigen Web-Bemühungen in den letzten 20 Jahren dürfen aus meiner Sicht als gescheitert angesehen werden. Adobe hat in der Webwelt nie richtig Fuß fassen können. Ich frage mich bisweilen, woran das liegt.
Ganz klar hat es etwas mit der Geschwindigkeit zu tun, in der sich die Art und Weise verändert, wie wir Websites vorgestern, gestern und heute entwickeln:
Adobe kann bei diesen schnellen Paradigmenwechseln nicht mithalten, dafür ist die Firma zu groß und schwerfällig – allen Edge-Initiativen und experimentellen Laboratorien zum Trotz. Echte Innovation gibt es leider nur in zugekaufter Form (Macromedia, Typekit), um sie dann kaputtzuvereinheitlichen, und zwar stets zielsicher am Bedarf der maßgeblichen Kundschaft vorbei.
Ein weitere Faktor ist aber auch der starre Fokus auf die kreativen Designer*innen als Zielgruppe. Adobe ignoriert immer noch die massiven technischen und kulturellen Unterschiede zwischen Print, statischem Screen und dynamischem Web. Für den Konzern sind das alles nur unterschiedliche Ausspiel-Medien der gleichen Kreativität. Es beginnt bereits mit der Wortwahl – ein Großteil der professionellen Webentwickler*innen würde sich eher die rechte Hand abhacken, als kreativ genannt zu werden. Webdesigner ist ein verbranntes Wort (auch wenn ich es mit trotzigem Stolz immer noch verwende). Adobe richtet sich an alle Arten von visuellen Designer*innen, ohne zu verstehen, dass Frontend-Entwickler*innen keine Designer*innen sein mögen. Also werden sie die Frontend-Entwickler*innen, die heute die maßgeblichen Personen im Web darstellen, auch nicht als Kund*innen gewinnen können.
Das Web bewegt sich sich in eine Richtung, in der die Art von Webdesign, wie sie sich Adobe vorstellt, immer weniger wichtig wird. Die Integration von Photoshop ist völlig irrelevant, wenn man nach einem groben Sketch-Mockup sofort in einen echten HTML-Prototypen wechselt. Wer direkt CMS-Templateschnipsel in HTML und Sass umsetzt, braucht keinen XD-Klickdummy mehr. Je agiler der Workflow, desto weniger werden Entwürfe 1:1 abgesegnet, die zuvor im CreativeCloud Showroom bestaunt werden konnten. So läuft das alles nicht mehr – zumindest immer seltener.
Ob da nochmal was kommt? Ich bezweifele es. Selbst Microsoft hat jüngst mehr Gespür bewiesen und mit Visual Studio Code und dem Kauf von Github zwei Volltreffer ins Herz der Webgemeinde gelandet. Soll Adobe
abermals auf Einkaufstour gehen? Sich dabei Sketch, CodeKit, Fontspring und Tower kaufen? Wohl eher nicht, solange nur ein CreativeCloud-Kunde ein guter Adobe-Kunde ist. Webworker sind jedoch untreu, sie wechseln ihren Werkzeugkoffer öfter als die Unterhose – das sind keine rosigen Aussichten für einen Konzern, der auf beständigen Geldfluss und die Alternativlosigkeit seiner Software setzt.
Keine Frage, eine Photovoltaik-Anlage musste aufs Dach! Die Planungen dafür sind inzwischen fast zwei Jahre alt, es hat aus diversen extrem nervigen Gründen dann bis zur Inbetriebnahme viel länger gedauert, aber das soll nicht das Thema sein. Vielmehr ein paar technische Infos: Unser Satteldach zieren nun 26 PV-Module mit je 270 W Maximalleistung, macht also insgesamt rund 7 kW. Davon bleiben in der Realität dann knapp 6 kW übrig, wenn die Sonne absolut am Zenit steht, was man hier sehr schön erkennen kann:
Das war am 1. Juli, ein absolut wolkenloser Tag mit knalliger Sonne. Wenn ein paar Wolken vorbeiziehen, sieht das schon etwas krakeliger aus:
Im Juli habe ich bisher durchschnittlich 35 kWh Sonnenenergie pro Tag geerntet. Zunächst wird mit dem Strom natürlich die Hausbatterie vollgemacht, welche 7 kWh Kapazität hat. Wenn diese voll ist, wird der Reststrom ins Netz eingespeist. Sobald es dunkel wird, wird der Spaß umgedreht – die Batterie versorgt das Haus solange mit Strom, bis sie leer ist, und dann beziehe ich den noch notwendigen Strom aus dem Netz. Ein typischer Zyklus sieht also im Hochsommer so aus:
Die roten Verbrauchsspitzen sind der Warmwasser-Herstellung durch die Wärmepumpe zu verdanken. Und dann kommt man auf die Idee, die ZOE an der 22-kW-Wallbox aufzuladen:
Wie man sieht, packt das interne System die 22 kW bei weitem nicht – die Hausbatterie kann den angeforderten Strom gar nicht schnell genug hergeben, es muss noch massiv aus dem Netz Strom bezogen werden. Diese Situation wird sich mit dem neuen Auto dann entspannen – der Hyundai Ioniq lädt mit maximal 7 kW an der Wallbox, das kann dann im Hochsommer zur Mittagszeit von Sonne und Hausbatterie wohl gut geleistet werden, der Beweis steht aber noch aus.
Was kostet jetzt so ein Spaß? Und rechnet sich das? Nun, das werden wir sehen. Wir haben uns für ein Flatrate-Modell unseres lokalen Stromanbieters entschieden, welches eine Laufzeit von zwanzig Jahren hat. Wir zahlen einmalig die Anschaffung der PV-Module und der Hausbatterie, und eine monatliche Pauschale (deutlich unter 50 Euro) für die Stromversorgung. Damit ist alles abgegolten – egal, wieviel wir einspeisen oder aus dem Netz beziehen. Nur der Gesamtverbrauch von 8.000 kWh dürfte sich nicht zu deutlich ändern, es gibt aber einen Toleranzbereich.
Der Clou für mich: Planungssicherheit für die nächsten 20 Jahre, denn die monatliche Pauschale ist fix. Der Clou für den Versorger: Er kriegt meinen gesamten Reststrom für lau. Das führt dazu, dass es in seinem eigenen Interesse ist, dass die Anlage läuft und ordentlich PV-Strom generiert. Defekte Module werden ausgetauscht und ggf. sogar gesäubert, denn jede kWh, die ich mehr produziere aber nicht selber verbrauche, geht an den Versorger.
Die Anlage rechnet sich nach 7 bis 14 Jahren finanziell – abhängig davon, wie sich der Preis für Strom auf dem Markt entwickelt. Denn was ich hier mache, ist eine Verabschiedung vom verbrauchsabhängigen Strompreis. Je teurer der Strom für euch wird, desto besser für mich und meine Amortisierung. Ein ganz schöner Perspektivwechsel!
Ach ja, für die Nachkriegsgeneration ist ja die Autarkie so wahnsinnig wichtig. Für mich eigentlich nicht, aber sei’s drum: Mir wurde ein Autarkiegrad von irgendwie 50 % errechnet. Das heißt allerdings im Wesentlichen, dass ich im trüben Herbst und Winter mit ständig laufender Heizung beinahe den gesamten Strom aus dem Netz beziehen werde (wie bisher auch), und im knalligen Sommer wie aktuell leicht auf 98 % Autarkie komme (ausgenommen an Tagen, wo ich den Wagen auflade). Insgesamt kein wichtiger Punkt für mich. Echte Autarkie hat man meines Erachtens nur mit wesentlich (wesentlich!) größeren Strom- oder Wärmespeichern, oder halt mit Dieselgeneratoren. Aber wo bekommt man den Diesel her? Eine andere Geschichte, fürchte ich.
Auf Wunsch der Kommentarsektion hier ein paar technische Details, obwohl ich nicht zuviel dazu weiß, da das gesamte System als Komplettpaket im Rundum-Sorglos-Modus verkauft wurde.