De Devschuur Coffee Corner - Iteratie ⓬

[alwinuzz]

Leuke discussie Ben toevallig bekend (bukent of beekunt?) in deze materie.

Elke taal is op andere manieren complex. De spelling van Nederlandse woorden is relatief goed te doen. Het Nederlands heeft een duidelijke koppeling tussen klank en letter, ook wel de klank-tekenkoppeling. Hier bovenop zijn er een aantal klankregels. Daarnaast is de woordvorming belangrijk (bijv. samenstellingen). En ja, veel uitzonderingen, vooral uit andere talen geïmporteerd.

De Nederlandse klank-tekenkoppeling is een stuk logischer dan de Engelse in ieder geval, zoals dit mooi laat zien: RayNbow in "De Devschuur Coffee Corner - Iteratie ⓬" en CurlyMo in "De Devschuur Coffee Corner - Iteratie ⓬"
Dat zegt niets over andere onderdelen van de taal, zoals waar (samengestelde) woorden vandaan komen en de zinsbouw (grammatica). Kan iemand mij uitleggen wanneer je het woordje 'er' gebruikt en op welke plek?

Zo is elke taal op een andere manier moeilijk en complex.

ThomasG schreef op donderdag 15 augustus 2019 @ 16:28:
[...]
Dat kun je namelijk wel aan het woord zien, ook bij bosui. Er zijn maar een paar gevallen wanneer je een o uitspreekt als oo; zoals een meervoudsvorm met een medeklinker en daarna -en. In het geval van bosui is er geen enkele reden om aan te nemen dan de o zou klinken als oo. Als ze dat wel denkt heeft ze dat helaas verkeerd aangeleerd.

Of je een lange klank zoals [oo] met 1 of 2 letters schrijft, heeft niets met meervoud te maken. Het gaat erom of de lange klank aan het einde van de klankgroep staat. Bo-ven, ro-ver, vo-gel t.o.v. hoog-te, brood-je
Helaas wordt dit in taalmethodes op school wel zo geoefend (het wordt goed uitgelegd maar de oefeningen/werkbladen focussen heel erg op 'langer maken').
Dit geldt ook voor verdubbelen na een korte klank.

Bij samenstellingen zoals bosui voeg je alleen de woorden samen. Je gebruikt geen nieuwe spellingregels 'op de plaknaad'. Dit is een duidelijke afspraak. Heel logisch, áls je doorhebt dat het woord uit bos+ui bestaat. Hiervoor is woordenschat ook belangrijk. Als ik dit niet zou herkennen, zou ik bij het lezen [boosui] met lange oo zeggen. Of bij het schrijven bossui opschrijven, verdubbelen na korte klank toch?

BarôZZa schreef op donderdag 15 augustus 2019 @ 14:55:
[...]


[...]

Enkele uitzonderingen? Nederlands is uitzondering op uitzondering. Alle regels vliegen sowieso(mooi woord trouwens) de deur uit bij de krankzinnige hoeveelheid leenwoorden uit de landen om ons heen. Die we uiteraard weer vernederlandst uitspreken. Chirurg, jam, machine. Klemtonen in het Nederlands zijn willekeurig en moet je stampen. Hoe je woorden schrijft met ij/ei, c/k, b/p, au/ou, g/ch ook. Accent, account, cel, cavia.
De stomme 'e' is ook een mooie. Meloen, elleboog.

Bedelen. Twee werkwoorden. Bedeeld en gebedeld.

Nog zo'n leuk: hoe we landen en mensen eruit noemen. Nederland -> Nederlander. Duitsland -> Duitser, Oostenrijk -> Oostenrijker. Frankrijk -> Fransman/Française/Franse, Georgië -> Georgiër, België -> Belg

M'n Taiwanese vriendin leert Nederlands en haar hoofd ontploft elke keer. Voor haar is het 'China', 'China people' en 'China food'. Oefenen is leuk. Boo-sui. Boo-sui? Oh, bos-ui.

Nederlands en Engels liggen trouwens heel dicht bij elkaar, dus veel zaken gaan voor beide talen op. Maar als Engels dan PHP is... Misschien is Nederlands dan wel Visual Basic of Objective C

Overigens zie ik net dat je in .NET het volgende hebt: TextSource.GetTextEffectCharacterIndexFromTextSourceCharacterIndex(Int32) Method

Een leuke en hele informatieve website over het Nederlands voor non-native speakers is Dutch Grammar
Misschien iets voor je vriendin? Of kende je deze al? Ze hebben ook een versie over NL in het Mandarijn (vlaggetjes rechtsboven).

Klemtonen / stomme 'e' is lastig, zeker voor non-native speakers. Veel stomme 'e's zijn vaste stukjes. Zoals ge- be- ver- en -eren, -elen, ... Daarmee kan je een eind komen, maar zeker niet 100%.

Voor ch/g is een regel. Met uitzonderingen natuurlijk, maar ja, 80/20 95/5 hè.

Leenwoorden zijn inderdaad lastig. Je noemt nu een paar van Franse oorsprong. Maar de Engelse leenwoorden zijn pas erg
Bij lezen is er een regel of je c als [k] of [s] uitspreekt.

ij/ei en ou/au is stampen. ou komt wel veeeel vaker voor dan au. Mensen zijn altijd ij (jij, hij, wij, zij...)

[armageddon_2k1]

Allemachtig mensen. Is het hier de Devschuir of is het hier Genootschap Onze Taal?

Wat vinden we overigens van Go?

[BertS]

armageddon_2k1 schreef op donderdag 15 augustus 2019 @ 19:09:
Wat vinden we overigens van Go?

lang...

[ThomasG]

armageddon_2k1 schreef op donderdag 15 augustus 2019 @ 19:09:
Allemachtig mensen. Is het hier de Devschuir of is het hier Genootschap Onze Taal?

Wat vinden we overigens van Go?

http://www.golang.sucks/

[.oisyn]

armageddon_2k1 schreef op donderdag 15 augustus 2019 @ 19:09:
Allemachtig mensen. Is het hier de Devschuir of is het hier Genootschap Onze Taal?

Wat vinden we overigens van Go?

Aardig spelletje, maar ik prefereer dammen.

[armageddon_2k1]

Woep woep! Na 1,5 jaar de overstap gemaakt te hebben van product developer (consumentenelec.) naar IT ga ik in December naar mijn eerste congres. KotlinConf! Ga daar ook de workshop Multiplatform with Kotlin doen. Erg veel zin in.

[R4gnax]

bwerg schreef op donderdag 15 augustus 2019 @ 10:43:
Waarom zijn bananen krom?

Omdat ze naar de zon toe groeien.

Sorry. Kon het niet laten...

[armageddon_2k1]

Als ze recht waren vielen ze om

[Xanland]

Olaf van der Spek schreef op dinsdag 13 augustus 2019 @ 10:31:
[...]

Hoe sla jij tijdzones op in de DB?

Zelf sla ik altijd unix timestamps op met type int.

In het kader van bijv. audittrail: Qua wat je opslaat is volgens mij de DateTime in UTC opslaan met apart, ander veld dus, de offset van de gebruiker die het - al dan wel indirect - opslaat. Hiermee kan je zowel, inderdaad, aan de voorkant berekenen hoe laat het daadwerkelijk is opgeslagen, maar ook eventueel omzetten naar een tijd voor een willekeurige gebruiker die het bekijkt.
Soms wil je immers wel weten wat het daadwerkelijke tijdstip is van opslaan.

In het geval dat de gebruiker datum en tijd op mag slaan waarbij één van de 2 optioneel is, doe dat dan wel in 2 aparte velden.

Overigens is het altijd weer een bijzonder vraagstuk vol discussie.

[gekkie]

Mjah en dan moet je nog alle tijdzone wijzigingen sindsdien nog apply'en .. of niet .. afhankelijk van wat je wil berekenen of representeren . Dezer dagen net weer een update gehad van tzdata pakketje op Debian.

[Olaf van der Spek]

Xanland schreef op donderdag 15 augustus 2019 @ 22:44:
[...]
In het kader van bijv. audittrail: Qua wat je opslaat is volgens mij de DateTime in UTC opslaan met apart, ander veld dus, de offset van de gebruiker die het - al dan wel indirect - opslaat. Hiermee kan je zowel, inderdaad, aan de voorkant berekenen hoe laat het daadwerkelijk is opgeslagen, maar ook eventueel omzetten naar een tijd voor een willekeurige gebruiker die het bekijkt.
Soms wil je immers wel weten wat het daadwerkelijke tijdstip is van opslaan.

