Krautkanal.com

Veröffentlicht am 2016-11-16 21:16:34 in /prog/

/prog/ 9454: Programmierer der verbotenen Sprache

syntetyc Avatar
syntetyc:#9454

Enterprise Entwickler der verbotenen Sprache, berichtet von eurem täglichen Leid:

Bernd arbeitet in einer Agentur und hat bereits alles.jpg gesehen. Von irgwelchem "ich tue irgnen kleinen Bugfix ins Framework reinmodeln" bis zu "Och wer braucht den Updates, wir bleiben bei <verbotene sprache> 4.0, so läuft nunmal unser Geschäft". Mittlerweile gibt es vor jeder Projektübernahme erstmal eine "Evaluation" , wo die Größe des Krebs ermittelt wird. Manchmal raten wir dem Kunden einfach neu anzufangen und die wichtigsten Modulealle zu portieren auf einen sauberen Stand. Oft stellt sich heraus, das der Kunde sich garnicht bewusst ist, was für einen Krebs seine bisherigen Programmierer gebaut haben. Einige Kunden leben mit Downzeiten von bis zu 9 Std in der täglich, weil irgein Prozess eben die ganze Nacht benötigt. Das wird oft als "Alternativlos" verkauft, da der Prozess ja soo resourcenlastig ist.

Javascript-Bernd darf auch gerne sein Leid berichten

aluisio_azevedo Avatar
aluisio_azevedo:#9455

dieser Bernd hat vor der ganzen web 2.0 zeyt viel in der verbotenen Sprache entwickelt. Das ist jetzt schon ueber 10 Jahre her oder so. Frameworks waren da noch gar nicht so ein Begriff, zur php 3 Zeit gabs da noch nichts, jedenfalls dachte ich nicht soweit.

Auf jeden Fall war es immer eine Sprache die Bernd mochte und für die Dinge die ich tun musste war sie ausreichend. Größtenteils liegt es auch einfach an den Entwicklern die totalen Bockmist produzieren. Ich habe also nichts gegen die Sprache an sich.

joe_black Avatar
joe_black:#9461

>>9454
>dyd horrorstories
Nun, Bernd hat vor ca. nem Jahr an ner Uni als Webdevmaintainer/Adminfürarme/Mädchen für alles gearbeitet und es sind halt alle Dinge aufgetreten, die an einem infolastigen Institut ohne Ahnung von Realität halt so auftreten.

- Teile des Quellfäkals mit "toller" Anwendung von Objektorientierung
- unnötige 100+ Spalten in einer Datenbanktabelle
- bescheuerte Aufteilung in externe Dateien von denen manche nach dem Schema [0-1]+\.dyd hießen und in denen teilweise einfach nur riesige case-statements drin sind die andere Dateien einbinden
- Password bescheuert gehascht oder im Klartext gespeichert/interessantes Usermanagement

Das alleine ist nicht so selten und nicht alles dyd zuzuschieben. Jedoch folgendes:
- htmlspecialchars und Freunde können einen leeren String zurückgeben, wenn man das Encoding nicht angibt und in dem String dann ein Zeichen außerhalb des ASCII-Bereiches ist...
Eine Suche in der Kotbasis hat mehrere hunderte Vorkommnisse ohne Encodingparameter hervorgefördert.

Ich hab gehört, mittlerweile denken sie darüber nach, das Ding in Node neuzuschreiben.

Was auch ein echter Krebs werden kann, aber damit hab ich nichts mehr zu schaffen.

leelkennedy Avatar
leelkennedy:#9463

>Programmierer der verbotenen Sprache, dyd
Ich möchte OP für einen Orden vorschlagen! Das klingt mindestens genauso böse wie PHP wirklich ist.

