Ruby on Rails today

Stefan Tilkov:

Hallo und herzlich willkommen zu einer neuen Episode des INNOQ Podcasts. Das ist heute mal wieder eine der Folgen mit verdrehten Rollen, weil unser normalerweise als Interviewer tätiger Kollege Lucas heute interviewt wird. Hallo Lucas.

Lucas Dohmen:

Hallo Stefan.

Stefan Tilkov:

Lucas, alle kennen dich als Podcast-Host. Aber sag ganz kurz, was du noch für ein Leben hast bei uns.

Lucas Dohmen:

Genau, ich bin bei INNOQ auch Senior Consultant und dann bin ich als Web-Entwickler und Web-Architekt vor allem unterwegs, gebe auch Schulungen zu Web-Architektur und Web-Technologien. Das mache ich so bei INNOQ.

Stefan Tilkov:

Ok. Als Thema haben wir uns heute “Ruby on Rails” ausgesucht, so eine Art Status Update zu “Ruby on Rails”. Und ich würde gerne mit einer ungewöhnlichen Frage beginnen. Nämlich, sag uns doch erst mal, was du anderes kennst, also welche anderen Webframeworks oder Webbibliotheken, -technologien hast du denn schon benutzt in deinem Leben?

Lucas Dohmen:

Ja, also ich hab vor allem Rails gemacht in meiner Zeit als Software-Entwickler, aber ich habe auch relativ viel Express.js gemacht in Node.js. Das ist so das Framework, was ich vermutlich am zweitmeisten benutzt habe. Dann habe ich etwas Django gemacht, sogar auch im Projekt-Kontext und dann habe ich seit diesem Jahr Go gemacht, also da vor allem gorilla/mux, was auch so ein Web Routing Framework ist, würde ich jetzt mal sagen. Genau, das sind so die Sachen, womit ich im Backend bisher mein Geld verdient habe.

Stefan Tilkov:

Ein Grund, warum ich die Frage stelle, ist, dass wir beide uns häufig in der Position finden, dass wir Leuten davon vorschwärmen wie cool Rails eigentlich ist. Dann finde ich es immer ganz gut, wenn die Leute wissen, dass das nicht das Einzige ist, was man kennt, einfach um ein bisschen Vergleiche ziehen zu können und dass unsere Begeisterung immer noch gerechtfertigt ist für das Ding. Mal sehen, ob wir das rüberbringen können oder nicht. Ich würde mich bemühen, die Java-Fraktionen halbwegs würdig zu vertreten. Mal sehen, ob ich das noch schaffe, und dann lass uns doch einfach direkt mit der Gegenfrage einsteigen. Du hast gesagt, du machst schon relativ lange Rails. Was hast du denn sonst noch für eine Beziehung zu diesem Ding?

Lucas Dohmen:

Ja genau, seit Rails 6 rausgekommen ist, bin ich dabei, an “The Rails 6 Way” zu schreiben. Es gibt ein Buch in der Rails-Welt, die erste Version hieß “The Rails Way” von Obie Fernandes und der Obie Fernandes, der hat angefangen nach einem, nach zwei weiteren Leuten suchen, die mithelfen, die neue Version zu schreiben, weil er nicht mehr so die Zeit hat, für jede neue Rails-Version, die rauskommt, die kommende Version zu schreiben. Und ja, da bin ich jetzt seit ungefähr zwei Jahren dran, woran man vielleicht auch erkennt, dass das gar nicht so wenig ist, was in diesem Framework so drin ist. Weil das doch relativ viel Zeit in Anspruch nimmt, zu prüfen, ob alles, was da drin steht, noch stimmt, ob vielleicht manche Sachen vielleicht so, wenn man den Rails 3-Weg beschrieben hat, das vielleicht heute trotzdem anders beschreiben würde, weil das, was da historisch dann drin steht, nicht mehr so relevant ist, also da so ein bisschen aufzuräumen, auch mit Sachen, die heute gar nicht mehr so wichtig sind. Genau und damit beschäftige ich mich in meiner Freizeit.

Stefan Tilkov:

Gut, dann lass uns doch vielleicht eine möglicherweise noch interessante Frage beantworten, nämlich: Lebt das überhaupt noch? Ist das überhaupt noch relevant?

Lucas Dohmen:

Ja, ich finde die Frage immer interessant, weil es gibt zumindest mal eine Rails-Anwendung, die viele von uns fast täglich benutzen und das ist GitHub. Also GitHub ist von Anfang an in Rails geschrieben und ist auch bis heute in Rails geschrieben. Da hat sich auch nichts geändert und ich habe auch noch nicht gehört, dass sie irgendwelche Pläne haben, das zu ändern. Und GitHub ist ja wirklich so eine Plattform, die wir vermutlich, also wenn nicht täglich aber doch mal mindestens einmal die Woche benutzen und die auch immer ganz gut zeigt, dass Rails auch skalieren kann, weil ich glaube die meisten von uns werden, glaube ich, keine Anwendung schreiben, die so viele Benutzer und Benutzerinnen hat wie GitHub. Und das ist auch interessant deswegen, weil es da auch ganz lange eine Sorge oder Kritik gab und das war so, als Rails 3 herauskam, das war eine relativ große Änderung, weil es da, historisch gesehen, eine Zusammenführung mit dem anderen Ruby-Framework gab, das “Merb” heißt oder hieß. Das gibt es heute nicht mehr, das war ungefähr 2010, glaube ich, und zu dem Zeitpunkt gab es halt Rails-Anwendungen, die gesagt haben, ok, der Umstieg ist für uns zu schwierig, wir kriegen das nicht hin, so viele Änderungen durchzuführen, weil sich doch relativ viel geändert hat. Und GutHub hat damals entschieden, ein Fork von Rails 2 weiter zu verwenden. Bis vor zwei Jahren sind die quasi noch auf ihrem eigenen Rails 2-Branch gewesen. Also konnte man durchaus sagen, ja, GitHub benutzt ja gar kein Rails, sondern die benutzen halt ihr eigenes Webframework. Das hat sich dann tatsächlich geändert. Die haben eine Entwicklerin eingestellt, die Eileen, die nur daran gearbeitet hat, die quasi schrittweise irgendwie zu Rails 6 zu bringen, dass es damals halt noch nicht gab und die hat da auch ganz tolle Talks zu gemacht. Da können wir auch ein paar von verlinken. Und ja, das war dann tatsächlich so, dass Rails 6 die erste Version war, wo GitHub wieder auf Rails gesetzt hat, also jetzt wieder das ganz normale Rails-Framework benutzt. Und das finde ich halt auch schön, dass man jetzt auch sieht, das GitHub da jetzt auch Sachen zurückgibt an Rails. Beispielsweise ihr Datenbank-Setup, da haben die einiges draus gelernt und in Rails 6 mit eingebaut und die anderen zwei großen Plattformen, würde ich sagen, sind Shopify und Basecamp. Basecamp als der Ort, an dem es entstanden ist. Aber auch Shopify ist halt eine riesige Plattform und da kann man glaube ich schon sehen, dass zumindest mal bis heute große Firmen es auch weiterhin als sinnvolle Plattform sehen und wenn ich das jetzt auch, du hast mich am Anfang gefragt, welche anderen Webframeworks ich kenne und mit denen ich gearbeitet habe und für mich ist Rails halt immer noch etwas, wo ganz viele Sachen, die ich jedesmal brauche, schon in der Box mit dabei sind, wo ich nicht recherchieren muss, welche Library nehme ich jetzt dafür. Das ist einfach schon dabei und das ist für mich bis heute sehr angenehm. Gerade wenn man einfach schnell starten will, schnell an ein Ergebnis kommen will, ohne dass es dabei jetzt eine “Quick and Dirty”-Solution ist. Das funktioniert halt und weil es halt auch von vielen in Produktion verwendet wird.