Ik begrijp niet waarom je de offset (tijdzone?) opslaat. UTC geeft al het exacte tijdstip en bij presentatie heb je de tijdzone van de gebruiker die het bekijkt.

gekkie schreef op donderdag 15 augustus 2019 @ 22:58:
Mjah en dan moet je nog alle tijdzone wijzigingen sindsdien nog apply'en .. of niet .. afhankelijk van wat je wil berekenen of representeren . Dezer dagen net weer een update gehad van tzdata pakketje op Debian.

Niet echt, dat doet de date/time formatter voor je. Als je dat zelf doet ben je vrijwel zeker verkeerd bezig.

[ Voor 22% gewijzigd door Olaf van der Spek op 16-08-2019 09:12 ]

[ElkeBxl]

ThomasG schreef op woensdag 14 augustus 2019 @ 16:41:
[...]
Daarom vieren ze in veel landen ook hun "geboortedag": birthday, geburtstag, etc. etc. De meeste belgen noemen het ook de geboortedag. Alleen wij Nederlanders moeten het zo nodig de verjaardag noemen.

Ik heb nog nooit iemand hier in België horen spreken over hun geboortedag te vieren. Zowel in het Vlaams als in het Frans. Maar ik zit sowieso met rare situaties doordat ik in Brussel woon Maar de vele vrienden en kennissen die ik heb in Vlaanderen en Wallonië spreken altijd over een verjaardag / anniversaire.

BarôZZa schreef op donderdag 15 augustus 2019 @ 17:09:
[...]
'Boven' is geen meervoudsvorm.

Doet me denken aan een uitspraak die ik ooit ergens hoorde die me altijd is bijgebleven:

Leven is het meervoud van lef

[ Voor 7% gewijzigd door ElkeBxl op 16-08-2019 09:40 ]

[gekkie]

Olaf van der Spek schreef op vrijdag 16 augustus 2019 @ 09:12:
[...]
Ik begrijp niet waarom je de offset (tijdzone?) opslaat. UTC geeft al het exacte tijdstip en bij presentatie heb je de tijdzone van de gebruiker die het bekijkt.
[...]
Niet echt, dat doet de date/time formatter voor je. Als je dat zelf doet ben je vrijwel zeker verkeerd bezig.

Zolang je bijvb geen vliegreizen gaat maken en een afspraak gaat maken in andere tijdzones waar vervolgens ook nog eens een tijdzone / day-light-savings wijziging plaats zal vinden, ja dan is het makkelijk.
Anders gaat er toch gauw wat kapot, zie het afgelopen jaar de mensen die in Marokko het vliegtuig misten omdat de reizigers en de vliegmaatschappij er wat andere gedachten op na hielden.

Ook als je gaat rekenen met de duur van het interval tussen twee timestamps met dat soort dingen kan het leuk worden. (wat doe je bijvb met rente berekeningen etc.).

ElkeBxl schreef op vrijdag 16 augustus 2019 @ 09:39:
[...]
Ik heb nog nooit iemand hier in België horen spreken over hun geboortedag te vieren. Zowel in het Vlaams als in het Frans. Maar ik zit sowieso met rare situaties doordat ik in Brussel woon Maar de vele vrienden en kennissen die ik heb in Vlaanderen en Wallonië spreken altijd over een verjaardag / anniversaire.

Ik mocht hier in NL lezen dat den kleine steeds met woorden zou overnemen (in het kader van vroegtijdig aanschouwen van TV en youtube ).
Naja sweet revenge op jullie poging tot indoctrinatie met die plopsa, S&G, k3 toestand .

[ Voor 35% gewijzigd door gekkie op 16-08-2019 10:09 ]

[ElkeBxl]

gekkie schreef op vrijdag 16 augustus 2019 @ 10:02:
Ik mocht hier in NL lezen dat den kleine steeds met woorden zou overnemen (in het kader van vroegtijdig aanschouwen van TV en youtube ).
Naja sweet revenge op jullie poging tot indoctrinatie met die plopsa, S&G, k3 toestand .

Ja toen ik dat las had ik wel even een "nou breekt mijn klomp!" momentje... Op zich heb ik zelf geen issue met wat internationalisering maar ik hoop dat de Vlaamse jeugd dan ook wat beter wordt in bijvoorbeeld het Frans, kwestie van eerst de eigen landstalen wat beter te leren kennen (mogen we het Duits ook niet vergeten). Het Engels lijkt dik in orde te zijn.

Maar als onze Vlaamse jeugd naast het Vlaams ook Nederlands begint te spreken, gaat gijle dan ook Vlaams beginnen te klappen? Zou vree charmant zijn om meer "gij/ge" te horen voor die keren dat ik op visite kom

[Douweegbertje]

ThomasG schreef op donderdag 15 augustus 2019 @ 19:14:
[...]
http://www.golang.sucks/

wow, ik weet niet zo goed wat ik hier van moet vinden lol. Die pagina op zich zelf is echt lame. De github page voelt ook echt 'nasty'. Even snel door de issues door gescrolled waar er IMO genoeg van zijn opgelost of niet van toepassing (meer) zijn. Los van het "ik zoek nu echt even iets om over te janken" argumenten. Waarvan er uiteraard een aantal zeker fair zijn.

Af en toe merk ik echt een nerd rage om redenen die mij niet duidelijk zijn.

Valt er niet voor elke taal zo'n shitlist te maken, waarom de haat vanuit sommige zo groot is, is mij echt nog onduidelijk.

[armageddon_2k1]

@Douweegbertje
Gewoon het effect van je identificeren met een idee, keuze of groep en vasthouden aan eerdere beslissingen.

Elke taal heeft z'n nukken, en sommige zijn natuurlijk wel beter ontworpen dan anderen, maar mensen maken ergens een keuze voor, gebaseerd op rationele en/of niet-rationele redenen.

Voor sommige mensen is het erg lastig om vervolgens in te zien waarom hun keuze niet goed (meer) is, of gaan ze koste wat het kost hun keuze verdedigen door potentiele gevaren aan te vallen. Als men eenmaal heftig geinvesteerd is in een idee, keuze, of groep is het nogal lastig daarvan af te stappen voor sommigen. Die steker dan liever hun energie in het affakkelen van de ideeen, keuzes en groepen die anders zijn.

[ Voor 5% gewijzigd door armageddon_2k1 op 16-08-2019 11:08 ]

[Gropah]

ElkeBxl schreef op vrijdag 16 augustus 2019 @ 10:29:
[...]
kwestie van eerst de eigen landstalen wat beter te leren kennen
[...]

Ja, dag! Dan moeten alle Nederlanders zeker ook Fries leren? En Nedersaksisch? Dacht het niet. Ik vind Nederlands al moeilijk genoeg.

[ElkeBxl]

Gropah schreef op vrijdag 16 augustus 2019 @ 11:17:
[...]


Ja, dag! Dan moeten alle Nederlanders zeker ook Fries leren? En Nedersaksisch? Dacht het niet. Ik vind Nederlands al moeilijk genoeg.

Ik had het dan vooral over de Belgische jeugd Wat jullie in jullie thuislandje uitspoken kan me geen reet schelen zolang wij Belgen er geen last van hebben

[gekkie]

Urgh gevalletje RTFM ...
TO_CHAR(NOW(), HH24:MM:SS') levert toch niet helemaal op wat ik dacht in Postgres.

ElkeBxl schreef op vrijdag 16 augustus 2019 @ 10:29:
[...]
Maar als onze Vlaamse jeugd naast het Vlaams ook Nederlands begint te spreken, gaat gijle dan ook Vlaams beginnen te klappen? Zou vree charmant zijn om meer "gij/ge" te horen voor die keren dat ik op visite kom

Komt wel eens voor als ik met wat quasi oud-Nederlandsch voor de dag probeer te komen .

[ Voor 66% gewijzigd door gekkie op 16-08-2019 11:30 ]

[Koenvh]

ElkeBxl schreef op vrijdag 16 augustus 2019 @ 10:29:
[...]

Maar als onze Vlaamse jeugd naast het Vlaams ook Nederlands begint te spreken, gaat gijle dan ook Vlaams beginnen te klappen? Zou vree charmant zijn om meer "gij/ge" te horen voor die keren dat ik op visite kom

Awel, als ge dat zo graag moogt, dan kunnen we voor de volgende rendez-vous wel iets regelen.

Zoiets? M'n Vlaams is nogal roestig geworden nadat Professor T. was afgelopen; zijn daar ook cursussen voor?

[ Voor 3% gewijzigd door Koenvh op 16-08-2019 23:51 ]

[YakuzA]

FUUUU.
Hele dag lopen graven waar naar de obfuscator onze release build sloopte.
200 commits om door te spitten om er dan uiteindelijk achter te komen dat de obfuscator met iets sufs en onverwachts moeite had en wat verklootte in de IL oid.

[Immutable]

YakuzA schreef op vrijdag 16 augustus 2019 @ 23:52:
FUUUU.
Hele dag lopen graven waar naar de obfuscator onze release build sloopte.
200 commits om door te spitten om er dan uiteindelijk achter te komen dat de obfuscator met iets sufs en onverwachts moeite had en wat verklootte in de IL oid.

Wel een beetje jammer dat jullie een obfuscator gebruiken. Als ik klant was van jullie zou ik dat niet willen. Ik wil jullie code kunnen decompilen wanneer jullie failliet gaan.

[YakuzA]

Immutable schreef op zaterdag 17 augustus 2019 @ 10:56:
[...]


Wel een beetje jammer dat jullie een obfuscator gebruiken. Als ik klant was van jullie zou ik dat niet willen. Ik wil jullie code kunnen decompilen wanneer jullie failliet gaan.

Source code is eigendom van de klant in dit geval. Obfuscation moet verplicht van hun security afdeling

[kenneth]

Immutable schreef op zaterdag 17 augustus 2019 @ 10:56:
[...]


Wel een beetje jammer dat jullie een obfuscator gebruiken. Als ik klant was van jullie zou ik dat niet willen. Ik wil jullie code kunnen decompilen wanneer jullie failliet gaan.

Beter een escrow dan.

En hoe zit dat met rechten? De boedel zal verkocht worden door de curator toch? En geldt voor decompilen dezelfde vrijheid als reverse engineering?

[Immutable]

kenneth schreef op zaterdag 17 augustus 2019 @ 11:30:
[...]

Beter een escrow dan.

En hoe zit dat met rechten? De boedel zal verkocht worden door de curator toch? En geldt voor decompilen dezelfde vrijheid als reverse engineering?

En wat als je reverse engineering doet op basis van de decompiled code + spec. ?
Of code jatten en dan reverse engineering doen?

En wat moet je als bedrijf doen die geen verstand van software heeft, maar wel een oud programma heeft en geen source code en ze moeten alles aanpassen? Kan je deze klant de schuld geven dat ze geen verstand van software hebben en dus aan het begin geen aanspraak hebben gedaan om de source code te krijgen bij faillissement? En omdat je geen verstand hebt van software, heb je ook geen verstand genoeg om bijvoorbeeld een bedrijf in te huren die tussen jou en het software bedrijf in zit en jou belangen behartigd? En jou ook adviseert?

[advocaat van de duivel mode:]
Waarom worden bedrijven die geen verstand hebben van software zo vaak genaaid, zowel korte als lange termijn? Wat kunnen ze doen om software bedrijven terug te naaien? Zodat er een equilibrium ontstaat.

[Matis]

Uhhh YouTube

[downtime]

Immutable schreef op zaterdag 17 augustus 2019 @ 11:40:
[...]

[advocaat van de duivel mode:]
Waarom worden bedrijven die geen verstand hebben van software zo vaak genaaid, zowel korte als lange termijn? Wat kunnen ze doen om software bedrijven terug te naaien? Zodat er een equilibrium ontstaat.

Eén woord: Ondernemersrisico.

Voor ondernemers geldt de markt, het recht van de sterkste, en je wordt als ondernemer geacht te weten wat je doet. Je hoort slimmer, beter en sterker dan de concurrent te zijn. Ben je dat niet dan verdien je ook om genaaid te worden door mensen die net een beetje slimmer zijn.

[ElkeBxl]

Koenvh schreef op vrijdag 16 augustus 2019 @ 23:50:
[...]

Awel, als ge dat zo graag moogt, dan kunnen we voor de volgende rendez-vous wel iets regelen.

Zoiets? M'n Vlaams is nogal roestig geworden nadat Professor T. was afgelopen; zijn daar ook cursussen voor?

Ongeveer zoiets? Ik snap niet echt wat ik graag zou mogen?

Pintjes komen pakken, dat is de beste cursus Is het ooit nog eens devschuur meeting eigenlijk?

[kevintjeb]

Matis schreef op zaterdag 17 augustus 2019 @ 21:22:
Uhhh YouTube
[Afbeelding]

Toevallig op vakantie in Polen? Ik had dit ook dit jaar, aangezien ik een lange periode in Polen was..

[Douweegbertje]

Immutable schreef op zaterdag 17 augustus 2019 @ 11:40:
[...]


En wat als je reverse engineering doet op basis van de decompiled code + spec. ?
Of code jatten en dan reverse engineering doen?

En wat moet je als bedrijf doen die geen verstand van software heeft, maar wel een oud programma heeft en geen source code en ze moeten alles aanpassen? Kan je deze klant de schuld geven dat ze geen verstand van software hebben en dus aan het begin geen aanspraak hebben gedaan om de source code te krijgen bij faillissement? En omdat je geen verstand hebt van software, heb je ook geen verstand genoeg om bijvoorbeeld een bedrijf in te huren die tussen jou en het software bedrijf in zit en jou belangen behartigd? En jou ook adviseert?

[advocaat van de duivel mode:]
Waarom worden bedrijven die geen verstand hebben van software zo vaak genaaid, zowel korte als lange termijn? Wat kunnen ze doen om software bedrijven terug te naaien? Zodat er een equilibrium ontstaat.

Als je voor een paar ton software koopt maar geen kennis hebt, al dan niet algemene kennis, om zo'n aankoop te doen dan is het zeker eigen schuld dikke bult.

In een aantal grotere projecten zie ik vaak dat bedrijf X een daadwerkelijke product owner aanneemt (freelance) die het project beheerd. Vergeet niet; voor beide kanten (als hij/zij goed is tenminste). Dus die houdt bedrijf X in toon met bijv. requirements, afspraken, wensen, etc. alsmede "ons" qua sprints, kwaliteit, requirements, etc.

M.b.t. het naaien van elkaar. Ik zie dat net zoals @downtime als ondernemen. Het is uiteindelijk niet naaien maar domweg zaken met elkaar doen. Dit is exact hetzelfde als je een huis koopt, neem aankoopbegeleiding, dwing zaken af en whatnot. Of als je een huis gaat bouwen, neem een fatsoenlijke architect, aannemer, etc.
Als je een tweedehands auto koopt, doe het bij een fatsoenlijke zaak en neem je autogekke oom mee voor advies.

[ThomasG]

kevintjeb schreef op zondag 18 augustus 2019 @ 11:06:
[...]


Toevallig op vakantie in Polen? Ik had dit ook dit jaar, aangezien ik een lange periode in Polen was..

Dat heeft daar denk ik niets zo veel mee te maken. Ik krijg al ruim een jaar geregeld Duitse reclame op YouTube, terwijl ik met dit apparaat niet in Duitsland ben geweest, mijn OS in het Engels staat en ik een Nederlands IP gebruik. En het gekke is, met andere apparaten op dit IP gebeurt dat niet; ik ben er niet steeds niet achter hoe dat nu komt.

[Matis]

kevintjeb schreef op zondag 18 augustus 2019 @ 11:06:
Toevallig op vakantie in Polen? Ik had dit ook dit jaar, aangezien ik een lange periode in Polen was..

Nee, nog nooit geweest. Hetzelfde verhaal als @ThomasG aangeeft.

[gekkie]

Toevallig laatstelijk nog ergens een wandje gestuc't, dat zal wel in de etnisch profileer AI zitten .

[Matis]

gekkie schreef op zondag 18 augustus 2019 @ 18:54:
Toevallig laatstelijk nog ergens een wandje gestuc't, dat zal wel in de etnisch profileer AI zitten .

Nie

[Antrax]

YakuzA schreef op vrijdag 16 augustus 2019 @ 23:52:
FUUUU.
Hele dag lopen graven waar naar de obfuscator onze release build sloopte.
200 commits om door te spitten om er dan uiteindelijk achter te komen dat de obfuscator met iets sufs en onverwachts moeite had en wat verklootte in de IL oid.

Misschien een andere manier vinden om je product te shippen naar klanten?

[ThomasG]

Antrax schreef op maandag 19 augustus 2019 @ 08:13:
[...]

Misschien een andere manier vinden om je product te shippen naar klanten?

Gewoon obfuscated programmeren

[YakuzA]

ThomasG schreef op maandag 19 augustus 2019 @ 09:07:
[...]
Gewoon obfuscated programmeren

Sommige mensen hebben die gave idd om altijd obfuscated te programmeren

[gekkie]

Beetje als Booking.com, gewoon weer Perl gaan gebruiken. Obfuscation als language feature .
(gelukkig klopt er vast niemand meer Perl, dus wat meer risicoloos als een PHP is ...)

[Antrax]

gekkie schreef op maandag 19 augustus 2019 @ 10:36:
Beetje als Booking.com, gewoon weer Perl gaan gebruiken. Obfuscation als language feature .
(gelukkig klopt er vast niemand meer Perl, dus wat meer risicoloos als een PHP is ...)

Booking.nerp? Ik hoop dat die recruiters mij daar ooit nog eens op de blacklist gaan proppen.

Ik blijf lastig gevallen worden of ik daar wil werken maar snap niet waarom je zoveel _developers_ nodig hebt voor zo'n website. Of de vraag is gewoon dat iedereen constant weg loopt. Inefficiency valt gewoon te lezen in de berichten die ik van recruiters ontvang.

[Gropah]

Antrax schreef op maandag 19 augustus 2019 @ 10:51:
[...]

Booking.nerp? Ik hoop dat die recruiters mij daar ooit nog eens op de blacklist gaan proppen.

Ik blijf lastig gevallen worden of ik daar wil werken maar snap niet waarom je zoveel _developers_ nodig hebt voor zo'n website. Of de vraag is gewoon dat iedereen constant weg loopt. Inefficiency valt gewoon te lezen in de berichten die ik van recruiters ontvang.

Heb je het volkskrant artikel gelezen? Genoeg redenen om daar niet te gaan werken

[__fred__]

Matis schreef op zaterdag 17 augustus 2019 @ 21:22:
Uhhh YouTube
[Afbeelding]

Thanks, ben net bezig met Pools leren ;-)

"Onbeperkt vermaak".
"Alleen op netflix, één betaling voor eindeloos amusement".

Hopelijk heb je je Netflix weer naar Nederlands gekregen, want ik moet weer aan het werk ;-)

[Antrax]

Gropah schreef op maandag 19 augustus 2019 @ 10:54:
[...]


Heb je het volkskrant artikel gelezen? Genoeg redenen om daar niet te gaan werken

Nu wel, én gelukkig vanaf nu een reactie voor de betreffende recruiters

[isomis]

Vandaag weer even op LinkedIn gekeken en er was weer iemand die met vol trots de nieuwe website van een bekende drogist promoot. Ik bekijk gelijk even de website en zie de HTML body beginnen op regel 159 en 182 requets verder voordat de homepage het doet. Klanten kiezen altijd voor partijen met een sterke marketing afdeling. Waarom gaat dat altijd ten koste van techniek........

[hellum]

isomis schreef op maandag 19 augustus 2019 @ 15:01:
Vandaag weer even op LinkedIn gekeken en er was weer iemand die met vol trots de nieuwe website van een bekende drogist promoot. Ik bekijk gelijk even de website en zie de HTML body beginnen op regel 159 en 182 requets verder voordat de homepage het doet. Klanten kiezen altijd voor partijen met een sterke marketing afdeling. Waarom gaat dat altijd ten koste van techniek........

Kennis kost geld en het werkt toch goed?

[kevintjeb]

__fred__ schreef op maandag 19 augustus 2019 @ 11:04:
[...]


Thanks, ben net bezig met Pools leren ;-)

"Onbeperkt vermaak".
"Alleen op netflix, één betaling voor eindeloos amusement".

Hopelijk heb je je Netflix weer naar Nederlands gekregen, want ik moet weer aan het werk ;-)

Hmm, ik ben ook bezig met Pools leren maar zoek nog steeds naar een goede aanpak. Hoe pak jij dit aan? Een DM is misschien handiger dan in de devschuur

[ThomasG]

isomis schreef op maandag 19 augustus 2019 @ 15:01:
Vandaag weer even op LinkedIn gekeken en er was weer iemand die met vol trots de nieuwe website van een bekende drogist promoot. Ik bekijk gelijk even de website en zie de HTML body beginnen op regel 159 en 182 requets verder voordat de homepage het doet. Klanten kiezen altijd voor partijen met een sterke marketing afdeling. Waarom gaat dat altijd ten koste van techniek........

Tja. Mensen die goed zijn qua de techniek snappen marketing niet. Klanten zitten helemaal niet te wachten hoe geweldig het product technisch wel niet is. De techniek snappen ze niet, en interesseert ze niets. Als je niet goed kunt uitleggen waarom ze dat nodig hebben, heb je al verloren. Ze willen gewoon een mooie website. Dat werkt in elke branche zo. Of het product wel of niet geweldig is doet het helemaal niet toe, zolang mensen maar het idee hebben dat het zo is. Als je een mooi verkoop praatje hebt, en zorgt dat het er grafisch gelikt uit ziet, kom je technisch bijna overal mee weg.

[isomis]

ThomasG schreef op maandag 19 augustus 2019 @ 15:29:
[...]
Tja. Mensen die goed zijn qua de techniek snappen marketing niet. Klanten zitten helemaal niet te wachten hoe geweldig het product technisch wel niet is. De techniek snappen ze niet, en interesseert ze niets. Als je niet goed kunt uitleggen waarom ze dat nodig hebben, heb je al verloren. Ze willen gewoon een mooie website. Dat werkt in elke branche zo. Of het product wel of niet geweldig is doet het helemaal niet toe, zolang mensen maar het idee hebben dat het zo is. Als je een mooi verkoop praatje hebt, en zorgt dat het er grafisch gelikt uit ziet, kom je technisch bijna overal mee weg.

Korte termijn doelen. Bij lange termijn doelen zoals doorontwikkeling, komt de slechte techniek om de hoek kijken.

[Kalentum]

isomis schreef op maandag 19 augustus 2019 @ 15:43:
Korte termijn doelen. Bij lange termijn doelen zoals doorontwikkeling, komt de slechte techniek om de hoek kijken.

Vaak worden dat soort sites helemaal niet lang onderhouden. Op een gegeven moment wordt er gewoon weer een nieuwe site 'besteld' en beginnen ze weer opnieuw.

[ThomasG]

kevintjeb schreef op maandag 19 augustus 2019 @ 15:22:
[...]


Hmm, ik ben ook bezig met Pools leren maar zoek nog steeds naar een goede aanpak. Hoe pak jij dit aan? Een DM is misschien handiger dan in de devschuur

Zoals de Polen zelf zeggen, met kurwa ken je al 50% Pools

[kevintjeb]

ThomasG schreef op maandag 19 augustus 2019 @ 16:02:
[...]
Zoals de Polen zelf zeggen, met kurwa ken je al 50% Pools

Helaas kan ik dan niet meer dan boos overkomen bij mijn vriendin haar familie

[kenneth]

Ernstig geval van imposter syndrome ...

Deze bug komt bekend voor. Eens kijken hoe het eerder is opgelost. Ah, deze changeset. Oh, dat is een nette fix, ik weet niet of ik dat zelf had kunnen bedenken. Wie is de auteur van de changeset? Oh.

[CurlyMo]

Ik had laatst zelf een soort van:
- Wie schreef de bijbel: God
- Hoe weet je dat God bestaat: omdat dan in de Bijbel zo is geschreven.

Praktijkvoorbeeld (A = ander, I = ik):
A Er zit een bug in ons script.
I Wat was het functionele doel van het script?
A Dat staat in het script.
I Daar staat inderdaad wat er is uitgewerkt, maar wat moet het doen?
A Dat staat in het script.
I Wat was de aanleiding om te denken dat het script niet doen wat het moet doen?
A Omdat het anders is dan in het script beschreven staat.
I Als ik dat wat er in het script sta probeer uit te werken, hoe weet ik dan dat de uitkomst klopt?
A Als het technisch klopt bij de beschrijving dan klopt het
I Ik lees inderdaad de beoogde aanpak, de hoe dus, maar niet de waarom? Waarom was dit nodig?
A Dat staat dan weer in het script.
I Laat maar.

Waarbij ik altijd sterk moet denken aan het bekende XY probleem:

A Kan iemand me helpen bij de regex om de strings uit deze code te halen? {"foo":"bar"}
B Is de data toevallig in JSON?
A Dat was de vraag niet. Ik zoek een regex om die strings foo en bar te extraheren.
B Maar als het in JSON staat kan het zonder regex.
A Wat is JSON?

Alhoewel het eerste probleem veel meer gaat over het niet kunnen scheiden van de functionele vraag en technische implementatie, waardoor het wel weer op dit XY probleem lijkt, waarin de implementatie belangrijker wordt gemaakt dan het oorspronkelijke doel.

[ Voor 9% gewijzigd door CurlyMo op 20-08-2019 11:44 ]

[Matis]

kenneth schreef op dinsdag 20 augustus 2019 @ 11:06:
Ernstig geval van imposter syndrome ...

Deze bug komt bekend voor. Eens kijken hoe het eerder is opgelost. Ah, deze changeset. Oh, dat is een nette fix, ik weet niet of ik dat zelf had kunnen bedenken. Wie is de auteur van de changeset? Oh.

Ik heb dat soms andersom. Wat een waardeloze code, eens kijken wie dit heeft gemaakt...

* Matis schaamt zich

[mcDavid]

Antrax schreef op maandag 19 augustus 2019 @ 11:09:
[...]

Nu wel, én gelukkig vanaf nu een reactie voor de betreffende recruiters

Net alsof die dat wat uitmaakt. Die vinden bedrijven met zo'n hoge turnover juist geweldig! Meer werk voor hun.

[ThomasG]

mcDavid schreef op dinsdag 20 augustus 2019 @ 13:58:
[...]

Net alsof die dat wat uitmaakt. Die vinden bedrijven met zo'n hoge turnover juist geweldig! Meer werk voor hun.

Ze moeten een site maken waar je recruiters kunt raten

[Alex)]

ThomasG schreef op dinsdag 20 augustus 2019 @ 14:00:
[...]
Ze moeten een site maken waar je recruiters kunt raten

Helaas bestaat blacklist-recruiters.nl niet meer

[acemoo]

Matis schreef op dinsdag 20 augustus 2019 @ 13:08:
[...]

Ik heb dat soms andersom. Wat een waardeloze code, eens kijken wie dit heeft gemaakt...

* Matis schaamt zich

Als je oude code van jezelf ziet en je niet schaamt, heb je te weinig geleerd.

[Mugwump]

br men schreef op woensdag 21 augustus 2019 @ 09:13:
[...]


Als je oude code van jezelf ziet en je niet schaamt, heb je te weinig geleerd.

Sterker nog, ik heb na een project van pakweg een jaar met een redelijk complex domein al de neiging om aan het eind de hele boel weg te willen flikkeren en goed te willen bouwen op basis van de kennis die je gedurende het jaar hebt opgedaan over de organisatie en de processen binnen die organisatie.

[CurlyMo]

Mugwump schreef op woensdag 21 augustus 2019 @ 09:55:
[...]


Sterker nog, ik heb na een project van pakweg een jaar met een redelijk complex domein al de neiging om aan het eind de hele boel weg te willen flikkeren en goed te willen bouwen op basis van de kennis die je gedurende het jaar hebt opgedaan over de organisatie en de processen binnen die organisatie.

Dat is dan nog vanuit de ideale situatie, waarin jij jezelf nog goed kan volgen en weet waar de onhandigheden in je code zitten. N.a.v. mijn vorige reactie zit in nu in de situatie dat ik aan de hand van dezelfde input probeer de output te generen om er achter te komen wat bij gebrek aan documentatie nu precies de bedrijfsregels achter het algoritme was. Daarbij wist ik bij aanvang al dat ik betere input zou kunnen gebruiken. Maar als ik dat doe breng ik meer variatie in het proces, waardoor ik de oorspronkelijke aannames minder goed in beeld krijg. Op basis van de output uit de onbekende oorspronkelijke aannames draaien weer andere belangrijke processen, dus simpelweg dingen 'verbeteren' zonder het transparant te kunnen verhouden aan het oorspronkelijke algoritme is dus ongewenst.

Het komt dus neer op een knap klusje reverse engineering.

TLDR; soms weet je bij de start van een klus al dat het na afronding herschreven moet worden.

[Antrax]

mcDavid schreef op dinsdag 20 augustus 2019 @ 13:58:
[...]

Net alsof die dat wat uitmaakt. Die vinden bedrijven met zo'n hoge turnover juist geweldig! Meer werk voor hun.

Ik snap dat het gross van de recruiters nou eenmaal geen lievertjes zijn maar ik kan mij niet voorstellen dat ze in zee zullen gaan met zo'n bedrijf

[Marc3l]

isomis schreef op maandag 19 augustus 2019 @ 15:01:
Vandaag weer even op LinkedIn gekeken en er was weer iemand die met vol trots de nieuwe website van een bekende drogist promoot. Ik bekijk gelijk even de website en zie de HTML body beginnen op regel 159 en 182 requets verder voordat de homepage het doet. Klanten kiezen altijd voor partijen met een sterke marketing afdeling. Waarom gaat dat altijd ten koste van techniek........

Zoals Jos Burgers zo mooi zegt, klanten willen gaten en geen boren.

[ThomasG]

Antrax schreef op woensdag 21 augustus 2019 @ 11:25:
[...]

Ik snap dat het gross van de recruiters nou eenmaal geen lievertjes zijn maar ik kan mij niet voorstellen dat ze in zee zullen gaan met zo'n bedrijf

Recruiters gaan erg ver. Een collega kwam (vrouwelijke-)recruiters tegen op een dating app

[acemoo]

ThomasG schreef op woensdag 21 augustus 2019 @ 12:15:
[...]
Recruiters gaan erg ver. Een collega kwam (vrouwelijke-)recruiters tegen op een dating app

Mogen recruiters niet daten?

[ThomasG]

br men schreef op woensdag 21 augustus 2019 @ 12:39:
[...]


Mogen recruiters niet daten?

Jawel, maar dat is niet waarom ze daarop zaten. Ze waren daar om mensen een nieuwe baan aan te smeren

[Olaf van der Spek]

ThomasG schreef op woensdag 21 augustus 2019 @ 12:48:
[...]
Jawel, maar dat is niet waarom ze daarop zaten. Ze waren daar om mensen een nieuwe baan aan te smeren

Zoiets als Fake Agent (NSFW)?

[ElkeBxl]

ThomasG schreef op woensdag 21 augustus 2019 @ 12:15:
[...]
Recruiters gaan erg ver. Een collega kwam (vrouwelijke-)recruiters tegen op een dating app

Can confirm, heb het ook al gehad. Of zelfs ook al eens 2 politiekers die zo stemmen aan het ronselen waren

[gekkie]

Op zich komt het toch ook aardig overeen met daten ?

[Antrax]

Olaf van der Spek schreef op woensdag 21 augustus 2019 @ 13:00:
[...]

Zoiets als Fake Agent?

I should not have Googled that.

[ZpAz]

ThomasG schreef op woensdag 21 augustus 2019 @ 12:15:
[...]
Recruiters gaan erg ver. Een collega kwam (vrouwelijke-)recruiters tegen op een dating app

Als ik een nieuwsbericht van gisteren mag geloven waren dat mannelijke recruiters.

[Mugwump]

CurlyMo schreef op woensdag 21 augustus 2019 @ 10:15:
[...]

Dat is dan nog vanuit de ideale situatie, waarin jij jezelf nog goed kan volgen en weet waar de onhandigheden in je code zitten. N.a.v. mijn vorige reactie zit in nu in de situatie dat ik aan de hand van dezelfde input probeer de output te generen om er achter te komen wat bij gebrek aan documentatie nu precies de bedrijfsregels achter het algoritme was. Daarbij wist ik bij aanvang al dat ik betere input zou kunnen gebruiken. Maar als ik dat doe breng ik meer variatie in het proces, waardoor ik de oorspronkelijke aannames minder goed in beeld krijg. Op basis van de output uit de onbekende oorspronkelijke aannames draaien weer andere belangrijke processen, dus simpelweg dingen 'verbeteren' zonder het transparant te kunnen verhouden aan het oorspronkelijke algoritme is dus ongewenst.