Ich knechte als Webentwickler in einer der örtlichen Agentur-Buden und freue mich derzeit über die Tatsache, dass sich mein Hirn nur noch halb so schnell verflüssigt wie früher. Jedenfalls hoffe ich, dass ich das schlimmste hinter mir habe. Von absurden Datenbankstrukturen über riesige Sicherheitslücken (Benutzer anlegen und löschen ohne Abfrage, ob der Benutzer auch nur angemeldet ist) bis hin zu "Anwendungsteile hören in ca. 6 Monaten auf zu funktionieren" weil Clusterfuck^10 in Zusammenhang mit Datumsfunktionen betrieben wurde, habe ich schon ziemlich viel gesehen. Aber egal, der Kunde glaubt er hat ein funktionierendes Produkt und es ist völlig normal im Jahr eine 5-stellige Summe zu investieren um den komplett verbastelten Seuchenherd am kochen zu halten. Selten so gezeltet.

Mittlerweile bin ich als Programmierer davon überzeugt: Je weniger ich programmiere desto weniger Scheiße passiert in einem Projekt. Deswegen kote ich so wenig wie möglich, wenn's geht überhaupt nicht. Neuerdings hample ich viel mit Drörpel rum, einfach 100 Module reindrücken und so lange herumkonfigurieren, bis die auch die absurdesten Anforderungen erfüllen. Ganz ohne herumgekote. Seitdem ich das so mache schlafe ich durch.

salleedesign Avatar
salleedesign:#9470

>>9463
OP hier. Danke für die Komplimente.

Mit welchem System arbeitest du den? Meiner Erfahrung nach funktioniert diese Vorgehensweise auf Dauer nicht.

Wir hatten einen Kunden der genauso vorgegangen ist, und sich über 150 "Module" installiert hat. Der Zweck der Module war oft genug "zweifelhaft". Oft wurde einfach ein neues Modul gekauft um Bugs von andren zu "beheben". Ansonsten gab es auch "Das wurde gekauft weil wir XY ausprobieren wollten, leider sind wir nicht dazu gekommen aber wir wollen das auf jeden Fall drinbehalten für den Fall der Fälle". Das Ende vom Lied war, das sein System langsam wie Fick war und er kehren musst, da es mehrmals täglich abgestürzt ist. Trotz 4 Applikationsserver + 3 Datenbankserver im Cluster. Man muss dazu auch sagen, das da mehrere Leute parallel gearbeitet haben und das seine einzige Einkommensquelle war. Da er sich strikt weigerte den Krebs aus seinem System zu bannieren, wurde dann mit noch mehr zweifelhaften Methoden versucht das ganze zu beheben. Mit Varnish sowie das neue DyD 7.0 sollten alles in Ordnung kommen. DyD 7.0 zerfickte die Hälfte seiner Module und sorgte selbst auf dem Testsystem für mehr Performance-Probleme als das alte 5.6. Varnish dagegen funktionierte einwandfrei ja wirklich[spoiler]. Leider war das System nicht dazu ausgelegt, und so wurde manch einem User der Warenkorbinhalt eines andren angezeit. Das sorgte für köstliches Mett, da es Kundenspezifische Preise gab. Mehrere Kunden waren mett, da er sie zu sehr abgejudet hat im vergleich zu einem andren Kunden. Es landete schließlich beim Anwalt , wo wir zum Glück sehr gut rauskamen. Wir hatten nämlich einen relativ guten Vertrag. Nachdem dies geklärt war, wurde der Kunde immer noch weiter betreut. Am Ende hat sich meine Agentur von diesem Kunden getrennt, nachdem selbst der Chef erkannt hat, das es nur Ärger bringt solche Systeme zu betreuen.

karsh Avatar
karsh:#9471

>>9470
Jenes. Allgemeine CMSse sind langfristig scheise, deren APIs sind Krebs und betet, dass ihr nie an das Glück kommen dürft deren ultraperformanten, total glasklaren Datenbankstrukturen warten zu dürfen.

RussellBishop Avatar
RussellBishop:#9472

>Varnish dagegen funktionierte einwandfrei
>Leider war das System nicht dazu ausgelegt, und so wurde manch einem User der Warenkorbinhalt eines andren angezeit.
Ha ha ha, oh wow! Der Klassiker, absolutes Paradebeispiel dafür wie sehr einen der Krebs in die Scheiße reiten kann.

>Mit welchem System arbeitest du den?
Normalerweise habe ich Content Management am Hals, damit bin ich aber okeh. Besser als Anschnur-Shoppse wo dich Kunden um 4 Uhr morgen anrufen, weil der scheisSQL-Server kurz Schluckauf hatte. Rede mal mit Menschen, die 24/7 vor dem Rechner sitzen weil ja gleich jemand was bestellen könnte. Manchmal hänge ich aber auch vor irgendeiner individualprogrammierten (sprich von unten auf verhunzten) "Lösung", und darf das um Gnade bettelnde System künstlich am Leiden halten. Dass so ein System dauernd brennt und der Kunde seine Featuritis nicht im Griff hat ist mir aber egal, Scheiße wird ja schließlich bezahlt.

>Wir hatten einen Kunden der genauso vorgegangen ist, und sich über 150 "Module" installiert hat. Der Zweck der Module war oft genug "zweifelhaft".
Ich würde dir normalerweise Recht geben, je weniger komische Module desto besser. Ich habe aber irgendwann gemerkt, dass alles selber verbasteln totaler Bockmist ist. Wenn ich was programmiere, dann dauert das, es wird von nicht mehr als zwei Leuten getestet, an nicht mehr als einem System eingesetzt und absolut null dokumentiert. Kann einen genauso in die Kacke reiten. Eine Liste mit gut funktionierenden, gepflegten Modulen ist hier der Weg. Gerade bei Drupal hatte ich beim testen vom Modulen erstaunlich wenig WTF-Momente, was mich durchaus wundert, aber solange mir nicht alles um die Ohren fliegt werde ich das so weiter machen.

chanpory Avatar
chanpory:#9473

>>9472

Op hier:

>Ha ha ha, oh wow! Der Klassiker, absolutes Paradebeispiel dafür wie sehr einen der Krebs in die Scheiße reiten kann.
Varnish ist sowas wie ein Mem bei manchen Unternehmen. Die gehen auf Mittwald, schauen sich dort ihr CMS mit und ohne Varnish an und denken dann, das wäre die Lösung für ihre Performance Probleme. Wenn es dann zu Aufwänden bei der Integration kommt, sind die Kunden dann total überrascht, das es so teuer ist. Wir raten ihnen dann immer zu Mittwald zu gehen und ihr Projekt dort zu hosten, da dort ja der Varnish schon integriert ist. Danach warten auf ihren Anruf :)

>Besser als Anschnur-Shoppse wo dich Kunden um 4 Uhr morgen anrufen, weil der scheisSQL-Server kurz Schluckauf hatte
Bernd macht zum großteil OnlineShops mit Magento. Abstürze um 4 Uhr morgends sind wirklich selten, dafür aber gerne zum "Black Friday" oder zum "Kunde spammt mal wieder Gutschein-Mails". Mehr als "Hoster" anrufen und Leistung hochfahren lassen, ist da normalerweise auch nicht zu tun.


>Ich habe aber irgendwann gemerkt, dass alles selber verbasteln totaler Bockmist ist.
Meist aber besser entwickelt als so manch ein "Fremdherstellermodul". Was da teilweise an Scheisse abgeliefert wird. Oft auch von fragwürdigen Anbietern aus Vietnam oder Indien.

>Eine Liste mit gut funktionierenden, gepflegten Modulen ist hier der Weg
Geb ich dir Recht. Bernds Liste besteht größtenteils aus Open-Source Modulen. Bei Magento ist die Community sehr gut vernetzt und ich kann bei Bugs oft per Zwitscher Kontakt zum Entwickler aufbauen. Danach überlasse ich den Kaufmännern das ganze, die ihn dann höflich bitten gegen einen kleinen Obulus den Bug zu beheben.



>solange mir nicht alles um die Ohren fliegt werde ich das so weiter machen.
Ich hoffe du trollierst. Wir haben unsere Unternehmensseite in Drupal und das ist der Krebs schlechthin. Wir können oft keine sicherheitskritischen Patches einspielen weil das Template dann total zerschossen ist. Allgemein ist das ganze sehr sehr instabil und wird einfach aus Faulheit nicht in Ordnung gebracht. Welches Drupal verwendest du ? Wir benützen noch die 7ner.