Stefan Tilkov:

Dann lass uns doch vielleicht einfach mal einen kurzen Überblick oder gib du doch mal eine kurzen Überblick darüber, was da bei diesen “Batteries included” alles drin ist. Was ist denn das überhaupt für ein Framework und welche Bestandteile gibt es?

Lucas Dohmen:

Genau, also grundsätzlich würde ich sagen, das man erstmal überlegen muss, was bedeutet überhaupt Webframework? Darunter verstehen verschiedene Leute verschiedene Sachen. Im Kern, das was wirklich jedes Webframework hat, ist halt irgendeine Möglichkeit, Routing zu machen. Also, dafür zu sorgen, wenn diese URL aufgerufen wird, wird dieser Code ausgeführt. Das hat Express.js, das hat Rails, das hat Spring Boot, das hat jedes Framework irgendwo. Und das ist in Rails natürlich der Kern von dem Framework, der viele interessante Features hat. Aber ja, würd ich jetzt nicht im Detail drauf eingehen. Aber da ist auf jeden Fall so das dabei, was man erwartet, dass man irgendwie Controller hat, dass man Routes definieren kann und so weiter und so fort. Aber neben dem ist ein sehr großes Framework noch mit eingebaut. Das ist Active Record. Das ist ein ORM, das ganz klar auch auf relationale Datenbanken fokussiert ist. Also man kann das jetzt nicht mit MongoDB benutzen oder so etwas. Das ist fokussiert auf relationale Datenbanken und ist auch ein sehr umfangreiches Framework, dass sehr viele Features hat, wo manche Leute finden, dass es zu viele Features hat und da sind auch so Sachen bei wie Validierungen, da sind so Sachen bei wie Associations definieren und nette Zusatzfunktion, die man hat, um mit diesen Associations umzugehen. Es hat ein sehr mächtiges Query Interface, mit dem wir Abfragen machen können. Wir haben die Möglichkeit, Modelle zu definieren, in denen wir Queries vordefinieren und auch neu zusammenstellen können. Das find ich auch immer sehr praktisch. Genau, das ist so der andere Teil von dem Framework. Rein vom Code her ist das mit Abstand der größte Teil von Rails. Also, Active Record ist die größte Codebase innerhalb von diesem Framework. Dann gibt es natürlich eine Möglichkeit, Views zu definieren. Das ist Action View. Das bietet so Sachen wie Layouts und Templates und so weiter. Da ist eine Templating Sprache dabei, die in Ruby dabei ist, das ist die ERB. Man kann aber auch andere Templating Sprachen benutzen. Das andere ist, also ich würde sagen, es gibt 2 Templating Sprachen, die man in der Ruby-Welt nutzt. Das eine ist halt ERB. Das andere Haml. Und beides ist halt supported. Man kann beides verwenden und ich würd sagen, dass es im Kern, dass ist so das Kern-Framework, das, was man auf jeden Fall erstmal immer benutzt. Aber neben dem und das ist das, was glaube ich, wirklich anders ist als bei anderen Frameworks, die viel mit dabei haben, dass es da noch eine ganze Reihe von weiteren Komponenten gibt, die mit der Zeit dazugekommen sind, die man halt einfach so “out of the box” verwenden kann.

Stefan:

Ich fand früher den Vergleich immer ganz passend, für die Java-Leute, dass Rails eigentlich eher wie Java EE ist und nicht nur wie, was weiß ich, Spring MVC oder JSF oder irgendwie sowas, sondern das ist ein absolutes Fullstack-Framework. Aber eigentlich greift selbst das noch irgendwie zu kurz, weil diese ganze JavaScript-Welt ist irgendwie auch mit drin, oder?

Lucas Dohmen:

Also, ich würde sagen, das war wirklich eine Besonderheit, die bei Rails, also wenn man wie ich, sowohl im Backend als auch im Front End arbeitet, vermisst man einfach Dinge wie eine Asset-Pipeline. Das ist etwas, was in vielen Frameworks leider immer noch fehlt.

Stefan Tilkov:

Kannst du kurz erklären, was das ist, eine Asset Pipeline?

Lucas Dohmen:

