Frust-Thread


#927

Liebe Kollegen hier vor Ort: Nein, wenn die Anforderung lautet “ein Geburtsdatum darf maximal 110 Jahre in der Vergangenheit liegen” ist die Lösung nicht(!) im Frontend auf “birthDate.getYear >= 1908” zu validieren.


#928

Durften wir hier vor noch gar nicht allzu langer Zeit auch umsetzen. Wobei unsere Kunden afair nicht älter sein dürfen als 100. Da durfte sich unser PO einiges wegen Altersdiskriminierung vom Team anhören :slight_smile:


#929

Ja, die Witze gehen hier auch rum :wink:

Übrigens hat sich mittlerweile herausgestellt, dass das auch im letzten Jahr so gebaut war. Der Entwickler hat einen Defect zugewiesen bekommen und es gelöst, indem er aus “1907” einfach “1908” gemacht hat. Jahreswechsel, da ist ja nur logisch.


#930

Mal ehrlich… sind solche Patzer nicht eher amüsant, als frustrierend?:grin:


#931

Nicht, wenn es laufend passiert. Hier gibt es laufend Defects wegen String Vergleichen mit ‘==’, falscher Benutzung von java.util.Date, wir bekommen Soap Services in denen “Date” ein String ist… im kleinen Umfang ist es lustig, wenn es Methode hat, nicht mehr.


#932

Vielleicht solltet ihr nicht nur Praktikanten an den Code lassen :wink:


#933

Projektarbeit mit anderen Firmen, die Leute die das alles verbrechen sind nicht von uns, sondern von der Global Delivery Unit eines großen IT Dienstleisters. Da kannst du leider nichts machen, weil wenn du dann sagst “Die liefern nur Mist” wird es direkt als Angriff und als Fingerpointing bezeichnet. Politik im Projekt halt :man_shrugging:


#934

Allerdings finde ich die Anforderung als solches schon komisch. Soll doch ruhig eine Person mit 111 Jahren sich anmelden dürfen. In den meisten Fällen dürfte das kein Problem sein. :smiley:


#935

Solange niemand angibt 200 Jahre alt zu sein…


#936

Auch das wäre doch egal. Ist es wirklich sinnvoll dafür eine Prüfung zu implementieren und durch die QA testen zu lassen? Ich denke (in den meisten Fällen) nicht.


#937

Ich habe mal deutlich erkannt wieso es Probleme bereiten kann ein Feld und ein Methoden/Konstruktor Parameter mit dem gleichen Namen zu haben und später sich im gleichen Scope darauf zu beziehen mit dem Gedanken: “Ja so heißt ja das Feld”


#938

Verkacktes Visual Studios -.-. Ich versuch mich gerade an Xamarin und nutze dne Live-Player. Nur ist das komplett unbrauchbar. Sobald ich was im Code ändere, dann will er noch während ich tippe das Zeug neu kompilieren. Soweit noch ok. Aber jetzt kommts: da der Code nicht kompilierbar ist (logisch ICH TIPP JA NOCH!!!) poppt die Fehler-liste auf und klaut den Fokus vom Editor! Welcher Vollidiot hält es denn für eine gute Idee da den Fokus gewaltsam hinzulegen -.- …

Würde ja gerne Rider verwenden, aber das findet mein Xamarin-SDK nicht … und ich hab keine Ahnung wo das liegt. Man kann es ja nicht separat downloaden. Nein nur ausschließlich innerhalb Visual Studio und dann wird es in irgendwelchen Untiefen installiert … Bescheuerter hätte man es nicht mehr machen können…


#939

Mein Kunde stellt sein Mailsystem auf office365 um.
Dafür muss jeder Teilnehmer am Mailsystem eine Konfiguration über das intranet vornehmen. Natürlich ist dieser Link für Externe nicht erreichbar…

Ich meine: wenn die Ihr “intelectual property” an M$ abgeben wollen ist das ja deren Sache, aber sie sollten dann nicht solche Hürden hinstellen…

bye
TT


#940

Vielleicht sollte dein Kunde Hilfe von uns annehmen, das klingt als wäre da am Design was kaputt. Intranet ist einfach Oldschool :wink:


#941

Wenigsten habe ich die notwendige Info inzwischen bekommen, der Sametime geht nämlich noch…

Und ja: Benutzer selektiv von Informationen auszuschließen und andererseits o365 einzusetzen ist irgendwie inkonsequent…

bye
TT


#942

Wenn ich noch einmal einen Stringvergleich mit “==” sehe muss ich irgendwas kaputt machen. :rage:

Und ja, es wird jeweils nur der Inhalt des Strings verglichen und nicht die String-Objekte.


#943

Du vergleichst Tangas ??? :no_mouth:


#944

Nö, nur den Inhalt :no_mouth:


#945

:face_vomiting::zipper_mouth_face:


#946

Ihr seid komisch :smiley: