Nuxt.js

nuxtjs vuejs javascript

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:

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…

Projektbezogene irb-Historie für Rails

ruby rails irb

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')
  end

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:

  ActiveRecord::Base.logger = nil

Eine populäre Alternative zu irb ist pry. pry hat viele Features, fast schon zu viele, weshalb ich irb bevorzuge.

Ein Happen Dynamik: isso installieren und in ein statisches jekyll-Blog einbinden

isso python jekyll …

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…

Weiterlesen…

Eine Datei aus der git-Historie ausgraben…

git

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.

Weiterlesen…

Das nächste große Ding: JAMstack

ssg jamstack

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…