Genau, mach ich gerne. Eine Asset Pipeline ist erstmal grundsätzlich die Idee, wir haben Assets. Das ist ein etwas merkwürdiger Name, ich suche immer noch nach einem besseren, aber ein Asset ist so was wie unsere CSS-Files, sowas wie unsere JavaScript-Files, Bilder und so weiter, die wir ausliefern müssen für unsere Website und es ist eigentlich immer so, dass wir diese Files irgendwie vorprozessieren müssen. Wir liefern die nie, also ich, in jeder Anwendung, in der ich bisher gearbeitet habe, haben wir die nie einfach so ausgeliefert wie wir sie geschrieben haben. Man möchte sowas machen wie, beispielsweise hat man Typescript verwendet und möchte aus Typescript JavaScript machen oder man hat SCSS benutzt und möchte daraus CSS machen. Solche ganz einfachen Transformationen oder man möchte vielleicht mehrere Dateien zu einer Datei zusammenfügen, bevor man sie ausliefert. Oder man möchte die Datei modifizieren, bevor man sie ausliefert. Das sind alles Sachen, die so eine Asset Pipeline bieten kann. Ein Beispiel für so eine Asset Pipeline wäre Webpack. Das benutzen heute viele, aber weit bevor es Webpack gab, hatte halt Rails schon eine Asset Pipeline eingebaut, die heißt, also manche nennen sie einfach Asset Pipeline, eigentlich heißt ist Sprockets und Sprockets hat halt zu dem Zeitpunkt viele von den Features schon angeboten, die es einfach in anderen Webframeworks gar nicht gab. Das ist natürlich heute nicht mehr so. Heute bieten andere Webframeworks auch Asset Pipelines an. Aber ich bin immer wieder erstaunt, dass es doch wieder viele Ökosysteme gibt, wo es so was überhaupt nicht gibt oder wo sowas halt nur sehr rudimentär existiert. Und in Rails ist es halt so und war es auch so, dass sich das immer weiter entwickelt hat, also Sprockets hatte eine ganze Zeit einen ganz starken Fokus auf einer Sprache, die CoffeeScript heißt, weil der Erfinder von Rails, D.H.H. oder David Heinemeier Hansson, ein ganz großer Fan von dieser Sprache war, die glaube ich, heute die meisten Leute nicht mehr verwenden würden. Und da war halt einfach dieser Support für CoffeeScript mit eingebaut. Da haben viele Leute nicht JavaScript Code, sondern stattdessen CoffeeScript geschrieben. Und das hat sich jetzt halt auch wieder schrittweise verändert, gerade dadurch, ich hatte ja schon Webpack erwähnt, das ist ja eine in JavaScript geschriebene Asset Pipeline, deren Fokus aber ganz klar auch auf dem Verarbeiten von JavaScript liegt und jetzt nicht so sehr auf CSS und Bildern und so weiter, auch wenn es dafür auch Support anbietet. Und da hat das Rails-Team mit 5.1 damals Webpacker, deswegen mein Versprecher eben, eingeführt. Das ist quasi ein Ruby Wrapper um Webpack herum. So, und das hat es halt angeboten als eine Möglichkeit, bestimmte Sachen, die Sprockets, was halt einfach modernere Features nicht mehr so gut unterstützt hat, wie jetzt zum Beispiel das neuere Modulsystem von JavaScript und so weiter, einfach angeboten hat, dafür Webpack zu verwenden. Und da wurde mit Rails 5.1 damals Support für eingebaut. In Rails 6 wurde das dann zum Default, um sein JavaScript zu verarbeiten. Man hat weiterhin Sprockets verwendet, um CSS zu verarbeiten, um Bilder zu verarbeiten, Fonts zu verarbeiten. Aber WebPacker war halt für JavaScript da. Aber das wird sich wahrscheinlich jetzt mit Rails 7, wie ich vermute – das Rails-Team hält seine Release-Planung etwas geheim, deswegen kann man das nicht immer so genau sagen – aber mit sehr hoher Wahrscheinlichkeit wird Rails 7 nächstes Jahr herauskommen. Möglicherweise so am Ende des ersten Quartals, Anfang des zweiten Quartals. Da wird wahrscheinlich Webpack wieder rausfliegen und durch noch einen neuen Ansatz ersetzt werden. Und das finde ich auch deswegen interessant, nicht unbedingt, also ich bin kein großer Fan von Webpack, aber dafür ist jetzt nicht der Platz in dieser Folge. Aber das Rails-Team beschäftigt sich damit, wie können wir dieses Problem lösen und versucht, verschiedene Dinge aus. Ich bin da jetzt auch nicht 100prozentig der Meinung, dass sie da den besten Weg gefunden haben, aber sie sind auf jeden Fall, haben nicht gesagt, so, das Problem ist halt erledigt und wir sind fertig, Asset Pipelines sind gelöst, sondern sie versuchen halt weiter aus, wie können wir das einfacher machen, wie können wir dafür sorgen, dass es auch für Leute, die sich nicht ausgiebig mit JavaScript und so weiter beschäftigen, sehr einfach starten können? Das, finde ich, kann man auch gerade an der Asset Pipeline gut sehen. Webpacker war jetzt relativ komplex eine ganze Zeit, und jetzt versuchen sie wieder eine einfachere Lösung zu finden.

Stefan Tilkov:

Meine aktive Rails-Zeit liegt etwas zurück, deswegen würde ich aus Interesse einfach mal fragen. Früher war ein Merkmal, ein zentrales Merkmal, immer dieses “opinionated”. Das hat ja bei dir auch so ein bisschen durchgeschimmert. Also wenn D.H.H., der Haupt-Entwickler irgendwas toll findet, dann wandert das halt da rein, und wenn er was doof findet, dann fliegt es genauso schnell wieder raus.

Lucas Dohmen:

Genau.

Stefan Tilkov:

Das, das ist ja irgendwie, das war das Hauptmerkmal und ein großer Unterschied zu anderen Frameworks, z.B. in der Java-Welt, Spring hat immer den Anspruch gehabt, ganz, ganz viele Optionen zu lassen und ganz, ganz viele unterschiedliche Dinge zu ermöglichen, so dass man sich eben selbst zusammenstellt, was man für das Richtige hält. Wie ist denn das heute bei Rails? Wie sehr ist es “opinionated” und wie sehr unterstützt es ganz viele verschiedene Optionen?

Lucas Dohmen:

Ja, also es ist auf jeden Fall immer noch so, dass die Meinungen von David sehr prominent sind. Das bedeutet erstmal, der Default ist das, was er für die beste Idee hält. Er findet ERB ist die bessere Templating-Sprache, also ist die der Default. Er findet, das Webpack, also bis vor kurzem fand er, dass Webpack die beste Lösung ist für JavaScript, also ist das der Default. Das jetzt mal als Beispiel. Aber genauso muss man jetzt ganz kurz nochmal auf Basecamp eingehen. Basecamp ja so eine Projektmanagement-Software, würde ich jetzt mal vereinfacht sagen. Und Basecamp wurde halt über die Zeit zweimal neu geschrieben. Also es gab Basecamp 1, 2 und aktuell Basecamp 3. Und die Sachen, die er benötigt, um Basecamp zu bauen, die werden halt auch in das Framework eingebaut. Ein Beispiel: In Basecamp 3 kam ein neues Feature, das man per Mail Sachen in sein Basecamp rein speichern kann. Also, man kann da so eine Mail hinschicken und dann wird daraus ein Reply gemacht oder was auch immer. Und das wurde in Rails, da gab es ganz einfachen Support. Also Rails hat erstmal Support dafür, Mails rauszuschicken mit Action Mailer. Aber das mit den eingehenden Mails, das war wirklich sehr einfach gehalten. Also hat David gesagt, dann brauchen wir wohl besseren Support für eingehende Emails in Rails. Also wurde in Rails 6 Action Mailbox eingeführt. Action Mailbox ist eine kleine Library, die halt Teil von Rails ist. Also auch nicht irgendwas, was man zusätzlich installiert. Sondern das ist tatsächlich einfach eingebaut in Rails. Man kann damit Mails empfangen und prozessieren. Und das ist da drin, weil Basecamp das gebraucht hat und das ist auch bis heute so. Es ist aber ganz klar so, dadurch, dass es ganz viele weitere Anwendungen gibt und auch große Anwendungen gibt, wie beispielsweise GitHub und Shopify, die natürlich ganz andere Anforderungen haben, dass man bestimmte Sachen auch sehr einfach ausstellen kann, ersetzen kann und so weiter. Also, das ist irgendwie auch das Schöne an Rails, dass man halt immer erstmal diesen Basecamp-Default hat, das heißt erstmal, wenn man sich keine größeren Gedanken gemacht hat, ist es erstmal da und wenn man dann sagt, ja, irgendwie finde ich das doch doof oder ich brauch das gar nicht, dann kann man es entweder abschalten oder ersetzen. Das ist weiterhin möglich. Und gerade in Rails 3, was vor über 10 Jahren rausgekommen ist, wurde das halt ganz stark verbessert, dass man da dafür sorgen kann, dass man ganz viele Sachen austauschen kann, ohne dass da was kaputt geht. Also selbst dieser ORM, der ja wirklich tief eingearbeitet ist in das Webframework, den kann man auch ersetzen durch eine MongoDB Datenbank Library. Das machen auch gar nicht so wenig Leute. Das ist auch der Grund im übrigen, warum das Buch, an dem wir schreiben, “The Rails 6 Way” heißt, weil die Philosophie eben eine opinionated in Anführungsstrichen Philosophie ist, das heißt also auch in unserem Buch sagen wir, unserer Meinung nach sind das halt gute Wege, das zu lösen und an manchen Stellen haben wir halt eine andere Meinung als Basecamp, und dann stellen wir die halt auch in dem Buch vor und sagen, wie man auch von diesem Weg abweichen kann und eher auf den Weg kommt, den wir für sinnvoller halten.

