:strip_icc():strip_exif()/u/53213/crop57ace20969734.jpeg?f=community)
☎ Telecommunicatie van vroeger
🚅Alles over spoor en treintjes
/u/12668/hydra.png?f=community)
Volgens mij bedoelde 'ie het als eenmalige actie. Lijkt me simpeler om de fout uit 't script te halen dan om een aparte job te starten om die fout te corrigeren
https://niels.nu
:strip_icc():strip_exif()/u/206968/325134.jpg?f=community)
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
Scary stuff.
Ten eerste killt het potentieel - alle - php scripts op het systeem.
Ten tweede neemt het ook alles mee dat toevallig met php begint.
Ik zou filteren op de naam van het script, zoals "waarom-is-die-trein-er-nou-niet.php"
Ask yourself if you are happy and then you cease to be.
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
En terecht
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.
Zou inderdaad standaard scheduled moeten draaien op servers elke seconde ofzo.:
[...]
En terecht
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Klopt:
Scary stuff.
Ten eerste killt het potentieel - alle - php scripts op het systeem.
Ten tweede neemt het ook alles mee dat toevallig met php begint.
Ik zou filteren op de naam van het script, zoals "waarom-is-die-trein-er-nou-niet.php"
Zie daarom ook mijn verbeterde post Matis in "cURL requests zonder timeout in cronjobs"
If money talks then I'm a mime
If time is money then I'm out of time
:strip_icc():strip_exif()/u/246777/crop5665347035c66.jpeg?f=community)
Houden jullie het nog een beetje uit met de hitte?
Ik ben zo blij dat mijn werkgever paar jaar geleden heeft geïnvesteerd in een airco systeem! Nu is het makkelijk uit te houden (alleen dan naar huis fietsen is zo zwaar).
Denk ook zonder de airco dat het op het kantoor bloedheet was geworden (kantoor zit aan zonkant, en dan hebben wij ook nog dat 'anti-inkijkfolie' dat veel hitte binnenhoudt)
Ik ben zo blij dat mijn werkgever paar jaar geleden heeft geïnvesteerd in een airco systeem! Nu is het makkelijk uit te houden (alleen dan naar huis fietsen is zo zwaar
).Denk ook zonder de airco dat het op het kantoor bloedheet was geworden (kantoor zit aan zonkant, en dan hebben wij ook nog dat 'anti-inkijkfolie' dat veel hitte binnenhoudt)
:strip_icc():strip_exif()/u/510323/crop5c49c55cb1a09_cropped.jpeg?f=community)
Met de prive airco unit die ik heb op het werk houd ik het altijd vol:
Houden jullie het nog een beetje uit met de hitte?
Ik ben zo blij dat mijn werkgever paar jaar geleden heeft geïnvesteerd in een airco systeem! Nu is het makkelijk uit te houden (alleen dan naar huis fietsen is zo zwaar
Denk ook zonder de airco dat het op het kantoor bloedheet was geworden (kantoor zit aan zonkant, en dan hebben wij ook nog dat 'anti-inkijkfolie' dat veel hitte binnenhoudt)
In 2017 is een nieuwe airco unit op het dak gezet boven mijn werkplek. De bedoeling was om hierop 8 kantoren en een groot magazijn aan te sluiten. Echter ging dit allemaal niet door door te hoge kosten, vandaar dat ik nu een hele airco unit voor mijzelf heb
[ Voor 19% gewijzigd door BladeSlayer1000 op 05-06-2019 19:54 ]
Van de vier werklocaties heb ik er twee met uitstekende airco, eentje gaat wel en een is vrij matig.:
Houden jullie het nog een beetje uit met de hitte?
Ik ben zo blij dat mijn werkgever paar jaar geleden heeft geïnvesteerd in een airco systeem! Nu is het makkelijk uit te houden (alleen dan naar huis fietsen is zo zwaar
Denk ook zonder de airco dat het op het kantoor bloedheet was geworden (kantoor zit aan zonkant, en dan hebben wij ook nog dat 'anti-inkijkfolie' dat veel hitte binnenhoudt)
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Wij zitten in een gebouw eind jaren 50 met buitenmuren van ruim 80 cm dik. Wij hebben het eerder te koud dan te warm. Dat was vorig jaar in de zomer wel een grote overgang. Van krap aan 20.5 graden naar 34 zodra je buiten komt. We hadden zelfs de klimaatbeheersing op verwarmen gezet, omdat het toch wel koud was met de zomerse kledij binnen
:strip_icc():strip_exif()/u/148505/31bb5b263ef71bb4d5751e9a89035105.jpeg.jpg?f=community)
Zijn er dan nog kantoren plekken waar geen airco is?:
Houden jullie het nog een beetje uit met de hitte?
Ik ben zo blij dat mijn werkgever paar jaar geleden heeft geïnvesteerd in een airco systeem! Nu is het makkelijk uit te houden (alleen dan naar huis fietsen is zo zwaar
Denk ook zonder de airco dat het op het kantoor bloedheet was geworden (kantoor zit aan zonkant, en dan hebben wij ook nog dat 'anti-inkijkfolie' dat veel hitte binnenhoudt)
Going for adventure, lots of sun and a convertible! | GMT-8
:strip_exif()/u/91205/avator_pavo.gif?f=community)
Welke hitte?:
Houden jullie het nog een beetje uit met de hitte?
Ik ben zo blij dat mijn werkgever paar jaar geleden heeft geïnvesteerd in een airco systeem! Nu is het makkelijk uit te houden (alleen dan naar huis fietsen is zo zwaar
Denk ook zonder de airco dat het op het kantoor bloedheet was geworden (kantoor zit aan zonkant, en dan hebben wij ook nog dat 'anti-inkijkfolie' dat veel hitte binnenhoudt)
]|[ Apple Macbook Pro Retina 13" ]|[
:strip_icc():strip_exif()/u/36083/crop5dca9e34ce091_cropped.jpeg?f=community)
/u/243953/crop56f55a7bcf291.png?f=community)
:strip_icc():strip_exif()/u/68028/crop5c0ef8207f712_cropped.jpeg?f=community)
Wij zijn het ook aan het overwegen voor wat bestaande REST / SOAP APIs. Die zijn vooral gericht op redelijk flexibel zoeken en dan is REST niet ideaal. Je gaat toch wat gekunsteld zaken doen om het in een resource structuur te rammen.
SOAP is sowieso ellende.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Juist dat is het stuk waar ik vanaf wil. Dat werkt namelijk niet lekker met de dev middleware.
Ben er nog op aan het puzzelen.
Je moet sowieso altijd heel goed oppassen met welke API dan ook
Infinite recursion zie ik niet meteen als een probleem, door gewoon je types goed te definieren.
Bijvoorbeeld, ik heb als definitie:
code:
1
2
3
4
5
| type Entity {
id: UUID,
name: String,
children: [Entity]
} |
Dan zou je infinite recursion krijgen als de client z'n best doet. Maar ik los dat gewoon zo op:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| type Entity {
id: UUID,
name: String,
children: [EntityRef]
}
type EntityRef {
id: UUID,
name: String
}
type Query {
entity(id: UUID): Entity
entities(ids: [UUID]): [Entity]
} |
Dan kan de client in meerdere stappen de data ophalen, heel bewust. Onder water verwijzen EntityRef en Entity letterlijk naar dezelfde class, maar andere fields zijn beschikbaar.
In ons geval zijn we door de jaren heen van een single-user desktop app naar een multiuser webapp gegaan. De server draait nu de oude desktop code grotendeels in Kotlin welke serialized wordt als XML. Ons data model is echt een graph. Hele hiërarchieën, die ook nog eens horizontaal naar elkaar toe linken. Daarnaast genereren we ook nog eens SVG's aan de hand van de data in sommige gevallen.
Ons hele data-model is prima werkbaar vanuit Kotlin aangezien het typesafe is en je makkelijk door de objecten heen kan lopen.
Echter, de webapp is JS. We hebben dus meerdere endpoints die allemaal doorsnedes van de data in XML terugsturen. Door ons complexe datamodel krijg je dus hele complexe requests, met allemaal parameters die je aan en uit kan zetten om vooral niet teveel data terug te krijgen. Dit werkt helemaal door in de XML serialization. Onze projecten kunnen makkelijk 100MB aan ruwe XML worden, wat niet wenselijk is.
Dus, middels GraphQL kunnen we nu ons Kotlin data-model heel mooi mappen naar een nette type hierarchy in GraphQL, waardoor de client zo granulair mogelijk de data op kan halen. Daarnaast definieren we dus gewoon types als 'SVG':
code:
1
2
3
4
5
6
7
8
9
10
11
12
| type Organogram {
name: String!
image: SVG!
}
type SVG {
width: Float,
height: Float,
url: URL,
contents: String,
base64: ByteArray
} |
ls een client dus een SVG oproept kan ie ervoor kiezen of ie de viewBox krijgt en de base64. Maar als ie de URL ophaalt is de gerenderde SVG tijdelijk beschikbaar onder een endpoint op de server en met contents krijgt de client puur de SVG-dom als string. Etc. Etc Etc
Erg leuk spul.
[ Voor 16% gewijzigd door armageddon_2k1 op 06-06-2019 12:13 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Ik begin echt een hekel te krijgen aan contrib commits op Webpack onderdelen.
Zit nu midden in een pull request samen met een collega, wat al 2 maanden sleept.
Initieel krijg je gewoon geen antwoord en moet je nog eens extra gaan roepen of er iemand wil gaan kijken.
Vervolgens accepteren ze de pull-request niet omdat deze ook een aantal zaken aanpast die ze onder "chore-jobs" scharen. Maar ja; als je een stokoude pre-commit hook hebt die kapot is en commits blokkeert; wat dan? Die zul je toch moeten fixen om überhaupt een PR op te zetten, niet waar?
Na een hoop gezever alles er toch nog doorgefrut gekregen. (Creatief zijn met o.a. git reset en git push --force om enkel de wijzigingen aan die hook er after-the-fact weer af te slopen...)
Krijgt mijn collega vervolgens - weer weken later - commentaar dat deze PR 'bestaand gedrag aanpast' (uh nee... dat doet het niet) en dat het dingen stuk zou maken.
Wij: Wat dan?
Zij: Nou gewoon het maakt dingen stuk.
Wij: Ja, maar wat dan? De unit-tests zijn allemaal groen.
Zij: Ja; in de integratie-tests gaat er allemaal spul stuk.
Wij: Welke integratie-tests? Kun je die ergens laten zien? Of beschikbaar maken om te draaien?
Zij: Ja, nee, ja... uh... da's allemaal moeilijk op te zetten en niet voor gewone developers bedoeld.
Wij:
Echt. Het verbaasd me totaa-----l niets dat er aan die specifieke loader sinds 2017 niets meer gewijzigd is, als de aangewezen maintainer er zo mee omspringt.
Fucking hell zeg...
Webpack: Fantastische tool. Kut development team.
Denk dat we tegen betere etiquette in toch maar gewoon een fork aan gaan houden en een better-<foo>-loader package gaan maken.
Zit nu midden in een pull request samen met een collega, wat al 2 maanden sleept.
Initieel krijg je gewoon geen antwoord en moet je nog eens extra gaan roepen of er iemand wil gaan kijken.
Vervolgens accepteren ze de pull-request niet omdat deze ook een aantal zaken aanpast die ze onder "chore-jobs" scharen. Maar ja; als je een stokoude pre-commit hook hebt die kapot is en commits blokkeert; wat dan? Die zul je toch moeten fixen om überhaupt een PR op te zetten, niet waar?
Na een hoop gezever alles er toch nog doorgefrut gekregen. (Creatief zijn met o.a. git reset en git push --force om enkel de wijzigingen aan die hook er after-the-fact weer af te slopen...)
Krijgt mijn collega vervolgens - weer weken later - commentaar dat deze PR 'bestaand gedrag aanpast' (uh nee... dat doet het niet) en dat het dingen stuk zou maken.
Wij: Wat dan?
Zij: Nou gewoon het maakt dingen stuk.
Wij: Ja, maar wat dan? De unit-tests zijn allemaal groen.
Zij: Ja; in de integratie-tests gaat er allemaal spul stuk.
Wij: Welke integratie-tests? Kun je die ergens laten zien? Of beschikbaar maken om te draaien?
Zij: Ja, nee, ja... uh... da's allemaal moeilijk op te zetten en niet voor gewone developers bedoeld.
Wij:
Echt. Het verbaasd me totaa-----l niets dat er aan die specifieke loader sinds 2017 niets meer gewijzigd is, als de aangewezen maintainer er zo mee omspringt.
Fucking hell zeg...
Webpack: Fantastische tool. Kut development team.
Denk dat we tegen betere etiquette in toch maar gewoon een fork aan gaan houden en een better-<foo>-loader package gaan maken.
[ Voor 5% gewijzigd door R4gnax op 06-06-2019 19:40 ]
Maar het is open source dus sowieso goed
Wel herkenbaar. Heb iets dergelijks aan 't handje gehad met Spring HATEOAS. Maintainer daarvan reageerde als een flinke eikel op eigenlijk alle communicatie dus uiteindelijk in overleg met de andere devs op dat project hebben we het eruit gesloopt en vervangen voor een simpele eigen library. Normaal probeer ik te voorkomen dat ik een wiel opnieuw uitvindt, maar soms is het nodig.
Wel herkenbaar. Heb iets dergelijks aan 't handje gehad met Spring HATEOAS. Maintainer daarvan reageerde als een flinke eikel op eigenlijk alle communicatie dus uiteindelijk in overleg met de andere devs op dat project hebben we het eruit gesloopt en vervangen voor een simpele eigen library. Normaal probeer ik te voorkomen dat ik een wiel opnieuw uitvindt, maar soms is het nodig.
https://niels.nu
/u/122874/crop5e26d7a209cd1_cropped.png?f=community)
Sowieso altijd goed bij de keuze van een framework/library hoe (snel) issues op Github opgelost worden en wie de maintainers zijn. In het geval van Webpack heb je niet zo veel keuze kwa lib's maar als je die wel hebt is het goed om het mee te nemen.
Heb tot nu toe alleen nog maar positieve ervaringen met het melden van issue's en PR's Uiteindelijk doet iedereen ook gewoon z'n best en hebben maintainers van grote projecten het gewoon druk
Heb tot nu toe alleen nog maar positieve ervaringen met het melden van issue's en PR's
Uiteindelijk doet iedereen ook gewoon z'n best en hebben maintainers van grote projecten het gewoon druk
[ Voor 13% gewijzigd door GrooV op 07-06-2019 08:46 ]
/u/262310/ava.png?f=community)
En uiteindelijk zegt dat ook niets.:
Sowieso altijd goed bij de keuze van een framework/library hoe (snel) issues op Github opgelost worden en wie de maintainers zijn. In het geval van Webpack heb je niet zo veel keuze kwa lib's maar als je die wel hebt is het goed om het mee te nemen.
Heb tot nu toe alleen nog maar positieve ervaringen met het melden van issue's en PR's
Ik heb helaas soms heel diep in bepaalde materie gezeten en dan vind je soms bugs die van een bepaald niveau zijn dat eigenlijk niemand nog snapt wat er gebeurd. Dat was voor een heel goed maintained project met een grote (zelfs betaalde) core aan developers.
Ten eerste kan je het dan vergeten dat iemand zelf een fix maakt; want A: niemand snapt het en B: niemand boeit het.
En dan heb je zelf wat gemaakt maar dan blijft je PR daar open staan want A: niemand snapt het en B: niemand wilt zich er aan branden
Ik heb dit pas gefixed bij een soort community event in Duitsland waarbij ik domweg naar die core devs was gelopen, een stuk of 6 bij de lurven had gepakt en een PoC heb laten zien. Toen semi iemand "geforceerd" om mijn PR te approven
Het was super awkward en mijn eigen collega's lagen dubbel, maar na meer dan een half jaar had ik eindelijk mijn fix in de master zitten.
:strip_exif()/u/80759/monstermania_small.gif?f=community)
Mooi weer om de loonslaaf rustig binnen te houden toch ?:
Ik dacht het zomer was
De zomer begint pas vrijdag 21 juni:
Ik dacht het zomer was
Goed voor de natoer jongen!:
Ik dacht het zomer was
]|[ Apple Macbook Pro Retina 13" ]|[
Ik maar denken dat het onderstaande (Entity Framework):
Werd omgeschreven naar:
Maar niet dus
SQL Profiler vol met losse delete statements.
*schrijft maar weer stored procedures*
C#:
1
2
3
| dbContext.Tabel.RemoveRange( dbContext.Tabel.Where(row => row.Year == year) ); |
Werd omgeschreven naar:
SQL:
1
| DELETE FROM Tabel WHERE Year = @year |
Maar niet dus
SQL Profiler vol met losse delete statements.*schrijft maar weer stored procedures*
:strip_icc():strip_exif()/u/87691/avatar_alex.jpg?f=community){kind=avatar}
Dat is inderdaad één van de (vele) tekortkomingen en onhebbelijkheden van Entity Framework. 
We are shaping the future
:strip_icc():strip_exif()/u/302903/logo.jpg?f=community){kind=logo}
/u/56000/neuken.png?f=community)
Is dat serieus nog steeds zo? Ik gebruik Entity Framework al jaren niet meer, mede door dit soort dingen.:
Ik maar denken dat het onderstaande (Entity Framework):
C#:
Werd omgeschreven naar:
SQL:
Maar niet dus
*schrijft maar weer stored procedures*
:strip_icc():strip_exif()/u/148671/skyaero_small_tweakers.jpg?f=community)
EF6 of EF Core?:
Ik maar denken dat het onderstaande (Entity Framework):
C#:
Werd omgeschreven naar:
SQL:
Maar niet dus
In EF Core zou RemoveRange() een single trip moeten zijn.
Pfffffffffff...
* Matis heeft nu weer iets moois: De volgorde waarin unit tests worden gedraaid is afhankelijk van de uitkomst van de desbetreffend tests.
We maken (in PHP) een SoapClient aan. Wanneer deze een ongeldige wsdl krijgt, raakt het systeem / de unit tests zo over de zeik dat 1 specifieke volgende test niet goed gaat
Los draaien beide tests goed, ook de tussenliggende tests zijn prima, alleen die twee specifieke tests samen in deze volgorde laat het systeem stuk gaan...
Het resulteert dan in een
* Matis heeft nu weer iets moois: De volgorde waarin unit tests worden gedraaid is afhankelijk van de uitkomst van de desbetreffend tests.
We maken (in PHP) een SoapClient aan. Wanneer deze een ongeldige wsdl krijgt, raakt het systeem / de unit tests zo over de zeik dat 1 specifieke volgende test niet goed gaat
Los draaien beide tests goed, ook de tussenliggende tests zijn prima, alleen die twee specifieke tests samen in deze volgorde laat het systeem stuk gaan...
Het resulteert dan in een
League\Csv\CannotInsertRecord : Unable to write record to the CSV document
[ Voor 10% gewijzigd door Matis op 14-06-2019 10:46 ]
If money talks then I'm a mime
If time is money then I'm out of time
Interessant. Iemand ook een e-mail gehad over "20 Juni | Breda | Accelerating Enterprise, Web & Mobile Development Event"?
Dat event is niet interessant, dat kan me gestolen worden. Wat interessant is, is dat het is verstuurd naar een emailadres dat ik puur en alleen gebruikt heb voor Fiddler. Lekker is dat. Dus dan browsen we even naar https://docs.telerik.com/fiddler/PersonalDataProtection
.edit: oh toch niet. Het event is van Progress zelf, en dat is blijkbaar tegenwoordig ook de eigenaar van Fiddler.
Dat event is niet interessant, dat kan me gestolen worden. Wat interessant is, is dat het is verstuurd naar een emailadres dat ik puur en alleen gebruikt heb voor Fiddler. Lekker is dat. Dus dan browsen we even naar https://docs.telerik.com/fiddler/PersonalDataProtection
Leugens, dus.
.edit: oh toch niet. Het event is van Progress zelf, en dat is blijkbaar tegenwoordig ook de eigenaar van Fiddler.
[ Voor 5% gewijzigd door .oisyn op 14-06-2019 10:51 ]
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.
Melding maken van hack/datalek
edit nav oisyn edit: het kan heel leuk onderdeel zijn van een reeks aan bedrijven, maar het bedrijf is eigenaar van de gegevens. Een zusterbedrijf mag dat niet zo maar gebruiken volgens mij.
[ Voor 14% gewijzigd door Gropah op 14-06-2019 10:53 ]
Ik weet het niet, maar misschien is het een dochterbedrijf? En dan kan ik me wel voorstellen dat het mag:
[...]
Melding maken van hack/datalek
edit nav oisyn edit: het kan heel leuk onderdeel zijn van een reeks aan bedrijven, maar het bedrijf is eigenaar van de gegevens. Een zusterbedrijf mag dat niet zo maar gebruiken volgens mij.
De wet van Murphy: Alles wat fout kan gaan zal fout gaan.
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.
EF6 inderdaad.
M'nee, queries schud ik zo uit mijn mouw, dat is het probleem niet. Zelf vind ik het wel lekker werken wanneer types uitgegenereerd worden. Zo hebben wij ook een tool die voor ons types uitgenereerd net zoals WCF dat doet, maar dan voor TypeScript (op basis van een interface in C# een request/response structuur genereren in TS). Uiteraard zijn er ondertussen ook wel tools beschikbaar die dat ook kunnen, echter was dat niet zo aan het begin van het TypeScript-tijdperk. Werkt wel goed, één keer een definitie schrijven, en daarna gewoon delen tussen de talen. Zo dus ook bij SQL (Server) en C#. Het grootste deel van code kloppen is toch het om-mappen van data of het tonen ervan.
Ben blij dat ik op het moment al die ORM-ellende kan vermijden.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ik vind "al die ORM-ellende" niet zo'n ellende anders hoor. Maar hoe vermijdtje het dan?:
Ben blij dat ik op het moment al die ORM-ellende kan vermijden.
Door simpelweg de de R uit je systemen te halen.
Het is niet altijd aan te raden, maar als het kan scheelt het wel een hoop gedoe.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Vandaag eens een deel van mijn code herschreven, maar er niet bij stil gestaan om het tussendoor te testen 
Gevolg; een deel van de website functioneerde niet meer zoals gewenst
Gevolg; een deel van de website functioneerde niet meer zoals gewenst
Euhm, wat heb je dan gedaan? Gewoon een paar uur zitten typen ervanuitgaande dat alles dat je doet foutloos is?:
Vandaag eens een deel van mijn code herschreven, maar er niet bij stil gestaan om het tussendoor te testen
Gevolg; een deel van de website functioneerde niet meer zoals gewenst
Engineering is like Tetris. Succes disappears and errors accumulate.
:strip_icc():strip_exif()/u/116726/crop5e3ee297a8a03_cropped.jpeg?f=community)
:
Vandaag eens een deel van mijn code herschreven, maar er niet bij stil gestaan om het tussendoor te testen
Gevolg; een deel van de website functioneerde niet meer zoals gewenst
Testen, version control en ga zo maar door zijn niet voor niets een integraal onderdeel van elk fatsoenlijk softwareproject.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Ik zat een film te kijken en tergelijk code te herschrijven, waardoor ik niet in de gaten had hoeveel tijd vergaan was en hoeveel ik al had veranderd
Gelukkig niet in productie
[ Voor 24% gewijzigd door BladeSlayer1000 op 16-06-2019 17:56 ]
Daarom bij refactoren altijd zorgen dat de randen automatisch worden afgetest, zodat je ongestraft de binnenkant kunt herschrijven.:
[...]
Ik zat een film te kijken en tergelijk code te herschrijven, waardoor ik niet in de gaten had hoeveel tijd vergaan was en hoeveel ik al had veranderd
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Dat je dat kan 2 dingen tegelijk:
[...]
Ik zat een film te kijken en tergelijk code te herschrijven, waardoor ik niet in de gaten had hoeveel tijd vergaan was en hoeveel ik al had veranderd
Als ik dat doe mis ik of de film of ik kan alle code dat ik die avond heb geschreven weggooien!
:strip_exif()/u/13818/episodebutler_60x60.gif?f=community)
Nou, z'n post gaf al aan dat dat voor hem ook geldt. En hij heeft de film blijkbaar wel kunnen volgen
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
hmm zitten er daarom zoveel transgender-fluoride types in de IT ... dat ze denken dat zich vrouw noemen ze in ineens helpt bij het wel kunnen multi-tasken ?
:strip_icc():strip_exif()/u/105199/crop5cb76c6d18020_cropped.jpeg?f=community)
Is dat een mannetje-vrouwtje-nicht-typje met erg glimmende tanden?:
hmm zitten er daarom zoveel transgender-fluoride types in de IT ... dat ze denken dat zich vrouw noemen ze in ineens helpt bij het wel kunnen multi-tasken ?
:strip_icc():strip_exif()/u/734655/crop6390c3acd41c6_cropped.jpg?f=community)
Dat vrouwen beter zijn in multi-tasken dan mannen is natuurlijk een leugen. Wij "mannen" verwachten gewoon dat vrouwen twee keer zo veel doen als wij mannen. Daarom hebben we die leugen de wereld in geholpen.:
hmm zitten er daarom zoveel transgender-fluoride types in de IT ... dat ze denken dat zich vrouw noemen ze in ineens helpt bij het wel kunnen multi-tasken ?
Gezien mijn bovenstaande opmerking als kwetsend ervaren kan worden...
Ik denk/hoop dat er binnen de IT zoveel ruimte is voor alle soorten mensen is omdat wij individuen meer beoordelen op hun vaardigheden en resultaten dan op hun gedrag. Hierdoor krijgen individuen meer ruimte om zichzelf te zijn en kunnen ze zich ook makkelijker als persoon ontwikkelen.
En laten we eerlijk zijn: Hoewel onze sector op dit moment voornamelijk bestaat uit mannen hebben wij ontzettend veel te danken gehad aan individuen die niet in de "klassieke" man/vrouw rol vallen.
Alan Turing, Sophie Wilson, Mary Ann Horton en vele andere hebben aan de krib gestaan van onze sector en zijn uitzonderlijke individuen met een ongebruikelijke achtergrond.
"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
Trappen ze er toch allemaal mooi in:
[...]
Dat vrouwen beter zijn in multi-tasken dan mannen is natuurlijk een leugen. Wij "mannen" verwachten gewoon dat vrouwen twee keer zo veel doen als wij mannen. Daarom hebben we die leugen de wereld in geholpen.
Niet om jou aan te vallen maar mijn ervaring is dat men ORM ellende vindt op het moment dat ze de meest bizare meuk uitvoeren omdat of A ) de dateset krom is of B ) de applicatie krom is.:
Ben blij dat ik op het moment al die ORM-ellende kan vermijden.
Vandaar misschien ook jOOQ, ze zeggen niet voor niets: Je database eerst, of dat voor een nieuwe applicatie of legacy is
M.a.w. : Hoe krom je database ook is, het werkt. Mooi principe natuurlijk maar soms verhult het ook juist je echte probleem.
[ Voor 25% gewijzigd door Douweegbertje op 17-06-2019 06:23 ]
In zekere zin klopt het wel. Vrouwen doen veel dingen tegelijk, maar hebben daardoor minder focus per taak:
[...]
Trappen ze er toch allemaal mooi in
Dat is ook deels de reden waarom vrouwen vooral voor socialere beroepen kiezen, en mannen gemiddeld genomen beter zijn op technisch vlak. En het een is niet per definitie beter dan het ander. Anders we het met computers vergelijken zijn mannen een CPU en vrouwen meer een GPU.
In mijn geval meer omdat ik bijvoorbeeld met optimalisatie van complexe queries zit en dan zit ORM vaak eerder in de weg dan dat het helpt. Zoals ik in mijn vervolgpost aangaf is ORM best handig als je veelal complexe writes doet, maar daar zijn ook andere oplossingen denkbaar. Uiteindelijk is het probleem ook vaak inderdaad dat je een systeem hebt waarbij je bijvoorbeeld zowel complexe (real-time) writes als complexe reads op één datamodel probeert te doen. Dat vinden de meeste RDBMsen niet zo heel leuk.:
[...]
Niet om jou aan te vallen maar mijn ervaring is dat men ORM ellende vindt op het moment dat ze de meest bizare meuk uitvoeren omdat of A ) de dateset krom is of B ) de applicatie krom is.
Vandaar misschien ook jOOQ, ze zeggen niet voor niets: Je database eerst, of dat voor een nieuwe applicatie of legacy is
Daarom zit ik nu ook in een project om een complete rebuild / cloudmigratie te doen waarbij we ook veel meer gebruik maken van gescheiden schrijf- en leesmodellen ook in verschillende vormen van opslagtechnologie, of dat nou SQL, NoSQL, search engine, in-memory cache of wat dan ook is zolang het maar het juiste gereedschap voor de klus is.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Echt parellalisme is het toch niet ?:
[...]
In zekere zin klopt het wel. Vrouwen doen veel dingen tegelijk, maar hebben daardoor minder focus per taak
Is het niet meer Async met callbacks dan ?
Zolang het I/O waiting is dan winnen ze er wat mee, maar als het diehard number chrunching is niet en kan het een negatieve impact hebben ?
Daarnaast is het door de callback nesting volstrekt onmogelijk om er nog iets van te begrijpen laat staan er een handleiding van te maken
.Moet nu wel oppassen, straks heb ik weer een bias, krijg ik er net als de TNO meneer dit weekend problemen mee
Ik bedoelde meer dat vrouwen hun focus beter kunnen verdelen over meerdere dingen tegelijk. Een gemiddelde man heeft daar meer moeite mee. Mannen zijn daarentegen gemiddeld wel beter in het gebruiken van al hun focus op een onderwerp.:
[...]
Echt parellalisme is het toch niet ?
Is het niet meer Async met callbacks dan ?
Zolang het I/O waiting is dan winnen ze er wat mee, maar als het diehard number chrunching is niet en kan het een negatieve impact hebben ?
Daarnaast is het door de callback nesting volstrekt onmogelijk om er nog iets van te begrijpen laat staan er een handleiding van te maken
Moet nu wel oppassen, straks heb ik weer een bias, krijg ik er net als de TNO meneer dit weekend problemen mee
En dan zijn er vast mensen die zeggen dat dát seksisme e.d. is, maar dat is om evolutionaire redenen nu eenmaal zo (uitzonderingen daargelaten). Een gevolg daarvan is dat mannen en vrouwen in andere gebieden uitblinken. En het een is dus niet perse beter dan het ander.
Da's een heel slecht voorbeeld. Een GPU doet eigenlijk helemaal niet zoveel verschillende dingen tegelijk. Hij doet heel veel dezelfde dingen tegelijk
. Eigenlijk zijn vrouwen dan meer een multicore CPU, en mannen kunnen alleen multitasken door preemptive scheduling
[ Voor 16% gewijzigd door .oisyn op 17-06-2019 11:54 ]
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.
Complexe objectstructuren opslaan is een van de dingen waar een ORM relatief goed in is. Maar in mijn ervaring zie je die usecase veel minder dan projecties op je data. En daar gaan ORMs vaak de mist in.
ORMs zijn wat mij betreft een beetje gebaseerd op het idee van een enkel 'model' in memory dat van en naar een relationeel model gemapt moet worden. En da's in de huidige wereld van REST (micro) services meestal niet erg accuraat. Heb danook in de laatste 10 ofzo jaar niet of nauwelijks met ORMs gewerkt, en ik mis ze ook niet.
Of je bent gewoon zo ver in ervaring met verschillende manier van zaken aanpakken dat doorhebt dat ORMs een abstractielaag leggen op je data, die zowel voor als nadelen heeft, zonder te moeten doen alsof mensen die er anders over denken slechte programmeurs zijn.
Niet alleen dat. Juist als je netjes, volgens de regels, je data modelleert heb je al snel te maken met compound keys. Die zijn al vrij lastig te modelleren in je code, je hebt dan meestal een aparte key class per compound key nodig. Dat in je code 'netjes' aan elkaar hangen levert je al snel een flinke annotation hell op. Da's dan nog voordat je uberhaupt gaat testen wat je ORM er van maakt onderwater; je bent dan misschien geen SQL aan het schrijven, je bent wel een hoop code aan het schrijven in plaats van SQL, waarna je ook nog eens moet gaan kijken wat de ORM er van bakt kwa SQL. Als dat niet klopt kun je vaak alsnog direct de SQL schrijven, of de code aanpassen op de SQL.
Dit terwijl SQL ongeveer de meest expressieve taal is die je maar kunt bedenken: het is een declarative taal, dus je vertelt de server alleen maar wat je wil. In plaats van in code waarin je moet vertellen dat de machine allemaal moet doen.
Het enige wat die ORMs dus nog voor je oplossen is het mappen van de resultaten naar objecten. Daar heb je prima light-weight rowmappers voor. Dan heb je niet de problemen van de abstractielaag, want je schrijft direct SQL, maar wel het voordeel dat de software de kolommen rechtstreeks in de juiste velden van je objecten propt.
Maarja. Ik zal wel een slechte programmeur zijn...
Of we blijven gewoon weg van het hangen van dit soort eigenschappen aan een sekse. Nog makkelijker en neigt een stuk minder naar seksisme
[ Voor 59% gewijzigd door Hydra op 17-06-2019 15:02 ]
https://niels.nu
Ik weet niet of je nu bewust verzint wat ik heb gezegd maar dat laatste is verre van wat ik zei.
Nogmaals: mijn ervaring, is dat mensen die er over zeuren, juist op zoveel andere vlakken het verpesten waardoor je maar ORM de schuld geeft "want het kan X niet". Het motto van jOOQ word inherent ook zo misbruikt. Zoals ik zei; "het maakt niet uit hoe krom het is, het werkt" - wat eigenlijk hetzelfde is als PHP met loosely typed, maar nu gaan we opeens wel in de verdediging hoe goed het is om structuur te vergeten
Want naar mijn inziens is ORM maar net een middel waar je niet op hoeft te zeuren aangezien het compleet logisch is om basis meuk via je ORM te doen en je special shit buiten ORM om voor de bulks, custom optimalisaties, etc.
Waar je mij wel op mag quoten als het gaat om "slechte programmeurs"; de gene die ontiegelijk lopen te ranten en te bitchen over prima technieken, omdat ze helemaal misbruikt worden. Overigens niet dat het hier in de devschuur daar nou over ging
:strip_exif()/u/73955/foxavatar-60.gif?f=community){kind=avatar}
Homo's zijn gewoon mannen hoor.
Maar ik snap je punt.
Op zoek naar een nieuwe collega, .NET webdev, voornamelijk productontwikkeling. DM voor meer info
een linux "ping of death", weer fijn patchen dan maar.Vond het al wat wazig dat er een 5.1.11 uit kwam met alleen maar een paar netwerk patches, maar dit verklaard het wel aardig
[ Voor 21% gewijzigd door gekkie op 17-06-2019 22:54 ]
/u/3813/100_8985_ICON2.JPG?f=community)
Ik ben niet een hele dikke n00b op dit gebied, maar ik heb precies hetzelfde
Later weer verder met Rust, nu eerst productief zijn...
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.
Je zegt letterlijk dat, in jouw ervaring, de programmeurs die klagen altijd die mensen zijn die er zelf een potje van gemaakt hebben. Misschien is het niet je bedoeling te stellen dat mensen die klagen over ORMs slechte devs zijn, maar zo komt het, in ieder geval op mij, wel over.
Jij stelt dat ORMs prima technieken zijn. Prima. Mag je vinden. Ik vind dat absoluut niet. In ons dagelijks werk passen we een hoop verschillende abstracties toe. Heck; zonder abstracties waren we allemaal letterlijk machine code aan het produceren. Maar elke transactie komt ook met een 'cost', dus het is altijd een afweging. In het geval van ORMs is er een hele grote hidden cost die vaak niet meegenomen wordt (N+1 en andere lastige te debuggen problemen) terwijl de benefit vrij minimaal is.
Als ik dat dan netjes probeer te beredeneren en er komt daarna iemand met een "Nou hurr durr alle developers die ik ken die klagen over ORMs zijn echt fucking slecht joh!" dan wordt ik daar wel enigzins chagerijning van.
No hard feelings verder, kan wel wat hebben hoor
Heb hetzelfde. Ben afgelopen jaar voor Advent of Code begonnen met Rust, maar al vrij snel naar Kotlin overgestapt omdat ik gewoon niks gedaan kreeg. Ben er nog steeds niet uit of ik nu te dom ben of dat Rust zo lastig in 't gebruik ik. Beetje van beiden vermoed ik. Ik hoor zelf van Rust-fans dat bijvoorbeeld een Game in Rust schrijven masochistisch is...
Denk erover het dit jaar in C++ te doen, gewoon back naar de roots. En dan in plaats van een focus op 'mooie' FP code, code die gewoon zo snel mogelijk is. Hoop wel dat komend jaar de opdrachten leuker zijn, op een gegeven moment was het vooral een complexe set instructies die gevolgd moest worden i.p.v. zelf een oplossing uitvogelen.
[ Voor 37% gewijzigd door Hydra op 18-06-2019 08:39 ]
https://niels.nu
Als je het hebt over "letterlijk", quote mij dan gewoon en probeer niet steeds iets toe te voegen aan mijn mening als ik dat niet "letterlijk" zo heb gezegd. Want nu doe je het exact weer net zoals je vorig bericht waar je een stukje van iemand pakt, je eigen negatieve mening er aan vast plakt en dan semi gestrekt erin terug reageert.
Wat klopt hier nou niet aan. Dit is toch puur de definitie waarop ORM niet ok is. Als je dataset niet goed is of dat bizare meuk uitvoert. Want anders is ORM prima voor zijn doel (bijv. simpele CRUD). Opnieuw met aannames wat iemand bedoelt die je op jezelf reflecteert. Ik heb helemaal niet letterlijk gezegd dat ze er zelf een potje van hebben gemaakt.
Volwassen.
Nou, laten we dan even agree to disagree. Zolang je steeds een stukje van iemand pakt en totaal niet snapt wat iemand bedoelt te zeggen en dat verdraait, maak je het jezelf wel erg moeilijk.
/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!
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/105842/Homer_60x60.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_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Je zegt hier toch echt dat het de schuld van de developer is. De applicatie is 'krom' of de dataset is 'krom'? Beiden zijn de verantwoordelijkheid van de developer.
Ik ben het daar dus compleet mee oneens. Het N+1 probleem kan op de meest onverwachte momenten optreden dus je moet vrijwel altijd in de gaten houden wat je ORM er van bakt. Erger nog; je moet dat iedere keer bij een upgrade doen; een andere Hibernate versie kan prima het gedrag opeens veranderen. En dan heb je nog het probleem dat juist als je database-first werkt je vaak met compound keys komt te zitten waarmee het via een ORM, omdat alles naar objecten gemapped moet worden, behoorlijk omslachtig werken is.
Ook ben ik het niet met je eens dat een ORM een goeie match is voor simpele CRUD. Juist daar kun je prima uit de voeten met een simpele rowmapper library, of JOOQ ofzo. Het theoretische 'best fit' model voor een ORM is juist het laden / saven van complexe objectstructuren. In theorie kan het je juist daar enorm veel tijd schelen. En in de praktijk gaat het nu dus juist daar vaak mis.
Dan stellen dat de dataset vast 'krom' is of anders de applicatie 'krom' moet zijn, vind ik gewoon lomp. Ik heb hier jarenlang ervaring mee en vaak dit soort shit moeten fixen.
Ik vond je reactie nogal extreem ongenuanceerd en nogal denigrerend overkomen. Daarnaast zitten ORM aanhangers al snel in m'n allergie-zone met dat soort dooddoeners. Vandaar m'n ongenuanceerde reactie terug
https://niels.nu
"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
Het omgekeerde gebeurt gelukkig ook
Ik had (jaren geleden) een LINQ-query die Entity Framework omsmurfte in een SQL-statement dat dermate complex was dat SQL Server zich erin verslikte. Toen ik eens in de package manager keek zag ik dat er een minor update was voor EF. In de changelogs kon ik eigenlijk niks noemenswaardigs vinden over veranderingen aan de query interpreter.
Na het installeren van de update werd er echter een heel andere SQL-query gegenereerd, en daar had SQL Server geen moeite meer mee.
We are shaping the future
/u/81985/crop566b00b43645a.png?f=community)
Even advocaat van de duivel / knuppel in het hoenderhok
, maar als je model dusdanig complex is dat ORM's niet lekker meer werken, waarom dan niet gewoon makkelijkere representaties van de data voorschotelen middels views en CRUD op die views weer binnen de database afhandelen met triggers? Daarmee trek je die abstractie verder je data laag in i.p.v. dat die tussen je data en controller laag in zit, of zelfs meer richting je controller laag hangt.Ik doe (in mijn professionele leven) weinig aan echte software development, maar meer met data-warehouses / data-management en data-analyse, dus zeer zeker gekleurd door de database bril
Sinds de 2 dagen regel reageer ik hier niet meer
Degene die verantwoordelijk was voor het opzetten van het datamodel en data access-model was nogal een voorstander van ORMs en abstracties, zodoende dat dus ook alles via LINQ en EF gebeurde. Ik heb meer een voorkeur voor de juiste tools gebruiken voor de juiste omstandigheden.
Onlangs heb ik een keer Petapoco gebruikt om af te zijn van het geestdodend saaie mappen (het probleem waarvoor ORMs meestal gebruikt worden), het schrijven van SQL-queries doe ik wel liever met de hand.
Een tijd geleden heb ik een keer een oplossing gemaakt waarbij ik een stored procedure gemaakt heb, die een table accepteert (user defined table type). De stored procedure gebruikt vervolgens T-SQL's MERGE-command om data in bulk te upserten in de target table. Dat werkte verrassend goed, en lekker snel. Zo'n oplossing bouwen met een ORM leidt dan tot een hoop losse queries, nu is het in één keer klaar
Onlangs heb ik een keer Petapoco gebruikt om af te zijn van het geestdodend saaie mappen (het probleem waarvoor ORMs meestal gebruikt worden), het schrijven van SQL-queries doe ik wel liever met de hand.
Een tijd geleden heb ik een keer een oplossing gemaakt waarbij ik een stored procedure gemaakt heb, die een table accepteert (user defined table type). De stored procedure gebruikt vervolgens T-SQL's MERGE-command om data in bulk te upserten in de target table. Dat werkte verrassend goed, en lekker snel. Zo'n oplossing bouwen met een ORM leidt dan tot een hoop losse queries, nu is het in één keer klaar
We are shaping the future
Dat was dan weer niet het antwoord waar ik op hoopte
Sinds de 2 dagen regel reageer ik hier niet meer
Waarom views (dat zijn ook maar gewoon queries) bouwen in je database als je diezelfde queries gewoon vanuit je code kan doen?:
Even advocaat van de duivel / knuppel in het hoenderhok
Ik volg je vraag niet; de complexiteit komt meestal vanuit de ORM zelf. SQL is best wel simpel over 't algemeen (rare schema's daargelaten). Een schema kan heel netjes genormaliseerd zijn, maar waarbij je toch door hoepels moet springen in een ORM (JPA met compound keys is een PITA bijvoorbeeld). Het N+1 probleem is een complexiteit van de ORM zelf; je weet zelf nooit wanneer 't precies gaat gebeuren (meestal niet, soms wel). Je weet nooit of een update roet in het eten gooit.
Dit terwijl een SQL query in je code gewoon een query blijft.
Mijn punt is dus dat een ORM voor simpel CRUD werk eigenlijk niks toevoegt (geen tijdswinst) en alleen bij complexere entity trees up-front tijdswinst oplevert. Maar die tijd die je wint, verlies je vaak aan de achterkant dubbel en dwars als je weer eens performance issues met Hibernate (daar zijn serieus boeken over geschreven) op moet lossen.
Wat mij betreft zijn ORMs gewoon altijd een slecht idee geweest. Ik heb er in al die jaren dat ik in de Java hoek zit nooit echt profijt van gehad.
Dus ik doe eigenlijk wat @Alex) doet; gewoon een rowmapper library gebruiken en klaar. Die SQL queries schrijven is niet erg interessant, maar da's die entity annotations e.d. op objecten plakken ook niet.
[ Voor 5% gewijzigd door Hydra op 18-06-2019 16:20 ]
https://niels.nu
Dit topic is gesloten.