:strip_icc():strip_exif()/u/87691/avatar_alex.jpg?f=community){kind=avatar}
We are shaping the future
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
/u/81985/crop566b00b43645a.png?f=community)
:strip_icc():strip_exif()/u/510323/crop5c49c55cb1a09_cropped.jpeg?f=community)
/u/373849/cowava2.png?f=community)
I'm not a complete idiot. Some parts are missing.
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
:strip_icc():strip_exif()/u/734655/crop6390c3acd41c6_cropped.jpg?f=community)
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
Mijn eerste reactie: "Hey, die heeft precies dezelfde naam als de zanger van Iron Maiden.". Check ik vervolgens de website...
/u/12668/hydra.png?f=community)
:strip_icc():strip_exif()/u/284419/Mexican%2520Wolf%2520Klein.jpg?f=community)
Ik gebruik nu Spring Data (JPA/Hibernate) voor queries en die doet dus alles voor mij qua mapping e.d. Welke Rowmapper raad jij aan? Want ik merk dat de rowmapper van Spring gewoon neerkomt op "Map zelf de zaken uit de resultset" terwijl ik nu alles via annotations laat mappen (en dat graag zo houd).
Anders kan ik net zo goed heel Spring JDBC negeren en gewoon zelf queries bouwen met preparedstatements en de resultset zelf afhandelen
Edit: Ah ik zie al dat BeanPropertyRowMapper het zelf kan op basis van kolomnamen in de tabel en variabelenamen in je model. Hm. Kwestie van verschil tussen tabelnaam en variabelenaam oplossen met aliassen. Okido.
[ Voor 9% gewijzigd door Merethil op 19-06-2019 09:52 ]
/u/262310/ava.png?f=community)
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/3813/100_8985_ICON2.JPG?f=community)
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_icc():strip_exif()/u/304716/enforcer_small.jpeg?f=community)
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
:strip_exif()/u/26373/anim4.gif?f=community)
"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney
*snip*
* RobIII wijst naar de topicwarning. Open even een topic per onze Quickstart
* RobIII wijst naar de topicwarning. Open even een topic per onze Quickstart
[ Voor 85% gewijzigd door RobIII op 20-06-2019 15:09 ]
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Members only:
Alleen zichtbaar voor ingelogde gebruikers.
Inloggen
.edit: lol. clear:both for the lose
[ Voor 14% gewijzigd door .oisyn op 24-06-2019 16:30 ]
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.
:
[...]
Members only:
Alleen zichtbaar voor ingelogde gebruikers. Inloggen
.edit: lol. clear:both for the lose
Members only:
Alleen zichtbaar voor ingelogde gebruikers.
Inloggen
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:strip_icc():strip_exif()/u/36083/crop5dca9e34ce091_cropped.jpeg?f=community)
Oftewel die gast heeft een onduidelijke opdracht gekregen 
Wie geeft er nou floats door als de vraag over het restgetal van een deling van ints gaat. Wel precies zij he ;-)
Wie geeft er nou floats door als de vraag over het restgetal van een deling van ints gaat. Wel precies zij he ;-)
[ Voor 17% gewijzigd door armageddon_2k1 op 24-06-2019 21:01 ]
Engineering is like Tetris. Succes disappears and errors accumulate.
Neh dat laatste is overduidelijk een gevalletje van een premature optimalisatie
(bij de grote code-klop-clubs, moet je neem ik toch aan, wel wat optimalisaties achter de hand houden om nog lekker lang wat billable hours er tegen aan te kunnen gooien.)
:strip_exif()/u/47168/loop.gif?f=community)
Als het een fixed price-project is? Vergeet het maar. Bij Fixed Price betaalt de klant niet meer dan wat is afgesproken.
Als je meer nodig hebt moet je met hangende pootjes naar de klant, en hopen dat je een goed verhaal hebt (bijvoorbeeld: significant meerwerk door een onverwachte API-wijziging). Maar het kan ook zijn dat de klant zegt "Nee, dit is het en ik verwacht dat je levert conform afspraak."
Bij Time and Material (T&M) wordt er inderdaad gewerkt met billable hours, maar dat is geen vrijbrief om maar wat aan te prutsen. Een klant wil -in de regel- verantwoording zien voor de gemaakte uren en zal niet zomaar blijven betalen. Als je een beetje pech hebt schakelen ze een derde partij in om het geleverde werk te reviewen. Als die dan een rapport oplevert waarin staat dat er slordig werk is opgeleverd, slaat de klant je daarmee om je oren. Voor jou 3 anderen hoor
Dat wil niet zeggen dat elke onhandigheid of slordigheid je meteen problemen kan opleveren. Als er een nette oplossing wordt opgeleverd, maar er zitten een paar regels code in zoals hierboven getoond, dan is dat te vergeven. Als het project echter al 3 maanden achterloopt op schema en uit een review blijkt dat het lasagne-met-gehaktballencode is dan kun je een moeilijk gesprek verwachten.
[ Voor 14% gewijzigd door Alex) op 24-06-2019 23:18 ]
We are shaping the future
yeah yeah, niet alles is een overheidsproject dat is waar ... maar dat is meer curry-in-a-hurry dan italiaansekeuken bij mijn weten:
[...]
Als het een fixed price-project is? Vergeet het maar. Bij Fixed Price betaalt de klant niet meer dan wat is afgesproken.
Als je meer nodig hebt moet je met hangende pootjes naar de klant, en hopen dat je een goed verhaal hebt (bijvoorbeeld: significant meerwerk door een onverwachte API-wijziging). Maar het kan ook zijn dat de klant zegt "Nee, dit is het en ik verwacht dat je levert conform afspraak."
Bij Time and Material (T&M) wordt er inderdaad gewerkt met billable hours, maar dat is geen vrijbrief om maar wat aan te prutsen. Een klant wil -in de regel- verantwoording zien voor de gemaakte uren en zal niet zomaar blijven betalen. Als je een beetje pech hebt schakelen ze een derde partij in om het geleverde werk te reviewen. Als die dan een rapport oplevert waarin staat dat er slordig werk is opgeleverd, slaat de klant je daarmee om je oren. Voor jou 3 anderen hoor
Dat wil niet zeggen dat elke onhandigheid of slordigheid je meteen problemen kan opleveren. Als er een nette oplossing wordt opgeleverd, maar er zitten een paar regels code in zoals hierboven getoond, dan is dat te vergeven. Als het project echter al 3 maanden achterloopt op schema en uit een review blijkt dat het lasagne-met-gehaktballencode is dan kun je een moeilijk gesprek verwachten.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
/u/243953/crop56f55a7bcf291.png?f=community)
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
Een praktische opdracht die past bij de functie.
Een web developer zou ik een simpele web api laten bouwen, een frontend ervoor bouwen, database modelleren etc.
Dan zie je wat iemand voor werkervaring meeneemt als je kijkt naar wat hij of zij zelf erbij betrekt (qua security, performance, schaalbaarheid, testbaarheid etc).
Een opdracht over een kubus is leuk (ik begin al te puzzelen
), maar zegt zo weinig over iemand zijn toepasbare kennis.PS
Er zit een wetmatigheid in het aantal steentjes.
2 vlakken zijn volledig, 10x10
2 vlakken missen de randen, 8x10
2 vlakken missen de randen rondom, 8x8
Dus 2 x (100 + 80 + 64) = 488 steentjes.
Een eenvoudiger alternatief is substractie. 10^3 - 8^3 = 1000 - 512 = 488.
[ Voor 19% gewijzigd door Lethalis op 25-06-2019 12:01 ]
Ask yourself if you are happy and then you cease to be.
Dan moet je iemand al een basis geven, want anders gaat dat niet lukken. Of het gaat te veel tijd kosten. Misschien heeft die persoon geen ervaring met de desbetreffende framework en libraries, waardoor het weer lastiger wordt.:
[...]
Een praktische opdracht die past bij de functie.
Een web developer zou ik een simpele web api laten bouwen, een frontend ervoor bouwen, database modelleren etc.
Dan zie je wat iemand voor werkervaring meeneemt als je kijkt naar wat hij of zij zelf erbij betrekt (qua security, performance, schaalbaarheid, testbaarheid etc).
Een opdracht over een kubus is leuk (ik begin al te puzzelen
Wij vragen altijd of ze zelf iets kunnen laten zien voor zover mogelijk, en dan stellen we daar een paar vragen over. Bijvoorbeeld waarom ze bepaalde keuzes hebben gemaakt, dan pik je de bullshitters er vaak snel uit.
Het is makkelijker om een kubus van 8x8x8 af te trekken van de volledige van 10x10x10
Maar dat bedacht ik ook pas later
Ask yourself if you are happy and then you cease to be.
Ik snap het idee, maar:
- Het word dan echt een opdracht waar iemand wat tijd voor moet vrijmaken/hebben
- Aangenomen dat er niets als basis word gegeven, weet je niet of iemand dan ook lekker kan werken binnen het framework wat je op het werk hebt
Zit wat in, maar dan ben je wel heel erg aan het leunen op de cultuur dat developers in hun vrije tijd ook met programmeren bezig moeten zijn. En dat is iets wat ik persoonlijk niet zou willen aanwakkeren of vanuit zou willen gaan.
Dat is inderdaad het antwoord. De volgende stap zou zijn om het generieker te maken voor een kubus van N bij N bij N. Daarna de vraag of ze die formule kunnen versimpelen, om te kijken of ze uiteindelijk op dit kunnen komen:
:
[...]
Het is makkelijker om een kubus van 8x8x8 af te trekken van de volledige van 10x10x10
Maar dat bedacht ik ook pas later
klopt, maar goed ze willen toch een beetje systematische uitleg ?:
[...]
Het is makkelijker om een kubus van 8x8x8 af te trekken van de volledige van 10x10x10
Maar dat bedacht ik ook pas later
Zullen ze het krijgen ook
, wederom ook hier, premature optimalisatie Overigens wel gek, doe het eigenlijk regelmatig met solid-modelling, kubusjes van elkaar aftrekken, toch niet de eerste gedachte, eerst maar systematisch opbouwen ipv de simpelste oplossing kiezen.
[ Voor 20% gewijzigd door gekkie op 25-06-2019 12:36 ]
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
Als iemand met een dergelijk antwoord komt dan zijn dat gewoon bonuspunten. Een hele elegante oplossing voor wat er gevraagd is, waar je meestal niet direct aan denkt. Soort out of the box denken, maar dan inside the box
Ik zat zelf te denken aan 6*10x10 - 12*10 + 8.
6 vlakken van 10x10. Maar dan tel je de edges dubbel, dus 12 edges van 10 blokjes eraf. Maar dan haal je er per hoekpunt weer een teveel af, dus 8 hoekpunten er weer bij.
In het generieke geval dus: 6n2 - 12n + 8.
Met de andere oplossing: n3 - (n-2)3
= n3 - (n - 2)(n2 - 4n + 4)
= n3 - ((n3 - 4n2 + 4n) - (2n2 - 8n + 8))
= n3 - (n3 - 4n2 + 4n - 2n2 + 8n - 8)
= n3 - (n3 - 6n2 + 12n - 8)
= n3 - n3 + 6n2 - 12n + 8
= 6n2 - 12n + 8
QED
[ Voor 48% gewijzigd door .oisyn op 25-06-2019 12: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.
Klopt.:
[...]
Als iemand met een dergelijk antwoord komt dan zijn dat gewoon bonuspunten. Een hele elegante oplossing voor wat er gevraagd is, waar je meestal niet direct aan denkt. Soort out of the box denken, maar dan inside the box
Interessante mengeling van additie en subtractie
Vele wegen die naar Rome leiden ...
Vul eens 1 in:
[...]
6n2 - 12n + 8
QED
Gaat bij mij natuurlijk ook fout, maar je mag het bereik van een domein nooit vergeten.
Dus volgende stappen zijn alle input kleiner dan 0 niet accepteren, en een if statement voor de 0 en 1 situatie.
Ask yourself if you are happy and then you cease to be.
Doet er niet toe, gevraagd werd op een kubus van 10 groot. De generalisatie naar n deed ik om te bewijzen dat hij overeenkwam met de andere oplossing, en niet alleen toevallig bij n=10:
[...]
Vul eens 1 in
[ Voor 6% gewijzigd door .oisyn op 25-06-2019 13:12 ]
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.
Maar de generalisatie is dus alleen maar geldig als de generaal geen andere dingen zit te doen in het kleinste hokje. Kortom het stinkt:
[...]
Doet er niet toe, gevraagd werd op een kubus van 10 groot. De generalisatie naar n deed ik om te bewijzen dat hij overeenkwam met de andere oplossing, en niet alleen toevallig bij n=10
Geef mij maar eens een generieke oplossing die werkt voor n=1 of n=2, ben erg benieuwd.:
[...]
Maar de generalisatie is dus alleen maar geldig als de generaal geen andere dingen zit te doen in het kleinste hokje. Kortom het stinkt
Overigens is de oplossing die .oisyn gaf met de vlakken - ribben + hoeken ook de oplossing die ik zelf als eerste had.
Maar goed, de vraag was dus: als niet dit soort dingen, wat dan wel? En nu het toch over dit soort vraagstukken gaat: zijn er nog mensen die meer van dit soort dingetjes weten? Vind ze zelf wel grappig en kunnen handig zijn om te weten voor sollicitaties
We namen aan dat de n3 - (n-2)3 correct was. Mijn oplossing geeft exact dezelfde output als die oplossing. Het domein komt dus automatisch ook overeen met die oplossing.
Maar goed, zelfde bijdehandmodus dan:
En wat als n=√5? Of n=34+5i?
[ Voor 26% gewijzigd door .oisyn op 25-06-2019 13:31 ]
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.
Maar dan is er toch geen generalisatie mogelijk zonder ook de grenzen aan generieke oplossing te geven (en de uitzonderingsgevallen eventueel los te definieren in dit geval), zoals iemand eerder al aangaf ?
Ook eentje die ik als eerste overwogen heb, maar toch maar gekozen voor volledig opbouwen / addities ipv een mengeling met subtracties.
Op zich een mengeling kan geen kwaad, dit test wat (ruimtelijk)inzicht en eventueel decomposen van je probleem in hapbare brokken. Stukje waarbij je wel syntax en taalkennis test hoeft ook niet per se verkeerd te zijn zoals het remainder probleem in feite was. Bij de gekozen oplossing zou doorvragen op het waarom van de oplossing misschien naar voren hebben gebracht dat deze oplossing gekozen is omdat men niet zeker wist of en hoe er een remainder functies is in die taal (sommatie idem dito). Afhankelijk van het gewenste niveau van de kandidaat.Maar goed, de vraag was dus: als niet dit soort dingen, wat dan wel? En nu het toch over dit soort vraagstukken gaat: zijn er nog mensen die meer van dit soort dingetjes weten? Vind ze zelf wel grappig en kunnen handig zijn om te weten voor sollicitaties
Basic tooling is misschien ook nog wel iets om aan te stippen.
Als er gewerkt moet worden met (SQL) databases, daar wat vragen over, optimalisatie van een query ?
Er lijkt me op zich genoeg te verzinnen, al blijft het belangrijkste het waarom van de gekozen oplossing.
Vraag is ook of en hoeveel je parate kennis wilt testen en hoeveel op inzicht en het kunnen vergaren en interpreteren van de benodigde kennis op dat moment.
En als je bij de TU/e in de sollicitatiecommissie zit is het makkelijk .. to be V or not to be V.
Owhhh maar dan heb ik nog een veel kortere en eenvoudigere generieke oplossing voor dat domein:
488.
Maar goed misschien zijn we nu alle sollicitatie-bonus-punten wel weer aan het verspelen als muggeziftende autisten.
[ Voor 13% gewijzigd door gekkie op 25-06-2019 13:40 ]
Maar het domein was niet n=10.:
Owhhh maar dan heb ik nog een veel kortere en eenvoudigere generieke oplossing voor dat domein:
488.
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.
Ik blijf het als een programmeur zien, dus wanneer je alleen een unsigned integer als input accepteert, hoef je ook alleen de 0 en 1 situatie af te vangen:
[...]
En wat als n=√5? Of n=34+5i?
Uiteindelijk wil je correcte code. Dus het is niet eens zo bijdehand bedoeld van mij
Ask yourself if you are happy and then you cease to be.
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.
Kan ik begrijpen, de afweging:
1. uint dwingt positief getal af, maar heeft als nadeel dat het een veel hogere waarde kan hebben dan een int (met risico op overflow ergens anders in de code).
2. int gebruiken kan ook, als je een ArgumentException geeft bij een negatief getal (al dan niet met behulp van een framework).
3.De overdreven oplossing kan een custom type zijn.
Choose your poison
Optie 2 is wellicht de veiligste.
Ask yourself if you are happy and then you cease to be.
Maar dat is ook maar een arbitraire regel die in de verste verte niet opweegt tegen de problemen die je krijgt met het mixen van ints en uints in code. Je zult hoe dan ook je domein af moeten dekken. Als je bijvoorbeeld de n3 - (n-2)3 oplossing pakt mag n ook niet groter zijn dan 1290 bij een 32 bits signed int (al blijft het bij two's complement op zich wel lang goed gaan). Het testen op 0 is nauwelijks extra moeite
[ Voor 5% gewijzigd door .oisyn op 25-06-2019 14:20 ]
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.
Een generieke formule die werkt voor n=1 of n=2, is er niet. Als je er een sequence van maakt is de 2nd difference steeds een stap van 12, behalve bij n=1 en n=2 (19 tussen 1 en 2, 8 tussen 2 en 3). Zonder check daarop gaat het dus niet werken.
Een hele crappy pseudo-recursieve functie die daar gebruikt van maakt
JavaScript:
Speciale cases voor 1 en 2 en x^3-x(-2)^3 is waarschijnlijk gewoon de efficiëntste manier.1
2
3
4
5
6
7
8
9
10
11
12
13
14
| let fn = (n) => { if (n == 1) { return 1; } else if (n == 2) { return 4; } else if (n == 3) { return 26; } // return 30 + 12 * (n - 4) + fn(n - 1); // edit: return (12 * n - 18) + fn(n - 1); } |
Edit: domme fout, n=2 is natuurlijk 8.
JavaScript:
1
2
3
4
5
6
7
8
9
| fn = (n) => { if (n == 1) { return 1; } else if (n == 2) { return 8; } return (12 * n - 18) + fn(n - 1); } |
[ Voor 13% gewijzigd door ThomasG op 25-06-2019 15:09 ]
Komt nog eens bij dat dit een vrij 'standaard' vraag is, en je er dus, als je hem vaker gehad hebt, heel snel doorheen bent. Het is de som van de lengte van de ribben en het oppervlak tussen die ribben. En dat weet ik dan omdat 't toevallig terugkwam in de Advent of Code deze winter
https://niels.nu
2 *n2 + 2 * ((n-2) *n) + 2 * ((n-2) * (n-2)) werkt ook gewoon voor n=2.:
[...]
Een generieke formule die werkt voor n=1 of n=2, is er niet. Als je er een sequence van maakt is de 2nd difference steeds een stap van 12, behalve bij n=1 en n=2 (19 tussen 1 en 2, 8 tussen 2 en 3). Zonder check daarop gaat het dus niet werken.
Een hele crappy pseudo-recursieve functie die daar gebruikt van maaktJavaScript:Speciale cases voor 1 en 2 en x^3-x(-2)^3 is waarschijnlijk gewoon de efficiëntste manier.
Die formule is gebaseerd op het idee dat je het in drie stappen bepaalt. De twee zijkanten zijn dan n*n. Daarna de voor en achterkant 'zonder de zijkanten' (dus 2 keer n * (n-2)). dan de boven en onderkant zonder zijkanten en voor- en achterkant, dus 2 keer (n-2)*(n-2).
Volgens mij ontkom je voor 1 niet aan een special case, al heb ik er ook niet heel diep over nagedacht.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
:strip_exif()/u/306933/ezgif.com-optimize.gif?f=community)
2x Dell UP2716D | R9 7950X | 128GB RAM | 980 Pro 2TB x2 | RTX2070 Super
.oisyn: Windows is net zo slecht in commandline als Linux in GUI
/u/296460/beaker_s.png?f=community)
Toch zie ik persoonlijk niet zo het nut van 'wiskundige' puzzeltjes in bij het zoeken naar een goede programmeur. Natuurlijk als je in een specifieke industrie of domein zit kan het toegevoegde waarde hebben, maar ik ken genoeg slimme mensen die een zootje van hun code maken en ook niet makkelijk inzien hoe het beter kan.
Programmeren is niet alleen systematisch denken of slimme algoritmes verzinnen. Het heeft naar mijn mening ook een creatieve kant.
Structureren, ordenen, het grote plaatje zien, zinnige interfaces bedenken, interactie tussen componenten modelleren, documenteren, handigheid met diverse tools, zelfinzicht, omgaan met feedback, omgaan met teamleden, datastructuren, goede tests schrijven, documentatie lezen, jezelf willen verbeteren, communiceren en ga zo maar door. Allemaal zaken die je niet test met puzzeltjes, maar die voor functioneren een team ook heel zijn om dingen gedaan te krijgen.
Hoe je in al deze zaken inzicht krijgt tijdens een sollicitatiegesprek is dan weer een 2e
Programmeren is niet alleen systematisch denken of slimme algoritmes verzinnen. Het heeft naar mijn mening ook een creatieve kant.
Structureren, ordenen, het grote plaatje zien, zinnige interfaces bedenken, interactie tussen componenten modelleren, documenteren, handigheid met diverse tools, zelfinzicht, omgaan met feedback, omgaan met teamleden, datastructuren, goede tests schrijven, documentatie lezen, jezelf willen verbeteren, communiceren en ga zo maar door. Allemaal zaken die je niet test met puzzeltjes, maar die voor functioneren een team ook heel zijn om dingen gedaan te krijgen.
Hoe je in al deze zaken inzicht krijgt tijdens een sollicitatiegesprek is dan weer een 2e
Inderdaad koude rillingen. Vaak wordt er ergens anders in de code weer gebruik gemaakt van signed ints bij invoer of het resultaat want "we voeren alleen kleine getallen in" of dat men toch om een gekke reden negatieve waardes gaat invoeren.
Simpel, als sollicitant vragen wat een bedrijf belangrijk vind en als bedrijf aangeven wat jij belangrijk vindt. Vervolgens kijken of je visie op die punten overeenkomt en hoe je dat kan bewijzen.:
Toch zie ik persoonlijk niet zo het nut van 'wiskundige' puzzeltjes in bij het zoeken naar een goede programmeur. Natuurlijk als je in een specifieke industrie of domein zit kan het toegevoegde waarde hebben, maar ik ken genoeg slimme mensen die een zootje van hun code maken en ook niet makkelijk inzien hoe het beter kan.
Programmeren is niet alleen systematisch denken of slimme algoritmes verzinnen. Het heeft naar mijn mening ook een creatieve kant.
Structureren, ordenen, het grote plaatje zien, zinnige interfaces bedenken, interactie tussen componenten modelleren, documenteren, handigheid met diverse tools, zelfinzicht, omgaan met feedback, omgaan met teamleden, datastructuren, goede tests schrijven, documentatie lezen, jezelf willen verbeteren, communiceren en ga zo maar door. Allemaal zaken die je niet test met puzzeltjes, maar die voor functioneren een team ook heel zijn om dingen gedaan te krijgen.
Hoe je in al deze zaken inzicht krijgt tijdens een sollicitatiegesprek is dan weer een 2e
Ik zie sollicitatiegesprekken altijd als een spelletje en om een spel te winnen moet je bekend zijn met de regels
"Doubt—the concern that my views may not be entirely correct—is the true friend of wisdom and (along with empathy, to which it’s related) the greatest enemy of polarization." -- Václav Havel
/u/56000/neuken.png?f=community)
Mijn setup was gewoon een opdracht die gemaakt moest worden. Geen limitaties, dus prima om Google erbij te pakken. In eerste instantie even de tijd gunnen om zijn/haar eigen IDE en whatever te installeren en dat alles "goed" staat. Hoe kut is het dat je altijd op een Mac werkt en vervolgens een opdracht op een Windows bak moet doen waar alleen notepad++ op staat.. Daarom dus.
Vervolgens niet perse over de schouder mee kijken maar wel enigszins aanwezig zijn. Qua opdracht staat er vooral gespecificeerd dat men voor deze ene keer excessief veel comments moet maken, qua denkwijzes etc.
Uiteindelijk lopen we er samen doorheen en ik ben vooral benieuwd naar het proces, hoe/wat iemand zoekt en hoe iemand iets oplost.
Men wordt zeker niet afgerekend op hoeveel ze kunnen doen, dat vertel ik al aan het begin. Ik vertel sowieso wat de bedoeling is en waar ik allemaal naar kijk (het totaal plaatje dus).
Dit is vaak dan na een eerste "persoonlijk" gesprek, en visa-versa laat ik van alles van het bedrijf / applicatie zien.
Toentertijd in elk geval nooit een slechte keuze genomen met het aannemen
Vervolgens niet perse over de schouder mee kijken maar wel enigszins aanwezig zijn. Qua opdracht staat er vooral gespecificeerd dat men voor deze ene keer excessief veel comments moet maken, qua denkwijzes etc.
Uiteindelijk lopen we er samen doorheen en ik ben vooral benieuwd naar het proces, hoe/wat iemand zoekt en hoe iemand iets oplost.
Men wordt zeker niet afgerekend op hoeveel ze kunnen doen, dat vertel ik al aan het begin. Ik vertel sowieso wat de bedoeling is en waar ik allemaal naar kijk (het totaal plaatje dus).
Dit is vaak dan na een eerste "persoonlijk" gesprek, en visa-versa laat ik van alles van het bedrijf / applicatie zien.
Toentertijd in elk geval nooit een slechte keuze genomen met het aannemen
Want grote getallen zijn idd wél een goede reden om unsigned ints te gebruiken
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.
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!
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.
:strip_icc():strip_exif()/u/246777/crop5665347035c66.jpeg?f=community)
Dat was mijn reactie ook gelijk!
Gefeliciteerd @Firesphere
Hopelijk heb jij veel plezier in je nieuwe functie.
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
Gefeliciteerd @Firesphere!
Amper bekend zijn met C++ en continu dingen moeten opzoeken:
Gelukkig bouwt DuckDuckGo geen profiel op
Amper bekend zijn met C++ en continu dingen moeten opzoeken:
Gelukkig bouwt DuckDuckGo geen profiel op
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
Bij een database primary keys (sequence of increment) is dat soms inderdaad de reden, want die kunnen toch niet negatief zijn (tenzij je rare dingen doet). Je kunt dan namelijk zonder extra schijfruimte in te nemen, grof weg 2 keer het aantal rijen opslaan. En voor indices is dat erg fijn. Een signed 32 bit PK kan te weinig zijn, en 64 bit primary keys zijn weer overkill en hebben een performance impact.:
[...]
Want grote getallen zijn idd wél een goede reden om unsigned ints te gebruiken
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.
Erg herkenbaar, ik zie deze regelmatig langs komen:
Amper bekend zijn met C++ en continu dingen moeten opzoeken:
[Afbeelding]
Gelukkig bouwt DuckDuckGo geen profiel op
[ Voor 5% gewijzigd door bauke1994 op 26-06-2019 09:28 ]
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
“Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.”
Bijvoorbeeld iets als adressen in Europa. Misschien zijn er nu 1,5 miljard (nu ja, in werkelijkheid minder gok ik, maar het is een voorbeeld), is 2 miljard wat riskant, maar zullen het er nooit 4 miljard worden.
Er zijn altijd wel uitzonderingen met datasets die groot zijn, maar nog amper of niet meer groeien.
Of stel nu dat je toch maar een 64 bit key hebt genomen, maar je moet belachelijk veel gaan jongleren met de data. Als je nu 3 miljard entries hebt, kan je prima in je jongleer code met een 32 bit unsigned int werken om wat snelheid te winnen. Tegen dat je 5 jaar later aan de limiet komt (of bent, want je gaat het vergeten en het in de error logging zien
) maak je er even een 64 bit van en klaar is kees.Dat gezegd zijnde zal zo'n situatie inderdaad wel zeldzaam zijn, en zal de performantie winst dikwijls niet eens opwegen tegen het uur onderzoek wat je ernaar moet doen.
Ach, een project bij ons had laatst binnen maand al een koppeltabelletje van 750GB. Zou dus niet willen zeggen dat IDs en schijfruimte helemaal geen issue zouden kunnen zijn.
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Willekeurig overal (btree) indexen op mikken kan er zo nog een veelvoud van maken:
Ach, een project bij ons had laatst binnen maand al een koppeltabelletje van 750GB. Zou dus niet willen zeggen dat IDs en schijfruimte helemaal geen issue zouden kunnen zijn.
.
Kwestie van je OLTP en je OLAP op één model doen. Succes gegarandeerd.:
[...]
Willekeurig overal (btree) indexen op mikken kan er zo nog een veelvoud van maken
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger Dijkstra
Gelukkig dan maar dat niemand dat zegt:
Ach, een project bij ons had laatst binnen maand al een koppeltabelletje van 750GB. Zou dus niet willen zeggen dat IDs en schijfruimte helemaal geen issue zouden kunnen zijn.
https://niels.nu
:strip_icc():strip_exif()/u/206968/325134.jpg?f=community)
Als je je in uberprogressief Sillicon Valley zo voorstelt aan een vrouw heb je meteen een #metoo aan je broek hangen. Misogynistisch patriarchaal zwijn dat je bent.
Feli trouwens
Engineering is like Tetris. Succes disappears and errors accumulate.
Ja, dat ook. Al maakt dat bij ons niet heel veel uit, want er is geen koppeling met een gebruiker mogelijk.
En een uuid ziet er natuurlijk veel l33t haxors uit dan een suffe integer (unsigned of niet
)
[ Voor 15% gewijzigd door Matis op 26-06-2019 22:47 ]
If money talks then I'm a mime
If time is money then I'm out of time
:strip_icc():strip_exif()/u/437778/crop684040f89be83_cropped.jpg?f=community)
@Verwijderd Niet YouTube: Richard Strauss - Also sprach Zarathustra, Op. 30 ? Valt me toch weer tegen
🠕 This side up
Verwijderd
Die pauken klinken wel als mijn constanten. Verder wat veel grandeur:
@Verwijderd Niet YouTube: Richard Strauss - Also sprach Zarathustra, Op. 30 ? Valt me toch weer tegen
Hoe doen jullie het eigenlijk qua database indexes?
UUID's zijn lekker uniek en random, maar daardoor ook vrij nasty als primary index (veel fragmentatie).
Nu kun je natuurlijk extra ruimte reserveren in de index, maar ik ben benieuwd
SQL Server heeft ook sequentiële UUID'S, maar that kinda defeats the purpose (wat enumeration attacks e.d. betreft).
Ook kun je natuurlijk een clustered sequentiële surrogate index gebruiken en een non clustered index voor de UUID's die je regelmatig defragmenteert.
Geen idee of dat best practice is echter. Al geeft het wel minder I/O overhead (om te defragmenteren).
PS
https://tomharrisonjr.com...s-be-careful-7b2aa3dcb439
Hier wordt aangeraden idd beide te gebruiken. Sequentiële ID's voor interne verwijzingen, random UUID's voor externe doeleinden.
[ Voor 40% gewijzigd door Lethalis op 27-06-2019 15:39 ]
Ask yourself if you are happy and then you cease to be.
Dit topic is gesloten.