Stefan Tilkov:

Zum Beispiel “Haml” anstatt “ERB” oder so.

Lucas Dohmen:

Ja, genau. Beispielsweise das. Das ist eine der bekannten Entscheidungen, wo das Buch abweicht. Das andere ist das Test-Framework. Das Default für Test-Framework heißt “MiniTest” und das, was wir vorschlagen, heißt “RSpec”. Das sind so die zwei großen Sachen, wo es abweicht. Aber auch an vielen kleineren Stellen, wo wir andere Sachen empfehlen als Basecamp oder David.

Stefan Tilkov:

Wo steht die Rails-Community heute in Sachen Server-side Rendering versus Client-side JavaScript SPA?

Lucas Dohmen:

Ja, also, ich glaub tatsächlich, dass die Rails-Community vielleicht auch zusammen mit der Django-Community, das sind wirklich Communities, in denen ist der Default weiterhin Server-side Rendering, was heute eher ungewöhnlich ist. Ich würde vermuten, auch in Java eher ungewöhnlich ist, wo man wahrscheinlich auch relativ häufig eher eine API baut in seinem Backend-Framework. Das ist in Rails immer noch so, dass der Fokus ganz klar auf Server-side Rendering liegt und dafür auch ganz viel Support eingebaut ist. Weil das ist das, was mir auch auffällt, wenn ich jetzt zum Beispiel sowas benutze wie Express in Node oder jetzt in Go. Da habe ich auch versucht, Server-side Rendering zu machen. Da fehlen einem einfach einige Dinge, z.B. wie gehe ich mit Formularen um? Das ist etwas, das ist wenn man Rails benutzt, ganz ganz selbstverständlich. Da ist einfach Support für eingebaut und in Go muss man sich da Sachen zusammensuchen und zusammenkleben, damit das funktioniert.

Stefan Tilkov:

Was ja schon ein bisschen schräg ist, oder? Ich meine, ein Webframework, das keine Web-Formulare verwalten kann out of the box. Also, das finde ich dann irgendwie offensichtlich.

Lucas Dohmen:

Ja, das stimmt. Aber gerade halt diese Philosophie der Frameworks, die man halt als Routing-Frameworks bezeichnet, wie jetzt Express oder gorilla/mux, die sagen halt, unsere Aufgabe ist es, Routing zu machen. Und alles, was darüber hinausgeht, ist also schon extra. Also ich meine, in Express kann man jetzt auch ein Template rendern beispielsweise, das ist in gorilla/mux schon nicht mehr so, dass das mit dabei ist. Aber wenn der Fokus der Community vor allem darauf liegt, APIs zu bauen, dann sind Formulare schon nicht mehr so interessant. Und das merkt man bei den Frameworks und das ist definitiv etwas, was in Rails anders ist und was ich sehr vermisse, wenn ich ein anderes Webframework benutze, um Server-side Rendering zu machen. Also, man kann natürlich Rails auch verwenden, um eine API zu bauen. Seit einiger Zeit, das kann ich jetzt aus dem Kopf nicht sagen, gibt es halt auch die Optionen, so eine Rails-Anwendung zu generieren, die ganz viele Sachen ausgeschaltet hat, weil man wirklich nur die API bauen will. Da ist dann z.B. das ganze View Layer ausgenommen und so weiter. Und dann kann man auch eine API damit bauen. Es gibt auch Leute, die nutzen Rails als Backend für ihre React-Anwendung beispielsweise aber ich kann natürlich jetzt keine Zahlen dazu sagen, aber ganz klar von dem, was ich mitbekomme, von anderen Leuten, ist der Fokus ganz stark Server-side Rendering und bietet dafür viel Support an.

Stefan Tilkov:

Ich glaube, das ist wahrscheinlich auch dann vielleicht das schlagendste Argument: Wenn man das tun will, wenn man so eine… Nein, ich formuliere es als Frage und nicht als Aussage und du musst mir sagen, ob du das auch so sehen würdest oder nicht. Ich würde sagen wenn man eine Web-Anwendung bauen möchte, die serverseitig gerendert wird, die auf eine relationale Datenbank zugreift und die sich so im großen und ganzen an aktuelle Best Practices, was Security und sonstigen Kram angeht, hält, dann ist Rails so eine super effiziente “out of the box”-Lösung, mit der man genau das ohne großes Nachdenken macht. Ist das so?

Lucas Dohmen:

Genau. Ja, würde ich so sagen. Also wie gesagt, ich habe auch schon bisschen was mit Django gemacht im Projekt. Das erfüllt viele ähnliche Requirements. Das weicht an einigen Stellen philosophisch von Rails stark ab. Aber grundsätzlich merkt man auch in dem Framework, dass sie großen Fokus auf Server-side Rendering legen und auch da ist zum Beispiel ganz ganz toller Form-Support mit eingebaut. Aber wenn man Server-side Rendering machen will, dann sollte Rails zumindest auf der Auswahlliste stehen, weil es wirklich guten Support dafür bietet und dann sollte man das auch mal vergleichen mit dem, was die anderen Frameworks, die man da auf der Liste hat. Ich sag ja nicht, dass ist die einzige Möglichkeit, absolut nicht, aber dass Rails eine wirklich gute Wahl ist, weil eben so viele Sachen wie jetzt Asset Support, Templating mit Form-Support und so weiter mit dabei ist. Und da, also an dieses Feature-Set reichen viele Webframeworks meiner Erfahrung nach einfach nicht an.

Stefan Tilkov:

Noch eine Frage, auch wenn ich die Antwort natürlich eigentlich schon kenne, aber ich stelle sie trotzdem. Da ich deine Meinung natürlich schon kenne. Wie sehr hältst du Ruby in diesem Zusammenhang für ein Asset? Also, ist Ruby was Positives, stört es dich eher? Würdest du eher eine statisch getrübte Sprache bevorzugen und akzeptierst Ruby nur, weil es Teil von diesem Ding ist oder weil es für dieses Framework genutzt wird? Oder findest du das ist generell eine super Sprache, um Geschäftslogik zu implementieren?

Lucas Dohmrn:

Also, ich finde, Ruby ist eine super Sprache. Ist eine Sprache, die sehr dynamisch ist und nicht nur dynamisch typisiert, sondern so viele Möglichkeiten einem gibt, die Sprache zu erweitern, die Sprache an die Bedürfnisse anzupassen. Das sieht man auch an vielen Stellen in Rails, wo dann halt solche “domain-specific languages”, das ist ja so ein Begriff, manche würden sagen, es ist kein DSL da, aber etwas was dann halt eher so wie eine DSL aussieht, aber ganz gültiger Ruby Code ist, ohne dass da jemand irgendwie Ruby verbiegen muss dafür. Und das sind Sachen, also, Rails könnte nicht so aussehen wie es aussieht, wenn man es in einer anderen Programmiersprache geschrieben hätte. Und für mich ist halt, als jemand der vor allem JavaScript und Ruby bisher programmiert hat, ist immer ein ganz großer Unterschied zwischen der Art und Weise, wie man eine dynamisch typisierte Sprache betrachtet zwischen diesen beiden Programmiersprachen. Wo ich in JavaScript immer wieder merke, ja, ich verstehe, warum ihr so was wie Typescript benutzen wollt, weil ich hab jetzt schon wieder irgendwie ein Objekt, bei dem fehlt was und dann kommt undefined is not a function. Heutzutage ist die Fehlermeldung etwas besser, aber das Problem ist immer noch dasselbe. Das ist etwas, was ich in Ruby eigentlich nie habe. Also in Ruby habe ich fast nie das Bedürfnis zu sagen, ja das würde ich jetzt gerne mehr typisieren und selbst für die Fälle wird es sich ja auch ändern, seitdem Ruby ein optionales striktes Typ-System anbietet. Aber das ist zumindest mal in Rails nicht wirklich supported und ich glaub das steckt noch in den Kinderschuhen. Aber grundsätzlich könnte man damit den Kern seiner Geschäftslogik auch streng typisieren, was auch größere Firmen teilweise machen. Ich hab den Namen vergessen, ein Payment-Prozessor, der auch relativ viel benutzt wird. Die benutzen auch Ruby, die benutzen kein Rails.

Stefan Tilkov:

Stripe?

Lucas Dohmen:

Exakt, danke dir! Stripe benutzt Ruby, aber eben kein Rails. Und die benutzen ganz intensiv dieses neue Typ-System in ihren Anwendungen und berichten darüber sehr viel Positives. Aber wie gesagt, ich hab dafür im Ruby-Kontext selten das Bedürfnis. Und ja, Ruby ist nicht die schnellsten Programmiersprache der Welt, das ist irgendwie bekannt, aber sie ist immer noch schnell genug, um GitHub.com zu betreiben. Deswegen reicht sie für meine Anwendungen üblicherweise aus.

Stefan Tilkov:

Ich finde ganz interessant, ich persönlich finde, es gibt alle möglichen Dinge, die man da kritisieren kann. Also ich finde, es gibt schönere Programmiersprachen als Ruby. Entschuldigung!

Lucas Dohmen:

Das ist ok.

Stefan Tilkov:

Ich mag z.B. Clojure viel lieber. Es gibt viel elegantere, schönere Programmiersprachen. Es gibt viel effizientere Umgebungen, es gibt Dinge, die schonender mit Ressourcen umgehen. Es gibt 1000 gute Gründe, etwas anderes zu machen. Ruby und Ruby on Rails haben auch so ein bisschen ein Marketing Problem. Die sind eben nicht mehr so hot wie vor, ich weiß nicht, seit wann es die gibt, 12 Jahren, 13, 15 Jahren. Ich weiß nicht, am Anfang war es mal total cool, was mit Ruby on Rails zu machen und heute ist das ja mehr so, hmmh, wieso machst du das? Ich dachte, das ist schon vorbei. Tatsächlich finde ich, dass trotz all dieser… Achso, auch noch was, ich finde, es gibt diese, diese viele Magie, die auch so ein bisschen zweifelhaft ist. Ist hier wieder irgendwas, von dem man nicht so genau weiß, wie es funktioniert oder nur wenige Leute wissen, wie es funktioniert. Man kann extrem viele Sachen kritisieren an diesen Dingen, aber es gibt einfach nichts, was auch nur annähernd vergleichbar wäre von der Vollständigkeit her. Nirgendwo, nicht in der Java-Welt, nicht in der… Vielleicht sowas wie Django. Das kenne ich nicht gut genug und da höre ich von dir und anderen immer, dass es in einer ähnlichen Liga spielt. Aber zum Beispiel leider nichts in der Clojure-Welt und ganz sicher nichts in der JavaScript-Welt, definitiv nichts in der Java-Welt. Also, das ist schon, das ist schon cool wenn wir sehen bei uns, wenn Leute, die Rails beherrschen, so wie du und auch andere Kolleginnen und Kollegen, wenn die einfach so eine Anwendung bauen sollen, ohne lange Technologiediskussionen zu führen, dann ist das derartig produktiv und derartig schnell und erlaubt so, dass man Feedback bekommt von Echt-Anwender:innen. Das ist schon echt eine coole Sache.

Lucas Dohmen:

Ja, auf jeden Fall. Und dabei finde ich halt immer wichtig, weil das klingt immer so, als wäre Rails etwas, um Prototypen zu bauen.

Stefan Tilkov:

Das stimmt gar nicht, ja.

Lucas Dohmen:

Genau. Es ist auf jeden Fall so, dass das, was man da gebaut hat, dann immer noch Hand und Fuß hat und man es auch weiterentwickeln kann. Es ist nicht so, dass es dann irgendwie sagt, ja okay, jetzt hab ich den Prototypen gebaut. Jetzt benutze ich ein richtiges Webframework. Das ist nicht notwendig. Und ein großer Unterschied, den ich auch zu Django sehe, ist: Manchmal sagen Leute so, warum ist beispielsweise in einem Webframework sowas drin wie Action Job? Also, Action Job ist ein Abstraktionslayer, um Hintergrundjobs auszuführen. Also, da kann man einfach sagen, hier mach das mal später. Und wie genau das funktioniert, dafür kann man verschiedene Adapter auswählen und das sind dann irgendwelche Queues oder was auch immer man da benutzen will. Oder Redis oder was auch immer. Genauso ist da ein Ding drin, mit dem kann man Dateien abspeichern, das heißt Action Storage. Damit kann man sagen, hier, ich hab eine Datei. Leg die bitte ab. Und man könnte sagen, wozu braucht man das? Da kann man doch einfach eine Library für installieren. Der Unterschied ist, und das ist, glaube ich, die Stärke von Rails im Vergleich zu Django, dass dadurch, dass es die gibt, also dadurch, dass man weiß, Active Job ist da und das man weiß, Action Storage ist da, kann ich Libraries bauen, die darauf aufsetzen. Ich kann also beispielsweise eine Library bauen, die weiß, wie man einen Hintergrundjob ausführt, egal was jetzt meine spezielle Rails-Anwendung für ein Queuing-System benutzt, weil wir uns darauf geeinigt haben, wir benutzen Action Job als Interface, ja. Und wir sind uns alle darüber einig und dann kann ich einfach ein Gem installieren. Also, das ist der Name von Libraries in Ruby, und sagen, hier baut das mal ein und zack, es funktioniert. Meine Erfahrungen in Node.js ist, ah ok, jetzt muss ich erstmal gucken, wie ich das integriert bekomme und die haben sich natürlich eine andere Library ausgesucht um Backgroundjobs zu machen. Die haben also wahrscheinlich den eigenen Backgroundjob-Prozessor mit dabei. Und dadurch sind die Gems, die es aus diesem Rails-Kontext gibt, wesentlich mächtiger und umfangreicher als jetzt das in anderen Webframeworks, die ich kenne, weil sie sich einfach auf mehr grundlegende Funktionalität verlassen können, um darauf aufzubauen, ohne dass sie mich dann jetzt dazu zwingen, ein bestimmtes Queuing-System oder eine bestimmte Art und Weise, wie ich meine Dateien ablege, zu verwenden. Und das finde ich weiterhin sehr angenehm, auch wenn man manchmal denkt, wieso ist das jetzt mit dabei? Aber es ergibt dann durchaus Sinn.

Stefan Tilkob:

Wollen wir vielleicht noch kurz darüber sprechen, was in den letzten Jahren so an Erneuerung passiert ist? Also, was sind so die Haupt-, die coolen Features in Rails 6 und was ist von Rails 7 zu erwarten?

Lucas Dohmen:

Ja, gerne. In Rails 6 kam Action Mailbox dazu. Das habe ich eben schon erwähnt, um Mails zu empfangen. Action Text, das ist tatsächlich ein Webframework, wo ich denke, also ein Teil von Rails, wo ich denke, ja okay, den hätte man wirklich als Gem bauen können. Das ist so ein Rich Text Editor, den man in Rails einbauen kann, der ist aber sehr nett integriert, also, der verwendet beispielsweise auch dieses Active Storage, was ich eben erwähnt habe, um, wenn man jetzt ein Bild hochlädt in seinem Web, in seinem CMS, ja, hat er da so ein Textfeld, dropped da ein Bild rein, dann sorgt das schon im Hintergrund dafür, dass das hochgeladen wird, dass das in dem Action Storage abgelegt wird, das Action Storage auch irgendwelche weiteren Prozessierungsschritte machen kann, wie das Bild zu optimieren oder zu verkleinern, zu vergrößern, was auch immer. Das heißt also, es ist einfach ein Rich Text Editor, der fest eingebunden ist und alle Fähigkeiten von Rails und drunter schon mal zusammen gesteckt hat, so dass wenn ich jetzt sowas habe, wie ich baue ein einfaches CMS und ich brauche nur Text Editor, dass ich das wirklich out of the Box direkt verwenden kann ohne irgendwelche Sachen zusammen zu stecken. Also gerade wenn man dann irgendwann Bild-Uploads oder sowas machen will, merkt man ja, dass das gar nicht so trivial ist, so einen Editor einzubauen. Und eine weitere Sache hatte ich eben schon mal kurz angeschnitten, wo GitHub ganz viel beigetragen hat, ist der Multi Database Support. Ich habe ja schon gesagt, Active Record ist dieses ORM, das mit eingebaut ist und da war es eigentlich immer so, dass Active Record davon ausgegangen ist, dass man eine Datenbank benutzt. Also natürlich konnte die repliziert sein und so weiter, aber halt eine und jetzt ist es so, dass man sagen kann, dieses Model ist in dieser Datenbank persistiert, dieses Model in dieser Datenbank persistiert. Oder, was halt auch sehr sehr schick ist: Ich kann sagen, dieses Model hier ist für Lesezugriffe in dieser Datenbank und für Schreibzugriffe in dieser Datenbank. Das heißt, ich kann Replica Databases als Read Follower aufsetzen ohne viel Mühe. Und das ist tatsächlich das System, was GitHub in Produktion benutzt, um genau das zu tun für GitHub.com. Ganz nett ist auch der parallele Testing Support. Generell hat Rails sehr guten Support, um Tests zu schreiben. Sowohl so irgendwelche Fullstack Tests, wo man die ganze Anwendung durchspielt, also sagt: Klick mal auf den Button, geh mal dahin und so weiter. Das ist sowieso schon supported. Und jetzt ist da halt ein Parallelisierungssupport dabei. Das bedeutet, ich kann sagen, hier, lass meine Tests laufen und zwar mit, keine Ahnung, acht parallel laufenden Threads und dann sorgt Rails im Hintergrund dafür, dass jeder davon seine eigene Datenbank bekommt, damit sie sich nicht gegenseitig auf den Füßen stehen. Also, fährt dann halt acht Test-Datenbanken hoch, sorgt dafür, dass die immer in dem richtigen Status sind und lässt sie dann parallelisiert durchlaufen. Das funktioniert tatsächlich sehr gut.

Stefan Tilkov:

Eindeutig nur ein Spielzeug-Framework für Prototypen-Erstellung.

Lucas Dohmen:

Eindeutig, genau. Auf die Asset-Pipeline bin ich eben schon kurz eingegangen. Da verändert sich aktuell ziemlich viel. Ich glaub, das wird jetzt auch noch mal sehr interessant, wenn Rails 7 rauskommt. Was dann jetzt schlussendlich dabei rauskommt. Da können wir gern den Blogpost zu verlinken, den David geschrieben hat, wo er ein bisschen darauf eingeht, was er sich für die nächste Version vorstellt. Ich bin gespannt, ob das jetzt genauso passiert, wie er sich das überlegt hat. Aber wie gesagt, das ist jetzt ein bisschen zu großes Thema. Aber da müssen wir mal das Thema Asset Pipeline aufmachen und dann wird das eine sehr lange Folge. Interessant ist auch, da könnten wir auch nochmal ganz kurz auf eins von den Features eingehen, die für mich so ganz lange selbstverständlich waren und die aber auch wirklich eigentlich nur in einer Sprache wie Ruby funktionieren und das ist der Auto Loader. In Rails ist es so, wenn man sich die Source Dateien anschaut von all seinen Models, Controllers und so weiter, dann steht in keiner davon irgendein Import Statement oben in der Datei. Also, in Python oder in JavaScript, muss ich, wenn ich auf ein anderes Modul zugreifen will, dann sag ich irgendwie sowas wie Import xyz oder auch in Java ist das ja auch so. Und da kommt man ja auch gar nicht drum herum, weil das Modul-System gibt es ja gar nicht her, dass man was anderes tut. In Rails ist es aber wirklich so, wenn du diese Dateien anguckst, dann steht da kein einziges Import Statement. In Ruby wäre das ein Require Statement aber das ist jetzt grundsätzlich erst mal das gleiche. In Rails ist es so, da gibt es diesen Auto Loader und der schaut halt, wenn an irgendeiner Stelle jetzt beispielsweise Timeline steht, als Konstante und Timeline ist nicht definiert, dann hat Rails Konventionen, wie es Timeline findet, lädt und dann das definiert ist. Also, das ist in Rails mit eingebaut und dadurch sind diese Dateien halt so, dass wenn man die Datei aufmacht, dann sieht man direkt den Code. Man sieht nicht erstmal zeilenweise irgendwelche Import Statements, sondern sieht direkt den Code, der einen interessiert. Und manche Leute finden das halt total doof, weil die sagen, ja dann ist es ja gar nicht mehr explizit, welche Beziehungen zwischen den Dateien sind, aber tatsächlich ist das eine Kritik, die ich persönlich einfach nicht nachvollziehen kann, weil ich kann ja immer noch sehen, welche Konstanten hier verwendet werden und worauf die sich beziehen. Also mich hat das nie gestört, dass das so ist, sondern mich freut das immer, dass ich einfach das runter schreiben kann und dann funktioniert das und dieser Auto Loader, der wurde jetzt in Rails 6 ersetzt, den gab es schon seit Rails 1 oder zumindest mal seit Rails 2, und der ist jetzt ersetzt worden durch einen, der Zeitwerk heißt. Es ist sehr lustig, weil der Autor ist kein native German Speaker, der kann den Namen seiner Library gar nicht so richtig aussprechen. Aber er fand den Namen so toll da und Zeitwerk ist jetzt ein neuerer Auto Loader, der an bestimmten Stellen ein bisschen strikter ist als der alte Auto Loader und dadurch nochmal ein ganzes Stück schneller ist und in Test-Szenarien dafür sorgen kann, dass immer dafür gesorgt wird, dass die Sachen nicht mehr definiert sind und neu geladen werden können. Und da gab’s halt ein bisschen Kritik an dem Auto Loader für eine ganze Zeit und jetzt ist Zeitwerk die Antwort auf diese Kritik und hat das halt wesentlich vereinfacht und interessant an Zeitwerk ist halt auch, dass es so gebaut wurde, dass er auch außerhalb von Rails funktionieren kann. Man kann das also auch in anderen Ruby-Anwendungen verwenden.

