{ "version": "https://jsonfeed.org/version/1", "title": "nil?", "home_page_url": "https://old-school.dev/", "feed_url": "https://old-school.dev/feed.json", "description": "Old-School-Web-Developer-Blog. Rails, Frontend, Javascript, Rants.", "icon": "https://old-school.dev/apple-touch-icon-180x180.png", "favicon": "https://old-school.dev/favicon.ico", "expired": false, "items": [ { "id": "https://old-school.dev/2022/12/21/under-reconstruction/", "title": "Under (Re-)Construction", "summary": "", "content_text": "Long time no read! Aber da jetzt wg. Elon und Twitter die große Re-Dezentralisierung und Rückbesinnung auf gute alte Sachen wie Blogs beginnt (sagen sie zumindest überall, schaun mer mal…), wird dieses kleine etwas eingeschlafene Blog gerade ein wenig »realigned« und irgendwann im Januar mit neuem Glanz zurückkommen.Und auf Mastodon bin ich auch wieder (trotz »Fott damet«): @oldschooldev@masto.futbol", "content_html": "
Long time no read! Aber da jetzt wg. Elon und Twitter die große Re-Dezentralisierung und Rückbesinnung auf gute alte Sachen wie Blogs beginnt (sagen sie zumindest überall, schaun mer mal…), wird dieses kleine etwas eingeschlafene Blog gerade ein wenig »realigned« und irgendwann im Januar mit neuem Glanz zurückkommen.
Und auf Mastodon bin ich auch wieder (trotz »Fott damet«): @oldschooldev@masto.futbol
", "url": "https://old-school.dev/2022/12/21/under-reconstruction/", "tags": ["miszellen"], "date_published": "2022-12-21T13:55:00+01:00", "date_modified": "2022-12-21T13:55:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2021/10/26/es-ist-liebe/", "title": "Es ist Liebe!", "summary": "", "content_text": "Josh Marcello – »A Love Letter to Ruby and Rails«: »In my experience working in other technologies, 50-80% of my time is spent solving technology problems and what's left is used to solve actual business problems. These technology problems are tasks such as building out database connections, setting up boilerplate, writing build pipelines, etc. Meanwhile with Rails I've noticed I get to spend spent the vast majority of my time focusing on business logic.«Ich würde es nicht gar so lyrisch wie Josh ausdrücken, aber das ist auch meine Erfahrung. Während manche noch ihr tolles Serverless konfigurieren und sich die Festplatte mit npm füllen, tippen wir trocken ein rails new schoenenuetzlicheapp ins Terminal und beginnen mit der Programmierung.Auch 2021 ist Ruby on Rails immer eine gute Wahl für ein Webprojekt. Zumal man auch zunehmend weniger anstrengende Lösungen für die glorreichen JavaScript-Segnungen der Moderne im gewohnten Rails-Stil mitgeliefert bekommt…", "content_html": "Josh Marcello – »A Love Letter to Ruby and Rails«:
»In my experience working in other technologies, 50-80% of my time is spent solving technology problems and what's left is used to solve actual business problems. These technology problems are tasks such as building out database connections, setting up boilerplate, writing build pipelines, etc. Meanwhile with Rails I've noticed I get to spend spent the vast majority of my time focusing on business logic.«
Ich würde es nicht gar so lyrisch wie Josh ausdrücken, aber das ist auch meine Erfahrung. Während manche noch ihr tolles Serverless konfigurieren und sich die Festplatte mit npm füllen, tippen wir trocken ein rails new schoenenuetzlicheapp ins Terminal und beginnen mit der Programmierung.
Auch 2021 ist Ruby on Rails immer eine gute Wahl für ein Webprojekt. Zumal man auch zunehmend weniger anstrengende Lösungen für die glorreichen JavaScript-Segnungen der Moderne im gewohnten Rails-Stil mitgeliefert bekommt…
", "url": "https://old-school.dev/2021/10/26/es-ist-liebe/", "tags": ["rails","ruby","meta"], "date_published": "2021-10-26T11:54:00+02:00", "date_modified": "2021-10-26T11:54:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2021/10/09/abgruende-moderner-webentwicklung/", "title": "Abgründe moderner Webentwicklung", "summary": "", "content_text": "Kent C. Dodds: »How I built a modern website in 2021«.Es gab selten etwas zu lesen, was die Abgründe »moderner« Webentwicklung so schön beschreibt. Das Lustige daran: Mr. Dodds findet das genau so ziemlich großartig. Und andere auch, schaut man sich das Echo in Social Media an. Da sitzt der »Old-School-Developer« staunend vor dem Endgerät…", "content_html": "Kent C. Dodds: »How I built a modern website in 2021«.
Es gab selten etwas zu lesen, was die Abgründe »moderner« Webentwicklung so schön beschreibt. Das Lustige daran: Mr. Dodds findet das genau so ziemlich großartig. Und andere auch, schaut man sich das Echo in Social Media an. Da sitzt der »Old-School-Developer« staunend vor dem Endgerät…
", "url": "https://old-school.dev/2021/10/09/abgruende-moderner-webentwicklung/", "tags": ["javascript","tooling"], "date_published": "2021-10-09T11:30:00+02:00", "date_modified": "2021-10-09T11:30:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2021/07/06/zwitschiloesch/", "title": "zwitschiloesch.rb, oder: Wie man mit Ruby den eigenen Twitter-Account leert!", "summary": "", "content_text": " Twitter ist ein gefährliches Netz-Pflaster geworden. Irgendein schnoddriger Tweet von 2012 kann Dich einholen und Dir in der dort mittlerweile 24/7/365 tobenden Polit- und Ideologie-Schlacht um die Ohren gehauen werden. Davon abgesehen schadet es eh nicht, mal die Netz-Spuren von Jahren ein wenig zu verwischen…Es ist im Hause Twitter nicht vorgesehen, dass man die Inhalte des eigenen Twitter-Account »einfach so« auf einmal löschen kann. Mit ein paar Zeilen Ruby und dem Twitter-Gem kann man sich aber selbst etwas bauen, was den eigenen Twitter-Account gründlich leert…(Photo by Jeremy Zero on Unsplash, thanx!)Twitter: »Du sollst nicht löschen!«Wie gesagt, das Löschen von vielen (oder allen) Tweets des eigenen Accounts ist bei Twitter nicht vorgesehen. Dort erwartet man, dass man alle Tweets einzeln aufruft, auf »Löschen« klickt und das bestätigt. Das machen sie natürlich deshalb so umständlich wie möglich, weil der große digitale Müllberg der im Laufe der Jahre angefallenen Millionen und Abermillionen von Tweets ihr »Kapital« ist.Es gibt verschiedene externe Dienste, die einem beim einmaligen oder zeitgesteuerten Löschen der eigenen Tweets unterstützen, aber denen muss man natürlich einen recht umfangreichen Zugriff auf den eigenen Account gewähren. Was immer ungut ist, denn solche Dienste können in die Hand von Leuten fallen, deren Ansinnen Schabernack ist…zwitschiloesch.rbAlso bauen wir lieber selbst etwas. Eine Warnung vorweg:Dieser Code macht ernst! Wenn man sich das Ruby-Skript anlegt und laufen lässt, dann löscht es unwiderruflich die Tweets des eigenen Twitter-Accounts! Es gibt keine Nachfragen ob man »wirklich will« – es wird gelöscht und die Tweets sind weg!VorarbeitenBei eigenen Twitter-API-Anwendungen hat man nur eine begrenzte Anzahl an API-Requests pro Zeitraum zur Verfügung, was das Löschen von vielen Tweets (bei meinem seit 2007 existierenden Account über 60.000) zu einer langwierigen Angelegenheit machen würde. Denn um die ID der Tweets zu bekommen, müssten wir diese erst einmal alle einlesen. Nach etwa 3000 Requests wäre dann aber Schluss und man müsste erst einmal 15 Minuten Pause einlegen, um die nächsten 3000 einzulesen.1. Twitter-Archiv besorgenDamit das nicht nötig ist, holen wir uns die IDs aller im Account existierenden Tweets auf einem anderen Weg. Man kann sich in Twitter ein Archiv aller Account-Daten erstellen lassen. Nach diversen Abfragen von Passwort, Zugangs-Code etc. bekommt man dann irgendwann einen Downloadlink für das eigene Twitterarchiv. Packt man dieses aus, findet man im Verzeichnis »data« eine Datei namens tweet.js. Die brauchen wir!2. Twitter-Gem besorgenDie Kärrnerarbeit der Kommunikatiom mit Twitter übernimmt das Twitter-Gem. Dieses lässt sich unter Ruby 2.4 bis 2.7 mit gem install twitter installieren und ist dann verfügbar.3. Twitter-App anlegen und Zugang konfigurierenVor die Nutzung des Twitter-Gems haben die Twitter-Götter das Erstellen eines Haufen von IDs und Token gesetzt, Details dazu findet man in der Doku des Twitter-Gems. Zum Löschen von Tweets braucht man »Single-user Authentication«. Das ist leider alles etwas kompliziert und aufwändig und die Beschreibung dieser Dinge wäre ein deutlich längerer Artikel als zwitschiloesch selbst. Wie man das angeht, kann man z.B. sich bspw. in envatos Tutorial an einem Beispiel in PHP ansehen. Am Ende des OAuth-Geweses sollte man Consumer-Key und -Secret für seine neue Twitter-API-App sowie ein Access-Token und ein Access-Token-Secret für den Zugriff dieser App auf den Account besitzen. Nun kann man endlich mit dem Löschen beginnen!Wir löschen unsere Tweets!Das gesamte Skript ist in einem Github-Gist verfügbar. Um es zu nutzen, müssen zunächst oben im Config-Block einige Einstellungen vorgenommen werden: # Config require \"twitter\" config = { consumer_key: \"Der Twitter-Consumer-Key\", consumer_secret: \"Das Twitter-Consumer-Secret\", access_token: \"Das Access-Token\", access_token_secret: \"Das Access-Token-Secret\" } twitta = Twitter::REST::Client.new(config) twarchiv = \"/pfad/zur/datei/im/twitter-archiv/namens/tweet.js\" stopwords = [\"nothing\",\"old-school.dev\",\"borussia\"] rcount = 0In config müssen die Zugangsdaten zu Twitter (s.o.) gespeichert werden, außerdem braucht die Variable twarchiv den Pfad zu der tweet.js im Verzeichnis data des downgeloadeteten Twitterarchivs (ebenfalls s.o.).Eine Besonderheit sind die stopwords. Enthält ein Tweet einen String aus diesem Array, so wird dieser nicht gelöscht. Das kann auch eine URL sein, das Skript löst dazu die t.co-Links von Twitter auf. Das ist praktisch, wenn man z.B. das ganze Gelaber löschen, aber Tweets mit Links zum eigenen Blog (oder über Borussia) erhalten möchte. Ausnahme sind »Replies«, das Skript geht davon aus, dass Antworten auf anderer Leuts Tweets immer weg sollen. Wenn man das nicht möchte, muss man das im Code ändern.Damit ist alles bereit, die Verarbeitung selbst ist ganz einfach. Lediglich die Ermittlung der wahren URL hinter dem t.co-Link ist etwas umständlich, Twitter verwendet da für so etwas einfaches wie einen Tweet unnötig komplizierte Datenstrukturen. Aber auch das bekommen wir hin: # Verarbeitung JSON.parse(File.read(twarchiv).gsub(\"window.YTD.tweet.part0 = \",\"\")).each do |tw| # Wenn wir Tweets mit Links auf eine bestimmte URL aufheben wollen, # muessen wir die richtige URL auslesen, der Tweettext enthält # nur den gekuerzten Link auf t.co. tw_url = '' tw[\"tweet\"].each do |el| if el[0]==\"entities\" el[1].each do |ent| if ent[0]==\"urls\" if ent[1].size > 0 tw_url = ent[1][0][\"expanded_url\"] end end end end end full_text = \"#{tw[\"tweet\"][\"full_text\"].to_s} #{tw_url}\".downcase # Ermitteln ob der Tweet eine Reply ist, Replies werden immer geloescht! is_reply = false if tw[\"tweet\"][\"in_reply_to_status_id_str\"] is_reply = true end # Entscheiden ob man den Tweet loeschen moechte delete_it = false if is_reply # Replies immer loeschen! delete_it = true else # Schauen ob eines der stopwords enthalten ist unless stopwords.any? {|s| full_text.include?(s.downcase)} delete_it = true end end # Loeschen if delete_it begin puts \"#{rcount}: zwitschiloesch #{tw[\"tweet\"][\"id_str\"]}\" twitta.destroy_tweet tw[\"tweet\"][\"id_str\"].to_s if kill rescue Twitter::Error::NotFound => e puts \" => ERR not found\" rescue Twitter::Error::Forbidden => e puts \" => ERR forbidden: #{e}\" end else puts \"#{rcount}: keep #{tw[\"tweet\"][\"id_str\"]}\" end rcount += 1 end»So geht das!«Damit ist alles klar, wir können uns an die Arbeit machen. Das Skript gibt es in einem Github-Gist, nach der Änderung der Config kann man es laufen lassen. Noch einmal eine Warnung: Das Skript fragt nicht mehr nach, es tut was es machen soll: Löschen! Und nichts bringt einmal gelöschte Tweets wieder zurück. Wat fott es es fott!Allerdings nicht so ganz, führt man es einfach mit ruby zwitschiloesch.rb aus, so gibt es zunächst einmal nur aus, was es machen würde. Möchte man tatsächlich zur Tat schreiten, so muss man noch den Parameter kill angeben: ruby zwitschiloesch.rb killDann gibt es kein zurück mehr, wie der Protagonist Billy Pilgrim in Kurt Vonneguts »Schlachthof 5« stets sagt, wenn jemand getötet wird: »So geht das!«Übrigens scheint es für das Löschen via Twitter-API kein Limit zu geben, das Entfernen von über 60.000 Tweets aus meiner tweet.js lief ohne Probleme durch.Mehr Spaß mit dem Twitter-GemDa man nun die ganze Mühsal der Konfiguration hinter sich hat, kann man das Skript auch als Basis für jegliche Aktionen mit dem Twitter-Gem nutzen, denn das kann eine ganze Menge. Z.B. könnte man ein Skript bauen, das regelmäßig per Cron den eigenen Account scannt und neu dazugekommene Tweets nach einem definierten Zeitraum löscht.", "content_html": "Twitter ist ein gefährliches Netz-Pflaster geworden. Irgendein schnoddriger Tweet von 2012 kann Dich einholen und Dir in der dort mittlerweile 24/7/365 tobenden Polit- und Ideologie-Schlacht um die Ohren gehauen werden. Davon abgesehen schadet es eh nicht, mal die Netz-Spuren von Jahren ein wenig zu verwischen…
Es ist im Hause Twitter nicht vorgesehen, dass man die Inhalte des eigenen Twitter-Account »einfach so« auf einmal löschen kann. Mit ein paar Zeilen Ruby und dem Twitter-Gem kann man sich aber selbst etwas bauen, was den eigenen Twitter-Account gründlich leert…
(Photo by Jeremy Zero on Unsplash, thanx!)
Wie gesagt, das Löschen von vielen (oder allen) Tweets des eigenen Accounts ist bei Twitter nicht vorgesehen. Dort erwartet man, dass man alle Tweets einzeln aufruft, auf »Löschen« klickt und das bestätigt. Das machen sie natürlich deshalb so umständlich wie möglich, weil der große digitale Müllberg der im Laufe der Jahre angefallenen Millionen und Abermillionen von Tweets ihr »Kapital« ist.
Es gibt verschiedene externe Dienste, die einem beim einmaligen oder zeitgesteuerten Löschen der eigenen Tweets unterstützen, aber denen muss man natürlich einen recht umfangreichen Zugriff auf den eigenen Account gewähren. Was immer ungut ist, denn solche Dienste können in die Hand von Leuten fallen, deren Ansinnen Schabernack ist…
Also bauen wir lieber selbst etwas. Eine Warnung vorweg:
Dieser Code macht ernst! Wenn man sich das Ruby-Skript anlegt und laufen lässt, dann löscht es unwiderruflich die Tweets des eigenen Twitter-Accounts! Es gibt keine Nachfragen ob man »wirklich will« – es wird gelöscht und die Tweets sind weg!
Bei eigenen Twitter-API-Anwendungen hat man nur eine begrenzte Anzahl an API-Requests pro Zeitraum zur Verfügung, was das Löschen von vielen Tweets (bei meinem seit 2007 existierenden Account über 60.000) zu einer langwierigen Angelegenheit machen würde. Denn um die ID der Tweets zu bekommen, müssten wir diese erst einmal alle einlesen. Nach etwa 3000 Requests wäre dann aber Schluss und man müsste erst einmal 15 Minuten Pause einlegen, um die nächsten 3000 einzulesen.
Damit das nicht nötig ist, holen wir uns die IDs aller im Account existierenden Tweets auf einem anderen Weg. Man kann sich in Twitter ein Archiv aller Account-Daten erstellen lassen. Nach diversen Abfragen von Passwort, Zugangs-Code etc. bekommt man dann irgendwann einen Downloadlink für das eigene Twitterarchiv. Packt man dieses aus, findet man im Verzeichnis »data« eine Datei namens tweet.js. Die brauchen wir!
Die Kärrnerarbeit der Kommunikatiom mit Twitter übernimmt das Twitter-Gem. Dieses lässt sich unter Ruby 2.4 bis 2.7 mit gem install twitter installieren und ist dann verfügbar.
Vor die Nutzung des Twitter-Gems haben die Twitter-Götter das Erstellen eines Haufen von IDs und Token gesetzt, Details dazu findet man in der Doku des Twitter-Gems. Zum Löschen von Tweets braucht man »Single-user Authentication«. Das ist leider alles etwas kompliziert und aufwändig und die Beschreibung dieser Dinge wäre ein deutlich längerer Artikel als zwitschiloesch selbst. Wie man das angeht, kann man z.B. sich bspw. in envatos Tutorial an einem Beispiel in PHP ansehen. Am Ende des OAuth-Geweses sollte man Consumer-Key und -Secret für seine neue Twitter-API-App sowie ein Access-Token und ein Access-Token-Secret für den Zugriff dieser App auf den Account besitzen. Nun kann man endlich mit dem Löschen beginnen!
Das gesamte Skript ist in einem Github-Gist verfügbar. Um es zu nutzen, müssen zunächst oben im Config-Block einige Einstellungen vorgenommen werden:
In config müssen die Zugangsdaten zu Twitter (s.o.) gespeichert werden, außerdem braucht die Variable twarchiv den Pfad zu der tweet.js im Verzeichnis data des downgeloadeteten Twitterarchivs (ebenfalls s.o.).
Eine Besonderheit sind die stopwords. Enthält ein Tweet einen String aus diesem Array, so wird dieser nicht gelöscht. Das kann auch eine URL sein, das Skript löst dazu die t.co-Links von Twitter auf. Das ist praktisch, wenn man z.B. das ganze Gelaber löschen, aber Tweets mit Links zum eigenen Blog (oder über Borussia) erhalten möchte. Ausnahme sind »Replies«, das Skript geht davon aus, dass Antworten auf anderer Leuts Tweets immer weg sollen. Wenn man das nicht möchte, muss man das im Code ändern.
Damit ist alles bereit, die Verarbeitung selbst ist ganz einfach. Lediglich die Ermittlung der wahren URL hinter dem t.co-Link ist etwas umständlich, Twitter verwendet da für so etwas einfaches wie einen Tweet unnötig komplizierte Datenstrukturen. Aber auch das bekommen wir hin:
Damit ist alles klar, wir können uns an die Arbeit machen. Das Skript gibt es in einem Github-Gist, nach der Änderung der Config kann man es laufen lassen. Noch einmal eine Warnung: Das Skript fragt nicht mehr nach, es tut was es machen soll: Löschen! Und nichts bringt einmal gelöschte Tweets wieder zurück. Wat fott es es fott!
Allerdings nicht so ganz, führt man es einfach mit ruby zwitschiloesch.rb aus, so gibt es zunächst einmal nur aus, was es machen würde. Möchte man tatsächlich zur Tat schreiten, so muss man noch den Parameter kill angeben:
Dann gibt es kein zurück mehr, wie der Protagonist Billy Pilgrim in Kurt Vonneguts »Schlachthof 5« stets sagt, wenn jemand getötet wird: »So geht das!«
Übrigens scheint es für das Löschen via Twitter-API kein Limit zu geben, das Entfernen von über 60.000 Tweets aus meiner tweet.js lief ohne Probleme durch.
Da man nun die ganze Mühsal der Konfiguration hinter sich hat, kann man das Skript auch als Basis für jegliche Aktionen mit dem Twitter-Gem nutzen, denn das kann eine ganze Menge. Z.B. könnte man ein Skript bauen, das regelmäßig per Cron den eigenen Account scannt und neu dazugekommene Tweets nach einem definierten Zeitraum löscht.
", "url": "https://old-school.dev/2021/07/06/zwitschiloesch/", "tags": ["ruby","twitter"], "date_published": "2021-07-06T13:50:00+02:00", "date_modified": "2021-07-06T13:50:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2021/06/18/hi-na/", "title": "Hi, na?", "summary": "", "content_text": "Einmal im Jahr sollte man in sein(e) Blog(s) ja auch mal wieder etwas schreiben, damit die Archivseiten nicht so viele Zeitsprünge haben!(Pic: KOBU agency auf Unsplash, thanx!)So ist das halt. Der Mitteilungsdrang bewegt sich in Wellen. Und ich werde nach einigen weiteren Erfahrungen mit der Webentwicklungs-Moderne (ein Modul mit recht trivialen Funktionsumfang mit npm installieren = minutenlanges Gerödel und 25000 Dateien…) immer mehr »old school«.Mein Liebling der Developer-Moderne ist noch stets alles rund um »Jamstack«. So stellen sich z.B. die Akteure dieser Glaubensrichtung den Weg vor, ein »einfaches« Blog an den Start zu bringen.Alles und jedes soll »statisch« und »serverless« werden, garniert mit megabyteweise JS. Nun stellten sie aber fest, dass ab einer gewissen Komplexität der Website/Webanwendung der Weg, alles statisch in gewaltige JS-Bundle zu packen und sich dazu eine Abhängigkeit von zwei, drei, vier externen Diensten (»serverless«) zu machen, irgendwie nicht der Königsweg ist. Also ruft man »The Evolution Of Jamstack« aus und baut sich, versteckt unter neuen klangvollen Namen (mit das Wichtigste in der Webdev-Moderne!) wie »Incremental Static Regeneration« oder »Distributed Persistent Rendering« den Rückweg zum guten alten dynamischen Rendering, nur viel komplizierter (Zitat): »At Netlify, we see a lot of promise in the idea of allowing developers to render critical pages at build time.«Ja, da waren wir schon vor vielen Jahren. Es ist und bleibt ein ewiger Kreislauf in der Moderne des Web-Developments…", "content_html": "Einmal im Jahr sollte man in sein(e) Blog(s) ja auch mal wieder etwas schreiben, damit die Archivseiten nicht so viele Zeitsprünge haben!
(Pic: KOBU agency auf Unsplash, thanx!)
So ist das halt. Der Mitteilungsdrang bewegt sich in Wellen. Und ich werde nach einigen weiteren Erfahrungen mit der Webentwicklungs-Moderne (ein Modul mit recht trivialen Funktionsumfang mit npm installieren = minutenlanges Gerödel und 25000 Dateien…) immer mehr »old school«.
Mein Liebling der Developer-Moderne ist noch stets alles rund um »Jamstack«. So stellen sich z.B. die Akteure dieser Glaubensrichtung den Weg vor, ein »einfaches« Blog an den Start zu bringen.
Alles und jedes soll »statisch« und »serverless« werden, garniert mit megabyteweise JS. Nun stellten sie aber fest, dass ab einer gewissen Komplexität der Website/Webanwendung der Weg, alles statisch in gewaltige JS-Bundle zu packen und sich dazu eine Abhängigkeit von zwei, drei, vier externen Diensten (»serverless«) zu machen, irgendwie nicht der Königsweg ist. Also ruft man »The Evolution Of Jamstack« aus und baut sich, versteckt unter neuen klangvollen Namen (mit das Wichtigste in der Webdev-Moderne!) wie »Incremental Static Regeneration« oder »Distributed Persistent Rendering« den Rückweg zum guten alten dynamischen Rendering, nur viel komplizierter (Zitat):
»At Netlify, we see a lot of promise in the idea of allowing developers to render critical pages at build time.«
Ja, da waren wir schon vor vielen Jahren. Es ist und bleibt ein ewiger Kreislauf in der Moderne des Web-Developments…
", "url": "https://old-school.dev/2021/06/18/hi-na/", "tags": ["miszellen","jamstack"], "date_published": "2021-06-18T12:05:00+02:00", "date_modified": "2021-06-18T12:05:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2020/05/31/jekyll-410/", "title": "Jekyll 4.1.0", "summary": "", "content_text": "Huch, dieses kleine Nebenblog gibt es ja auch noch!Das Release von Jekyll 4.1.0 war ein guter Grund, es upzugraden und wiederzubeleben. Jekyll hat in der Version 4 einen ordentlichen Performancesprung gemacht, die Zeit eines jekyll build für mein mittlerweile recht umfangreiches Fußballblog hat sich glatt halbiert.Das Gem jekyll-paginate-v2 hatte sich beim Upgrade auf Release 4 zunächst als Hindernis erwiesen, weil es seine Dependencies auf Jekyll v3 verdrahtet hatte. Das macht es mittlerweile nicht mehr, aber verhält sich mit der neuen Version 4.1 ziemlich merkwürdig.Deshalb habe ich ein eigenes Paginierungs-Plugin geschrieben, das hier und auch in den beiden anderen Blogs einwandfrei funktioniert. Die selbstproduzierte Arbeit geht halt nie aus…", "content_html": "Huch, dieses kleine Nebenblog gibt es ja auch noch!
Das Release von Jekyll 4.1.0 war ein guter Grund, es upzugraden und wiederzubeleben. Jekyll hat in der Version 4 einen ordentlichen Performancesprung gemacht, die Zeit eines jekyll build für mein mittlerweile recht umfangreiches Fußballblog hat sich glatt halbiert.
Das Gem jekyll-paginate-v2 hatte sich beim Upgrade auf Release 4 zunächst als Hindernis erwiesen, weil es seine Dependencies auf Jekyll v3 verdrahtet hatte. Das macht es mittlerweile nicht mehr, aber verhält sich mit der neuen Version 4.1 ziemlich merkwürdig.
Deshalb habe ich ein eigenes Paginierungs-Plugin geschrieben, das hier und auch in den beiden anderen Blogs einwandfrei funktioniert. Die selbstproduzierte Arbeit geht halt nie aus…
", "url": "https://old-school.dev/2020/05/31/jekyll-410/", "tags": ["jekyll","ssg"], "date_published": "2020-05-31T13:00:00+02:00", "date_modified": "2020-05-31T13:00:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/08/07/erlesenes/", "title": "Erlesenes VI – Die Sommerausgabe", "summary": "", "content_text": "Es ist sommerliche Ruhe im Internetz, was Artikel rund um Webdev angeht. Es war ja auch lange viel zu heiß zum Bloggen! Ein paar Links haben sich aber trotzdem angesammelt. Es geht um Ruby on Rails, jQuery, Frontend-Meta-Diskurse und Emojis!(Bild: Toa Heftiba auf Unsplash, thanx!)RailsWer vor der Meta-Frage »Welche Technologie/Programmiersprachen/Frameworks verwende ich denn für mein nächstes Projekt?« kann sich bei »Choosing Ruby On Rails for your next web development project« von Ideamotive informieren. Vielleicht etwas dick aufgetragen (»We give you all the info about Ruby on Rails in one place«), aber nichtsdestotrotz ein recht ausführlicher Überblick über Ruby on Rails.Giles Bowkett geht der Frage nach: »Should I Dish Up My Rails Front End With Webpack, Webpacker, Bundler, or the Asset Pipeline?« tl;dr: »Webpacker & The Asset Pipeline To Start; Webpack For Advanced Users«»Ruby mixins explained« macht genau das, es geht aber letztendlich um die »Concerns« in Rails.Irgendwann muss die schöne Rails-App auf den Server hinauf, um sie auf die Menschheit los zu lassen. Dann kann »Ruby Processes and Threads - Configuring a Web Server« von Jake Yesbeck eine wertvolle Hilfe sein.JavascriptEs gibt noch mehr »Old-School-Developer«, die nicht bei jedem Auftauchen eines neuen von »Ninja- und Hero-Devs« gehypten Frameworks sofort die Technologie wechseln. Martin Tournoij ist so einer und erklärt in »Why I'm still using jQuery in 2019«: »That being said, I think there are a few reasons to stick with simple JavaScript; primarily because I want to build webpages that are fast, use the simplest feasible code, and are accessible by as many people as possible. In my experience server-side generated templates lightly sprinkled with ›progressive enhancement‹-style JavaScript are often the best way to do that.«jQuery ist übrigens nicht mal ansatzweise so »tot«, wie es uns die Artikelfluten rund um die neuen und schönen Frameworks manchmal glauben lassen. Laut Stack Overflows »Developer Survey 2019« nutzen 48,7% aller Antwortenden jQuery.Wer nur die »Komfortfunktionen gegenüber reinem JavaScript« von jQuery benötigt, kann sich einmal Cash ansehen, eine »absurdly small jQuery alternative for modern browsers«.MetaWer das noch nie gemacht hat werfe den ersten Web-Inspector:border: 1px solid red; is the console.log of css— Kitze (@thekitze) August 2, 2019Ein derzeit beliebtes Sujet in der Frontend-Szene ist öffentliche Selbstreflektion unter dem Motto »Was für ein Developer bin ich und wenn ja, wie viele?«…»The Great Devide« nimmt sich des Themas unter dem Motto »Two front-end developers are sitting at a bar. They have nothing to talk about.« in epischen Dimensionen an. Das liest man am besten an einem lauen Sommerabend mit einem kühlen Getränk…Wer jemals in »the Enterprise« gearbeitet hat, kennt das:»$ Marketing Strategy« von Daniel Stori auf turnoff.us, CC Attribution-NonCommercial-ShareAlike 4.0 International LicenseSommer braucht Entspannung!Ja, das ist alles schwierig! Warum nicht zur Entspannung URLs in der Adressleiste mit Emojis und JavaScript animieren? »Animating URLs with Javascript and Emojis« von Matthew Rayfield zeigt, wie es geht…Das finde ich super, deshalb habe ich gleich mal eine hübsche sommerliche Animation in die URL dieses Artikels eingebaut. Lasset die 🌞 scheinen!", "content_html": "Es ist sommerliche Ruhe im Internetz, was Artikel rund um Webdev angeht. Es war ja auch lange viel zu heiß zum Bloggen! Ein paar Links haben sich aber trotzdem angesammelt. Es geht um Ruby on Rails, jQuery, Frontend-Meta-Diskurse und Emojis!
(Bild: Toa Heftiba auf Unsplash, thanx!)
Wer vor der Meta-Frage »Welche Technologie/Programmiersprachen/Frameworks verwende ich denn für mein nächstes Projekt?« kann sich bei »Choosing Ruby On Rails for your next web development project« von Ideamotive informieren. Vielleicht etwas dick aufgetragen (»We give you all the info about Ruby on Rails in one place«), aber nichtsdestotrotz ein recht ausführlicher Überblick über Ruby on Rails.
Giles Bowkett geht der Frage nach: »Should I Dish Up My Rails Front End With Webpack, Webpacker, Bundler, or the Asset Pipeline?« tl;dr: »Webpacker & The Asset Pipeline To Start; Webpack For Advanced Users«
»Ruby mixins explained« macht genau das, es geht aber letztendlich um die »Concerns« in Rails.
Irgendwann muss die schöne Rails-App auf den Server hinauf, um sie auf die Menschheit los zu lassen. Dann kann »Ruby Processes and Threads - Configuring a Web Server« von Jake Yesbeck eine wertvolle Hilfe sein.
Es gibt noch mehr »Old-School-Developer«, die nicht bei jedem Auftauchen eines neuen von »Ninja- und Hero-Devs« gehypten Frameworks sofort die Technologie wechseln. Martin Tournoij ist so einer und erklärt in »Why I'm still using jQuery in 2019«:
»That being said, I think there are a few reasons to stick with simple JavaScript; primarily because I want to build webpages that are fast, use the simplest feasible code, and are accessible by as many people as possible. In my experience server-side generated templates lightly sprinkled with ›progressive enhancement‹-style JavaScript are often the best way to do that.«
jQuery ist übrigens nicht mal ansatzweise so »tot«, wie es uns die Artikelfluten rund um die neuen und schönen Frameworks manchmal glauben lassen. Laut Stack Overflows »Developer Survey 2019« nutzen 48,7% aller Antwortenden jQuery.
Wer nur die »Komfortfunktionen gegenüber reinem JavaScript« von jQuery benötigt, kann sich einmal Cash ansehen, eine »absurdly small jQuery alternative for modern browsers«.
Wer das noch nie gemacht hat werfe den ersten Web-Inspector:
border: 1px solid red; is the console.log of css
— Kitze (@thekitze) August 2, 2019
Ein derzeit beliebtes Sujet in der Frontend-Szene ist öffentliche Selbstreflektion unter dem Motto »Was für ein Developer bin ich und wenn ja, wie viele?«…
»The Great Devide« nimmt sich des Themas unter dem Motto »Two front-end developers are sitting at a bar. They have nothing to talk about.« in epischen Dimensionen an. Das liest man am besten an einem lauen Sommerabend mit einem kühlen Getränk…
Wer jemals in »the Enterprise« gearbeitet hat, kennt das:
»$ Marketing Strategy« von Daniel Stori auf turnoff.us, CC Attribution-NonCommercial-ShareAlike 4.0 International License
Ja, das ist alles schwierig! Warum nicht zur Entspannung URLs in der Adressleiste mit Emojis und JavaScript animieren? »Animating URLs with Javascript and Emojis« von Matthew Rayfield zeigt, wie es geht…
Das finde ich super, deshalb habe ich gleich mal eine hübsche sommerliche Animation in die URL dieses Artikels eingebaut. Lasset die 🌞 scheinen!
", "url": "https://old-school.dev/2019/08/07/erlesenes/", "tags": ["erlesenes","rails","frontend","javascript","jquery"], "date_published": "2019-08-07T13:45:00+02:00", "date_modified": "2019-08-07T13:45:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/07/19/note-2/", "title": "", "summary": "", "content_text": "'What about \"ninja\"?' https://www.reddit.com/r/webdev/comments/ccj6eb/what_does_rockstar_wizard_guru_etc_mean/etnsi1d/ 'Someone who writes React apps during the day, and murders people in their sleep at night.' 😀", "content_html": "'What about \"ninja\"?' https://www.reddit.com/r/webdev/comments/ccj6eb/what_does_rockstar_wizard_guru_etc_mean/etnsi1d/ 'Someone who writes React apps during the day, and murders people in their sleep at night.' 😀
", "url": "https://old-school.dev/2019/07/19/note-2/", "tags": ["rants"], "date_published": "2019-07-19T10:27:27+02:00", "date_modified": "2019-07-19T10:27:27+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/07/19/note/", "title": "", "summary": "", "content_text": "reddit: 'What does \"rockstar\", \"wizard\", \"guru\", etc… mean?' https://www.reddit.com/r/webdev/comments/ccj6eb/what_does_rockstar_wizard_guru_etc_mean/ Antwort: 'It means you're going to have a bad time.' 😀", "content_html": "reddit: 'What does \"rockstar\", \"wizard\", \"guru\", etc… mean?' https://www.reddit.com/r/webdev/comments/ccj6eb/what_does_rockstar_wizard_guru_etc_mean/ Antwort: 'It means you're going to have a bad time.' 😀
", "url": "https://old-school.dev/2019/07/19/note/", "tags": ["rants"], "date_published": "2019-07-19T10:22:35+02:00", "date_modified": "2019-07-19T10:22:35+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/07/06/note/", "title": "", "summary": "", "content_text": "Wenn man sich von den React, Vue und Co. nutzenden Massen abheben will, benutzt man ab sofort #Svelte https://svelte.dev/Denn: \"Svelte is the most beautiful web framework I've ever seen\" https://www.thefutureoftheweb.com/blog/svelte-is-the-most-beautiful-framework-ive-ever-seen", "content_html": "Wenn man sich von den React, Vue und Co. nutzenden Massen abheben will, benutzt man ab sofort #Svelte https://svelte.dev/
Denn: \"Svelte is the most beautiful web framework I've ever seen\" https://www.thefutureoftheweb.com/blog/svelte-is-the-most-beautiful-framework-ive-ever-seen
", "url": "https://old-school.dev/2019/07/06/note/", "tags": ["Svelte","javascript"], "date_published": "2019-07-06T12:48:27+02:00", "date_modified": "2019-07-06T12:48:27+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/07/05/erlesenes/", "title": "Erlesenes V", "summary": "", "content_text": "Es ist mal wieder Zeit, eine Bookmarkkiste auszukippen! Es geht um CSS, HTML und Node.js. Und es gibt ein wenig »Webdev-Meta-Diskurs«…(Bild: Markus Clemens auf Unsplash, thanx!)CSS und HTMLManchmal wiege ich zweifelnd mein Old-School-Developer-Haupt, wenn ich in der Webdev-Bloggeria mitbekomme, was sich Leute für Sachen ausdenken, um etwas relativ Simples wie CSS zu verkomplizieren.Ein Beispiel: »Functional CSS«. Bei der Anwendung von Konzepten, die aus Programmiersprachen kommen, auf Dinge, die keine Programmiersprachen sind, bin ich stets skeptisch (siehe auch objektorientiertes CSS). Immerhin, diese Ideen geben Anstöße für schöne Problematisierartikel wie »The perils of functional CSS« von Jay Freestone. Sein Fazit ist, dass diese Tools versuchen Probleme, die durch die Zusammenarbeit mehrerer Menschen an einem Projekt entstehen, mit komplizierten Konzepten zu lösen. Oder, wie der große Jeffrey Zeldman einst schrieb: »I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.«Etwas Handfesteres gibt es mit »CSS Grid: No Nonsense Layouts« bei testdriven.io. Schöne nachvollziehbare Praxisbeispiele für die Arbeit mit CSS-Grids!Bradley Taunt mahnt in »Write HTML Like It's 1999«, dass man vor lauter Verwendung von Toolchains und Frameworks nicht die Grundlage aller Dinge im Web vergessen soll: HTML!Ob eine solche Ermahnung wirklich notwendig ist? Nun ja…Let's check in now live to see some modern JavaScript developers writing HTML.THIS IS NOT A PARODY. pic.twitter.com/BVd2mtnYMh— Tom Morris 🏳️🌈 (@tommorris) June 27, 2019Node.jsEs gibt Tage, da muss man seine Lieblings-Tools beiseite legen und mit etwas anderem arbeiten. »Node.js for Rails Lovers« von Craig Phares gibt eine Handreichung für Rails-Devs, die sich an einem Projekt mit Node.js versuchen wollen (oder müssen…).MetaFür große Erheiterung sorgen immer Artikel, die eine monströse Liste von Dingen zusammentragen, die man angeblich beherrschen muss, um Web-Development zu betreiben. »The 2019 Web Development (Frontend + Backend) RoadMap« von Michael Bryan ist diesbezüglich ein prächtiges Beispiel. Wir wollen nicht kleinlich sein, man muss neben einem Sack von Grundlagen natürlich Angular, React und Vue beherrschen. Und Node.js, Java, Python, PHP! ;-)Wenn man so etwas liest und das mit der er- und gelebten Praxis vergleicht, kann man sich durchaus mal fragen: »Does real web dev exist? Like the stuff they write all those articles about?«.»Real Programmers« widmen sich sowieso lieber esoterischen Problemen und schreiben einen Quine. Das ist ein Computerprogramm, das sich selbst schreibt. Im secretGeekWiki versucht man sich an einem Quine in C…Und wenn man wirklich nicht mehr weiter weiß: »How to Design for the Web in 2019«", "content_html": "Es ist mal wieder Zeit, eine Bookmarkkiste auszukippen! Es geht um CSS, HTML und Node.js. Und es gibt ein wenig »Webdev-Meta-Diskurs«…
(Bild: Markus Clemens auf Unsplash, thanx!)
Manchmal wiege ich zweifelnd mein Old-School-Developer-Haupt, wenn ich in der Webdev-Bloggeria mitbekomme, was sich Leute für Sachen ausdenken, um etwas relativ Simples wie CSS zu verkomplizieren.
Ein Beispiel: »Functional CSS«. Bei der Anwendung von Konzepten, die aus Programmiersprachen kommen, auf Dinge, die keine Programmiersprachen sind, bin ich stets skeptisch (siehe auch objektorientiertes CSS). Immerhin, diese Ideen geben Anstöße für schöne Problematisierartikel wie »The perils of functional CSS« von Jay Freestone. Sein Fazit ist, dass diese Tools versuchen Probleme, die durch die Zusammenarbeit mehrerer Menschen an einem Projekt entstehen, mit komplizierten Konzepten zu lösen. Oder, wie der große Jeffrey Zeldman einst schrieb:
»I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.«
Etwas Handfesteres gibt es mit »CSS Grid: No Nonsense Layouts« bei testdriven.io. Schöne nachvollziehbare Praxisbeispiele für die Arbeit mit CSS-Grids!
Bradley Taunt mahnt in »Write HTML Like It's 1999«, dass man vor lauter Verwendung von Toolchains und Frameworks nicht die Grundlage aller Dinge im Web vergessen soll: HTML!
Ob eine solche Ermahnung wirklich notwendig ist? Nun ja…
Let's check in now live to see some modern JavaScript developers writing HTML.
— Tom Morris 🏳️🌈 (@tommorris) June 27, 2019
THIS IS NOT A PARODY. pic.twitter.com/BVd2mtnYMh
Es gibt Tage, da muss man seine Lieblings-Tools beiseite legen und mit etwas anderem arbeiten. »Node.js for Rails Lovers« von Craig Phares gibt eine Handreichung für Rails-Devs, die sich an einem Projekt mit Node.js versuchen wollen (oder müssen…).
Für große Erheiterung sorgen immer Artikel, die eine monströse Liste von Dingen zusammentragen, die man angeblich beherrschen muss, um Web-Development zu betreiben. »The 2019 Web Development (Frontend + Backend) RoadMap« von Michael Bryan ist diesbezüglich ein prächtiges Beispiel. Wir wollen nicht kleinlich sein, man muss neben einem Sack von Grundlagen natürlich Angular, React und Vue beherrschen. Und Node.js, Java, Python, PHP! ;-)
Wenn man so etwas liest und das mit der er- und gelebten Praxis vergleicht, kann man sich durchaus mal fragen: »Does real web dev exist? Like the stuff they write all those articles about?«.
»Real Programmers« widmen sich sowieso lieber esoterischen Problemen und schreiben einen Quine. Das ist ein Computerprogramm, das sich selbst schreibt. Im secretGeekWiki versucht man sich an einem Quine in C…
Und wenn man wirklich nicht mehr weiter weiß: »How to Design for the Web in 2019«
", "url": "https://old-school.dev/2019/07/05/erlesenes/", "tags": ["erlesenes","css","html","nodejs","quine","meta"], "date_published": "2019-07-05T12:28:00+02:00", "date_modified": "2019-07-05T12:28:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/07/04/note/", "title": "", "summary": "", "content_text": "Ein neues #jekyll Release: https://jekyllrb.com/docs/history/#v3-8-6 Funktioniert!", "content_html": "Ein neues #jekyll Release: https://jekyllrb.com/docs/history/#v3-8-6 Funktioniert!
", "url": "https://old-school.dev/2019/07/04/note/", "tags": ["jekyll","v3","ssg"], "date_published": "2019-07-04T11:46:28+02:00", "date_modified": "2019-07-04T11:46:28+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/06/25/xml-in-rails-verarbeiten/", "title": "XML in Rails verarbeiten", "summary": "", "content_text": "XML! Kaum jemand ist ein großer Fan davon, man kann dem großen Klammern-Salat aber kaum entrinnen, wenn man mit externen Daten von »The Enterprise™« arbeiten muss. Zur Weiterverarbeitung in der eigenen Rails-Anwendung hatte ich dazu bisher stets eine große Parserei mit Nokogiri veranstaltet oder auf zur Datenquelle passende Gems zurückgegriffen.Aber, TIL: Schon seit Rails 3.0.0 hat Active Support eine Erweiterung für Hash an Bord, die einen String voller hässliches XML in einen wohlgeformten Hash umwandelt.Ein Beispiel, hier ist ein Stück XML: <?xml version=\"1.0\" encoding=\"ISO-8859-1\" ?> <produkt> <ean><![CDATA[4212345678901]]></ean> <name><![CDATA[Biereis am Stiel]]></name> <gruppe id=\"1\"> <name><![CDATA[Bierige Dinge]]></name> <merkmal id=\"kategorie\"> <name><![CDATA[kategorienname]]></name> <wert><![CDATA[Gefrorenes Bier]]></wert> </merkmal> </gruppe> </produkt>Das steckt in einer Variable productugly und soll zur vernünftigen Weiterverarbeitung in einen Hash umgewandelt werden. Dazu erweitert Active Support Rubys Hash um die Methode from_xml: productnice = Hash.from_xml(productugly)Das Ergebnis ist ein schöner Hash: {\"produkt\"=> {\"ean\"=>\"4212345678901\", \"name\"=>\"Biereis am Stiel\", \"gruppe\"=> {\"id\"=>\"1\", \"name\"=>\"Bierige Dinge\", \"merkmal\"=> {\"id\"=>\"kategorie\", \"name\"=>\"kategorienname\", \"wert\"=>\"Gefrorenes Bier\"} } } }So einfach! Peinlich, dass ich das erst nach 9 Jahren (Rails 3.0 erschien im August 2010…) mitbekommen habe. Aber besser spät als nie…", "content_html": "XML! Kaum jemand ist ein großer Fan davon, man kann dem großen Klammern-Salat aber kaum entrinnen, wenn man mit externen Daten von »The Enterprise™« arbeiten muss. Zur Weiterverarbeitung in der eigenen Rails-Anwendung hatte ich dazu bisher stets eine große Parserei mit Nokogiri veranstaltet oder auf zur Datenquelle passende Gems zurückgegriffen.
Aber, TIL: Schon seit Rails 3.0.0 hat Active Support eine Erweiterung für Hash an Bord, die einen String voller hässliches XML in einen wohlgeformten Hash umwandelt.
Ein Beispiel, hier ist ein Stück XML:
Das steckt in einer Variable productugly und soll zur vernünftigen Weiterverarbeitung in einen Hash umgewandelt werden. Dazu erweitert Active Support Rubys Hash um die Methode from_xml:
Das Ergebnis ist ein schöner Hash:
So einfach! Peinlich, dass ich das erst nach 9 Jahren (Rails 3.0 erschien im August 2010…) mitbekommen habe. Aber besser spät als nie…
", "url": "https://old-school.dev/2019/06/25/xml-in-rails-verarbeiten/", "tags": ["xml","rails","ruby"], "date_published": "2019-06-25T11:20:00+02:00", "date_modified": "2019-06-25T11:20:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/06/25/so-ist-es-immer/", "title": "So ist es immer!", "summary": "", "content_text": "Goldene Regel: Wenn auf einem Linux-System etwas kaputt geht, sich nicht installieren lässt oder nicht funktioniert, ist #python im Spiel. Selbst das so zuverlässige Debian ist bei einem schnöden apt-get upgrade davor nicht sicher…", "content_html": "Goldene Regel: Wenn auf einem Linux-System etwas kaputt geht, sich nicht installieren lässt oder nicht funktioniert, ist #python im Spiel. Selbst das so zuverlässige Debian ist bei einem schnöden apt-get upgrade davor nicht sicher…
", "url": "https://old-school.dev/2019/06/25/so-ist-es-immer/", "tags": ["python","linux"], "date_published": "2019-06-25T08:08:26+02:00", "date_modified": "2019-06-25T08:08:26+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/06/21/jamstack-fundamentals/", "title": "»JAMstack Fundamentals«", "summary": "", "content_text": "Kürzlich hatten wir es hier vom aktuellen Hype-Begriff »JAMstack«. Smashing jetzt auch, in einem ausführlichen Webinar mit einem JAMstack- und »Serverless«-Protagonisten, Phil Hawksworth von Netlify:JAMstack Fundamentals: What, What And HowGroßartig: Smashing liefert eine komplette Transkription des einstündigen Videos mit!Mr. Hawksworth erklärt das Thema etwas langatmig, aber ziemlich gründlich. Das ganze natürlich aus Sicht von Netlify. Er relativiert dabei den Mode-Begriff »JAMstack« (»Javascript- APIs- and Markup-Stack«) ein wenig (Zitat): »Because the common misconception is that every JAMstack site has to be JavaScript and APIs, and Markup, but this kind of thing that we’ve overlooked is that we don’t have to use all three — every one one of these is, kind of, optional. We can use as much, or as little of these as we like. In the same way that a LAMP stack site wouldn’t necessarily need to be hitting a data base. Now, I’ve built things in the past that are served by an apache server, on a Linux machine, and I’ve been using PHP, but I haven’t been hitting a database and I wouldn’t start to rename a stack necessarily for that.«Und hebt auf das seiner Ansicht nach perfekte Zusammenspiel von JAMstack und »Serverless« ab. »Serverless« ist ein anderer Modebegriff, im Prinzip bedeutet das nur, dass man statt eines eigenen Servers den eines Cloud-Anbieters nutzt und sich nicht um den eigenen Server kümmern muss (Zitat): »Serverless and JAMstack, they just fit together really beautifully.«Ein empfehlenswertes Video, um die Ideen der Webdevelopment-Glaubensrichtung »JAMstack« etwas genauer kennenzulernen.Wir »Old-School«-Developer sind naturgemäß etwas skeptisch. Wenn man auf den vollen JAMstack-Pfad geht, erkauft man sich den Vorteil, sich nicht um einen eigenen Server (CMS, dynamische Komponenten…) kümmern zu müssen, mit der Abhängigkeit von diversen Cloud-Anbietern…(Bild: Samuel Zeller auf Unsplash, thanx!)", "content_html": "Kürzlich hatten wir es hier vom aktuellen Hype-Begriff »JAMstack«. Smashing jetzt auch, in einem ausführlichen Webinar mit einem JAMstack- und »Serverless«-Protagonisten, Phil Hawksworth von Netlify:
JAMstack Fundamentals: What, What And How
Großartig: Smashing liefert eine komplette Transkription des einstündigen Videos mit!
Mr. Hawksworth erklärt das Thema etwas langatmig, aber ziemlich gründlich. Das ganze natürlich aus Sicht von Netlify. Er relativiert dabei den Mode-Begriff »JAMstack« (»Javascript- APIs- and Markup-Stack«) ein wenig (Zitat):
»Because the common misconception is that every JAMstack site has to be JavaScript and APIs, and Markup, but this kind of thing that we’ve overlooked is that we don’t have to use all three — every one one of these is, kind of, optional. We can use as much, or as little of these as we like. In the same way that a LAMP stack site wouldn’t necessarily need to be hitting a data base. Now, I’ve built things in the past that are served by an apache server, on a Linux machine, and I’ve been using PHP, but I haven’t been hitting a database and I wouldn’t start to rename a stack necessarily for that.«
Und hebt auf das seiner Ansicht nach perfekte Zusammenspiel von JAMstack und »Serverless« ab. »Serverless« ist ein anderer Modebegriff, im Prinzip bedeutet das nur, dass man statt eines eigenen Servers den eines Cloud-Anbieters nutzt und sich nicht um den eigenen Server kümmern muss (Zitat):
»Serverless and JAMstack, they just fit together really beautifully.«
Ein empfehlenswertes Video, um die Ideen der Webdevelopment-Glaubensrichtung »JAMstack« etwas genauer kennenzulernen.
Wir »Old-School«-Developer sind naturgemäß etwas skeptisch. Wenn man auf den vollen JAMstack-Pfad geht, erkauft man sich den Vorteil, sich nicht um einen eigenen Server (CMS, dynamische Komponenten…) kümmern zu müssen, mit der Abhängigkeit von diversen Cloud-Anbietern…
(Bild: Samuel Zeller auf Unsplash, thanx!)
", "url": "https://old-school.dev/2019/06/21/jamstack-fundamentals/", "tags": ["jamstack","ssg"], "date_published": "2019-06-21T12:20:00+02:00", "date_modified": "2019-06-21T12:20:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/06/21/note/", "title": "", "summary": "", "content_text": "Großartig: \"How to Design for the Web in 2019\" https://medium.com/commitlog/how-to-design-for-the-web-in-2019-a0be4d6702e2 Das Beste: Einige Kommentatoren, die das für ernstgemeinte Ratschläge halten…", "content_html": "Großartig: \"How to Design for the Web in 2019\" https://medium.com/commitlog/how-to-design-for-the-web-in-2019-a0be4d6702e2 Das Beste: Einige Kommentatoren, die das für ernstgemeinte Ratschläge halten…
", "url": "https://old-school.dev/2019/06/21/note/", "tags": ["rants"], "date_published": "2019-06-21T10:14:33+02:00", "date_modified": "2019-06-21T10:14:33+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/06/13/note-2/", "title": "", "summary": "", "content_text": "\"IntersectionObserver API\" hatte ich schon mal gehört, aber keine Ahnung wofür das gut sein soll. Sieht aber durchaus nützlich aus: \"Build An Intersection Observer Directive In Vue\" https://dev.to/alexsasharegan/build-an-intersection-observer-directive-in-vue-ljh #vuejs", "content_html": "\"IntersectionObserver API\" hatte ich schon mal gehört, aber keine Ahnung wofür das gut sein soll. Sieht aber durchaus nützlich aus: \"Build An Intersection Observer Directive In Vue\" https://dev.to/alexsasharegan/build-an-intersection-observer-directive-in-vue-ljh #vuejs
", "url": "https://old-school.dev/2019/06/13/note-2/", "tags": ["vuejs","javascript"], "date_published": "2019-06-13T23:52:30+02:00", "date_modified": "2019-06-13T23:52:30+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/06/13/note/", "title": "", "summary": "", "content_text": "»CSRF in Action« https://smellycode.com/csrf-in-action/ widmet sich dem Thema »Cross-Site Request Forgery« am Beispiel einer simplen JavaScript-Anwendung. Es wird schön erklärt, wie das funktioniert und wie man sich davor schützen kann.", "content_html": "»CSRF in Action« https://smellycode.com/csrf-in-action/ widmet sich dem Thema »Cross-Site Request Forgery« am Beispiel einer simplen JavaScript-Anwendung. Es wird schön erklärt, wie das funktioniert und wie man sich davor schützen kann.
", "url": "https://old-school.dev/2019/06/13/note/", "tags": ["security","csfr","javascript"], "date_published": "2019-06-13T22:47:33+02:00", "date_modified": "2019-06-13T22:47:33+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/05/29/hausmitteilung-indieweb/", "title": "Hausmitteilung: Indieweb", "summary": "", "content_text": "Kleine Hausmitteilung: Parallel zum Hauptblog wird auch dieses kleine Dev-Blog »indiewebifiziert« und kann nun auch Webmentions empfangen. Näheres dazu drüben im Uninformat.Technisch wird das realisiert, indem eine zentrale Rails-API-App für alle drei Blogs meines »Imperiums« als Server für Dinge bereit steht, die mit statisch erstellten Blogseiten ohne Klimmzüge nicht realisiert werden können. Ins Blog eingeführt werden sie über eine Vue.js-Komponente, die sich die evtl. vorhandenen Webmentions per JSON abholt.", "content_html": "Kleine Hausmitteilung: Parallel zum Hauptblog wird auch dieses kleine Dev-Blog »indiewebifiziert« und kann nun auch Webmentions empfangen. Näheres dazu drüben im Uninformat.
Technisch wird das realisiert, indem eine zentrale Rails-API-App für alle drei Blogs meines »Imperiums« als Server für Dinge bereit steht, die mit statisch erstellten Blogseiten ohne Klimmzüge nicht realisiert werden können. Ins Blog eingeführt werden sie über eine Vue.js-Komponente, die sich die evtl. vorhandenen Webmentions per JSON abholt.
", "url": "https://old-school.dev/2019/05/29/hausmitteilung-indieweb/", "tags": ["indieweb"], "date_published": "2019-05-29T10:42:00+02:00", "date_modified": "2019-05-29T10:42:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/05/22/erlesenes/", "title": "Erlesenes IV", "summary": "", "content_text": "Viele Browser-Tabs müssen mal wieder gedumpt werden!Das kann nicht sein Ernst sein! (Bild: Hitesh Choudhary auf Unsplash, thanx!)Python ist nicht gerade meine Lieblingssprache, alleine das seit Ewigkeiten parallele Existieren unterschiedlicher Versionen ist irgendwie »WTF?«. Heise läutet das Ende von Python 2 ein, worüber der Schockwellenreiter nur lachen kann.Das Arbeiten mit git ist immer wieder eine Quell der Freude, besonders wenn mehrere Devs zusammmenarbeiten. Drev DeVault gibt »Tips for a disciplined git workflow«. Z.B.: »Pick a random git man page and read it now.«»Oh Shit, git!« gibt Tipps für populäre »Notsituationen«, denn: »Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible.«JavaScript, wir alle lieben JavaScript! DWB hat »7 Useful JavaScript Tricks«. Den hier kannte ich noch nicht, »Get Unique Values of an Array«, ist ergreifend schlicht: var j = [...new Set([1, 2, 3, 3])] >> [1, 2, 3]Apropos JavaScript, Vue.js ist hier noch stets ein Thema.Wir Old-School-Developer lieben und kennen unser jQuery, »Making the Move from jQuery to Vue« bei CSS-Tricks führt in Vue.js aus der jQuery-Perspektive ein.Zum tiefergehenden Einstieg hat Tania Rascia mit »Getting Started with Vue - An Overview and Walkthrough Tutorial« ein großartiges und umfassendes Tutorial geschrieben.Weitere Vue.js-Links: »Build a Server-Side Rendered Vue App with Nuxt.js« »Vue.js Examples«. Was der Name sagt, eine umfangreiche Sammlung. »Thinking in components with Vue.js« »A Vue.js Component for editing and previewing markdown«. Erscheint mir nützlich. »How to build a large Vue application« »Vue.rb«. Vue.js in Ruby schreiben. Auch als Ruby-Fan bin ich mir nicht sicher, ob das sinnvoll ist…Die Auswahl des passenden JavaScript-Frameworks ist zwar bis zu einem gewissen Punkt »Religion«, aber sie haben trotzdem alle ihre Stärken und Schwächen. »Why I prefer React over Vue« vollzieht den Entscheidungsprozess nach.Um zu entscheiden, muss man aber alle einigermaßen gut kennen. Deshalb ist es interessant, wenn sich Sunil Sandhu die Mühe macht, die selbe App mit React und Vue.js zu bauen: »I created the exact same app in React and Vue. Here are the differences.«.Wenn es dann doch React sein soll, ist das ausführliche e-Book »React lernen und verstehen« von Manuel Bieh hilfreich.Aber vielleicht braucht man das auch gar nicht: »You probably don't need that hip web framework«.Und wenn all das zu langweilig wird, kann man sich auch esoterischen Dingen zuwenden. »legit« ist eine Programmiersprache, die in git-Commits programmiert wird: »Programs written in legit are defined entirely by the graph of commits in a Git repository.«Es ist schon erstaunlich, auf was für Ideen die Leute kommen…", "content_html": "Viele Browser-Tabs müssen mal wieder gedumpt werden!
Das kann nicht sein Ernst sein! (Bild: Hitesh Choudhary auf Unsplash, thanx!)
Python ist nicht gerade meine Lieblingssprache, alleine das seit Ewigkeiten parallele Existieren unterschiedlicher Versionen ist irgendwie »WTF?«. Heise läutet das Ende von Python 2 ein, worüber der Schockwellenreiter nur lachen kann.
Das Arbeiten mit git ist immer wieder eine Quell der Freude, besonders wenn mehrere Devs zusammmenarbeiten. Drev DeVault gibt »Tips for a disciplined git workflow«. Z.B.: »Pick a random git man page and read it now.«
»Oh Shit, git!« gibt Tipps für populäre »Notsituationen«, denn:
»Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible.«
JavaScript, wir alle lieben JavaScript! DWB hat »7 Useful JavaScript Tricks«. Den hier kannte ich noch nicht, »Get Unique Values of an Array«, ist ergreifend schlicht:
Apropos JavaScript, Vue.js ist hier noch stets ein Thema.
Wir Old-School-Developer lieben und kennen unser jQuery, »Making the Move from jQuery to Vue« bei CSS-Tricks führt in Vue.js aus der jQuery-Perspektive ein.
Zum tiefergehenden Einstieg hat Tania Rascia mit »Getting Started with Vue - An Overview and Walkthrough Tutorial« ein großartiges und umfassendes Tutorial geschrieben.
Weitere Vue.js-Links:
Die Auswahl des passenden JavaScript-Frameworks ist zwar bis zu einem gewissen Punkt »Religion«, aber sie haben trotzdem alle ihre Stärken und Schwächen. »Why I prefer React over Vue« vollzieht den Entscheidungsprozess nach.
Um zu entscheiden, muss man aber alle einigermaßen gut kennen. Deshalb ist es interessant, wenn sich Sunil Sandhu die Mühe macht, die selbe App mit React und Vue.js zu bauen: »I created the exact same app in React and Vue. Here are the differences.«.
Wenn es dann doch React sein soll, ist das ausführliche e-Book »React lernen und verstehen« von Manuel Bieh hilfreich.
Aber vielleicht braucht man das auch gar nicht: »You probably don't need that hip web framework«.
Und wenn all das zu langweilig wird, kann man sich auch esoterischen Dingen zuwenden. »legit« ist eine Programmiersprache, die in git-Commits programmiert wird:
»Programs written in legit are defined entirely by the graph of commits in a Git repository.«
Es ist schon erstaunlich, auf was für Ideen die Leute kommen…
", "url": "https://old-school.dev/2019/05/22/erlesenes/", "tags": ["erlesenes","git","vuejs","python","react","javascript"], "date_published": "2019-05-22T08:30:00+02:00", "date_modified": "2019-05-22T08:30:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/05/11/git-integration-in-sublime-deaktivieren/", "title": "Git-Integration in Sublime deaktivieren", "summary": "", "content_text": "Kürzlich kam die Version 3.2 meines aktuellen Lieblingseditors Sublime Text heraus. Eine der spektakulären Neuerungen: Git-Integration im Editor. Damit gab es ein handfestes Problem. Da ich in Sublime »lebe« (siehe Bild, alle Arbeits-, Neben- und Blog-Projekte sind ständig in einem eigenen Fenster offen), war Sublime dauerhaft damit beschäftigt, den Git-Status der vielen offenen Dateien zu ermitteln und hielt permanent die CPU auf Trab.Die Lösung: Git-Integration abschalten! Das geht mit einer Zeile in der Konfiguration überraschend einfach, steht in der Doku aber ganz unten im letzten Absatz und war deshalb für »tl;dr«-Kandidaten wie mich schwer zu finden: \"show_git_status\": falseDavon abgesehen stehe ich als »Old-School-Developer« der IDE-isierung aller Dinge skeptisch gegenüber. Das produziert auf die Dauer nur »Bloatware«. Ein Programm soll eine Aufgabe erfüllen, und die gut. Sprich: Ein Editor soll editieren, mit Git interagiert der Git-Client…", "content_html": "Kürzlich kam die Version 3.2 meines aktuellen Lieblingseditors Sublime Text heraus. Eine der spektakulären Neuerungen: Git-Integration im Editor. Damit gab es ein handfestes Problem. Da ich in Sublime »lebe« (siehe Bild, alle Arbeits-, Neben- und Blog-Projekte sind ständig in einem eigenen Fenster offen), war Sublime dauerhaft damit beschäftigt, den Git-Status der vielen offenen Dateien zu ermitteln und hielt permanent die CPU auf Trab.
Die Lösung: Git-Integration abschalten! Das geht mit einer Zeile in der Konfiguration überraschend einfach, steht in der Doku aber ganz unten im letzten Absatz und war deshalb für »tl;dr«-Kandidaten wie mich schwer zu finden:
Davon abgesehen stehe ich als »Old-School-Developer« der IDE-isierung aller Dinge skeptisch gegenüber. Das produziert auf die Dauer nur »Bloatware«. Ein Programm soll eine Aufgabe erfüllen, und die gut. Sprich: Ein Editor soll editieren, mit Git interagiert der Git-Client…
", "url": "https://old-school.dev/2019/05/11/git-integration-in-sublime-deaktivieren/", "tags": ["sublime","editor"], "date_published": "2019-05-11T09:22:00+02:00", "date_modified": "2019-05-11T09:22:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/04/16/erlesenes/", "title": "Erlesenes III", "summary": "", "content_text": "Höchste Zeit, mal wieder die Browser-Tabs und Bookmarks abzuarbeiten!Es gibt frische Handbücher und Checklisten! Wie die »Front-End Performance Checklist 2019«: »Let’s make 2019… fast! An annual front-end performance checklist (PDF/Apple Pages/MS Word), with everything you need to know to create fast experiences today. Updated since 2016.«Und das »Front-end Developer Handbook 2019«. Soso, das soll man also alles wissen. ;-)Ein Beitrag, der ausgesprochen »opiniated« ist: »7 web development practices challenged«. Zitat: »There are many myths in the software business that have led to wrong best practices. In this post I will address 7 of these best practices and explain on which wrong assumptions they are based.«Eine Handvoll Rezepte für die Arbeit mit Flexbox präsentiert Ahmad Shadeed: »CSS Flexbox: 5 Real World Use Cases«Lazy-Loader-JS für bildlastige Sites könnte bald der Vergangenheit angehören: »Native image lazy-loading for the web!«. Im Moment macht es aber erst einmal mehr Arbeit…console.log() kennen alle, aber Console API hat noch mehr zu bieten: »Getting creative with the Console API!«. console.table z.B…Friendly reminder that "o_o" is a valid identifier in JavaScript if you want little buddies to watch over your functions pic.twitter.com/MndQ9xJxmd— Jordan Scales (@jdan) April 10, 2019Ein paar Links aus der Vue-Welt (einige gefunden bei F-LOG-GE, Linkfutter): »How to Add Charts and Graphs to a Vue.js Application« Ein Tutorial: »Simple Photo App with Vue.js, Axios and Flickr API« Noch ein Tutorial: »Creating a Simple Blog using Vue with Markdown« »Dynamic Component Templates with Vue.js« »Vuex Explained Visually«. Ein schöner Artikel, der hilft das nicht ganz intuitive Konzept hinter Vuex (oder dem Vorbild Flux) zu verstehen. »Why I Chose Vue over React«. Eine Meta-Betrachtung, sehr »opiniated«, wie es in der Natur dieser Dinge liegt…Apropos »Meta-Betrachtungen« und dem Meta-Thema dieses Blogs, »Old-School-Development«:Bridget Stewart schaute sich ein Einführungsvideo zu Vue an und geriet darob ins Philosophieren über das Frontend und die Idee, die Business-Logic einer Web-Anwendung ins Frontend zu packen: »Stuffing the Front End«Ein in dem Zusammenhang typischer Text: »Why I miss Rails«. Ein Developer, der in der »Business-Logik-mit-JavaScript-ins-Frontend«-Hölle steckt und die Entwicklung mit Ruby On Rails vermisst: »Now, I know Rails isn’t universally beloved by developers, and I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again.«So, warum nicht? Manchmal ist genau das die Lösung, auch wenn »man« das angeblich 2019 nicht mehr macht…Und wenn es trotz all dieser Dinge mal langweilig ist? Dann schreibt man ein Web-Framework in bash…", "content_html": "Höchste Zeit, mal wieder die Browser-Tabs und Bookmarks abzuarbeiten!
Es gibt frische Handbücher und Checklisten! Wie die »Front-End Performance Checklist 2019«: »Let’s make 2019… fast! An annual front-end performance checklist (PDF/Apple Pages/MS Word), with everything you need to know to create fast experiences today. Updated since 2016.«
Und das »Front-end Developer Handbook 2019«. Soso, das soll man also alles wissen. ;-)
Ein Beitrag, der ausgesprochen »opiniated« ist: »7 web development practices challenged«. Zitat:
»There are many myths in the software business that have led to wrong best practices. In this post I will address 7 of these best practices and explain on which wrong assumptions they are based.«
Eine Handvoll Rezepte für die Arbeit mit Flexbox präsentiert Ahmad Shadeed: »CSS Flexbox: 5 Real World Use Cases«
Lazy-Loader-JS für bildlastige Sites könnte bald der Vergangenheit angehören: »Native image lazy-loading for the web!«. Im Moment macht es aber erst einmal mehr Arbeit…
console.log() kennen alle, aber Console API hat noch mehr zu bieten: »Getting creative with the Console API!«. console.table z.B…
Friendly reminder that "o_o" is a valid identifier in JavaScript if you want little buddies to watch over your functions pic.twitter.com/MndQ9xJxmd
— Jordan Scales (@jdan) April 10, 2019
Ein paar Links aus der Vue-Welt (einige gefunden bei F-LOG-GE, Linkfutter):
Apropos »Meta-Betrachtungen« und dem Meta-Thema dieses Blogs, »Old-School-Development«:
Bridget Stewart schaute sich ein Einführungsvideo zu Vue an und geriet darob ins Philosophieren über das Frontend und die Idee, die Business-Logic einer Web-Anwendung ins Frontend zu packen: »Stuffing the Front End«
Ein in dem Zusammenhang typischer Text: »Why I miss Rails«. Ein Developer, der in der »Business-Logik-mit-JavaScript-ins-Frontend«-Hölle steckt und die Entwicklung mit Ruby On Rails vermisst:
»Now, I know Rails isn’t universally beloved by developers, and I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again.«
So, warum nicht? Manchmal ist genau das die Lösung, auch wenn »man« das angeblich 2019 nicht mehr macht…
Und wenn es trotz all dieser Dinge mal langweilig ist? Dann schreibt man ein Web-Framework in bash…
", "url": "https://old-school.dev/2019/04/16/erlesenes/", "tags": ["erlesenes","frontend","css","javascript","vuejs","rails"], "date_published": "2019-04-16T11:15:00+02:00", "date_modified": "2019-04-16T11:15:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/04/12/old-school-developer/", "title": "Hausmitteilung: »Old-School-Developer«", "summary": "", "content_text": "[Foto: »IBM Type 26 Printing Card Punch Keyboard« von Ivan Lian, Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Generic Licence, thanks!]Manche Leute wechseln ihre Blog-Domains schneller als Hipster-Devs das JavaScript-Framework!Knapp zwei Monate nach der Eröffnung gibt es für nil? schon wieder etwas Neues. Die »Coolen« haben jetzt alle eine .dev-Domain! Deshalb firmiert dieses kleine Dev-Blog ab sofort mit dem Untertitel »Old-School-Web-Developer-Blog« auf einer eigenen modischen .dev-Domain: old-school.dev. Was dann natürlich eher nicht »old-school« ist, sondern mehr so Hipster-Dev-Kram. Die alte Domain hat selbstverständlich einen Redirect auf die neue. Außerdem hat das Blog ein kleines optisches »Realignment« bekommen. Und benutzt nun Flexbox statt Floats!»Old-School«, was soll das heißen? Wir »erfahrenen« (oder »alten«…) Webentwickler sind in manchen Dingen etwas »altmodisch«. Wir überlegen es uns z.B. ganz genau, eine laufende Anwendung komplett neu zu schreiben, weil ein neues JavaScript-Framework versucht, einen Paradigmenwechsel in der Entwicklung durchzusetzen und in Reddit, Hacker News und Blogs alle schreiben, dass man das jetzt unbedingt so machen soll. Oder wir rendern komplexe Web-Anwendungen lieber auf dem Server, statt sie als monströse SPA mit dem heißesten neuen JS-Framework im Client ablaufen zu lassen…Manchmal ist »Simple & Boring« die bessere Lösung. Und man sollte sich davor hüten, aus einer Flut von Artikeln und Vorträgen über ein neues Framework oder eine neue Software auf augenblickliche Relevanz für die eigene Arbeit zu schließen. Jeremy Keith schrieb dazu: »I don’t know about you, but I constantly feel like I’m behind the curve because I’m not currently using TypeScript or GraphQL or React.«Letztendlich ist »da draußen« eine Menge erprobtes und »altes« Zeug im Einsatz, man hört nur weniger davon. Denn es ist wie Metafizzy schrieb: »You don’t hear about TextMate because TextMate is old. What would I tweet? Still using TextMate. Still good.«So sieht es aus. In diesem Sinne: Weiter geht's, und »Happy Coding«!", "content_html": "[Foto: »IBM Type 26 Printing Card Punch Keyboard« von Ivan Lian, Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Generic Licence, thanks!]
Manche Leute wechseln ihre Blog-Domains schneller als Hipster-Devs das JavaScript-Framework!
Knapp zwei Monate nach der Eröffnung gibt es für nil? schon wieder etwas Neues. Die »Coolen« haben jetzt alle eine .dev-Domain! Deshalb firmiert dieses kleine Dev-Blog ab sofort mit dem Untertitel »Old-School-Web-Developer-Blog« auf einer eigenen modischen .dev-Domain: old-school.dev. Was dann natürlich eher nicht »old-school« ist, sondern mehr so Hipster-Dev-Kram. Die alte Domain hat selbstverständlich einen Redirect auf die neue. Außerdem hat das Blog ein kleines optisches »Realignment« bekommen. Und benutzt nun Flexbox statt Floats!
»Old-School«, was soll das heißen? Wir »erfahrenen« (oder »alten«…) Webentwickler sind in manchen Dingen etwas »altmodisch«. Wir überlegen es uns z.B. ganz genau, eine laufende Anwendung komplett neu zu schreiben, weil ein neues JavaScript-Framework versucht, einen Paradigmenwechsel in der Entwicklung durchzusetzen und in Reddit, Hacker News und Blogs alle schreiben, dass man das jetzt unbedingt so machen soll. Oder wir rendern komplexe Web-Anwendungen lieber auf dem Server, statt sie als monströse SPA mit dem heißesten neuen JS-Framework im Client ablaufen zu lassen…
Manchmal ist »Simple & Boring« die bessere Lösung. Und man sollte sich davor hüten, aus einer Flut von Artikeln und Vorträgen über ein neues Framework oder eine neue Software auf augenblickliche Relevanz für die eigene Arbeit zu schließen. Jeremy Keith schrieb dazu:
»I don’t know about you, but I constantly feel like I’m behind the curve because I’m not currently using TypeScript or GraphQL or React.«
Letztendlich ist »da draußen« eine Menge erprobtes und »altes« Zeug im Einsatz, man hört nur weniger davon. Denn es ist wie Metafizzy schrieb:
»You don’t hear about TextMate because TextMate is old. What would I tweet? Still using TextMate. Still good.«
So sieht es aus. In diesem Sinne: Weiter geht's, und »Happy Coding«!
", "url": "https://old-school.dev/2019/04/12/old-school-developer/", "tags": ["miszellen"], "date_published": "2019-04-12T17:15:00+02:00", "date_modified": "2019-04-12T17:15:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/04/03/entwickler-weisheiten/", "title": "Entwickler-Weisheiten: Serverless", "summary": "", "content_text": "»Uncle Dave« Wyner: »Serverless is one of those unfortunate names that confuse the hell out of people because it’s a lie. Your software most definitely runs on a server.«Lt. einer Quora-Frage wurde der schöne Begriff Serverless erstmals 2010 von einem Startup namens PiCLoud benutzt und dann 2012 in einem Blogeintrag bei Readwrite in den Diskurs geworfen.Natürlich geht in Wirklichkeit nichts ohne Server, und wenn man Serverless deployed, benutzt man halt Server anderer Leute in der Cloud statt des eigenen. Wahrscheinlich wollte man damals kein Wort mit Cloud verwenden, weil das Wort Cloud nach der ersten großen Euphorie zu Web-2.0-Zeiten schon ein wenig nach »Sicherheitslücken« und »Abhängigkeit von Big Playern aus USA« klang…", "content_html": "»Serverless is one of those unfortunate names that confuse the hell out of people because it’s a lie. Your software most definitely runs on a server.«
Lt. einer Quora-Frage wurde der schöne Begriff Serverless erstmals 2010 von einem Startup namens PiCLoud benutzt und dann 2012 in einem Blogeintrag bei Readwrite in den Diskurs geworfen.
Natürlich geht in Wirklichkeit nichts ohne Server, und wenn man Serverless deployed, benutzt man halt Server anderer Leute in der Cloud statt des eigenen. Wahrscheinlich wollte man damals kein Wort mit Cloud verwenden, weil das Wort Cloud nach der ersten großen Euphorie zu Web-2.0-Zeiten schon ein wenig nach »Sicherheitslücken« und »Abhängigkeit von Big Playern aus USA« klang…
", "url": "https://old-school.dev/2019/04/03/entwickler-weisheiten/", "tags": ["serverless","rants"], "date_published": "2019-04-03T13:09:00+02:00", "date_modified": "2019-04-03T13:09:00+02:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/03/21/erlesenes-2/", "title": "Erlesenes II", "summary": "", "content_text": "Es ist mal wieder Zeit, den Bookmark-Folder für Development-Links zu leeren!Auch wir »Old-School-Programmierer« wollen ja stets Neues lernen. Z.B. modernes JavaScript, damit sich die »jungen Leute« nicht über unseren Code kaputtlachen. »Modern JavaScript Explained For Dinosaurs« reitet einen schnellen Galopp durch die JavaScript-Moderne und ihre die Festplatten mit Abhängigkeiten füllenden Tools…Ein Weg, sich Neues anzueignen, ist der Vergleich mit gut abgehangenen alten Tools. »Vue.js vs jQuery: Use Cases and Comparison with Examples« erläutert Lösungen in Vue.js anhand typischer Anwendungsfälle für jQuery. Alternativ: »Vue for jQuery Developers« (via F-LOG-GE).Neu (nun ja, relativ neu) ist auch die Verwendung von CSS Grids anstelle des guten alten float-Gefrickels. »How You Can Get Started with CSS Grid« bietet eine schöne Einführung in diese Methode.Unsere Lieblingstätigkeit bei der Entwicklung ist aber natürlich das Kopieren fertiger Lösungen. »8 useful CSS tricks: Parallax images, sticky footers and more« hat ein paar davon auf Lager…Mit Rails baut man auch gerne REST-APIs. »A minimalistic foundation for a Rails REST API« zeigt eine dabei sinnvolle Vorgehensweise auf.Wer häufiger auf fremden Servern per ssh arbeitet, wird schon einmal von tmux gehört haben. Ein etwas älterer Artikel mit der Überschrift »Benefits of using tmux - lessons from streamlining a development environment« führt einige sinnvolle Anwendungsfälle zum Einstieg vor.Und dann wäre da noch Thanos JS. Es verspricht: »Reduce the file size of your project down to 50%, by randomly deleting half of the files.« Endlich eine sinnvolle Hilfe gegen den »Bloat« moderner Web-Projekte…", "content_html": "Es ist mal wieder Zeit, den Bookmark-Folder für Development-Links zu leeren!
Auch wir »Old-School-Programmierer« wollen ja stets Neues lernen. Z.B. modernes JavaScript, damit sich die »jungen Leute« nicht über unseren Code kaputtlachen. »Modern JavaScript Explained For Dinosaurs« reitet einen schnellen Galopp durch die JavaScript-Moderne und ihre die Festplatten mit Abhängigkeiten füllenden Tools…
Ein Weg, sich Neues anzueignen, ist der Vergleich mit gut abgehangenen alten Tools. »Vue.js vs jQuery: Use Cases and Comparison with Examples« erläutert Lösungen in Vue.js anhand typischer Anwendungsfälle für jQuery. Alternativ: »Vue for jQuery Developers« (via F-LOG-GE).
Neu (nun ja, relativ neu) ist auch die Verwendung von CSS Grids anstelle des guten alten float-Gefrickels. »How You Can Get Started with CSS Grid« bietet eine schöne Einführung in diese Methode.
Unsere Lieblingstätigkeit bei der Entwicklung ist aber natürlich das Kopieren fertiger Lösungen. »8 useful CSS tricks: Parallax images, sticky footers and more« hat ein paar davon auf Lager…
Mit Rails baut man auch gerne REST-APIs. »A minimalistic foundation for a Rails REST API« zeigt eine dabei sinnvolle Vorgehensweise auf.
Wer häufiger auf fremden Servern per ssh arbeitet, wird schon einmal von tmux gehört haben. Ein etwas älterer Artikel mit der Überschrift »Benefits of using tmux - lessons from streamlining a development environment« führt einige sinnvolle Anwendungsfälle zum Einstieg vor.
Und dann wäre da noch Thanos JS. Es verspricht: »Reduce the file size of your project down to 50%, by randomly deleting half of the files.« Endlich eine sinnvolle Hilfe gegen den »Bloat« moderner Web-Projekte…
", "url": "https://old-school.dev/2019/03/21/erlesenes-2/", "tags": ["erlesenes","javascript","vuejs","frontend","css","rails","tmux"], "date_published": "2019-03-21T12:25:00+01:00", "date_modified": "2019-03-21T12:25:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/03/21/nuxtjs/", "title": "Nuxt.js", "summary": "", "content_text": "Im Zuge meiner Versuche mit Vue.js habe ich Nuxt.js entdeckt. Wofür braucht man das? Im offiziellen Guide steht: »Nuxt.js is a framework for creating Vue.js applications, you can choose between Universal, Static Generated or Single Page application.«Also ein Framework, das auf einem Framework aufsetzt. ;-)Nuxt.js erscheint aber nützliches, als es klingt. Es ist weniger ein weiteres JavaScript-Framework, sondern mehr eine Art Distribution sinnvoller Defaults für die Arbeit an einem Vue-Projekt. Und Nuxt.js liefert serienmäßig alles mit, um aus dem Vue-Meisterwerk eine »universelle« Anwendung zu machen, d.h., man kann mit einer Codebase eine javascript-lastige SPA bauen, aber auch in Vue programmieren und dann alle Vue-Routen als statische HTML-Dokumente rendern lassen. Oder das Ganze mischen.Ein paar Links zum Einstieg: »Introduction«. Die offizielle Dokumentation kommt mit einer gut verständlichen Einführung »10 reasons to use Nuxt.js for your next web application«. Ein Blogbeitrag der die Vorteile von Nuxt.js näher bringt: »Even if you don’t need a universal app and want to stick with an SPA, there are still benefits to using Nuxt.js. It can be your project’s main base with benefits like .vue files, ES6 compilation, and many more features.« »Simple Server Side Rendering, Routing, and Page Transitions with Nuxt.js«. Ein simples Muster-Projekt mit CSS-Page-Transitions. »Building a Personal Site with Nuxt.js«. Ein weiteres einführendes Beispiel, wenn auch etwas oberflächlich geraten. »7 Problems you can avoid by using Nuxt.js for your next Vue app«. »Nuxt.js allows you to spend less time on configuration, and more time solving problems and building awesome Vue apps.« »awesome-nuxt. A curated list of awesome things related to Nuxt.js«. Eine sehr ausführliche Sammlung von Artikeln und Resourcen zum Thema. Auf dem ersten Blick sieht Nuxt.js sehr vielversprechend aus, aber man muss es (wie alles im Developer-Leben) einmal mit etwas »Richtigem« benutzt haben. Deshalb wird es demnächst mal ausprobiert…", "content_html": "Im Zuge meiner Versuche mit Vue.js habe ich Nuxt.js entdeckt. Wofür braucht man das? Im offiziellen Guide steht:
»Nuxt.js is a framework for creating Vue.js applications, you can choose between Universal, Static Generated or Single Page application.«
Also ein Framework, das auf einem Framework aufsetzt. ;-)
Nuxt.js erscheint aber nützliches, als es klingt. Es ist weniger ein weiteres JavaScript-Framework, sondern mehr eine Art Distribution sinnvoller Defaults für die Arbeit an einem Vue-Projekt. Und Nuxt.js liefert serienmäßig alles mit, um aus dem Vue-Meisterwerk eine »universelle« Anwendung zu machen, d.h., man kann mit einer Codebase eine javascript-lastige SPA bauen, aber auch in Vue programmieren und dann alle Vue-Routen als statische HTML-Dokumente rendern lassen. Oder das Ganze mischen.
Ein paar Links zum Einstieg:
»Introduction«. Die offizielle Dokumentation kommt mit einer gut verständlichen Einführung
»10 reasons to use Nuxt.js for your next web application«. Ein Blogbeitrag der die Vorteile von Nuxt.js näher bringt: »Even if you don’t need a universal app and want to stick with an SPA, there are still benefits to using Nuxt.js. It can be your project’s main base with benefits like .vue files, ES6 compilation, and many more features.«
»Simple Server Side Rendering, Routing, and Page Transitions with Nuxt.js«. Ein simples Muster-Projekt mit CSS-Page-Transitions.
»Building a Personal Site with Nuxt.js«. Ein weiteres einführendes Beispiel, wenn auch etwas oberflächlich geraten.
»7 Problems you can avoid by using Nuxt.js for your next Vue app«. »Nuxt.js allows you to spend less time on configuration, and more time solving problems and building awesome Vue apps.«
»awesome-nuxt. A curated list of awesome things related to Nuxt.js«. Eine sehr ausführliche Sammlung von Artikeln und Resourcen zum Thema.
Auf dem ersten Blick sieht Nuxt.js sehr vielversprechend aus, aber man muss es (wie alles im Developer-Leben) einmal mit etwas »Richtigem« benutzt haben. Deshalb wird es demnächst mal ausprobiert…
", "url": "https://old-school.dev/2019/03/21/nuxtjs/", "tags": ["nuxtjs","vuejs","javascript"], "date_published": "2019-03-21T10:25:00+01:00", "date_modified": "2019-03-21T10:25:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/03/12/projektbezogene-irb-historie/", "title": "Projektbezogene irb-Historie für Rails", "summary": "", "content_text": "Problem: Wenn man mit rails c in der Console mit irb (interactive Ruby) arbeitet, hat man nur eine globale History. Diese liegt im home-Verzeichnis des Users unter .irb_history (aber .irb-history wenn man RVM benutzt). Das ist unschön, denn wenn man an einem Projekt arbeitet, möchte man auch nur den dafür relevanten Teil der History sehen.Abhilfe schafft eine auf Github gefundene Konfigurationsdatei .irbrc im Homeverzeichnis. Diese speichert die Kommando-Historie fortan im Rails-Projektverzeichnis, »normale« Ruby-Arbeit aber weiterhin in der globalen Historie im home-Verzeichnis: # ~/.irbrc require 'irb/completion' require 'irb/ext/save-history' IRB.conf[:SAVE_HISTORY] = 1000 if defined?(::Rails) IRB.conf[:HISTORY_FILE] = File.join(ENV['PWD'], '.irb-history') else IRB.conf[:HISTORY_FILE] = File.join(ENV['HOME'], '.irb-history') endFortan liegt eine .irb-history im Rails-Projektverzeichnis. Man sollte diese dann in die .gitignore aufnehmen.Bonustipp: Wenn man in der Rails-Console mit Objekten arbeitet, kann die ständige Ausgabe der im Hintergrund ablaufenden SQl-Kommandos stören. Mit dem folgenden Befehl wird diese für die aktuelle irb-Session abgeschaltet: ActiveRecord::Base.logger = nilEine populäre Alternative zu irb ist pry. pry hat viele Features, fast schon zu viele, weshalb ich irb bevorzuge.", "content_html": "Problem: Wenn man mit rails c in der Console mit irb (interactive Ruby) arbeitet, hat man nur eine globale History. Diese liegt im home-Verzeichnis des Users unter .irb_history (aber .irb-history wenn man RVM benutzt). Das ist unschön, denn wenn man an einem Projekt arbeitet, möchte man auch nur den dafür relevanten Teil der History sehen.
Abhilfe schafft eine auf Github gefundene Konfigurationsdatei .irbrc im Homeverzeichnis. Diese speichert die Kommando-Historie fortan im Rails-Projektverzeichnis, »normale« Ruby-Arbeit aber weiterhin in der globalen Historie im home-Verzeichnis:
Fortan liegt eine .irb-history im Rails-Projektverzeichnis. Man sollte diese dann in die .gitignore aufnehmen.
Bonustipp: Wenn man in der Rails-Console mit Objekten arbeitet, kann die ständige Ausgabe der im Hintergrund ablaufenden SQl-Kommandos stören. Mit dem folgenden Befehl wird diese für die aktuelle irb-Session abgeschaltet:
Eine populäre Alternative zu irb ist pry. pry hat viele Features, fast schon zu viele, weshalb ich irb bevorzuge.
", "url": "https://old-school.dev/2019/03/12/projektbezogene-irb-historie/", "tags": ["ruby","rails","irb"], "date_published": "2019-03-12T11:25:00+01:00", "date_modified": "2019-03-12T11:25:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/03/12/css-resets/", "title": "CSS-Resets.", "summary": "", "content_text": "bitsofcode – »A look at CSS Resets in 2018«. Bei mir werkelt Normalize.css (via F-LOG-GE).", "content_html": "bitsofcode – »A look at CSS Resets in 2018«. Bei mir werkelt Normalize.css (via F-LOG-GE).
", "url": "https://old-school.dev/2019/03/12/css-resets/", "tags": ["frontend","css"], "date_published": "2019-03-12T10:48:00+01:00", "date_modified": "2019-03-12T10:48:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/03/07/isso-installieren/", "title": "Ein Happen Dynamik: isso installieren und in ein statisches jekyll-Blog einbinden", "summary": "", "content_text": "Statische Blog-Systeme sind schön und gut, ein bisschen Dynamik braucht man aber schon. Z.B. für Kommentare, auch wenn die große Zeit des Kommentierens in Blogs wohl vorbei ist. Der Meinungssturm tobt heutzutage in Social Media…Datensammler wie Disqus sind indiskutabel, also denken sich die Leute groteske Sachen aus wie Kommentare mit irgendeinem Formprozessor irgendwo in der Wolke zu verarbeiten und dann daraus einen commit auf ein Github-Repo auszulösen. Sinnvoller erscheinen da schon sich als datenschutzfreundlicher gebende gehostete Kommentardienste wie RemarkBox oder comment.sh.Letztere bieten eine gehostete Version von isso an, das in meinen Blogs schon länger werkelt isso. Das ist ein Kommentarsystem für den eigenen Server, das man wie disqus und Co. per JavaScript in seine statischen Seiten einbinden kann.isso funktioniert recht gut, wenn es einmal läuft, es hat aber einen großen Haken: Es ist in Python geschrieben, und es gibt nun einmal (für mich zumindest) nix Schlimmeres als das Rumgemache mit virtualenv, pip, easy_install und den diversen rummäandernden Python-Versionen…Es begab sich, dass ich isso neu installieren musste und die Erstinstallation damals nicht dokumentiert hatte. Damit das nicht noch einmal passiert, habe ich es diesmal aufgeschrieben und hier abgelegt. Vielleicht ist das ja auch noch für jemanden außer mir nützlich…1. isso-InstallationDie notwenig gewordene erneute Installation war schwieriger als gedacht. Es gibt halt nichts Schöneres als diesen vollgekotzten Bildschirm mit trace-Informationen, der einem eigentlich nur sagen will: »Da fehlt eine Library!« ;-)Nach einigen fehlgeschlagenen Versuchen mit pip und easy_install hat es dann auf Basis der amtlichen Anleitung funktioniert. Tückischerweise installiert pip seine benötigten Abhängigkeiten nicht vollständig, dem »Auswurf« konnte man aber entnehmen, was noch fehlte.Ich habe alles mit virtualenv in /opt/isso installiert, da liegen auch die conf-Dateien und die SQLite-Datenbanken. Das Ganze installiere ich mit einem »normalen« User, das braucht nicht als root gemacht zu werden. Ggf. muss man /opt/isso vorher als root anlegen und mit chown dem gewünschten User zugänglich machen. Oder ein beliebiges anderes Verzeichnis verwenden. virtualenv /opt/isso source /opt/isso/bin/activate pip install isso # die fehlenden Abhaengigkeiten pip install configparser pip install ipaddr deactivateDanach kann man es mit /opt/isso/bin/isso testhalber starten, und wenn es keinen »Python-Auswurf« mehr gibt, funktioniert alles. Herzlichen Glückwunsch, das Python-Monster ist besiegt!2. isso-Konfigurationisso benötigt eine Konfigurationsdatei, damit es seinen Port und das Blog kennt, in das es eingebunden werden soll.Für dieses kleine devblog sieht das dann z.B. so aus. Die Konfiguration nil.conf legt die Datenbank in /opt/isso ab, deaktiviert Moderation (dieses kleine Blog segelt unter dem Wahrnehmungsradar der »Turnhallen voller Chinesen«…) und möchte eine Benachrichtigung über neue Kommentare per E-Mail. listen geht auf localhost Port 9090. Hat man isso irgendwohin intern containerisiert, muss man entsprechend die interne IP angeben: [general] ; database location, check permissions, created if not exists dbpath = /opt/isso/nil.db ; your website or blog (not the location of Isso!) host = https://nil.uninform.at/ notify = smtp [moderation] enabled = false [server] listen = http://127.0.0.1:9090 [smtp] to = adresse@irgend.wohin security = starttls port = 25 host = EIN.MAIL.SERVER username = USERNAME password = PASSWORDWenn man damit fertig ist, kann man isso starten und fortan als Hintergrundprozess laufen lassen: /opt/isso/bin/isso -c /opt/isso/nil.conf run &3. isso ins jekyll-Blog einbindenNun muss die isso-Pracht noch in das statische Blog hinein. Mein Jekyll-Deployment ist »old school«. Ich möchte keine Github-Pages oder Cloud-Gedöns à la Netlify, ein ordentlicher metallener Server mit einem soliden nginx soll es sein.Zur Vermeidung von Problemem mit CORS etc. wird isso als Location mit proxy_pass in den nginx-Server eingebunden und ist dann unter https://nil.uninform.at/isso erreichbar: server { # ... das uebliche nginx-config-zeug der # Uebersicht halber weggelassen ... location /isso { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Script-Name /isso; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://127.0.0.1:9090; } }Nach dem Neustart des nginx ist /isso verfügbar.Fehlt noch die Einbindung in die Jekyll-Seiten. Diese wird durch ein Stück HTML im Seiten-Template realisiert, bei mir ist es layouts/post.html: <script data-isso=\"//nil.uninform.at/isso/\" data-isso-lang=\"de\" src=\"//nil.uninform.at/isso/js/embed.min.js\"></script> <section id=\"isso-thread\"></section>Jetzt noch einmal das Jekyll-Blog deployen und der Kommentarflut steht nichts mehr im Wege. Happy Jekylling!", "content_html": "Statische Blog-Systeme sind schön und gut, ein bisschen Dynamik braucht man aber schon. Z.B. für Kommentare, auch wenn die große Zeit des Kommentierens in Blogs wohl vorbei ist. Der Meinungssturm tobt heutzutage in Social Media…
Datensammler wie Disqus sind indiskutabel, also denken sich die Leute groteske Sachen aus wie Kommentare mit irgendeinem Formprozessor irgendwo in der Wolke zu verarbeiten und dann daraus einen commit auf ein Github-Repo auszulösen. Sinnvoller erscheinen da schon sich als datenschutzfreundlicher gebende gehostete Kommentardienste wie RemarkBox oder comment.sh.
Letztere bieten eine gehostete Version von isso an, das in meinen Blogs schon länger werkelt isso. Das ist ein Kommentarsystem für den eigenen Server, das man wie disqus und Co. per JavaScript in seine statischen Seiten einbinden kann.
isso funktioniert recht gut, wenn es einmal läuft, es hat aber einen großen Haken: Es ist in Python geschrieben, und es gibt nun einmal (für mich zumindest) nix Schlimmeres als das Rumgemache mit virtualenv, pip, easy_install und den diversen rummäandernden Python-Versionen…
Es begab sich, dass ich isso neu installieren musste und die Erstinstallation damals nicht dokumentiert hatte. Damit das nicht noch einmal passiert, habe ich es diesmal aufgeschrieben und hier abgelegt. Vielleicht ist das ja auch noch für jemanden außer mir nützlich…
Die notwenig gewordene erneute Installation war schwieriger als gedacht. Es gibt halt nichts Schöneres als diesen vollgekotzten Bildschirm mit trace-Informationen, der einem eigentlich nur sagen will: »Da fehlt eine Library!« ;-)
Nach einigen fehlgeschlagenen Versuchen mit pip und easy_install hat es dann auf Basis der amtlichen Anleitung funktioniert. Tückischerweise installiert pip seine benötigten Abhängigkeiten nicht vollständig, dem »Auswurf« konnte man aber entnehmen, was noch fehlte.
Ich habe alles mit virtualenv in /opt/isso installiert, da liegen auch die conf-Dateien und die SQLite-Datenbanken. Das Ganze installiere ich mit einem »normalen« User, das braucht nicht als root gemacht zu werden. Ggf. muss man /opt/isso vorher als root anlegen und mit chown dem gewünschten User zugänglich machen. Oder ein beliebiges anderes Verzeichnis verwenden.
Danach kann man es mit /opt/isso/bin/isso testhalber starten, und wenn es keinen »Python-Auswurf« mehr gibt, funktioniert alles. Herzlichen Glückwunsch, das Python-Monster ist besiegt!
isso benötigt eine Konfigurationsdatei, damit es seinen Port und das Blog kennt, in das es eingebunden werden soll.
Für dieses kleine devblog sieht das dann z.B. so aus. Die Konfiguration nil.conf legt die Datenbank in /opt/isso ab, deaktiviert Moderation (dieses kleine Blog segelt unter dem Wahrnehmungsradar der »Turnhallen voller Chinesen«…) und möchte eine Benachrichtigung über neue Kommentare per E-Mail. listen geht auf localhost Port 9090. Hat man isso irgendwohin intern containerisiert, muss man entsprechend die interne IP angeben:
Wenn man damit fertig ist, kann man isso starten und fortan als Hintergrundprozess laufen lassen:
Nun muss die isso-Pracht noch in das statische Blog hinein. Mein Jekyll-Deployment ist »old school«. Ich möchte keine Github-Pages oder Cloud-Gedöns à la Netlify, ein ordentlicher metallener Server mit einem soliden nginx soll es sein.
Zur Vermeidung von Problemem mit CORS etc. wird isso als Location mit proxy_pass in den nginx-Server eingebunden und ist dann unter https://nil.uninform.at/isso erreichbar:
Nach dem Neustart des nginx ist /isso verfügbar.
Fehlt noch die Einbindung in die Jekyll-Seiten. Diese wird durch ein Stück HTML im Seiten-Template realisiert, bei mir ist es layouts/post.html:
Jetzt noch einmal das Jekyll-Blog deployen und der Kommentarflut steht nichts mehr im Wege. Happy Jekylling!
", "url": "https://old-school.dev/2019/03/07/isso-installieren/", "tags": ["isso","python","jekyll","ssg"], "date_published": "2019-03-07T11:50:00+01:00", "date_modified": "2019-03-07T11:50:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/03/05/erlesenes/", "title": "Erlesenes I", "summary": "", "content_text": "Ihr kennt das. Wenn man durch Twitter und den RSS-Reader klickt, sammeln sich immer Links an, die man garantiert später noch einmal gründlich lesen wird (vielleicht)…Diese werden hier in nil? ab sofort von Zeit zu Zeit in der Rubrik »Erlesenes« gesammelt und rausgehauen.Rails 6 steht vor der Tür: »Rails 6.0.0 beta2 released«. Eine der interessantesten Neuerungen ist das Ersetzen der alten mit Sprockets realisierten JavaScript-Asset-Pipeline durch eine neue Lösung mit webpack. Ein etwas unnötig »übercool« verfasster aber nichtsdestotrotz informativer Artikel von »blackninja dojo« erklärt den Umgang damit: »Webpack, Webpacker and Modules, Oh My! How to Add Javascript to Ruby on Rails«.Auch sehr nützlich in Rails 6: Der Vergleich von Date-, DateTime- und Time-Objekten wird einfacher durch zwei neue Methoden namens before? und after?: »Rails 6 adds before? and after? methods to Date, DateTime, Time, and TimeWithZone.«.Apropos Ruby, ein Artikel bei »AppSignal« geht sehr detailliert auf die Funktionsweise und Unterschiede von dup und clone ein: »Diving into Ruby's #dup and #clone«.Noch ein lesenswerter Blogbeitrag von »AppSignal«: »An instrumental intro to GraphQL with Ruby«. GraphQL benutzen die coolen Dev-Girls und -Boys aus der JavaScript-Szene als Alternative zu REST zum Abfragen von APIs, z.B. in Gatsby. Der Artikel erläutert anhand einer Beispielapplikation, wie auch wir uncoolen Ruby-Devs GraphQL implementieren können…Vielleicht mag man Ruby, aber möchte nicht unbedingt Rails benutzen. Evtl. findet man dann hier eine Alternative: »8 Ruby frameworks that aren’t Rails«. Darin finden sich alte Bekannte wie Sinatra oder Hanami, aber auch (mir zumindest) unbekannte Newcomer wie Ramaze und NYNY…Oder man wechselt gleich die Sprache und taucht ein in die Abgründe Funktionaler Programmierung. Populär ist aktuell Elixir. Ein Artikel von MLSDev gibt Hilfe bei der Entscheidung: »Elixir Programming: Facts to Know for Better App Development«.Ein hübsches Spielzeug: Grid Divisions. Auf reddit wird erklärt, wofür das gut sein soll…jQuery soll ja angeblich tot sein, aber so ganz wohl doch nicht: »15 Best jQuery Image Galleries«.Und wenn die Langeweile plagt, warum nicht einfach mal einen Texteditor in C programmieren? »Build Your Own Text Editor«", "content_html": "Ihr kennt das. Wenn man durch Twitter und den RSS-Reader klickt, sammeln sich immer Links an, die man garantiert später noch einmal gründlich lesen wird (vielleicht)…
Diese werden hier in nil? ab sofort von Zeit zu Zeit in der Rubrik »Erlesenes« gesammelt und rausgehauen.
Rails 6 steht vor der Tür: »Rails 6.0.0 beta2 released«. Eine der interessantesten Neuerungen ist das Ersetzen der alten mit Sprockets realisierten JavaScript-Asset-Pipeline durch eine neue Lösung mit webpack. Ein etwas unnötig »übercool« verfasster aber nichtsdestotrotz informativer Artikel von »blackninja dojo« erklärt den Umgang damit: »Webpack, Webpacker and Modules, Oh My! How to Add Javascript to Ruby on Rails«.
Auch sehr nützlich in Rails 6: Der Vergleich von Date-, DateTime- und Time-Objekten wird einfacher durch zwei neue Methoden namens before? und after?: »Rails 6 adds before? and after? methods to Date, DateTime, Time, and TimeWithZone.«.
Apropos Ruby, ein Artikel bei »AppSignal« geht sehr detailliert auf die Funktionsweise und Unterschiede von dup und clone ein: »Diving into Ruby's #dup and #clone«.
Noch ein lesenswerter Blogbeitrag von »AppSignal«: »An instrumental intro to GraphQL with Ruby«. GraphQL benutzen die coolen Dev-Girls und -Boys aus der JavaScript-Szene als Alternative zu REST zum Abfragen von APIs, z.B. in Gatsby. Der Artikel erläutert anhand einer Beispielapplikation, wie auch wir uncoolen Ruby-Devs GraphQL implementieren können…
Vielleicht mag man Ruby, aber möchte nicht unbedingt Rails benutzen. Evtl. findet man dann hier eine Alternative: »8 Ruby frameworks that aren’t Rails«. Darin finden sich alte Bekannte wie Sinatra oder Hanami, aber auch (mir zumindest) unbekannte Newcomer wie Ramaze und NYNY…
Oder man wechselt gleich die Sprache und taucht ein in die Abgründe Funktionaler Programmierung. Populär ist aktuell Elixir. Ein Artikel von MLSDev gibt Hilfe bei der Entscheidung: »Elixir Programming: Facts to Know for Better App Development«.
Ein hübsches Spielzeug: Grid Divisions. Auf reddit wird erklärt, wofür das gut sein soll…
jQuery soll ja angeblich tot sein, aber so ganz wohl doch nicht: »15 Best jQuery Image Galleries«.
Und wenn die Langeweile plagt, warum nicht einfach mal einen Texteditor in C programmieren? »Build Your Own Text Editor«
", "url": "https://old-school.dev/2019/03/05/erlesenes/", "tags": ["erlesenes","ruby","rails","elixir"], "date_published": "2019-03-05T14:20:00+01:00", "date_modified": "2019-03-05T14:20:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/02/22/26-tips/", "title": "26 Vue Tips", "summary": "", "content_text": "Ich mache gerade ein bisschen mit Vue.js herum. Da ich davon durchaus angetan bin, war »Vueterich« ein ernsthafter Kandidat für die Benamung dieses kleinen devblogs…Zu dem Thema kommt diese Sammlung nützlicher Tipps gerade recht: »26 Time Saving Tips for Vue«Außerdem ist heute zum Thema Vue ein kleiner Rückblick auf VueJS Amsterdam im Angebot: »VueJS Amsterdam 2019 - The Best Bits«", "content_html": "Ich mache gerade ein bisschen mit Vue.js herum. Da ich davon durchaus angetan bin, war »Vueterich« ein ernsthafter Kandidat für die Benamung dieses kleinen devblogs…
Zu dem Thema kommt diese Sammlung nützlicher Tipps gerade recht: »26 Time Saving Tips for Vue«
Außerdem ist heute zum Thema Vue ein kleiner Rückblick auf VueJS Amsterdam im Angebot: »VueJS Amsterdam 2019 - The Best Bits«
", "url": "https://old-school.dev/2019/02/22/26-tips/", "tags": ["vuejs","javascript"], "date_published": "2019-02-22T12:55:00+01:00", "date_modified": "2019-02-22T12:55:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/02/20/frontend-2018/", "title": "Frontend 2018.", "summary": "", "content_text": "»A Recap of Frontend Development in 2018« resümiert das Frontend-Geschehens des vergangenen Jahres. Große Schwäche des Textes: Die Grundannahme Frontend == JavaScript (via F-LOG-GE).", "content_html": "»A Recap of Frontend Development in 2018« resümiert das Frontend-Geschehens des vergangenen Jahres. Große Schwäche des Textes: Die Grundannahme Frontend == JavaScript (via F-LOG-GE).
", "url": "https://old-school.dev/2019/02/20/frontend-2018/", "tags": ["frontend","javascript"], "date_published": "2019-02-20T10:09:00+01:00", "date_modified": "2019-02-20T10:09:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/02/18/help/", "title": "Help!", "summary": "", "content_text": "Großartiger Artikel: »Help! None of my projects want to be SPAs«. Zitat: »My strategy for dealing with the absurd pace of change in web development has been as follows: ignore 99% of it and see if it goes away.« (via Changelog)", "content_html": "Großartiger Artikel: »Help! None of my projects want to be SPAs«. Zitat: »My strategy for dealing with the absurd pace of change in web development has been as follows: ignore 99% of it and see if it goes away.« (via Changelog)
", "url": "https://old-school.dev/2019/02/18/help/", "tags": ["javascript"], "date_published": "2019-02-18T11:33:00+01:00", "date_modified": "2019-02-18T11:33:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/02/15/weird-ruby/", "title": "Weird Ruby.", "summary": "", "content_text": "Ruby hat schon einige esoterische Sprachelemente, im Blog von CultureHQ Engineering wurden ein paar vorgestellt: »Weird Ruby«. Mein Favorit ist der Flip-flop…", "content_html": "Ruby hat schon einige esoterische Sprachelemente, im Blog von CultureHQ Engineering wurden ein paar vorgestellt: »Weird Ruby«. Mein Favorit ist der Flip-flop…
", "url": "https://old-school.dev/2019/02/15/weird-ruby/", "tags": ["ruby"], "date_published": "2019-02-15T11:09:00+01:00", "date_modified": "2019-02-15T11:09:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/02/15/git-historie/", "title": "Eine Datei aus der git-Historie ausgraben…", "summary": "", "content_text": "Versionskontrollsysteme benutzt man bekanntlich, um die vorgenommenen Änderungen an den Dateien nachvollziehen und bei Bedarf zurückholen zu können. Wenn man das dann tatsächlich mal machen muss, stellt man fest, dass der Weg dahin gar nicht so einfach ist und es diverse unterschiedliche Herangehensweisen dafür gibt.Bei Github hat man sogar einen Longread für die unterschiedlichen Situationen und Wege dafür verfasst (»How to undo (almost) anything with Git«). Und bei Stack Overflow findet man eine schöne Diskussion mit hervorragend erklärten Wegen (»How to revert a Git repository to a previous commit«).Als einfachster Weg für den Fall »ich habe an einer Datei vor 47 Commits was geändert, war aber Mist und jetzt brauche ich mal den alten Stand aus genau einer Datei« hat sich in der Praxis die folgende Vorgehensweise bewährt:Zunächst muss man wissen, in welchen Commits die Datei überhaupt geändert wurde. Das kann man mit git log –follow– herausfinden: git log --follow -- app/views/products/_channelproducts_form.html.hamlDas Ergebnis ist eine Liste von Commits, in der die Datei verändert wurde. Der Commit ist der, den wir brauchen: commit 2918261… Author: Ralf G… <…> Date: Tue Dec 4 14:40:32 2018 +0100 Umbau der Produktform…Wenn man jetzt einfach den Commit mit git checkout 2918261 wieder auscheckt, befindet man sich in einem Zustand des »detached HEAD«, man ist also in keiner Branche mehr. Man kann dem zwar mit git checkout master wieder entfliehen. Gerade für Menschen, die das nicht so oft machen, ist die Gefahr groß, durch Änderungen und Checkouts ein kleines Durcheinander zu produzieren.Der sichere Weg ist das Auschecken des Commits in eine neue Branche: git checkout -b alte_produkt_form 2918261Die Branche alte_produkt_form befindet sich nun auf dem Stand des Commits 2918261. Man kann in dieser in aller Ruhe rummachen, ohne die anderen Branches anzurühren.Wenn man fertig ist und gefunden hat was man braucht, kann man sich die alte Datei über verschiedene Wege (gute alte Zwischenablage oder Stash) in seinen Master übernehmen und den alten Stand dort als neuen Commit einchecken. Was die Änderung dann im Log deutlich leichter nachvollziehbar macht als ein Löschen des Commits mit anschließendem Rebase.", "content_html": "Versionskontrollsysteme benutzt man bekanntlich, um die vorgenommenen Änderungen an den Dateien nachvollziehen und bei Bedarf zurückholen zu können. Wenn man das dann tatsächlich mal machen muss, stellt man fest, dass der Weg dahin gar nicht so einfach ist und es diverse unterschiedliche Herangehensweisen dafür gibt.
Bei Github hat man sogar einen Longread für die unterschiedlichen Situationen und Wege dafür verfasst (»How to undo (almost) anything with Git«). Und bei Stack Overflow findet man eine schöne Diskussion mit hervorragend erklärten Wegen (»How to revert a Git repository to a previous commit«).
Als einfachster Weg für den Fall »ich habe an einer Datei vor 47 Commits was geändert, war aber Mist und jetzt brauche ich mal den alten Stand aus genau einer Datei« hat sich in der Praxis die folgende Vorgehensweise bewährt:
Zunächst muss man wissen, in welchen Commits die Datei überhaupt geändert wurde. Das kann man mit git log –follow– herausfinden:
Das Ergebnis ist eine Liste von Commits, in der die Datei verändert wurde. Der Commit ist der, den wir brauchen:
Wenn man jetzt einfach den Commit mit git checkout 2918261 wieder auscheckt, befindet man sich in einem Zustand des »detached HEAD«, man ist also in keiner Branche mehr. Man kann dem zwar mit git checkout master wieder entfliehen. Gerade für Menschen, die das nicht so oft machen, ist die Gefahr groß, durch Änderungen und Checkouts ein kleines Durcheinander zu produzieren.
Der sichere Weg ist das Auschecken des Commits in eine neue Branche:
Die Branche alte_produkt_form befindet sich nun auf dem Stand des Commits 2918261. Man kann in dieser in aller Ruhe rummachen, ohne die anderen Branches anzurühren.
Wenn man fertig ist und gefunden hat was man braucht, kann man sich die alte Datei über verschiedene Wege (gute alte Zwischenablage oder Stash) in seinen Master übernehmen und den alten Stand dort als neuen Commit einchecken. Was die Änderung dann im Log deutlich leichter nachvollziehbar macht als ein Löschen des Commits mit anschließendem Rebase.
", "url": "https://old-school.dev/2019/02/15/git-historie/", "tags": ["git"], "date_published": "2019-02-15T10:50:00+01:00", "date_modified": "2019-02-15T10:50:00+01:00", "author": { "name": "" } }, { "id": "https://old-school.dev/2019/02/11/jamstack/", "title": "Das nächste große Ding: JAMstack", "summary": "", "content_text": "Alles in der Welt der Webentwicklung braucht einen griffigen Namen. Mit »Ajax« fing das an…Als in den letzten Jahren statische Seitengeneratoren wie Jekyll immer populärer wurden und man begann (so wie früher mit Wordpress), jede für diese Technologie geeignete und auch eher ungeeignete Aufgabe damit lösen zu wollen, stellte man fest, dass es ganz ohne »Dynamik« halt auch nicht geht. Man verlagerte die dynamischen Komponenten mangels Backend deshalb mit JavaScript ins Frontend. Statische Seiten enthalten JavaScript, das sich von APIs Daten holt und darstellt. Und schon war der »JAMstack« geboren: »Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.«Und so denken sich die Leute kühne Konstrukte für ihre Websites aus. Statische Websites werden mit aktuell voll im Trend liegenden javascriptlastigen Generatoren wie Gatsby (das gute alte Jekyll, das meine Blogs allesamt antreibt, ist bei den »Coolen« voll out…) gebacken und aus einem »Headless CMS« wie Contentful mit Inhalten gefüllt. Und das Endergebnis wird bei Hostern wie Netlify abgelegt. Das ist der Fortschritt: Die Abhängigkeit vom eigenen programmierten Backend durch Abhängigkeiten von einem oder mehreren externen Anbietern zu ersetzen…Wer sich in das Thema JAMstack einlesen möchte, findet bei JAMstack WTF eine schöne bunte Einführung. Und kann staunen, wie schnell es die Webentwicklungs-Community mal wieder geschafft hat, aus der simplen Idee »Wir nehmen einen SSG und backen aus ein paar Dokumenten eine statische Website und werfen diese auf einen Server und freuen uns!« ein kompliziertes Etwas voller externer Abhängigkeiten zu schaffen…", "content_html": "Alles in der Welt der Webentwicklung braucht einen griffigen Namen. Mit »Ajax« fing das an…
Als in den letzten Jahren statische Seitengeneratoren wie Jekyll immer populärer wurden und man begann (so wie früher mit Wordpress), jede für diese Technologie geeignete und auch eher ungeeignete Aufgabe damit lösen zu wollen, stellte man fest, dass es ganz ohne »Dynamik« halt auch nicht geht. Man verlagerte die dynamischen Komponenten mangels Backend deshalb mit JavaScript ins Frontend. Statische Seiten enthalten JavaScript, das sich von APIs Daten holt und darstellt. Und schon war der »JAMstack« geboren:
»Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.«
Und so denken sich die Leute kühne Konstrukte für ihre Websites aus. Statische Websites werden mit aktuell voll im Trend liegenden javascriptlastigen Generatoren wie Gatsby (das gute alte Jekyll, das meine Blogs allesamt antreibt, ist bei den »Coolen« voll out…) gebacken und aus einem »Headless CMS« wie Contentful mit Inhalten gefüllt. Und das Endergebnis wird bei Hostern wie Netlify abgelegt. Das ist der Fortschritt: Die Abhängigkeit vom eigenen programmierten Backend durch Abhängigkeiten von einem oder mehreren externen Anbietern zu ersetzen…
Wer sich in das Thema JAMstack einlesen möchte, findet bei JAMstack WTF eine schöne bunte Einführung. Und kann staunen, wie schnell es die Webentwicklungs-Community mal wieder geschafft hat, aus der simplen Idee »Wir nehmen einen SSG und backen aus ein paar Dokumenten eine statische Website und werfen diese auf einen Server und freuen uns!« ein kompliziertes Etwas voller externer Abhängigkeiten zu schaffen…
", "url": "https://old-school.dev/2019/02/11/jamstack/", "tags": ["ssg","jamstack"], "date_published": "2019-02-11T13:48:00+01:00", "date_modified": "2019-02-11T13:48:00+01:00", "author": { "name": "" } } ] }