Het komt dus neer op een knap klusje reverse engineering.

TLDR; soms weet je bij de start van een klus al dat het na afronding herschreven moet worden.

Ja dat soort situaties heb je ook nog. Zo heb ik wel eens een 'applicatie' gekregen die in de praktijk een lineair PHP script met procedurele code waarin myVariable1 t/m myVariable9387 en myTemporaryArray1 t/m myTemporaryArray2371 werden gebruikt. Gelukkig was het een extern bepaald algoritme, dus ik heb die hele code in de prullenbak gegooid en gewoon een fast applicatie gebouwd.

[raptorix]

br men schreef op woensdag 21 augustus 2019 @ 09:13:
[...]


Als je oude code van jezelf ziet en je niet schaamt, heb je te weinig geleerd.

Ik heb ooit een split string functie in VBscript geschreven om er vervolgens achter te komen dat die er gewoon standaard inzat

Een andere nare was een script waar ik een probleem met betrekking tot het aantal cookies had opgelost, echter na een jaar kwam ik er achter dat er een gigantische bug in zat als de lengte te lang werd, echter het script dat ik op een codesharing site had gezet kon ik niet meer aanpassen, man man man wat heb ik een hoop boze mailtjes gehad

[Douweegbertje]

Uiteindelijk maak je trade-offs. Zodra je een eigen toko hebt ben je ook veel bewuster van die tradeoffs. Domweg omdat je keer op keer wel kan doorgaan met "optimizen" en "best practices" waardoor er gewoon 0 resultaat is.

Ik ben voor mijzelf ook bezig met een bedrijfje/service en ik heb in eerste instantie ook werk van ongeveer 2 weken weggegooid omdat ik niet tevreden was. Heel tof dat ik natuurlijk die beslissing kan maken, maar uiteindelijk heb ik nu nog niets draaien

De reden dat ik het toch had gedaan was dat ik enorm veel problemen in de toekomst voorspelde. Daarom investeer ik nu liever toch in een wat betere structuur dan dat ik hier nog jaren tegenaan moet lopen. Feit is wel dat wat ik nu maak echt wel richting 'live' moet gaan.

Elk bedrijf heeft een potje leergeld. Bij de één is dat net iets meer dan de ander (soms 0..). Desalniettemin moet er ook iemand zijn die capabel genoeg is om een technische vertaling te maken waarom je dat leergeld wilt aanspreken. Een technische rant is vaak niet voldoende. Iets wat ik steeds vaker zie omdat ik in de detachering zit, is dat men er echt wel bereid voor is, maar dat niemand het eens fatsoenlijk heeft geopperd.

Dit is meer mijn ervaring van ~10 jaar programmeren naar een iets wat andere functie. Nu zie ik ook veel meer de andere kant.

@ThomasG

Klanten zitten helemaal niet te wachten hoe geweldig het product technisch wel niet is. De techniek snappen ze niet, en interesseert ze niets. Als je niet goed kunt uitleggen waarom ze dat nodig hebben, heb je al verloren. Ze willen gewoon een mooie website. Dat werkt in elke branche zo.

Doch boeit het wel degelijk. Sterker nog, ik heb vaak genoeg opdrachten gewonnen met exacte argumenten die jij aangeeft waar niemand naar kijkt. Op opdrachten waarbij concurrenten op ~15k zaten en wij op 25k+.

Soms moet je ook redeneren welke klanten je *niet* wilt hebben. Wil je wel/niet een samenwerking aangaan, is de klant bereid om na "oplevering" nog verder te investeren etc. etc.

[Mugwump]

Sorry, but at this point, I need to assume Javascript/Node culture is beyond saving.
Just today I was trialing Firebase Cloud Functions. The hello world of it requires a package "firebase-functions", by Google themselves. It has 73 dependencies, by 83 maintainers.

There's no being careful with that, I have to assume Google was careful on my behalf, right?

Except a few layers bellow, this is using 2 different versions of a package, that converts strings into milliseconds, just so developers can write strings like ms('2 days') in their code (evaluated at runtime obviously) instead of appropriately named numeric constants.

bron

[bauke1994]

[gekkie]

Tsja gebruk dan ook leftpad(dle).

[ThomasG]

[Gropah]

Ik blijf mij verbazen over de javascript/npm cultuur. Left pad was erg, maar ze lijken er niet van geleerd te hebben... Zo kwam ik net is-buffer tegen. Ook weer zo'n 1 functie van nog 10 regels package (met wat tests er bij). En uit de readme kan ik niet opmaken waarom de native manier niet goed genoeg is. Toch word het door bijna 4k repo's gebruikt in ~450 packages waaronder een aantal grote.

En dezelfde auteur is ook verantwoordelijk voor een linterconfig, die redelijk veel word gebruikt, waar hij nu reclame in heeft gestopt...

[Barryvdh]

Gropah schreef op maandag 26 augustus 2019 @ 13:36:
Ik blijf mij verbazen over de javascript/npm cultuur. Left pad was erg, maar ze lijken er niet van geleerd te hebben... Zo kwam ik net is-buffer tegen. Ook weer zo'n 1 functie van nog 10 regels package (met wat tests er bij). En uit de readme kan ik niet opmaken waarom de native manier niet goed genoeg is. Toch word het door bijna 4k repo's gebruikt in ~450 packages waaronder een aantal grote.

En dezelfde auteur is ook verantwoordelijk voor een linterconfig, die redelijk veel word gebruikt, waar hij nu reclame in heeft gestopt...

Het vreemde vind ik nog dat er maar 3 watchers zijn, dus niemand die echt let op nieuwe releases/wijzigingen (waar hacks/bugs ed. in kunnen zitten). Wordt overigens gebruikt door 3,8 miljoen repositories: https://github.com/feross...ja2FnZS0xNDgzOTMxNQ%3D%3D

[ Voor 8% gewijzigd door Barryvdh op 26-08-2019 14:05 ]

[Antrax]

Barryvdh schreef op maandag 26 augustus 2019 @ 14:05:
[...]


Het vreemde vind ik nog dat er maar 3 watchers zijn, dus niemand die echt let op nieuwe releases/wijzigingen (waar hacks/bugs ed. in kunnen zitten). Wordt overigens gebruikt door 3,8 miljoen repositories: https://github.com/feross...ja2FnZS0xNDgzOTMxNQ%3D%3D

Pffffft, praat mij d'r niet van.

Er gaat momenteel een vriendelijke discussie over open source en geld.
https://github.com/feross/funding

(In het bijzonder deze issue en deze issue (vervolg))

[ElkeBxl]

Antrax schreef op maandag 26 augustus 2019 @ 16:00:
[...]
(In het bijzonder deze issue en deze issue (vervolg))

Wow, just wow...

[Koenvh]

@Antrax Logging lijkt me nou bij uitstek de verkeerde plek voor advertenties, maar ik vind de discussie an sich wel interessant. Geld verdienen met open source is vaak lastig, dus ik ben benieuwd of er hierdoor goede ideeën komen opborrelen. Het grote voordeel is natuurlijk dat je niet constant zelf het wiel opnieuw hoeft uit te vinden, maar hoe zorg je ervoor dat je uitvinding vrij beschikbaar stellen de moeite waard is? In veel gevallen is het feit dat andere bugs kunnen vinden en features kunnen toevoegen voor mij al genoeg, maar ik kan me voorstellen dat dat met wat grotere projecten anders ligt.

[ Voor 45% gewijzigd door Koenvh op 27-08-2019 04:30 ]

[Mugwump]

Ik kwam gisteren nog wel een interessante onderzoekspublicatie tegen over sollicitatieprocedures voor ontwikkelaars. Er bestaat nogal een verschil in perceptie tussen o.a. HR en sollicitanten over de effectiviteit en wenselijkheid van dat soort procedures:

A technical interview for software development consists of one or more stages within the interview life cycle [3],[23]. It begins with an initial screening of the candidate, usually conducted over the phone or through an online codingsite, such as CoderPad. Depending on their performance, the candidate may be invited for an on-site visit. This on-site visit consists of a series of one-on-one interviews (each 45minutes to an hour, over a period of half a day to several days) with engineers, and sometimes managers. The interviews primarily focus on technical coding or algorithms, either on the whiteboard or using a simple text editor on a computer.In other words, technical interviews are primarily a test of the candidates’ problem-solving or “analytical ability” [23]. And if all goes well, the candidate can expect to receive an offer.For hiring managers, technical interview have considerable appeal [20]. First, hiring managers are able to ask questions directly from the companies’ question bank, instead of having to design their own interview questions. Second, the format purports to reduce variation between interviewers and teams,since candidates can be evaluated through objective scoring criteria. Finally, the interview process becomes scalable: new interviewers are straight-forward to train, and these interviewers can interchangeably ask coding questions to any software engineering candidate. All of these, in theory, result in amore-or-less standardized and meritocratic technical interview pipeline.The collective experiences of interview candidates, however, appear to tell a very different story—even a cursory glance reveals that “technical interviews are broken” [36], that they are an “antagonistic” [34] form of high-pressure “whiteboard algorithm hazing” [15] that have “nothing to do with real day-to-day developer work” [19], are “humiliat[ing] professionally” [31], assess candidates through an “algorithm question lottery [of] luck and chance” [39], and require substantial“upfront investment” from the candidate [33] to learn the“cultural norms necessary to get themselves into a desk at a technology firm” [25]. Still others argue that technical interviews may even “promote exclusion and discrimination,serving only as a barrier to entry for qualified underrepresented candidates” [1].

Ik moet zeggen dat bij mij zelf al dat soort algoritmische kennis over hoe Dijkstra's algoritme of BFS ook alweer precies werkt ver is weggezakt aangezien ik er in de dagelijkse praktijk nooit mee wordt geconfronteerd. Ik probeer in sollicitaties die ik zelf voer (wat vaak met kandidaten is die toch al wel enige jaren werkervaring hebben) vooral in te haken op het CV en de projecten waaraan iemand heeft gewerkt. Op basis daarvan kun je wel doorvragen naar gekozen technische oplossingen, gemaakte afwegingen en ga zo maar door. Geeft in mijn ogen een beter beeld van kandidaten dan 'los dit puzzeltje op een whiteboard op'.

[Hipska]

Koenvh schreef op dinsdag 27 augustus 2019 @ 04:25:
@Antrax Logging lijkt me nou bij uitstek de verkeerde plek voor advertenties, maar ik vind de discussie an sich wel interessant. Geld verdienen met open source is vaak lastig, dus ik ben benieuwd of er hierdoor goede ideeën komen opborrelen. Het grote voordeel is natuurlijk dat je niet constant zelf het wiel opnieuw hoeft uit te vinden, maar hoe zorg je ervoor dat je uitvinding vrij beschikbaar stellen de moeite waard is? In veel gevallen is het feit dat andere bugs kunnen vinden en features kunnen toevoegen voor mij al genoeg, maar ik kan me voorstellen dat dat met wat grotere projecten anders ligt.

Men maakt vaak de denkfout om enkel vanuit het eigen eindproduct te kijken. Echter heeft men meestal om dat eindproduct te bereiken ook zelf (gratis) gebruik gemaakt van andere open source producten.

Dus als je dan redeneert wat het zou zijn moest je voor die andere producten betalen om ze te kunnen gebruiken voor de ontwikkeling van uw product, dan loop je vast tegen een muur aan. Vandaar is zelf ook je code vrij beschikbaar houden een goede conclusie.

Daarnaast is Open Source niet per se gratis. Je code kan open zijn, maar je kan wel geld vragen voor support/service of zelfs het gecompileerde eindproduct.

[Hydra]

Mugwump schreef op dinsdag 27 augustus 2019 @ 09:05:
Ik moet zeggen dat bij mij zelf al dat soort algoritmische kennis over hoe Dijkstra's algoritme of BFS ook alweer precies werkt ver is weggezakt aangezien ik er in de dagelijkse praktijk nooit mee wordt geconfronteerd. Ik probeer in sollicitaties die ik zelf voer (wat vaak met kandidaten is die toch al wel enige jaren werkervaring hebben) vooral in te haken op het CV en de projecten waaraan iemand heeft gewerkt. Op basis daarvan kun je wel doorvragen naar gekozen technische oplossingen, gemaakte afwegingen en ga zo maar door. Geeft in mijn ogen een beter beeld van kandidaten dan 'los dit puzzeltje op een whiteboard op'.

An sich mee eens, maar ik heb ook de ervaring dat alleen een 'gesprek' een erg slechte methode is om een assessment te doen, puur en alleen omdat we slechts mensen zijn en er allemaal psychologische pitfalls zijn bij het interviewen van mensen waar we eigenlijk allemaal instinken.

Ten eerste; de 'eerste indruk'. Onze hersenen proberen alles zo snel mogelijk in hokjes te plaatsen. Is iemand vriend of vijand? Vertrouwen we hem of niet? Willen we met iemand samenwerken of niet? Dat hebben we eigenlijk al in de eerste paar minuten besloten. En tenzij iemand tijdens het gesprek het tegendeel van dat besluit hard bewijst, is de uitkomst al wat we besloten hebben. Ik heb dat in vrij extreme vormen gezien bij sommige interviewers waar of in de vraag al het antwoord zat (zodat de persoon makkelijk kon antwoorden) of dat er juist bizar slechte vragen gesteld werden om maar aan te sturen op het niet aannemen van iemand.

Daarnaast is er het "sunk cost fallacy" effect. Als developer wil je developen, meetings e.d. zijn 'tijdsverspilling' en een interview al helemaal. Meestal hebben 'we' er ook heel weinig zin in, maar er gaat behoorlijk veel tijd in zitten. Het zou zonde zijn als die tijd 'verspilling' is, dus ook daardoor kun je sneller geneigd zijn iemand het voordeel van de twijfel te vinden.

Wat ook nog eens meespeelt is dat in het geval van 'slechte' kandidaten deze mensen vaak veel meer ervaring hebben in het doen van interviews dan de personen die de interviews afnemen. Je door zo'n 'technisch' interview heen bullshitten is niet extreem moeilijk. Zolang je ietwat vaag blijft en je niet enorm klemlult of op leugens betrapt wordt. En wij mensen zijn niet goed in het betrappen op leugens.

Ik heb het zelf vrij vaak mis zien gaan en heb bij een vorige klant een test ontwikkeld die eigenlijk een redelijke kopie was van het 'echte' werk, dus in een soort peer-programming formaat samen een simpele REST service bouwen op basis van een aantal requirements, inclusief tests, etc. In mijn ervaring is samen achter een toetsenbord zitten en werken aan een 'echte' opdracht de beste manier om, na een technisch interview, te kijken wat iemand echt kan.

Dit heeft er bij ons toen ook toe geleid dat een paar mensen die het voordeel van de twijfel kregen tijdens een interview enorm hard door de mand vielen. En de goeie developers deden die test met twee vingers in de neus.

[Mugwump]

Hydra schreef op dinsdag 27 augustus 2019 @ 10:51:
[...]


An sich mee eens, maar ik heb ook de ervaring dat alleen een 'gesprek' een erg slechte methode is om een assessment te doen, puur en alleen omdat we slechts mensen zijn en er allemaal psychologische pitfalls zijn bij het interviewen van mensen waar we eigenlijk allemaal instinken.

Ten eerste; de 'eerste indruk'. Onze hersenen proberen alles zo snel mogelijk in hokjes te plaatsen. Is iemand vriend of vijand? Vertrouwen we hem of niet? Willen we met iemand samenwerken of niet? Dat hebben we eigenlijk al in de eerste paar minuten besloten. En tenzij iemand tijdens het gesprek het tegendeel van dat besluit hard bewijst, is de uitkomst al wat we besloten hebben. Ik heb dat in vrij extreme vormen gezien bij sommige interviewers waar of in de vraag al het antwoord zat (zodat de persoon makkelijk kon antwoorden) of dat er juist bizar slechte vragen gesteld werden om maar aan te sturen op het niet aannemen van iemand.

Daarnaast is er het "sunk cost fallacy" effect. Als developer wil je developen, meetings e.d. zijn 'tijdsverspilling' en een interview al helemaal. Meestal hebben 'we' er ook heel weinig zin in, maar er gaat behoorlijk veel tijd in zitten. Het zou zonde zijn als die tijd 'verspilling' is, dus ook daardoor kun je sneller geneigd zijn iemand het voordeel van de twijfel te vinden.