Stefan Tilkov:

Das ist so ein typisches Ding, dass ist für Leute, die Ruby nicht kennen, schwer vorstellbar. Weil die Konstante fehlt, landet das irgendwie bei einer Methode, die heißt “Missing Constant” oder “Constant missing”, irgendwie so, und die lädt dann die richtige Bibliothek nach, im Zweifelsfall auch eine neue Version dieser Bibliothek oder so ähnlich. Und das heißt, ohne irgendwie Zaubereien, kann ich den Source Code in meinem Editor ändern. Und wenn ich den gespeichert habe und dann in meinem Browser auf Refresh drücke oder irgendwo auf einen Link klicke oder eine Form abschicke, dann wird eben der neue Code ausgeführt. Aber das natürlich auch nicht immer, weil das wäre viel zu teuer, sondern nur, wenn ich im Test. oder Entwicklungsmodus bin. In Produktion passiert das nicht. Das ist schon eine Menge Magie, die da abläuft. Aber sie scheint ja zu funktionieren. Also ich glaube nicht, dass es da im letzten Jahr, das ist ja mittlerweile auch ein sehr ausgereiftes Framework, es ist nicht so als ob einem das ständig um die Ohren fliegt, oder?

Lucas Dohmen:

Nee, absolut nicht. Also, der Auto Loader ist mir, glaube ich, weiß ich nicht, in all den, weiß nicht, 10 oder 12 Jahren, die ich jetzt Rails mache, vielleicht eine handvoll Male um die Ohren geflogen.

Stefan Tilkov:

Also, eine Frage wäre vielleicht, wenn man jetzt sich vorstellt, dass man sehr große Code Bases hat, was passiert denn, wenn ich jetzt, wenn ich die Konstante an 2 Stellen verwendet habe, weil vielleicht 2 verschiedene Teams auf den Gedanken gekommen sind, dass Timeline ein super Name ist. Fliegt mir das Teil um die Ohren, merke ich, dass da das Falsche geladen wurde? Fällt das nicht in solchen Momenten auf die Nase?

Lucas Dohmen:

Also grundsätzlich, dadurch, dass es einfach einen Standard gibt, wo genau diese Timeline definiert sein muss, also der weiß, ok, ich habe die Konstante Timeline gefunden. Dann lade ich die jetzt und wenn du an einer anderen Stelle Timeline suchst, dann ist es ja schon definiert, also fliegt es dir auch nicht um die Ohren, weil dann benutzt du einfach das, was bei dem ersten Mal geladen wurde. Das besondere, also das ist der Fall, wenn man im Produktionsmodus ist, dann wird alles exakt einmal geladen und nie wieder rausgenommen. Im Test-, im Entwicklungsmodus ist es halt so, dass bei jedem Request geschaut wird, muss sich die Sache noch mal neu laden? Und dadurch wird auch quasi für jeden Request nur das geladen, was ich für exakt diese Route, diese Anfrage gerade brauche und danach wird das wieder verworfen und dann kommt eine neue Anfrage rein und dann kann er die wieder laden. Dabei hat Zeitwerk das halt verbessert, dass er dabei, wenn sich das nicht verändert hat, er im Hintergrund die einfach behält vom vorigen Request und dann ist es auch in der Entwicklung extrem schnell, selbst bei einer sehr großen Anwendung

Stefan Tilkov:

Ok gut, lass uns vielleicht… wir waren durch mit Rails 6-Features, oder?

Lucas Dohmen:

Ja, genau. Das waren die großen Rails 6 Features.

Stefan Tilkov:

Dann sag doch vielleicht noch, was ist bei Rails 7 zu erwarten, so als wichtigstes?

Lucas Dohmen:

Ja, genau. Erst noch ganz kurz Rails 6.1., klingt ja immer so ein bisschen klein, das ist halt so ein Jahr nach 6 rausgekommen und hat auch noch ein paar Sachen mitgebracht. Das adressiert nämlich eine Sache, die in Rails ganz lange kritisiert wurde. Das ist das sogenannte “Lazy Loading”. Beim Lazy Loading ist es so, dass, also wenn ich eine Datenbank Relation habe wie zum Beispiel ein “belongs to”, also ich sage dieser Record gehört zu diesem Record und in meiner View greife ich jetzt auf das Element zu, zu dem ich diese Relation habe. Dann sagt Rails einfach, ja okay, du bist jetzt zwar in der View aber ich lade das jetzt einfach, weil wieso nicht, du hast ja danach gefragt. Und das ist natürlich extrem komfortabel aus einer Entwicklungsperspektive, weil ich muss nicht vorher drüber nachdenken, was ich alles brauche. Aber aus der Performance Perspektive ist es vielleicht nicht so optimal, weil dann kann ich aus Versehen die n+1 Queries erzeugen, weil ich in den Views ganz oft irgendwie nochmal weitere Queries auslöse und immer nur exakt einen Eintrag aus der Datenbank auslese. Und das Problem hatte auch GitHub und hat jetzt die Möglichkeit eingebaut, “Strict Loading” zu aktivieren. Und beim “Strict Loading” ist es dann so, dass er einfach nicht automatisch nachlädt, sondern sagt einfach, hier kommt nichts zurück. Du hast danach gefragt, aber das gibt es halt nicht. Und das ist eine Option für Leute, die halt sagen, mir ist Performance hier wichtiger als diese Einfachheit, also dieses Komfort-Feature. Dann wird das halt nicht mehr automatisch geladen. Und das ist, glaube ich, eine Kritik, die es einfach sehr, sehr lange gab bei Rails, weil es halt Performance-Probleme verursacht usw. Das andere interessante Feature sind die “Delegated Types”. Das ist das, was man in Django als “Multi Table Inheritance” bezeichnet. Das ist die Möglichkeit, dass man sagt, man hat irgendwie einen Typ, der hat Untertypen. Dann ist ja jetzt die Frage, wie gehe ich damit auf einem Datenbank-Level um? Und da gibt es halt “Single Table Inheritance”, das heißt in einer Tabelle sind einfach alle Attribute von allen Kindern mit dabei, von allen Untertypen. Das bedeutet aber, dass man halt ganz ganz viele leere Spalten hat, wenn man, umso mehr die voneinander abweichen diese Untertypen. Und mit “Multi Table Inheritance” habe ich eine Tabelle, da sind alle Eigenschaften drin von der Elternklasse und dann eine weitere Tabelle pro Untertyp. Und das wird dann einfach zusammen gejoint. Auf diese Art und Weise kann ich halt so eine Relation gut abbilden, wenn es viele unterschiedliche Attribute gibt. Ein Beispiel dafür wäre jetzt unsere innoq.com-Seite. Da haben wir ja irgendwie ganz viele diese, die ist übrigens auch in Rails gebaut, darin haben wir ganz viele unterschiedliche Content-Typen. Also wir haben jetzt so was wie unsere Podcastfolge oder Artikel oder News Posts oder sowas. Und trotzdem sollen die ja alle in einer Übersicht angezeigt werden. Und das ist dann halt praktisch. Wenn wir ganz unterschiedliche Attribute haben, dass ich sie dann trotzdem sehr einfach mit einer Query abfragen kann und schonmal in so einer Übersichtsliste anzeigen kann. Und da brauche ich meistens dann ja nur die Eigenschaften, die alle gemeinsam haben und wenn ich dann halt spezielle Eigenschaften brauche, dann sind die halt in der eigenen Tabelle. Das ist halt “Multi Table Inheritance”, würde ich jetzt mal sagen. Genau, das sind die zwei Features, die in Rails 6.1 dazugekommen sind, die großen Features. Es gab natürlich viele Bug Fixes und so weiter und so fort. Aber das sind die großen Sachen. Genau. Und in Rails 7, da erwartet uns jetzt wahrscheinlich ein ganz neues System, um mit Assets umzugehen oder zumindest mal eine Erweiterung des existierenden Systems. Das wird interessant. Dieses Zeitwerk, was ich eben erwähnt habe, das wird nicht mehr optional sein. Also aktuell ist es so, man kann auch noch den alten Auto Loader benutzen für so eine Übergangsphase. Und in Rails 7 wird der dann abgeschaltet. Es gibt nur noch den Neuen. Es wird ein Encryption Feature geben, mit dem man einzelne Spalten der Datenbank verschlüsseln kann. Also wenn man jetzt wirklich nicht, man möchte nicht die gesamte Datenbank verschlüsseln, sondern nur bestimmte Attribute, dann kann ich in Active Record sagen: hier, dieses Attribut ist verschlüsselt und dann muss man das halt entschlüsseln, wenn man darauf zugreifen will. Dieses Aktive Storage, mit dem wir Daten ablegen können, das ist sehr gut darin, Verarbeitungsschritte zu machen, wie z.B. Resizing und so weiter, also alle Sachen, die so auf Bilder eingehen und Active Storage wird jetzt ganz stark dazu erweitert, dass es auch gut mit Video-Files und mit Audio-Files umgehen kann. Also auch da z.B. aus einem Video-File ein Thumbnail zu generieren. Das ist dann z.b. eine Zeile Code. Dann sagt man, hier, zeig dazu bitte ein Thumbnail an. Dann wird halt für das hochgeladene Video ein Thumbnail angezeigt. Um so etwas wird Active Storage erweitert. Und genauso um, mir fällt der Name gerade nicht ein, aber wenn man in HTTP, möchte man eine große Datei herunterladen, dann kann man ja sagen, hier bitte, gebt mir dieses Stück der Datei, also…

Stefan Tilkov:

… ein “Range Request”.

Lucas Dohmen:

Genau, danke dir… und die werden jetzt in Active Storage auch supported, gerade auch, um Video- und Audio-Files gut zu unterstützen. Also, damit dieser schrittweise Ladeprozess gut funktioniert. Darum wird Active Storage erweitert. Genau, und in Active Record gibt es halt einiges an kleineren Verbesserungen, die finde ich jetzt aber noch nicht interessant genug, um darüber zu sprechen. Es ist aber erwartungsgemäß so, dass irgendwann Anfang nächsten Jahres werden jetzt ein paar größere Sachen vorgestellt, die in Rails 7 kommen. Und da wird das nochmal interessanter werden.

Stefan Tilkov:

Ok, cool. Vielleicht kommen wir langsam zum Schluss. Wir sind auch in unserem Zeitbudget am äußeren Rand angekommen, würde ich sagen. Womit sollte man starten, wenn man sich dafür interessiert?

Lucas Dohmen:

Also, es ist natürlich naheliegend, euch zu empfehlen, mein Buch zu lesen.

Stefan Tilkov:

Unbedingt.

Lucas Dohmen:

Würde ich aber für das, was du gerade beschrieben hast, nur dann empfehlen, wenn ihr schon Erfahrung habt mit einem anderen Webframework. Also, wenn ihr irgendwie schon ein Framework benutzt habt und jetzt wollt ihr Rails lernen. Dann finde ich mein Buch gar nicht schlecht dafür. Das können wir natürlich gerne in den Shownotes verlinken. Das ist auf Leanpub und wir haben den Großteil des Buches schon veröffentlicht. Also wenn ihr das jetzt anfangt zu lesen, dann ist es fertig, wenn ihr soweit seid. Wenn ihr noch nie Web-Entwicklung gemacht habt oder noch nie serverseitige Web-Entwicklung gemacht habt, dann ist das Buch vielleicht noch nicht so das Richtige für euch, weil es halt doch davon ausgeht, dass man viele grundlegende Sachen kennt. Da kann man sich einmal die Guides von rubyonrails.org anschauen. Die sind sehr gut, da sind grundlegende Sachen drin erklärt und es gibt ein Online-Buch, dessen Name mir nicht einfällt, den ich aber in die Shownotes packen werde, was wirklich super ist, um das erste Mal mit einem Webframework, also um mit Rails als sein erstes Webframework anzufangen. Das würde ich in dem Fall eher empfehlen als das Rails Way-Buch, was einfach davon ausgeht, dass man schonmal grundlegend Web-Erfahrung hat, also auch Web-Erfahrungen mit so was wie Server-side Rendering.

Stefan Tilkov:

Cool. Lucas, ich denke, wir sollten da noch eine Nachfolge-Folge machen, einen Nachfolger oder eine Nachfolge-Folge, wie auch immer. Und vielleicht mal über eine konkrete Anwendung oder zwei sprechen, die wir damit gebaut haben. Aber für jetzt, denke ich, haben wir einen super Schlusspunkt erreicht! Ich danke dir sehr, fand’s sehr spannend. Hoffe, wir konnten den einen oder die andere dazu motivieren, sich das mal ein bisschen näher anzugucken. Danke euch für’s Zuhören und bis zum nächsten Mal. Tschüß.

Lucas Dohmen:

Genau, danke. Tschüß.