Hoe noemen we scripts geschreven in Java? 
/u/900065/crop65b3839879b1c_cropped.png?f=community)
/u/105842/Homer_60x60.png?f=community)
Was dat niet Java Web Start? Dat je als website min or meer automagisch een Java-applicatie kon laten starten?:
Hoe noemen we scripts geschreven in Java?
Read the code, write the code, be the code!
:strip_icc():strip_exif()/u/2108942/crop6614f8e0519b9_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/734655/crop6390c3acd41c6_cropped.jpg?f=community)
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
/u/142011/crop65b383c6c6c2f_cropped.png?f=community)
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Good job, UWV. Good job. 
:fill(white):strip_exif()/f/image/Nf8A1oS2CCYDAaFyqlWgfB2i.png?f=user_large)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_icc():strip_exif()/u/284419/Mexican%2520Wolf%2520Klein.jpg?f=community)
:strip_icc():strip_exif()/u/43400/avatar.jpeg?f=community){kind=avatar}
Ik wou zeggen maak er C%2B%2B van ofzo, maar dat mag natuurlijk ook niet vanwege de %
"Cplusplus" it is then 
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.
Je eigen tweaker.me redirect
Over mij
De bochten waarin een man zich moet wringen voor een overheid-betaalde sabbatical 
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Je zou maar Chekje doen. Wie weet lezen ze dat dan weer verkeerd:
[...]
Ik wou zeggen maak er C%2B%2B van ofzo, maar dat mag natuurlijk ook niet vanwege de %
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ook leuk hoe enters en paragrafen gewoon genegeerd worden. Typ je een beetje een duidelijk stukje, wordt het sowieso een onleesbare brij
Nou ja, op zich niet, ik zoek even helemaal geen werk
Nou ja, op zich niet
, ik zoek even helemaal geen werk
[ Voor 18% gewijzigd door .oisyn op 13-05-2024 16:46 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
Het probleem is dat de meeste mensen niet langer meer begrijpen hoe geheugen werkt. Zo heb ik tegenwoordig een standaard demonstratie van een onschuldige memory leak in javascript.
Wat dat betreft hanteer ik nog steeds de regel die ik in mijn C++ dagen heb geleerd: Voordat je een new schrijf zorg je eerst dat er een delete aanwezig is.
En die regel heeft zijn waarde bewezen in C++, JavaScript, C# en SQL (yep, fucking SQL). Rust heeft alleen die regel wat formeler gemaakt.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Yep, dat is het idee van RAII
https://www.stroustrup.com/bs_faq2.html#memory-leaks
https://en.cppreference.com/w/cpp/language/raii
Ask yourself if you are happy and then you cease to be.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
"We really hate repetitions in Rust"
....
"unwrap()"
"unwrap()"
"unwrap()"
Ik kom niet meer bij
PS
Mijn voorkeur voor C++ heeft denk ik ook te maken met dat ik OOP fijn vind. Ik ben niet anti OOP en hoewel ik functional programming wel interessant vind, hou ik er ook niet van als het mij opgedrongen wordt.
In C# gebruik ik LINQ bijvoorbeeld waar ik het handig vind, maar lang niet altijd. Soms is procedurele code gewoon veel makkelijker te begrijpen of iig te maken als je graag iets af wil maken.
Ik ben ook niet anti exceptions. Zolang je exceptions echt voor fouten gebruikt, komen ze als het goed is ook niet vaak voor... dus is de performance impact ook minimaal. Het enige nadeel is het onderbreken van de control flow, d.w.z. je kan niet altijd direct zien wat er in een stuk code kán gebeuren. In talen als Go en Rust moet je bewust met errors omgaan in de code, maar dat maakt het niet per se cleaner.
Misschien veiliger, maar niet cleaner. Exceptions geven je de mogelijkheid om een cleane "happy path" te programmeren.
De code staat niet vol met "if err != nil" zoals in Go of zoals in Rust met pattern matching voor elke enumeration, of erger met unwrap calls voor de lazy Rust dev.
[ Voor 58% gewijzigd door Lethalis op 13-05-2024 21:31 ]
Ask yourself if you are happy and then you cease to be.
/u/3813/100_8985_ICON2.JPG?f=community)
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Als exceptions in de codebase gemeen goed is dan is er iets uitzonderlijks aan de hand met de code.
En shared pointer gebruik je alleen wanneer er onduidelijkheid is over de levensduur van het object.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Dat is een technologisch oplossing, mijn oplossing zat in een aanpassing van mijn gedrag. Gewoon letterlijk altijd eerst delete schrijven en dan pas de new.:
[...]
Yep, dat is het idee van RAII
https://www.stroustrup.com/bs_faq2.html#memory-leaks
https://en.cppreference.com/w/cpp/language/raii
Overigens kan je beide combineren.
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/373849/cowava2.png?f=community)
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
:strip_icc():strip_exif()/u/86654/krat_toren.jpg?f=community)
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
/u/74211/crop5db297afbbd2b_cropped.png?f=community)
Daar heb je dan lekker overheen gelezen
:
[...]
Oh nee, je avatar is anders en nu herken ik je niet meer in één oogopslag.... Verandering is stom!
Einstein: Mijn vrouw begrijpt me niet
Je moet natuurlijk doen wat je zelf het leukst vindt en blij van wordt en C++ kan dat voor je doen, zeker. Rust is echter in veel opzichten moderner en moeilijker om niet correcte code mee te schrijven. Het nadeel daarvan is dat de BC je continue staat te naggen omdat je code niet correct is. C++ zegt dan gewoon niets, of misschien een warning als je mazzel hebt, Of een foutmelding van 20 pagina's.
Whatever je blij maakt, dat is het belangrijkst.
In geen geval zou ik willen suggereren dat Go een goed idee is, voornamelijk omdat ik die kennis niet heb.
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Op dit moment vind ik het gewoon leuk om mij in te lezen in C++ en ermee te spelen. Maar het is verre van statisch, misschien zit ik over 6 maanden alsnog met Rust te klooien:
[...]
Je moet natuurlijk doen wat je zelf het leukst vindt en blij van wordt en C++ kan dat voor je doen, zeker. Rust is echter in veel opzichten moderner en moeilijker om niet correcte code mee te schrijven. Het nadeel daarvan is dat de BC je continue staat te naggen omdat je code niet correct is. C++ zegt dan gewoon niets, of misschien een warning als je mazzel hebt, Of een foutmelding van 20 pagina's.
Whatever je blij maakt, dat is het belangrijkst.
In geen geval zou ik willen suggereren dat Go een goed idee is, voornamelijk omdat ik die kennis niet heb.
Go is simplistisch, dat is een bewuste keuze van de ontwerpers. Grootste verschil met Rust en C++ is dat het een garbage collector heeft. Er is dus voor gekozen om developer productiviteit voorrang te geven ten koste van wat performance. Maar omdat er verder geen runtime is, valt de performance impact t.o.v. C++ mee. En is het out of the box een stuk efficiënter dan .NET of Java.
Met cgo kun je C libraries gebruiken en de standard library is behoorlijk compleet waardoor je snel bepaalde dingen kunt bouwen. Ik had in een mum van tijd een web api draaien bijvoorbeeld die 7mb reserveerde, waarvan 125kb in gebruik was. Een .NET hello world pakt zo 100mb en gebruikt 15mb.
Maar goed, C++ en Rust geven meer controle omdat je zelf het geheugen beheert en kunnen dus nog efficiënter zijn.
[ Voor 12% gewijzigd door Lethalis op 14-05-2024 19:21 ]
Ask yourself if you are happy and then you cease to be.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/N0fnOFO8knUQVB0NfZKaCJmC.jpg?f=user_large)
Thanks man, goed om te weten
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Nog even als reactie op jouw mini C++ rant. Er staat tegenover dat het heel volwassen is. Qua package managers heb je vcpkg (van Microsoft) en Conan heb ik gelezen (kwam ik toevallig achter omdat ik libgit2 wil gaan gebruiken voor een tooltje en het in hun README.md staat
).En de rest van jouw verhaal heb je eigenlijk ook bij Java bijvoorbeeld. Er zijn 101 manieren om iets te doen, meerdere package / build managers (Maven, Gradle, etc), veel projecten die niet verder dan Java 8 zijn gekomen, etc.
Maar er staat net zoals bij C++ tegenover dat het volwassen is en je echt voor bijna alles wel een library kunt vinden om te gebruiken.
Bij Rust en Go kom je sneller op dat punt van "he bah, hier is nog niks voor". En dan kun je alsnog C bindings maken of het zelf gaan coden. Tuurlijk, Rust krijgt steeds meer creds... er is zelfs een artikel van het Witte huis in de VS die het voorstelt om veiligere code te schrijven, omdat 70% van alle security issues door memory bugs komen).
Is het momenteel de enige taal die "safe" is zonder garbage collector? Dat lijkt vooral het criterium voor de taal "van de toekomst" te zijn (voor realtime software die iets aanstuurt bijvoorbeeld).
Ask yourself if you are happy and then you cease to be.
Is dat niet vooral een kwestie van een wrapper class maken die in de destructor de juiste functies aanroept van de C library om eventuele resources op te ruimen?
Misschien krijg ik nog spijt zodra ik echt tegen issues aanloop
Maar ben gewoon benieuwd.
Ask yourself if you are happy and then you cease to be.
:strip_icc():strip_exif()/u/5964/crop56503163e97a5.jpeg?f=community)
Ik heb een paar maanden geleden mijn Chromebook (waarvan ik de firmware heb vervangen en Manjaro op heb geïnstalleerd) "nilbook" genoemd omdat hij matige specs heeft:
[...]
Ik kreeg ooit een mailtje die begon met:
[...]
Dan voel je je ook gewaardeerd
Alsnog draait Linux er wel aardig op (Pentium Silver, 4GB RAM en 64GB storage). Moest wel 6GB swap file aanmaken om de boel werkbaar te houden. Prima om mee te internetten en met vscode dingetjes uit te proberen met Rust, C++, Go, etc.
Ask yourself if you are happy and then you cease to be.
:strip_exif()/u/47168/loop.gif?f=community)
On that subject, ik heb net een nieuwe laptop gekregen van het werk, met 16GB RAM 
En in de oude was een jaar of 2 terug het RAM al vervangen door 32GB....
Erge is ook nog eens dat als ik PHPStan (static analyzer) uitvoer op het project dat die kijkt hoeveel (virtuele) CPUs er zijn (20), en op basis daarvan bepaald hoeveel processen te starten, dat gecombineerd met een groot project betekent dat er 1GB RAM nodig is per process, en die de laptop dus plat gooit (en bv PHPStorm wordt gekilld met een out of memory). Vervolgens via config het aantal processen beperkt tot 10, en nog steeds problemen. Dus intussen beperkt tot 5 processen...
3 weken terug over geklaagd, "herinner me er maar aan na mijn vakantie" (was afgelopen 2 weken). Maandag wel een linkje ontvangen naar een 64GB setje (meteen het maximale dat de laptop aan kan) met de vraag of ik dacht dat dat zou werken. Maar verder niks meer van vernomen.
En in de oude was een jaar of 2 terug het RAM al vervangen door 32GB....Erge is ook nog eens dat als ik PHPStan (static analyzer) uitvoer op het project dat die kijkt hoeveel (virtuele) CPUs er zijn (20), en op basis daarvan bepaald hoeveel processen te starten, dat gecombineerd met een groot project betekent dat er 1GB RAM nodig is per process, en die de laptop dus plat gooit (en bv PHPStorm wordt gekilld met een out of memory). Vervolgens via config het aantal processen beperkt tot 10, en nog steeds problemen. Dus intussen beperkt tot 5 processen...
3 weken terug over geklaagd, "herinner me er maar aan na mijn vakantie" (was afgelopen 2 weken). Maandag wel een linkje ontvangen naar een 64GB setje (meteen het maximale dat de laptop aan kan) met de vraag of ik dacht dat dat zou werken. Maar verder niks meer van vernomen.
Volwassen is niet de goede term voor wat C++ is wat mij betreft. Het is wel (in alle opzichten) ENORM flexibel.
Vandaar *standaard* package manager. Die lib die jij zoekt in de toekomst, staat niet in Conan.Qua package managers heb je vcpkg (van Microsoft) en Conan heb ik gelezen (kwam ik toevallig achter omdat ik libgit2 wil gaan gebruiken voor een tooltje en het in hun README.md staat
Euh nee, Java heeft geen UB. Rust ook niet. C en C++....not so much.
Oh ja, die was ik nog vergeten, build systems...
Veel zijn C libraries eigenlijk.
Geen idee eigenlijk. Als je echt real time wilt is trouwens niet alle "common" Rust/C++ gewenst aangezien ze beide een heap hebben die niet deterministisch is.
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Dat is wel een dingetje waar Rust veel makkelijker in is. Even dependencies toevoegen aan de Cargo.toml, cargo run draaien en alles wordt voor je opgehaald en gecompileerd.:
[...]
Oh ja, die was ik nog vergeten, build systems...
Build systems voor C++ vereisen een studie an sich. CMake ben ik nog niet heel handig in. Ik begrijp het concept (denk ik). In die zin dat het makefiles, project files etc voor jou kan genereren en je op een portable manier kunt ontwikkelen.
Maar dat gooit wel meldingen om mijn oren soms.. kan het weer 1 of andere generator niet vinden
Mijn C++ testproject gebruikt dan ook een ouderwetse simpele Makefile.Tot nu toe is mijn ervaring: C++ de taal is eenvoudiger voor mij dan Rust, maar de tools rondom C++ zijn veel lastiger / complexer.
Even een git2 crate binnenharken met Cargo met 1 tekstregel en 1 commando is wel prettiger dan vcpkg en cmake aan de praat krijgen en je afvragen waarom na de installatie van libgit2 de header file <ergens> staat, maar ik het nog ff niet weet.
Met Rust heb ik dan al vanuit code een git repo geopend en de branchnaam waar HEAD naar wijst opgevraagd... het C++ project compileert nog niet
Dat krijg ik wel aan de praat door handmatig te linken, maar als ik het netjes en cross platform wil doen... uh oh.
Ask yourself if you are happy and then you cease to be.
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/306933/ezgif.com-optimize.gif?f=community)
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
:fill(white):strip_exif()/f/image/sGQzkSAqobjQeknwpR7TgtwW.png?f=user_large)
I'll see myself out
(op mijn werk, een groot WinForms pakket op .NET 4.7.2 met meer dan een half miljoen regels code en tig dependencies waarvan het steeds lastiger wordt om ze bij te werken omdat het ook hip wordt om .NET 4.x steeds minder goed te supporten)
Ask yourself if you are happy and then you cease to be.
Omdat het ons simpelweg met het huidige team niet gaat lukken. Al zouden we fulltime daaraan werken zijn we over een jaar nog niet klaar... en kunnen we zoals @Caelorum ook al aangeeft de business niet ondersteunen met alle vragen en wijzigingen die ze elke dag hebben.
Ik werk aan een pakket dat in 2001 het daglicht zag en gebaseerd is op een VB6 voorganger. Wij hebben een iets andere definitie van Long Term Support dan Microsoft heeft tegenwoordig.
Daarom ben ik ook erg huiverig voor ons nieuwe Angular pakket. Dat moet dan ook weer 20 jaar meegaan. Al zouden we er fulltime aan werken, duurt het minimaal 5 jaar voordat het gereleased kan worden. Het is dan waarschijnlijk dead on arrival.
Ik heb ooit aan een AngularJS pakket gewerkt
Versie 1 was nog niet af en AngularJS was alweer dood. Vanuit de business is het ook niet te verteren. Daar heerst de mentaliteit "je bouwt iets een keer en dan heb je er vele jaren plezier van". Niet "het moet continu onderhouden en verbouwd worden".Vroeger klopte de oorspronkelijke stelling wat meer dan tegenwoordig. En hoewel ik het allemaal prima begrijp hoor, geef ik ze ook weer een beetje gelijk. Het lijkt soms alsof we ons als developers de hele tijd zelf werk verschaffen, omdat het weer anders / beter moet.
Als developer vind ik het prachtig om nieuwe dingen te leren en te doen. Maar als het mijn geld zou zijn... oei. Mijn auto is ook alweer 10 jaar oud, dus ik weet wel hoe ik zou zijn dan. I'll keep it running until the wheels fall off.
PS
Misschien valt het soms ook op aan mijn berichten hier... maar ik zoek al jaren bijna wanhopig naar het vereenvoudigen van alles. Web development is tegenwoordig namelijk een drama. Je zoekt in een zee van onzekerheid naar stabiliteit. Een basis waarop je voor vele jaren kan bouwen.
Dat leidt tot gedachten als "wat is het meest minimale framework dat ik kan gebruiken?", of "zou het ook lukken het helemaal zelf te doen?". Want elke keer als wij bouwen op een externe partij dan gaat de boel ineens weer overhoop, terwijl ons product nog lang niet af is.
Ik vind Angular hartstikke mooi en ik kan er leuke dingen mee bouwen... maar gaat mijn project nog werken als ik het over 10 jaar wil builden? Of lijkt het Angular dat er over 10 jaar is totaal niet meer op Angular 17 en had ik het al 10x moeten verbouwen terwijl ik daar bij lange na de tijd niet voor zal hebben?
Hoe lelijk en ouderwets het ook is, Windows Forms is behoorlijk lang meegegaan zonder grote wijzigingen. En Microsoft heeft het niet voor niets geporteerd, want ze weten ook dat veel bedrijven de boel niet gaan ombouwen naar iets anders. En als ze het wel doen, dan wordt het een webpakket waarvoor Windows niet meer nodig is.
PPS
Daarom vind ik het soms ook leuk om back to basics te gaan en C++ te doen etc. Ik heb er ook weleens aangedacht om ander soort werk te doen waarbij er geen user interface is. Embedded development, of mij helemaal storten op backend development. Dan ben ik maar geen full stack meer. F*ck dat
Ik ben pas 43... ik moet nog een tijdje mee. But sometimes, I'm getting too old for this shit
[ Voor 50% gewijzigd door Lethalis op 16-05-2024 16:49 ]
Ask yourself if you are happy and then you cease to be.
Sorry dat ik er om moet lachen. Of huilen. Ik weet het ook niet meer. Ik werk sinds 2003 als .NET developer trouwens.
Ask yourself if you are happy and then you cease to be.
Een goede reden om geen .NET te gebruiken dan:
[...]
Sorry dat ik er om moet lachen. Of huilen. Ik weet het ook niet meer. Ik werk sinds 2003 als .NET developer trouwens.
Microsoft was altijd van de backwards compatibility, en bijvoorbeeld de C/C++ API is enorm stabiel zelfs tussen de Windows versies door. Maar het antieke .NET Framework is blijkbaar gewoon overboord gegooid
Eerlijk is eerlijk, ik ben ooit met .NET begonnen voor het geld. Niet omdat mijn hart daar lag.:
[...]
Een goede reden om geen .NET te gebruiken dan
In 2003 regende het .NET vacatures en ik had een baantje nodig. Thuis draaide ik op dat moment Linux en ik programmeerde in C en C++. Okee, en het beetje webdevelopment dat ik deed, was PHP. Want dat was gewoon makkelijk en leidde snel tot resultaat.
Maar ja, dan krijg je ruzie met je ouders en moet je het huis uit. Je opent monsterboard en ziet dat .NET gevraagd is. Je vraagt destijds een vriend (@Marcade) voor een kopie van Visual Studio. Je leert jezelf .NET in een paar maanden en solliciteert.
Ach ja, ik kan zeiken over Microsoft wat ik wil, maar ik verdien er al 21 jaar mijn geld mee.
Ask yourself if you are happy and then you cease to be.
1 van de dingen die nogal onderbelicht zijn is het werkplezier om in die oude meuk te moeten werken. Wij hebben al ervaren dat junior developers gewoon vertrekken als ze zien dat ze nog jaren in legacy meuk moeten werken. Fijn dat je werkgever het nog lang wil ondersteunen, maar zonder mensen wordt dat toch lastig.:
[...]
#herkenbaar verhaal#
Ik ben pas 43... ik moet nog een tijdje mee. But sometimes, I'm getting too old for this shit
Een handvol labels en een timer op één form... Ja, dat converteert prima
Probeer het nu eens met iets van Telerik of DevExpress op honderden forms met custom code die op Windows XP nog werkte.
Maar WinForms werkt al wel twintig jaar hetzelfde want de Win32-User-API eronder is ook niet veranderd. Dat gedeelte van de code kun je prima porten. Het gaat om alle custom meuk, third-party controls waarvan de maker vaak niet eens meer leeft, enzovoorts. En om de opzet in het algemeen: elk form heeft z'n eigen data-controls, waarvan de queries worden herschreven met strings in knop-klik-events, de applicatie is bedacht met honderd databaseregels in het achterhoofd en dat zijn er na tien jaar gebruik honderdduizend, enzovoorts.
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Ik ben eind jaren 90 ook begonnen met Visual Studio samen met een buurjongen. Dan maakte we onbenullige applicaties in Visual Basic (vóór .NET) (waren gewoon Windows Forms die we niet eens hernoemd hadden, dus Form1, Form2, etc.) met wat in elkaar geknutselde form controls. Applicatie "afsluiten" deden wij met Me.Hide, waardoor het proces dus gewoon op de achtergrond bleven draaien. Wisten wij veel
Daarna kwam er een HTML, JavaScript en PHP fase want websites maken was hot. En dan ontdek je Linux, zo heb ik ooit nog eens in de winkel SuSE Linux gekocht en neig ik nog steeds richting RHEL (en heb ik een hekel aan Debian en afgeleiden
). Via allerlei paden en wegen ben ik toen uitgekomen bij embedded systemen, terwijl ik nu juist werk aan de backend van SaaS applicaties en WebGL.Op een of andere manier ben ik, behalve van stukjes spielerei en wat tools, met een grote boog om .NET heen gegaan
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Dit dus. Bij ons is het ComponentOne en DevExpress.:
[...]
Een handvol labels en een timer op één form... Ja, dat converteert prima
Probeer het nu eens met iets van Telerik of DevExpress op honderden forms met custom code die op Windows XP nog werkte.
Maar WinForms werkt al wel twintig jaar hetzelfde want de Win32-User-API eronder is ook niet veranderd. Dat gedeelte van de code kun je prima porten. Het gaat om alle custom meuk, third-party controls waarvan de maker vaak niet eens meer leeft, enzovoorts. En om de opzet in het algemeen: elk form heeft z'n eigen data-controls, waarvan de queries worden herschreven met strings in knop-klik-events, de applicatie is bedacht met honderd databaseregels in het achterhoofd en dat zijn er na tien jaar gebruik honderdduizend, enzovoorts.
En inderdaad intensief gebruik van data grids zonder scheiding van UI en business layer. Dus de code is afhankelijk van de events die de controls raisen en de properties die de controls hebben.
Overstappen op een ander component is al niet te doen zonder een complete rewrite.
En de directie vond het mooi dat je alles direct in de grids kon doen. Een formpje openen om een regel te wijzigen? Nee joh, het grid kan dat ook!
Enzovoorts...
Ask yourself if you are happy and then you cease to be.
:strip_icc():strip_exif()/u/492949/crop627d0c893ea0e_cropped.jpg?f=community)
Grappig, ik gebruikte Slackware Linux, maar ben destijds door een vriend (die later een heel hosting bedrijf heeft opgezet) juist Debian gaan gebruiken.:
[...]
Daarna kwam er een HTML, JavaScript en PHP fase want websites maken was hot. En dan ontdek je Linux, zo heb ik ooit nog eens in de winkel SuSE Linux gekocht en neig ik nog steeds richting RHEL (en heb ik een hekel aan Debian en afgeleiden
PHP was gewoon een verademing ten opzichte van een Perl script schrijven. Been there, done that
Ask yourself if you are happy and then you cease to be.
Dat klopt helemaal. En dat is dus precies het probleem. Maar wat je vervolgens vaak ziet is het helaas: oh, zo is het nu eenmaal, laten we maar op die manier verder gaan. Dan horen alle alarmbellen af te gaan. Daar kun je als individuele programmeur vaak ook helemaal niets aan doen, al zou je het willen. Vooral als je pas later in het project komt. Maar als een organisatie daar de ernst niet van inziet is gewoon vragen om grote problemen.
Vroeger toen iedereen de waterval-methode gebruikt was dit probleem heel groot. Veel van de (oude) software met zulke problemen stamt ook uit die tijd. Met scrum is het gelukkig veel makkelijker om vroegtijdig in te grijpen. Al is er dan nog steeds weinig te bereiken als het grootste deel uit beunhazen bestaat
Members only:
Alleen zichtbaar voor ingelogde gebruikers.
Inloggen
Ik denk dat veel bedrijven sowieso op die manier zijn begonnen. De directeur van het bedrijf waarvoor ik werk, was gewoon handig met computers terwijl hij ander werk deed. En als het dan lukt om in de jaren 90 een DOS programma te maken dat allerlei bedrijfsprocessen een stuk efficiënter laat verlopen, dan wordt dat jouw werk. En vervolgens groeit dat, krijgt de software een naam, wordt het ook verkocht aan andere bedrijven, neem je meer mensen aan ervoor, maak je een Windows versie, splits je later de software afdeling af van de main business... et voila, je hebt een softwarebedrijf.
En dan reageer ik op de vacature en ga er werken aan een ander project, een project dat uiteraard ermee stopte. Dan kun je kiezen. Aan de core producten werken, of weggaan. Als je dan net een huis hebt gekocht en jouw vriendin zwanger is... tsja. Kom maar op met die Windows Forms zooi.
Een andere collega van mij wou dat niet en die moest toen dus ook een andere baan zoeken. Is overigens ook weer prima terechtgekomen, dus hoe bang je daar nou uiteindelijk voor moet zijn geen idee. Ik ben alleen onderdeel van het meubilair geworden inmiddels, dus ik durf amper nog ergens anders te werken
Ik heb ook wel veel vrijheid. Kan thuiswerken, eerder weg wanneer ik wil, enzovoorts. Allemaal handige dingen als je een jong kind hebt. En als ik iets verkloot of niet op tijd af heb, dan heeft dat eigenlijk nooit consequenties. Als ik het maar weer oplos.
De sfeer is enorm informeel. Maar goed, ik vrees wel voor het aannemen van nieuw personeel. Die ga je nauwelijks kunnen motiveren om aan de bestaande software te werken. Laat staan dat ze het überhaupt kunnen, omdat ze die hele historie niet kennen.
Zo heb ik laatst met een collega een bug in de software opgelost door in te haken op de main message loop en te kijken welk control nou focus krijgt in een bepaalde situatie. Want dat kregen we standaard met de debugger niet meer voor elkaar (ook mede dankzij externe componenten die tig levels diep genest zijn).
Een jonge dev weet waarschijnlijk niet eens wat een Windows message loop is.
Ask yourself if you are happy and then you cease to be.
De jaren 90 noemen we op mijn werk ook wel de pioniertijd. Veel beunhazen inderdaad, maar wel échte hobbyisten. Kortom, misschien geen formele opleiding, maar konden wel van alles.:
[...]
Al is er dan nog steeds weinig te bereiken als het grootste deel uit beunhazen bestaat
***members only***
En tegenwoordig lijkt het andersom. Mooi papiertje, maar als ze iets moeten maken dan moeten ze aan het handje vastgehouden worden.
Ik val ertussen in overigens. Aan de ene kant echte hobbyist, aan de andere kant had ik bijna de HTS af. Alleen door de ruzie met mijn ouders destijds ben ik als HBO dropout gaan werken. Dus ik heb iig voor een deel formele opleiding gehad. Pascal, C en C++ heb ik bijvoorbeeld op school geleerd ooit. En ik moest code formeel bewijzen met discrete wiskunde (al vond ik dat in de praktijk niet heel nuttig). Leukste vak vond ik besturingssystemen. En toen begon ook mijn interesse voor Linux.
Mijn opleiding was echter nog gebaseerd op AMBI, dus de hele OOP rage kwam daarna pas. Ik heb wel later nog cursussen aan de Open Universiteit gevolgd daarvoor (Java, objectgeorienteerd analyseren en ontwerpen, etc).
Maar in de basis ben ik een hobbyist. Autodidact. Make it work. Weet je niet hoe? Ga lezen. Ik stam nog uit de tijd dat je gewoon een boek kocht en dat rustig ging lezen.
En ik vrees dat de jeugd veel te afgeleid is door alles. Ik ben eigenlijk bestwel blij dat in mijn jeugd geen internet was zoals we het vandaag kennen. Dat er geen social media was. Dat de tijd die ik achter de computer zat, besteed werd aan dingen leren en uitproberen... en niet doelloos filmpjes kijken en met iedereen chatten.
Want dan had ik misschien ook veel minder gekund...
Goh, ik klink nu echt als een oude zak
En ik zit eigenlijk alweer teveel op dit forum, proving my point
Ask yourself if you are happy and then you cease to be.
Het zal wel een domme opmerking van mij zijn, maar dit gaat toch vooral om de functionele eisen?
Het grote nadeel van de waterval methode was dat er weinig contact met de stakeholders was, waardoor je soms maanden aan iets werkte dat de klant helemaal niet zo bedoeld had. Met agile methoden kun je sneller bijsturen waardoor de kans van slagen groter wordt. Maar dat is dan vooral of het product voldoet aan wat de klant verwacht.
Dat het achter die mooie user interface compleet rot is, heeft die immers niet door
Hoogstens dat het netter opzetten het ook eenvoudiger maakt om bij te sturen. Maar gezien er ook een hoop "cowboy programming" is, wordt dat ook vaak gemaskeerd. Oftewel "oh crap, nou ik fix het dit weekend wel" en dan zijn we er alsnog ipv dat we het netjes gaan opzetten.
[ Voor 13% gewijzigd door Lethalis op 16-05-2024 14:17 ]
Ask yourself if you are happy and then you cease to be.
Ja, en nee. Het heeft wel enigszins met elkaar te maken. Wat in de praktijk vaak gebeurde is dat er bij de waterval aan een stuk door aan features werkt gewerkt en de teams geïsoleerd werkte. Dat de code review, als die er al was, en het integreren ook aan het einde gebeurde. Als er slechte code geschreven werd, zag je dat vaak dus pas na een lange tijd. De aangerichte schade was dan al enorm. Bij scrum heb je een andere werkwijze waardoor dat soort dingen indirect veel eerder naar voren komen. Het is natuurlijk geen garantie, maar het bij sturen is makkelijker. Bijvoorbeeld bij de daily dat je denkt volgens mij... en dan toch maar even gaat kijken.:
[...]
Het zal wel een domme opmerking van mij zijn, maar dit gaat toch vooral om de functionele eisen?
Het grote nadeel van de waterval methode was dat er weinig contact met de stakeholders was, waardoor je soms maanden aan iets werkte dat de klant helemaal niet zo bedoeld had. Met agile methoden kun je sneller bijsturen waardoor de kans van slagen groter wordt. Maar dat is dan vooral of het product voldoet aan wat de klant verwacht.
Dat het achter die mooie user interface compleet rot is, heeft die immers niet door
Hoogstens dat het netter opzetten het ook eenvoudiger maakt om bij te sturen. Maar gezien er ook een hoop "cowboy programming" is, wordt dat ook vaak gemaskeerd. Oftewel "oh crap, nou ik fix het dit weekend wel" en dan zijn we er alsnog ipv dat we het netjes gaan opzetten.
@ThomasG Code review?
Ik ben eerder gewend dat je ver van elkaars code blijft, want zodra je het aanraakt is het van jou
"Oh dat? Daar heeft Pietje het laatst aan gewerkt"
Arme Pietje. De nieuwe probleemeigenaar. Pietje heeft 1 regel aangepast en nu is alles van hem.
Maar goed, dat is meer een bedrijfscultuur dingetje (of ontbreken daarvan). En dat iedereen het te druk heeft, dus je schuift het maar al te graag af.
Ik ben eerder gewend dat je ver van elkaars code blijft, want zodra je het aanraakt is het van jou
"Oh dat? Daar heeft Pietje het laatst aan gewerkt"
Arme Pietje. De nieuwe probleemeigenaar. Pietje heeft 1 regel aangepast en nu is alles van hem.
Maar goed, dat is meer een bedrijfscultuur dingetje (of ontbreken daarvan). En dat iedereen het te druk heeft, dus je schuift het maar al te graag af.
[ Voor 16% gewijzigd door Lethalis op 16-05-2024 15:14 ]
Ask yourself if you are happy and then you cease to be.
Dit is inderdaad hoe het vaak gaat. Het begint klein en onschuldig, maar het stapelt zich wel allemaal op. En vraagt iedereen zich af hoe het heeft kunnen gebeuren, want er is nu een probleem. En het trieste is dan dat het allemaal voorkomen had kunnen worden toen het nog klein en onschuldig was. Gelukkig kun je tegenwoordig een heleboel vrij eenvoudig afvangen met goede DevOps. Zo wordt veel bullshit bij ons automatisch teruggefloten.:
@ThomasG Code review?
Ik ben eerder gewend dat je ver van elkaars code blijft, want zodra je het aanraakt is het van jou
"Oh dat? Daar heeft Pietje het laatst aan gewerkt"
Arme Pietje. De nieuwe probleemeigenaar. Pietje heeft 1 regel aangepast en nu is alles van hem.
Maar goed, dat is meer een bedrijfscultuur dingetje (of ontbreken daarvan). En dat iedereen het te druk heeft, dus je schuift het maar al te graag af.
Wat doe je dan zoal daarmee?
Wij hebben wel wat Jenkins taken lopen, om o.a. te controleren of de build blijft werken met de laatste versie van de code. Daarnaast heb ik een taak gemaakt die de code scant op veelvoorkomende fouten, zoals wanneer mensen SQL uit management studio kopiëren en de naam van onze ontwikkeldatabase er nog in staat.
Dat lijkt enorm stupid, maar omdat iedereen toegang heeft tot de ontwikkeldatabase, rolt het niet eens uit de tests. Mijn taak vangt het af, zodat het niet bij de klant terechtkomt
Ook scan ik op bepaalde keywords die misschien niet supported zijn door oudere versies van SQL Server, zoals OPTIMIZE_FOR_SEQUENTIAL_KEY.Enfin, het scheelt ons werk met het maken van updates van nieuwe releases, uitleveringen die we 's avonds opnieuw kunnen gaan doen etc.
[ Voor 6% gewijzigd door Lethalis op 16-05-2024 20:35 ]
Ask yourself if you are happy and then you cease to be.
Je kunt het een ander wel redelijk mitigeren met zaken als renovate of dependabot, maar uiteindelijk zul je inderdaad wel enig onderhoud moeten plegen.
Daarom moet je in mijn ogen ook altijd wel echt de tijd nemen om heel goed na te denken over potentieel toekomstig onderhoud.
Zo hadden we bijvoorbeeld op een vorig project met relatief veel developers een vrij uitgebreide scaffolding ingericht waardoor vrijwel iedere idioot een project kon genereren met CI / CD, vulnerability scanning, basisopzet voor Gradle / Java en ga zo maar door. Supermakkelijk, want elke junior kon zonder te snappen wat ie deed de basis scaffolden en aan de slag gaan. Het gevolg was lekker snel nieuwe dingen uit de grond stampen en dus een totale wildgroei aan copy-pasta zonder enige kritische noot over nut en noodzaak. En dan zit je na twee jaar al in de onderhoudshel.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
)
* RobertMe kwam laatst een stuk code tegen waarin \n en \n\r werden vervangen door een <br>
spoiler:
Die laatste zal dus niet veel gedaan hebben, gezien het \r\n is. En dan zullen er ook geen Mac gebruikers zijn geweest, dat vroeger (pre MacOS X? / unix based) nog \r had.
Dat zijn enters:
Enters bestaan niet, alleen maar CR en/of LF bytes.
Heb even gecheckt, zowel losse \n als \r accepteert hij ook niet. Een \t accepteert hij wel, maar dan zegt ie weer dat er "ongeldige tekens" in je bericht staan
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Pff... Ik ben dan soms in staat om snel de API te hacken en kijken of de backend het ook verbied. Want f-that-noise.:
[...]
Dat zijn enters
Heb even gecheckt, zowel losse \n als \r accepteert hij ook niet. Een \t accepteert hij wel, maar dan zegt ie weer dat er "ongeldige tekens" in je bericht staan
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
De UWV-site is gewoon een verkapt opleidingstraject tot ICT'er.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Het zijn returns:
[...]
Dat zijn enters
Technisch gezien voegt een "return" een nieuwe regel toe aan wat je hebt ingetypt, en een "enter" voert in wat je hebt ingetypt. In bijvoorbeeld het Terminal/DOS tijdperk ging je met de enter toets verder (naar bijv. het volgende veld) en in web-formulieren werkt het vaak als submit, en met Return kreeg je een nieuwe regel in hetzelfde veld. Tegenwoordig wordt het allemaal door elkaar gebruikt, en vaak dezelfde toets op een toetsenbord. Al kun je, afhankelijk van de applicatie, met ctrl/shift/alt het gedrag van de toets van Enter naar Return veranderen, of andersom. Maar: als er een ↵ op je toets staat is het eigenlijk een Return en geen Enter (⌅).
Nee, het is een carriage return én een line feed, en geen "return". Want als je terug gaat naar typemachines dan zorgt de carriage return ervoor dat je weer links typed (maar over de huidige regel heen) en de line feed dat het papier "door schuift" (/verder draait) zodat je op een volgende regel typt. Vandaar dus ook de \r\n die beide "acties" uitdrukt.:
[...]
Het zijn returns
Maar: als er een ↵ op je toets staat is het eigenlijk een Return en geen Enter (⌅).
Eigenlijk zei ik alles al, met slechts 10 worden totaal. Maar je kan het idd ingewikkelder maken door als referentie een specifiek DOS- en keyboardtijdperk erbij te halen. 
Dan nog was de klacht van .oisyn dat UWV over die specifieke bytes valt. Sites weten gelukkig niet of er ‘enter’ of ‘return’ als opschrift op het toetsenbord staat.
Dan nog was de klacht van .oisyn dat UWV over die specifieke bytes valt. Sites weten gelukkig niet of er ‘enter’ of ‘return’ als opschrift op het toetsenbord staat.
{signature}
Volgens mij is het systeem van de UWV geschreven in COBOL met een custom character encoding om bytes te besparen, en daar zitten in ieder geval geen +, \t, \r en \n in:
Eigenlijk zei ik alles al, met slechts 10 worden totaal. Maar je kan het idd ingewikkelder maken door als referentie een specifiek DOS- en keyboardtijdperk erbij te halen.
Dan nog was de klacht van .oisyn dat UWV over die specifieke bytes valt. Sites weten gelukkig niet of er ‘enter’ of ‘return’ als opschrift op het toetsenbord staat.
Of er zit een web application firewall tussen die van alles denkt dat het een aanval is:
[...]
Volgens mij is het systeem van de UWV geschreven in COBOL met een custom character encoding om bytes te besparen, en daar zitten in ieder geval geen +, \t, \r en \n in
Of gewoon een domme validatie check omdat iemand hoog in de boom een set aan regels in een excelsheet heeft gezet met wat er aan input validatie moet gebeuren, en die dan letterlijk geimplementeerd zijn zonder na te denken:
[...]
Of er zit een web application firewall tussen die van alles denkt dat het een aanval is
Als dit soort overheidsinstanties van iets wel te veel hebben dan is het wel 'belangrijke' mensen die de hele dag lullen over werk zonder ooit daadwerkelijk werk te verzetten.
:
[...]
Of gewoon een domme validatie check omdat iemand hoog in de boom een set aan regels in een excelsheet heeft gezet met wat er aan input validatie moet gebeuren, en die dan letterlijk geimplementeerd zijn zonder na te denken
Als dit soort overheidsinstanties van iets wel te veel hebben dan is het wel 'belangrijke' mensen die de hele dag lullen over werk zonder ooit daadwerkelijk werk te verzetten.
Members only:
Alleen zichtbaar voor ingelogde gebruikers.
Inloggen
Hoi en welkom bij de volgende editie van mijn UWV-rant-blog hier in de devschuur coffee corner
Ik zit dus nu in een teams meeting voor een welkomstbijeenkomst. Dan kun je dus eventueel vragen stellen via de chat. Ware het niet dat ze vergeten zijn de chat toe te staan voor gasten, dus niemand ziet die chat.
"Ik zie dat er nog steeds geen vragen zijn. Dan gaan we gewoon lekker verder! Schroom niet om vooral vragen te stellen via de chat"
Ik zit dus nu in een teams meeting voor een welkomstbijeenkomst. Dan kun je dus eventueel vragen stellen via de chat. Ware het niet dat ze vergeten zijn de chat toe te staan voor gasten, dus niemand ziet die chat.
"Ik zie dat er nog steeds geen vragen zijn. Dan gaan we gewoon lekker verder! Schroom niet om vooral vragen te stellen via de chat"
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.