Womit werden Web-basierte Geschäftsanwendungen entwickelt?

@[n]ARC
Danke für den Tipp mit Grav :) echt erstaunlich was es alles so gibt fern ab vom "Mainstream".
 
  • Gefällt mir
Reaktionen: [n]ARC
[n]ARC schrieb:
Wie ich schon sagte, es wurde keine einzige meiner Fragen von @ayngush beantwortet, stattdessen wird pauschal gesagt, dass Drupal und noch andere Systeme scheiße sind und er sich nur auf seinen Code verlässt.
Ich habe einfach keinerlei Interesse auf eine Diskussion dieser Art mit Dir darüber. Ich empfinde deine Art als extrem anstrengend und nervtötend. Das muss ich mir in meiner Freizeit einfach nicht geben.

Edit:
new Account() schrieb:
nein: mehr als ein Indiz für sonst vergleichbare Softwarestücke ist das nicht
Und damit ist es ein Prinzip (= bestimmte Grundlage - im dem Fall die Wahrscheinlichkeit, dass in weniger komplexen Code auch weniger Fehler enthalten sind ~ Indizienbeweis). Das lässt sich statistisch darlegen, das lässt sich durch Tests darlegen, das zeigt (nicht nur meine) langjährige Erfahrung im Bereich der Softwareentwicklung von damals bis heute...

Worauf willst du eigentlich hinaus?
 
Ich bringe hier noch eine Kundensicht rein. Als Kunde würde ich nur mit Firmen zusammenarveiten die offene Systeme wie WordPress, Drupal, Typo, etc verwenden.

Falls der Diendtleister mal Konkurs geht, oder andere Gründe gegen eine weitere Zusammenarbeit sprechen kann man so den Dienstleister flexibler tauschen.
 
  • Gefällt mir
Reaktionen: [n]ARC und BeBur
Ja, könnte sie. Ich Schleppe jedoch keinen unnötigen Ballast in den Anwendungen (es sind mehrere) herum. Sie erfüllen halt genau ihren Zweck und das gerade so komplex wie nötig. Das dürfte statistisch dazu beitragen, dass meine Anwendungen (es sind übrigens die Anwendungen meines Entwicklungsteams... Ich arbeite auch nicht alleine auf weiter Flur) sicher sind und Baukästen wie Drupal, Wordpress und Co. halt eher nicht so... Abgesehen davon steigt halt einfach die Gefahr, dass durch automatisierte Angriffe auf öffentliche Seiten noch nicht geschlossene Lücken in bekannter Software ausgenutzt werden. Das Problem ist leider inhärent bei bekannten Baukastensystemen für Webseiten / Frameworks und aus meiner Sicht sollte man an der Stelle auch dieses Risiko so gering wie möglich halten. Natürlich immer unter Abwägung der Vor und Nachteile. Unsere Webseite läuft auch mit Wordpress. Einfach weil die von einer Externen Bastelbude aufgesetzt und betrieben wird. Ich möchte damit nichts zu tun haben. Die "Designer" können jedoch nur Wordpress klicken und CSS-Hacks einbauen - und sonst nicht viel bis gar nichts. Das ist aber auch nicht schlimm wenn die Seite zerfällt, sie ist nicht relevant ("Visitenkarte" im Web halt...)

Für die relevanten Systeme (Extranet & die öffentlichen APIs) würde ich weder Drupal noch Wordpress noch sonst was aus der Reihe der Klick-Baukästen nehmen, schon alleine, weil die Integration in unser CRM unnötig kompliziert wäre. Allein schon die Tatsache, dass wir MS SQL Server im Backend haben und Drupal erst seit Drupal 8, also seit 2016, damit klar kommt... Ich habe unsere "Kern-Systeme" jedoch 2007 geschaffen und entwickle seit dem daran weiter (KVP und so)... Damals war Drupal (4, 5) die letzte Oberkackscheiße des Planeten und völlig out of scope. Drupal 6 hatten wir dann mal über eine Werbeagentur für unsere Webseite verpasst bekommen. Ein unnötig dämliches System war das damals: Unübersichtlich, Langsam und ständig kaputt - niemand fühlte sich dafür verantwortlich. Und das Ganze nur um "20 statische Seiten im Internet" auszuliefern... Hab die Seiten dann einfach als reine "HTML-Files" abgespeichert und Änderungen daran mit Notepad vorgenommen - einfacher, etwas schneller (von ~500ms Renderzeit auf irgendwas im Messtoleranzbereich ~2 ms herum), und sicher. (Es gab in der Zeit keine Meldungen zu schweren Sicherheitslücken in HTML 5 - Das ist nämlich ein "ausgereiftes System").

Das reichte dann ein paar Jahre hin, bis dann wegen Redesign usw. jetzt dieser Wordpress-Kram gemacht wird (mit den ich zum Glück nichts zu tun habe).

Deswegen: Bleibt im Scope und evaluiert ohne Fanboy-Brille die geeigneten Systeme und Frameworks - auch im Sicherheitskontext. Ich verwende zum Beispiel Teile vom Symfony-Framework für meine Anwendungen - weil ich ja angeblich so OSS-Feindlich bin... Ach, Drupal verwendet dann inzwischen (seit 2016...) übrigens auch Symfony. Jahre nachdem ich das .. ach egal, ich habe ja keine Ahnung laut dem Drupal-Priester hier... haben die Drupal Core developer eventuell bei mir abgeschaut? Oder haben die dann auch mal ein Buch zum Thema Webanwendungsentwicklung gelesen? Wer weiß. Eventuell kommen die demnächst auf so heißen Scheiß wie OOD/OOP und MVVC...

@BeBur Das sollte bei extern vergebenen Dingen auch immer eine gewichtige Rolle spielen. Wordpress klicken können zum Beispiel sehr viele Agenturen. Da findet sich immer jemand. Deswegen kostet das auch alles nicht so viel ;-)
Die Anwendungen, die ich entwickle, sind jedoch reine Inhouse-Anwendungen. Da gibt es keine externen Auftraggeber. Wie wartbar das ganze ist, nachdem ich weg bin? Es gibt ja mehrere Entwickler bei uns und dann stellt man halt neue Softwareentwickler ein. Es ist ja (fast) alles ordentlich dokumentiert, wir benutzen für die Codeverwaltung intern Gitea mit angebundenen, automatisierten Tests und Deployment, damit ist alles revisionsfest und nachvollziehbar abgelegt... Das muss dann halt reichen. Der Rest basiert halt auf ordentlichen Standards, Best Practises und sauberen Pattern und den üblichen Paradigmen. Was soll man dazu sagen? Softwareentwicklung halt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: BeBur
Ah ok jetzt verstehe ich, also inhouse ist das nochmal viel sinniger, da gibt es dann z.B. kein 'vendor lock-in' und organisatorisch ist das ja auch nochmal was ganz anderes.
 
Doch, einen vendor-lock-in gibt es auch, jedoch anders. Unser CRM zum Beispiel setzt MS-SQL voraus: Zack, vendor-lock. Ich würde ja die MS-Server gerne gegen Debian oder CentOS ersetzen. Geht aber nicht. Nächster Vendor Lock auf MS-Server. Also muss man WSUS haben - nächster Vendor Lock auf Active Directory... und so zieht sich das wie ein Raster aus Kackwürsten auch durch die interne IT.
 
Zuletzt bearbeitet:
Zurück
Oben