erikdkennedy Avatar
erikdkennedy:#9474

>>9454
>Einige Kunden leben mit Downzeiten von bis zu 9 Std in der täglich, weil irgein Prozess eben die ganze Nacht benötigt. Das wird oft als "Alternativlos" verkauft, da der Prozess ja soo resourcenlastig ist.
Das hört sich ja fast nach SAP an. Das Ding kann ja nicht einmal eine Sommerzeitumstellung ohne 2h-Downtime Vertragen, weil sie ihre internen Zeitstempel in Lokalzeit speichern.

snowwrite Avatar
snowwrite:#9479

>>9474
> weil sie ihre internen Zeitstempel in Lokalzeit speichern.
Echt jetzt? Aber SAP ist doch der weltweite Industriestandard für ERP??

vickyshits Avatar
vickyshits:#9481

>>9474
Aus welchem verfickten Grund speichert SAP die Zeit nicht als Unix-Timestamp? Damit könnte man doch wirklich jegliche Zeitzonen abdecken. Und was zum Fick ist "stretched time"?

dpg Avatar
dpg:#9483

>>9479
Dies macht dich denk, tut es nicht?

carlyson Avatar
carlyson:#9484

>>9473
Tatsächlich lasse ich mittlerweile auch die Finger von Kauf-Modulen, da quelloffene Software oft (erfahrungsgemäß) viel besser funktioniert. Keine Ahnung warum, ich vermute mal der Verkäufer will seinen Krams schnell loswerden und nimmt es nicht so genau mit dem testen. Und Chinesen und Inder basteln wirklich nur Scheiße zusammen. Noch nie etwas positives aus der Ecke kommen sehen.

>Danach überlasse ich den Kaufmännern das ganze, die ihn dann höflich bitten gegen einen kleinen Obulus den Bug zu beheben.
Das ist eigentlich ein guter Plan. Den Entwickler mit Kohle locken und das Mist dann beim eigenen Kunden abrechnen.

>Wir können oft keine sicherheitskritischen Patches einspielen weil das Template dann total zerschossen ist.
Wir haben hier auch Drupal 7 und wirklich wenig Probleme damit. Das letzte Problem, dass ich bei einem Update hatte, war ein zerschossenes Menü beim Update des Bootstrap Base-Themes. Das war aber meine eigene Schuld, weil ich dort Änderungen vorgenommen habe, die natürlich nach dem Update weg waren. Habe den Code dann mittels Hooks in's Haupt-Theme verschoben und es lief wieder ordnungsgemäß.
Daran wurde wirklich wenig selbst gebastelt, vieles wird mit den üblichen Modulen gemacht, wie z.B. Views oder Panels. Wenn man da mal Updates macht passiert da nicht viel. Habt ihr vielleicht am Core rumgespielt? ;)

greenbes Avatar
greenbes:#9585

>>9483
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/00269ed5-9f37-2f10-8686-f28792c1975a?QuickLink=index&overridelayout=true&53648436494668

keyuri85 Avatar
keyuri85:#9586

>>9585
Es erklärt leider immer noch nicht warum die lieben SAP-ler keinen normalen UTC-Linux-Timestamp verwenden. Gibt es Gründe die dagegen sprechen? Der sollte doch unabhängig von der lokalen Systemzeit immer richtig sein.

>>9484
>Habt ihr vielleicht am Core rumgespielt?
Nicht das ich wüsste.Eventuell doch, aber keiner wirds jemals zugeben wollen.. Allerdings wurde ein beschissenes 40$ Kauf-Template installiert und stark "verändert".

linux29 Avatar
linux29:#9604

>>9586
>Es erklärt leider immer noch nicht warum die lieben SAP-ler keinen normalen UTC-Linux-Timestamp verwenden.
Es ist Deutschland hier, deshalb

Neuste Fäden in diesem Brett: