Der IT-Thread

[pump3]

Ich argumentiere hier jetzt eher aus einer Advocatus Diaboli Position heraus, aber bedenke Folgendes:

Klar, Java ist sehr verbos (was such Vorteile hat, weil man den Code besser lesen kann als einen "klugen" Einzeiler) und Funktionsaufrufe.der.Bloatlord.Tier.sind.nervig.zu.lesen() aber dafür ist es funktional eindeutig und erfordert weniger Wissen über arkane Funktionsweisen der Sprache.

Dann würde ich dir Ada (2012) empfehlen, da ist es noch eindeutiger.

Warum nach einer Vererbung mehrere identische, aufrufbare Subobjekte in einem Objekt leben und Dir das ganze erst zur Runtime um die Ohren fliegt wenn Du ein Generisches davon aufrufst, sich das Programm dann aber nicht entscheiden kann, welches es nimmt bzw. Warum das wichtig ist und nicht wegabstrahiert wird, Du aber gleichzeitig ein spezifisches ohne Probleme aufrufen kannst außer es ist dann virtual, kannst Du keinem erklären.
Alleine der Satz liest sich so behindert, dass ich ihn nicht mehr verstehe nachdem ich ihn geschrieben habe. Und das ist nur die Spitze des Eisbergs.

Ok, genug über Java geredet, wann kommt deine Kritik an C++?

Java macht viel hinter der Bühne, aber wenn es kompiliert läufts auf dieser Version der JVM und gut ist. Die so gesparte Zeit kannst Du auch investieren um ein besseres Programm zu schreiben.

Ja, das stimmt, die meiste Zeit.
Aber komischerweise ist so gut wie jedes Java Programm lahm und schlecht Programmiert. Ich bin sicher das liegt nicht an Java selber

 

[BigBANG]

Mit dem Aprilscherz wurde eine neue Architektur eingeführt, die es ermöglicht, GWN zu erweitern, ohne dabei Xenforo-Plugins schreiben zu müssen.

Das Problem:
Beispielsweise sollte die Galerie so angepasst werden, dass sie mehr wie LS aussieht. @BSKartoffel hat damit begonnen, ein Xenforo-Plugin zu schreiben, es dann jedoch wieder verworfen (was ich verstehen kann).

Die Lösung:
Anstatt Xenforo per Plugin zu modifizieren, wird ein Proxy vor die Forensoftware gesetzt, der die Seite zuerst auf traditionelle Weise erstellt. Im Nachgang ermöglicht der Proxy jedoch anderen Services, den HTML-Content zu modifizieren.

Ich habe ein Diagramm erstellt, das den alten Userflow darstellt. Darunter befindet sich der Flow, wie er jetzt nach der Einführung des Proxies ist, und zuletzt, wie der Flow aussehen wird, wenn ein neuer Service (z.B. eine überarbeitete Galerie) eingeführt wird.

 

[panic]

Bild kann man nicht sehen...

 

[Lyoner]

Hast du schon mal probiert lange auf die Ein- und Ausschalttaste zu drücken?
Wir Informatiker nennen das „Hard Reset“

 

[BigBANG]

Bild kann man nicht sehen...

Hab's jetzt per imgur eingebunden.

 

[RichterinWinkelmann]

Mit dem Aprilscherz wurde eine neue Architektur eingeführt, die es ermöglicht, GWN zu erweitern, ohne dabei Xenforo-Plugins schreiben zu müssen.

Das Problem:
Beispielsweise sollte die Galerie so angepasst werden, dass sie mehr wie LS aussieht. @BSKartoffel hat damit begonnen, ein Xenforo-Plugin zu schreiben, es dann jedoch wieder verworfen (was ich verstehen kann).

Die Lösung:
Anstatt Xenforo per Plugin zu modifizieren, wird ein Proxy vor die Forensoftware gesetzt, der die Seite zuerst auf traditionelle Weise erstellt. Im Nachgang ermöglicht der Proxy jedoch anderen Services, den HTML-Content zu modifizieren.

Ich habe ein Diagramm erstellt, das den alten Userflow darstellt. Darunter befindet sich der Flow, wie er jetzt nach der Einführung des Proxies ist, und zuletzt, wie der Flow aussehen wird, wenn ein neuer Service (z.B. eine überarbeitete Galerie) eingeführt wird.

Sieht mir so aus als ob alle möglichen Enterprise Patterns verwendet hast um den Rewrite Proxy modular zu gestalten.

Meinst du wirklich man braucht einen neuen Service + Container für jede Modifikation?

 

[BigBANG]

Sieht mir so aus als ob alle möglichen Enterprise Patterns verwendet hast um den Rewrite Proxy modular zu gestalten.

Meinst du wirklich man braucht einen neuen Service + Container für jede Modifikation?

Design Patterns erzeugen einen kleinen Erstaufwand, reduzieren dann aber für den Rest der Lebzeit der Software Komplexität. Wenn man etwas modular aufbauen kann, sollte man es auch tun.
Ich hab genug hässliche Software gesehen. Ich weiss wie Software durch 1000 kleine Abkürzungen irgendwann unwartbar wird. In meiner eigenen Software halte ich alles so sauber, wie ich es auf der Arbeit gerne würde.

 

[RichterinWinkelmann]

Design Patterns erzeugen einen kleinen Erstaufwand, reduzieren dann aber für den Rest der Lebzeit der Software Komplexität. Wenn man etwas modular aufbauen kann, sollte man es auch tun.
Ich hab genug hässliche Software gesehen. Ich weiss wie Software durch 1000 kleine Abkürzungen irgendwann unwartbar wird. In meiner eigenen Software halte ich alles so sauber, wie ich es auf der Arbeit gerne würde.

Ich wollte Dich ja nur trollieren.

So schickst Du das ganze Dokument potentiell mehrfach zu diversen Diensten die alle in einem eigenen Container leben.
Wenn Du stattdessen z.B. eine Pipeline mit diversen Filtern hast kannst du auf dem gleichen Dokument arbeiten.

 

[pump3]

Mit dem Aprilscherz wurde eine neue Architektur eingeführt, die es ermöglicht, GWN zu erweitern, ohne dabei Xenforo-Plugins schreiben zu müssen.

Das Problem:
Beispielsweise sollte die Galerie so angepasst werden, dass sie mehr wie LS aussieht. @BSKartoffel hat damit begonnen, ein Xenforo-Plugin zu schreiben, es dann jedoch wieder verworfen (was ich verstehen kann).

Die Lösung:
Anstatt Xenforo per Plugin zu modifizieren, wird ein Proxy vor die Forensoftware gesetzt, der die Seite zuerst auf traditionelle Weise erstellt. Im Nachgang ermöglicht der Proxy jedoch anderen Services, den HTML-Content zu modifizieren.

Ich habe ein Diagramm erstellt, das den alten Userflow darstellt. Darunter befindet sich der Flow, wie er jetzt nach der Einführung des Proxies ist, und zuletzt, wie der Flow aussehen wird, wenn ein neuer Service (z.B. eine überarbeitete Galerie) eingeführt wird.

Also der Unterschied ist das das Forum jetzt im 90° Winkel zum ngnix steht?

Spass beiseite, sieht nach MVC pattern aus. Was genao sollen denn diese Proxies bzw. GWN services genau machen? Nur optisches Zeug verändern oder auch den Inhalt?

 

[Gueldener Nigel]

einfach mal ne kleine kot-injection auf gwn

boa wär des übl alda

 

[BigBANG]

Ich wollte Dich ja nur trollieren.

So schickst Du das ganze Dokument potentiell mehrfach zu diversen Diensten die alle in einem eigenen Container leben.
Wenn Du stattdessen z.B. eine Pipeline mit diversen Filtern hast kannst du auf dem gleichen Dokument arbeiten.

Konkretisiere bitte Pipeline mit diversen Filtern. Meinst du das innerhalb einer Python-App oder in einer Art Message Pipeline wie Kafka?

 

[BigBANG]

Also der Unterschied ist das das Forum jetzt im 90° Winkel zum ngnix steht?

Spass beiseite, sieht nach MVC pattern aus. Was genao sollen denn diese Proxies bzw. GWN services genau machen? Nur optisches Zeug verändern oder auch den Inhalt?

