Folge 26: Backend vs. Frontend – Der Showdown

@Autoweird.fm 2.0 noch kontroverser! Mehr Starkbier! Mehrere roten Fäden. Das ganze verpackt in einer (nennen wir es mal) ehrlichen Produktion. Das ist die Zukunft. Die logische Weiterentwicklung des Podcastens autoweirdscher Färbung. Oder haben wir uns einfach nur gnadenlos überschätzt beim Dienst am Hörer? Oder vertragen wir einfach doch kein Bier? Oder nur der Holger? Im Nachhinein nicht mehr wirklich zu sagen.
Ach ja, es gab auch ein Thema! Und das hat es in sich. Bene und Holger stellen sich dem Thema ‘Backend vs. Frontend’. Es werden Gräben geschaufelt und wieder zugeschüttet und wieder gegraben. Am Ende ergreifen wir sogar Partei und ranten dann doch mal, bis sich die Balken biegen. Das Ganze wird gekrönt von der miesesten Abmoderation ever! Auf welcher Seite steht ihr?

Links:

  • Die After-Work-Konferenz Nightly Build ist immer einen Besuch wert.
  • Das Kebapland ist total geil. Dürft ihr aber nicht hin, ist sowieso schon voll da.
  • MozJPEG ist ein voll geiler JPEG Encoder.
  • LAME setzt man halt ein.
  • Die fette Kuh ist sehr gut, aber noch voller als das Kebapland.
  • Der Bene macht ja alles. Z.B. auch Apache Commons Imaging.
  • Eclipse RCP gabs ja auch mal.
  • SWTBot ist das UI Testing Framework für Eclipse RCP.
  • Liquibase macht uns das Leben leichter.
  • Redux ist auch ziemlich cool!
  • Event-Sourcing gibts natürlich auch auf dem Server.
  • Spring-Tobi mag ROCA.
  • Ja! Spring Boot ist geil!
  • In Desktop-Java macht man [JavaFX].(https://de.wikipedia.org/wiki/JavaFX).
  • Redux mit JavaFX gibts.
  • NPM löst das Versionsproblem – wieder mal – für immer.
  • Wie lieben es, JSF zu hassen!
  • Wenn ihr was über Mob-Programming hören wollt, dann hört doch eine Folge des ominösen Holzheimer Underground Mobcaster Kollektivs.

Bier:

  • Holger trinkt ein seltenes Baltic Stout mit Eulen-Etikett. Sieht aus wie Erdöl oder halt Kaffee. Lecker! Vielen Dank an Elke und Jenny.
  • Bene trinkt ein Soltauer Bio-Produkt, was aber gar nicht aus Soltau kommt, sondern aus <klugscheiß>der Oberpfalz! Jahaaa! Soviel Zeit muss sein!</klugscheiß>: Ein Neumarkter Lammsbräu (mit durchgestrichenem Barcode). Der Bene ist kein IPA-Trinker und auch eigentlich kein Hefeweizentyp. Das Neumarkter Lammsbräu geht aber gut! Vielen Dank an Gregor!

Datum der Aufnahme: 04.09.2017

4 Gedanken zu „Folge 26: Backend vs. Frontend – Der Showdown

  1. greelgorke kommentierte am 11.09.2017:

    über npm:

    Also, Holger, ich bin ein wenig verstört, dass du Benes npm rant einfach so stehen lässt 🤣

    Man kann in npm, bzw der package.json schon immer feste Versionen vergeben. Das macht man aber nicht, weil wir eben semver haben und machen, und eben es ausnutzen um unkritische patches und minors automatisch reinzuziehen über ~ und ^ ranges. Wir nehmen nicht “irgendeine version” 🙄 . package-lock.json dient dazu reproduzierbare plain-installs zu machen. die Funktionalität des lockfiles ist aber auch nicht neu in npm, sondern mit shrinkwrap auch schon sehr lange gegeben. Was neu ist, ist der Automatismus. Feste versionen sind für stabile deployments gut, für work in progress aber eigentlich ein antipattern. Denn wenn du feste versionen hast, musst du dich bei jeder Abhängigkeit um jeden hotfix selbst kümmern. das kann keiner leisten.

    Ja, es halten sich nicht alle an semver, aber die meisten. Ist halt ein tradeoff, denn durch tooling nur unszureichen lösen kannst. Was letztes Jahr allerdings erst noch gefixt wurde ist, dass man versionen force-publishen konnte, was semver eben aushebelte.

    über TDD mit React:

    Challenge Accepted 🗡

  2. holgergp kommentiere am 11.09.2017:

    Hi Gregor,

    Danke fürs Feedback!

    Ja wenn der Bene einmal in Fahrt ist, ist er kaum zu stoppen. Er hatte schon Schaum vorm Mund und ich Angst um mein Leben 🙂
    Ich gebe euch aber beiden Recht. Wenn man mit der Maven-Brille auf npm schaut wirkt es immer noch ein wenig frickelig. Die Möglichkeit jetzt ‘nativ’ Versionen festzuzurren ohne noch einen weiteres Tool zu verwenden finde ich auch schon angenehm. Warum siehst du feste Versionen für WiP generell als Anti-Pattern. Klingt für mich auch erstmal nach erhöhtem Testaufwand. Hast du da nen Link parat? 🙂

    LG

  3. greelgorke kommentierte am 11.09.2017:

    Die Möglichkeit “nativ” versionen festzuzurren gab es von nahezu tag 1 bei npm 😀 schreib die version manuell komplett und exakt ins package.json hin. das machste in maven nicht anders, richtig? auch shrinkwrap ist ein npm feature https://docs.npmjs.com/cli/shrinkwrap

    Das mit WiP kannst du mit git vergleichen. deine node_dependencies sind der master branch, dein code ist featurebranch. wenn du zu lange den master nicht mergest, ist der Schmerz viel größer. wenn du aber regelmässig mergest vermeidest oftmals kleine konflikte ganz und größere konflikte fallen früher auf und tun weniger weh. Das selbe gilt eben für dependencies. Es ist auch nicht mehr Testaufwand, wenn du deine Testpyramide ernst nimmst. dazu noch tools wie npm outdated oder greenkeeper.io und das wars. Wie viele systeme laufen mit veralteten versionen, weil der schmerz zu updaten zu groß geworden ist? Wieviele Systeme laufen mit verwundbarem Code, weil kein Mensch die minor Patches und Fixes im Auge hat und die Versionen gepinnt sind?

    Oder hast du die Auto-Update Features in deinem Browser und OS auch ausgeschaltet? 😉

  4. dmies kommentierte am 12.09.2017:

    Vielleicht hängt auch dieser Blickwinkel damit zusammen, dass ihr die pom Dependencies oft selber schreibt und dann eine feste Version nehmt oder halt sowas wie Spring Boot im Einsatz habt wo es ja einer der Vorteile ist, dass alle Dependencies gleich mitkommen.

    Kann @greelgorke hier nur zustimmen: npm kann das alles schon sehr lange und es spricht ja auch nichts dagegen dynamische Versionen einzusetzen. Es gibt ja auch in Maven Version ranges und ich kenne auch Entwickler, die damit arbeiten.

    Es gibt sicher nicht nur im JS Umfeld Bibliotheken, die “semver nicht können” und hier hast Du als Entwickler alle Freiheiten Deine package.json anzupassen.

    Vielleicht spielt hier auch eine Rolle, dass das JS Ökosystem sehr jung und enorm aktiv ist. Sehr viele neue Entwicklungen (auch in der Sprache) erscheinen und werden schnell von Entwicklern gefordert. Natürlich klappt dann nicht alles perfekt aber es dauert halt auch nicht Ewigkeiten, bis sich etwas entwickelt (jigsaw anyone).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.