Wat ook nog eens meespeelt is dat in het geval van 'slechte' kandidaten deze mensen vaak veel meer ervaring hebben in het doen van interviews dan de personen die de interviews afnemen. Je door zo'n 'technisch' interview heen bullshitten is niet extreem moeilijk. Zolang je ietwat vaag blijft en je niet enorm klemlult of op leugens betrapt wordt. En wij mensen zijn niet goed in het betrappen op leugens.

Ik heb het zelf vrij vaak mis zien gaan en heb bij een vorige klant een test ontwikkeld die eigenlijk een redelijke kopie was van het 'echte' werk, dus in een soort peer-programming formaat samen een simpele REST service bouwen op basis van een aantal requirements, inclusief tests, etc. In mijn ervaring is samen achter een toetsenbord zitten en werken aan een 'echte' opdracht de beste manier om, na een technisch interview, te kijken wat iemand echt kan.

Dit heeft er bij ons toen ook toe geleid dat een paar mensen die het voordeel van de twijfel kregen tijdens een interview enorm hard door de mand vielen. En de goeie developers deden die test met twee vingers in de neus.

Ik zei ook niet dat er op geen enkele wijze programmeervaardigheden getoetst zouden moeten worden.
Ik maak vooral bezwaar tegen 'algoritmes whiteboarden'.
Het is net als dat je in een technisch interview iemand een stuk Java code voorlegt en daar allerlei strikvragen over gaat stellen.

Juist een praktische opdracht in een realistische werksituatie is iets dat ook in de paper wordt aangeraden.

[Hydra]

Mugwump schreef op dinsdag 27 augustus 2019 @ 11:36:
Ik zei ook niet dat er op geen enkele wijze programmeervaardigheden getoetst zouden moeten worden.
Ik maak vooral bezwaar tegen 'algoritmes whiteboarden'.
Het is net als dat je in een technisch interview iemand een stuk Java code voorlegt en daar allerlei strikvragen over gaat stellen.

Juist een praktische opdracht in een realistische werksituatie is iets dat ook in de paper wordt aangeraden.

Het was ook vooral bedoeld als aanvulling; ik ben het gewoon met je eens verder

[armageddon_2k1]

For fucks sake, Bitbucket heeft de laatste weken wel heel veel gezeik met hun Pipelines zeg. De hele dag al gehannes dat ze niet werken. Erg fijn als je hotfixes wil deployen....

[Matis]

armageddon_2k1 schreef op dinsdag 27 augustus 2019 @ 17:46:
For fucks sake, Bitbucket heeft de laatste weken wel heel veel gezeik met hun Pipelines zeg. De hele dag al gehannes dat ze niet werken. Erg fijn als je hotfixes wil deployen....

Ja, wij hebben er ook last van. Zijn eind vorig jaar overgestapt van on premises naar cloud.
Man man man, wat een gezeik sindsdien met de stabiliteit.

Vroegah kon je gewoon een klap op de server geven en dan deed ie het weer nu ben je afhankelijk van de gasten bij Atlassian.

[armageddon_2k1]

Ja maar vroeger werd het niet automatisch gedeployed naar kubernetes

[Antrax]

Matis schreef op dinsdag 27 augustus 2019 @ 19:59:
Vroegah kon je gewoon een klap op de server geven en dan deed ie het weer nu ben je afhankelijk van de gasten bij Atlassian.

Ik kom regelmatig nog bij bedrijven die ijzer in house hebben draaien.

Tegenwoordig willen alle bedrijven hip mee doen en developers aan zich te binden door kubernetes te gebruiken maar ik heb in een aantal gevallen al gezien dat het niet beter is om dit soort dingen te doen. Zeker niet in projecten die al langer leven dan een jaar. Alles wordt traag als dikke kak en je bent in 99% van alle gevallen opeens afhankelijk van Amazon, Google of welke tech derp dan ook waar je niks anders heen dockert dan een schip met geld

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Voutloos]

Dit soort klachten is de backend variant van Moet altijd alles een moderne SPA zijn?

[CurlyMo]

Voutloos schreef op woensdag 28 augustus 2019 @ 09:20:
Dit soort klachten is de backend variant van Moet altijd alles een moderne SPA zijn?

Uiteindelijk is het allemaal dezelfde discussie: Waarom moet alles (een) X zijn?

[hellum]

Je moet gewoon per project kijken wat de beste tools voor de job zijn. Kan een SPA zijn, kunnen microservices zijn, maar staar je niet blind op alles wat nieuw en fancy is.

[gekkie]

Antrax schreef op woensdag 28 augustus 2019 @ 08:07:
[...]
Ik kom regelmatig nog bij bedrijven die ijzer in house hebben draaien.

Tegenwoordig willen alle bedrijven hip mee doen en developers aan zich te binden door kubernetes te gebruiken maar ik heb in een aantal gevallen al gezien dat het niet beter is om dit soort dingen te doen. Zeker niet in projecten die al langer leven dan een jaar. Alles wordt traag als dikke kak en je bent in 99% van alle gevallen opeens afhankelijk van Amazon, Google of welke tech derp dan ook waar je niks anders heen dockert dan een schip met geld

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Mjah en de complexiteit schaalt meestal ook flink mee, maar goed je met van je SPOF af (en je hebt niet zelden MPOF weten te scheppen). Wat dat betreft is auto-failover enzo allemaal leuk, mitsdien je er goed over nagedacht hebt. Anders heb je de kans dat je meer data vernaggeld dan je lief is, voor een probleem wat zich niet of zelden voor deed (de laatste keer dat ik bijvb een Postgres server zichzelf op heb zien hangen is lang geleden en dat was omdat de OOM killler langs kwam door misconfiguratie).

Achja niettemin, verandering is altijd goed ... het houdt op z'n minst de mensen van de straat .

[boe2]

Voutloos schreef op woensdag 28 augustus 2019 @ 09:20:
Dit soort klachten is de backend variant van Moet altijd alles een moderne SPA zijn?

En volgens mij dezelfde oorzaak: Jonge developers die blind iedere trend achterna lopen, zonder ook maar even stil te staan of het wel een goed idee is

[CurlyMo]

boe2 schreef op woensdag 28 augustus 2019 @ 11:40:
[...]

En volgens mij dezelfde oorzaak: Jonge developers die blind iedere trend achterna lopen, zonder ook maar even stil te staan of het wel een goed idee is

Als we dan toch met doorverwijzingen naar andere topics strooien. Volgens mij is dit ook een belangrijk punt van: Wat maakt een functie een WO vereiste functie

Als je de waarom begrijpt, naast de hoe en de wat, dan laat je je minder snel leiden door hypes.

[armageddon_2k1]

hellum schreef op woensdag 28 augustus 2019 @ 10:13:
Je moet gewoon per project kijken wat de beste tools voor de job zijn. Kan een SPA zijn, kunnen microservices zijn, maar staar je niet blind op alles wat nieuw en fancy is.

Sowieso herschrijven in Rust Microservices. Dat is altijd beter.

CurlyMo schreef op woensdag 28 augustus 2019 @ 11:52:
[...]
Als je de waarom begrijpt, naast de hoe en de wat, dan laat je je minder snel leiden door hypes.

Hear hear! Een van m'n programmeurs denkt bij React + state Management == Redux. Maakt niet uit of er uberhaubt geen complexe state is die horizontaal door de applicatie heen gaat. Dat probeer ik hem toch wel af te leren.

[ Voor 38% gewijzigd door armageddon_2k1 op 28-08-2019 11:55 ]

[Antrax]

armageddon_2k1 schreef op woensdag 28 augustus 2019 @ 11:52:

Sowieso herschrijven in Rust Microservices. Dat is altijd beter.

Ik vroeg mij al af waar die opmerking bleef

[gekkie]

armageddon_2k1 schreef op woensdag 28 augustus 2019 @ 11:52:
[...]
Sowieso herschrijven in Rust Microservices. Dat is altijd beter.

Zit je dan met je pot hammerite .

[CurlyMo]

armageddon_2k1 schreef op woensdag 28 augustus 2019 @ 11:52:
Hear hear!

En dan is eigenlijk alles na C gewoon een grote hype