Was die Services im Detail machen, weiß ich noch nicht. Galerie würde im Optimalfall nur HTML/CSS modifizieren, evtl. braucht es aber eine eigene DB, falls die Bewertungen nicht so simpel dargestellt werden können.

Bei sowas wie einem AI-Automoderator hingegen bräuchte es viele verschiedene Komponenten.

 

[Pedder]

Mit dem Aprilscherz wurde eine neue Architektur eingeführt, die es ermöglicht, GWN zu erweitern, ohne dabei Xenforo-Plugins schreiben zu müssen.

Das Problem:
Beispielsweise sollte die Galerie so angepasst werden, dass sie mehr wie LS aussieht. @BSKartoffel hat damit begonnen, ein Xenforo-Plugin zu schreiben, es dann jedoch wieder verworfen (was ich verstehen kann).

Die Lösung:
Anstatt Xenforo per Plugin zu modifizieren, wird ein Proxy vor die Forensoftware gesetzt, der die Seite zuerst auf traditionelle Weise erstellt. Im Nachgang ermöglicht der Proxy jedoch anderen Services, den HTML-Content zu modifizieren.

Ich habe ein Diagramm erstellt, das den alten Userflow darstellt. Darunter befindet sich der Flow, wie er jetzt nach der Einführung des Proxies ist, und zuletzt, wie der Flow aussehen wird, wenn ein neuer Service (z.B. eine überarbeitete Galerie) eingeführt wird.

PHP muss ja echt grauenvoll sein, wenn man so viel aufwand betreibt, um nicht damit arbeiten zu müssen

 

[RichterinWinkelmann]

Konkretisiere bitte Pipeline mit diversen Filtern. Meinst du das innerhalb einer Python-App oder in einer Art Message Pipeline wie Kafka?

Das wäre nur ein anderer Aufbau um die Verarbeitung des html Dokument zu realisieren. Ich würde es in dem Python Proxy machen, bzw in einem extra Service dann. Der große Vorteil wäre wie gesagt, dass man sich das xfache hin- und herschicken des html docs und die ewig gleichen parsing Operationen spart. Wenn ich mich recht erinnere ist das Standard Beispiel dafür Map-Reduce.

Aussehen könnte das dann etwa wie folgt:

Ablauf wie bei Dir bis 5., dann:

1) Doc von Xenforo kommt an und irgendwo hast Du im Request stehen welche (optionalen) Änderungen ausgeführt werden sollen. Dann wird das Dokument geparsed und die zu ändernden Sektionen kopiert/isoliert.

2) Feste Reihenfolge an Komponenten durch die das Doc läuft, wenn die Änderung für das Doc durchgeführt werden soll, macht der das, schickt es an den nächsten Filter weiter, sonst lässt er es einfach durch und schickts direkt weiter.
z.B. Ingest -> Ersetzen von Piccolo mit Hurensohn -> Anpassen Gallerie -> in den Footer Surenhohn schreiben

3) Entweder bastelt man dann hier das Dokument mit allen Änderungen zusammen oder die Filter arbeiten gleich auf dem Doc und man muss vllt. noch irgendwelche Validierung machen.

Dann weiter wie bei Dir mit 7.

Hat mMn. den großen Vorteil, dass es einfacher zu grokken & debuggen ist weil fixe Reihenfolge. Du hast nicht 12345 Services mit eigener Infrastruktur die alle kapott gehen können + den Kommunikationsoverhead sondern lässt ein Objekt durchrutschen.

Wenn Du die Filter alle isolierst und an unterschiedlichen Orten hostest statt in einem Programm isses tatsächlich wieder eine Art Microservice Architektur. Aber warum ein distributed system bauen, wenns nicht sein muss, macht nur mehr Kopfschmerzen durch Komplexität. Sollte GWN tatsächlich so viele Requests produzieren, dass das eine Instanz ausknoggd kannst Du es auch so bauen, dass der Proxy die Requests an einen Pool von den Dingern schickt.

 

[Opeltfahrer]

PHP muss ja echt grauenvoll sein

Ist es

 

[BigBANG]

Das wäre nur ein anderer Aufbau um die Verarbeitung des html Dokument zu realisieren. Ich würde es in dem Python Proxy machen, bzw in einem extra Service dann. Der große Vorteil wäre wie gesagt, dass man sich das xfache hin- und herschicken des html docs und die ewig gleichen parsing Operationen spart. Wenn ich mich recht erinnere ist das Standard Beispiel dafür Map-Reduce.

Aussehen könnte das dann etwa wie folgt:

Ablauf wie bei Dir bis 5., dann:

1) Doc von Xenforo kommt an und irgendwo hast Du im Request stehen welche (optionalen) Änderungen ausgeführt werden sollen. Dann wird das Dokument geparsed und die zu ändernden Sektionen kopiert/isoliert.

2) Feste Reihenfolge an Komponenten durch die das Doc läuft, wenn die Änderung für das Doc durchgeführt werden soll, macht der das, schickt es an den nächsten Filter weiter, sonst lässt er es einfach durch und schickts direkt weiter.
z.B. Ingest -> Ersetzen von Piccolo mit Hurensohn -> Anpassen Gallerie -> in den Footer Surenhohn schreiben

3) Entweder bastelt man dann hier das Dokument mit allen Änderungen zusammen oder die Filter arbeiten gleich auf dem Doc und man muss vllt. noch irgendwelche Validierung machen.

Dann weiter wie bei Dir mit 7.

Hat mMn. den großen Vorteil, dass es einfacher zu grokken & debuggen ist weil fixe Reihenfolge. Du hast nicht 12345 Services mit eigener Infrastruktur die alle kapott gehen können + den Kommunikationsoverhead sondern lässt ein Objekt durchrutschen.

Wenn Du die Filter alle isolierst und an unterschiedlichen Orten hostest statt in einem Programm isses tatsächlich wieder eine Art Microservice Architektur. Aber warum ein distributed system bauen, wenns nicht sein muss, macht nur mehr Kopfschmerzen durch Komplexität. Sollte GWN tatsächlich so viele Requests produzieren, dass das eine Instanz ausknoggd kannst Du es auch so bauen, dass der Proxy die Requests an einen Pool von den Dingern schickt.

Natürlich ist das möglich.

Dann gerät man allerdings in eine Situation, in der man den Proxy neu starten muss, weil man einen kleinen Bug in der Darstellung der Galerie beheben muss.

Bei solchen Dingen, die offensichtlich eine in sich geschlossene Aufgabe erfüllen (wie zum Beispiel ein Proxy), halte ich es für sinnvoll, dieses kleine, in sich geschlossene Modul nicht mit zusätzlichen Funktionalitäten zu überfrachten.

Der Kommunikationsoverhead sollte im Bereich von einigen Millisekunden liegen.
Immer wenn Modularität gut möglich ist, würde ich sie auch anwenden. In dem Fall haben wir zwischen der Galerie und den Proxy absolut keine Abhängigkeiten, wodurch einem die Modularität quasi entgegenschreit.
Wenn man sich grundsätzlich fragt, ob es nicht besser ist immer Monolithen zu bauen, dann sage ich nein!

Ich habe diesen Dialog übrigens schon mit mir selbst geführt. Die Versuchung einfach alles im Proxy zu machen, ist durchaus gegeben. Aber ich merkte, wie es eher Faulheit und "Abkürzung nehmen" ist.

 

[DerBaron]

Ich fülle mich foll duhm wen ich hir lese. Hörd auf, aller.

 

[BigBANG]

PHP muss ja echt grauenvoll sein, wenn man so viel aufwand betreibt, um nicht damit arbeiten zu müssen

Ich bin der Meinung, dass es nicht sinnvoll ist, sich auf die Programmierung von Xenforo-Plugins zu spezialisieren.
Ein Python-Proxy, der als Strangle-Fig-Pattern dienen kann, um Legacy-Systeme schrittweise zu ersetzen, ist hingegen äußerst nützlich, damit vertraut zu sein.
Solche Situationen begegnet man in der Praxis sehr häufig. Es ist auch ansprechender, als sich mit proprietärem Xenforo-Kram auseinanderzusetzen.

 

[pump3]

Könnte man stattdessen nicht alles auf Haskell umstellen und das ganze Zeugs als eine einzige Mondaden-Pipeline implementieren?

 

[BSKartoffel]

Bibedi Babedi Buh