De Devschuur Coffee Corner - Iteratie ➓

[TheNephilim]

Nee Windows 7 vond ik altijd prettig werken, met Windows 8.x was het iets minder, maar met Windows 10 is het allemaal weer dik voor elkaar. Geen problemen eigenlijk, zowel thuis als op kantoor niet.

[Hydra]

.Gertjan. schreef op woensdag 07 september 2016 @ 09:30:
Er worden op vreemdere manieren fetishes geboren

En bedankt voor dat mental image...

TheNephilim schreef op woensdag 07 september 2016 @ 10:04:
Nee Windows 7 vond ik altijd prettig werken, met Windows 8.x was het iets minder, maar met Windows 10 is het allemaal weer dik voor elkaar. Geen problemen eigenlijk, zowel thuis als op kantoor niet.

Ik ben toen 8 kwam afgehaakt. Ik geloof best dat 10 een verbetering is maar ik heb eigenlijk geen enkele reden om Windows te gebruiken. Werk als Java dev en m'n Mac voldoet prima. Sowieso zijn er als je rondkijkt op Java conferenties e.d. relatief weinig Java devs die Windows gebruiken. Je deployed toch wel erg vaak op Linux systemen en dan is 't wel handig als je eigen systeem daar redelijk naadloos op aansluit. We hebben hier dus bijvoorbeeld ook geen batch of powershell scripts, alles is .sh.

[ Voor 72% gewijzigd door Hydra op 07-09-2016 10:25 ]

[.Gertjan.]

TheNephilim schreef op woensdag 07 september 2016 @ 10:04:
Nee Windows 7 vond ik altijd prettig werken, met Windows 8.x was het iets minder, maar met Windows 10 is het allemaal weer dik voor elkaar. Geen problemen eigenlijk, zowel thuis als op kantoor niet.

W10 is inderdaad een zeer goed werkbaar systeem. W8.1 was op een gegeven moment ook redelijk, maar toch voelde het soms niet helemaal compleet/lekker. Vind het sowieso een rare actie van Microsoft om de W8 experience naar Server 2012 te brengen, want daar stoor ik mij dan wel weer enorm aan. Een server OS wat zich voordoet als een tablet OS, ugh...

Hoewel W10 qua experience zeker goed te doen is, merk ik toch nog regelmatig dat Microsoft het nog niet helemaal "klaar" heeft. Er zitten toch nog wel enkele mismatches qua styling (sommige dingen zijn in de nieuwe stijl, sommige in de oude) of waar dingen zitten (zo is nog steeds niet alles via het nieuwe control-panel te doen).

Hydra schreef op woensdag 07 september 2016 @ 10:22:
[...]
En bedankt voor dat mental image...

Graag gedaan, never hurts to help

[TheNephilim]

.Gertjan. schreef op woensdag 07 september 2016 @ 10:44:
[...]

W10 is inderdaad een zeer goed werkbaar systeem. W8.1 was op een gegeven moment ook redelijk, maar toch voelde het soms niet helemaal compleet/lekker. Vind het sowieso een rare actie van Microsoft om de W8 experience naar Server 2012 te brengen, want daar stoor ik mij dan wel weer enorm aan. Een server OS wat zich voordoet als een tablet OS, ugh...

Ja dat was zeker geen succes. Na het installeren van wat tooltjes had je Start weer terug, wat voor mij persoonlijk het grootste pijnpunt was.

Hoewel W10 qua experience zeker goed te doen is, merk ik toch nog regelmatig dat Microsoft het nog niet helemaal "klaar" heeft. Er zitten toch nog wel enkele mismatches qua styling (sommige dingen zijn in de nieuwe stijl, sommige in de oude) of waar dingen zitten (zo is nog steeds niet alles via het nieuwe control-panel te doen).

Zoiets verbaast me nog altijd; bij launch kan ik me er nog iets bij voorstellen, maar dat het nog steeds niet helemaal consistent is moet toch niet kunnen eigenlijk. Persoonlijk denk ik dat het nogal een uitdaging is; de vrij uitgebreide instellingen-menu's ombouwen naar de (te) simpele nieuwe stijl.

Hydra schreef op woensdag 07 september 2016 @ 10:22:

[...]

Ik ben toen 8 kwam afgehaakt. Ik geloof best dat 10 een verbetering is maar ik heb eigenlijk geen enkele reden om Windows te gebruiken. Werk als Java dev en m'n Mac voldoet prima. Sowieso zijn er als je rondkijkt op Java conferenties e.d. relatief weinig Java devs die Windows gebruiken. Je deployed toch wel erg vaak op Linux systemen en dan is 't wel handig als je eigen systeem daar redelijk naadloos op aansluit. We hebben hier dus bijvoorbeeld ook geen batch of powershell scripts, alles is .sh.

Zowel thuis als op kantoor gebruik ik Windows; thuis wil ik 's avonds nog wel regelmatig een potje gamen en dan is Windows eigenlijk stiekem nog steeds wel een must. Op kantoor heb ik PhpStorm/VirtualBox/SourceTree/NodeJS/HipChat/Git Bash in gebruik, waarbij alleen de Laravel toolset (homestead etc.) een beetje meer voorkeur heeft voor MacOS.

[ Voor 27% gewijzigd door TheNephilim op 07-09-2016 10:56 ]

[Hydra]

.Gertjan. schreef op woensdag 07 september 2016 @ 10:44:
W10 is inderdaad een zeer goed werkbaar systeem. W8.1 was op een gegeven moment ook redelijk, maar toch voelde het soms niet helemaal compleet/lekker. Vind het sowieso een rare actie van Microsoft om de W8 experience naar Server 2012 te brengen, want daar stoor ik mij dan wel weer enorm aan. Een server OS wat zich voordoet als een tablet OS, ugh...

Tja. Da's voor mij een van de grootste pijnpunten van Windows. Ik krijg daar continue het gevoel dat marketing en styling belangrijker geacht wordt dan een goed werkend OS. Updates door je strot geschoven krijgen is belangrijker dan dat jij een presentatie kunt geven. En wat er op de achtergrond gebeurd is zo ondoorzichtig als wat. Ik heb op conferenties nu al meerdere malen meegemaakt dat iemand tijdens een presentatie een forced update kreeg. Hoe moeilijk is het om gewoon de niet-intrusive manier dat MacOS het doet te kopieren?

TheNephilim schreef op woensdag 07 september 2016 @ 10:50:
Zowel thuis als op kantoor gebruik ik Windows; thuis wil ik 's avonds nog wel regelmatig een potje gamen en dan is Windows eigenlijk stiekem nog steeds wel een must.

Ja, dat is het voornaamste nadeel. Best bizar dat de meeste indie devs wel gewoon cross-platform ontwikkelen maar dat vooral de AAA publishers last hebben van jaren legacy waardoor ze vast zitten aan een vendor lock-in. Nu zijn Macs gewoon geen game machines (heb een nieuwe MacBook pro maar Shadow of Mordor gaat vrij 'meh') maar tegenwoordig hebben ze prima capabilities.

Ik vind het jammer dat er zo'n monopolie ontstaan is. Daar profiteert alleen de monopolist van.

[ Voor 26% gewijzigd door Hydra op 07-09-2016 11:03 ]

[wackmaniac]

Het is meer dat DirectX niet beschikbaar is voor andere platformen en die naar mijn weten vaak wordt gebruikt. De indie-developers kiezen wat sneller voor OpenGL en aanverwante bibliotheken, waardoor de games makkelijker naar een ander platform kunnen. Maar dat kan ik natuurlijk ook helemaal verkeerd hebben

[Voutloos]

Imnsho allemaal gelul, hoe je het ook went of keert, blijft Linux op de desktop voor de meesten nog steeds ruk. Dáár zit het Echte Probleem.

Juist omdat causal games vrij populair zijn; als de toevallige gamer vaker voor zijn lol naar Linux overgestapt was, zou daar al meer de vraag onstaan en kunnen de games welke iets minder van de hele tech stack vragen het eerste gefixed worden (gebeurt al lafjes). Pas als dat aanslaat mag je grotere inspanningen verwachten.

Overigens meermaals geprobeerd, met name 40u/wk op werk, maar mn kantoor mac draait nu weer heerlijk soepel OS X.

Onderbouw van harte dat Linux nu bruikbaar is, mag je van mij helemaal vinden maar ik waag me er weer een paar jaar niet aan. Schaam me er ook niet voor of zo, ik kan namelijk mijn werk (webdev) heel efficient doen, ipv dat ik met te grote regelmaat bezig ben met de instabiele window manager vh jaar, of de onvergeeflijke *&%@ TERINGZOOI welke praktisch elke $distro van printer en audiomanagement maakt. Dingen als "Ja, dat zit zo en zo in Arch, want ALSA en historisch en moeilijk moeilijk, maar hier is een package voor een mixer welke er inderdaad helaas 1970 uit ziet" : Lekker boeiend, geluid moet gewoon werken en als ik me een driver developer wil voelen maak ik dat liever officieel onderdeel van mijn takenpakket.

Zowel conservatieve als progressieve distro's geprobeerd, bij beide teveel afleiding door ongemakjes welke uiteraard steeds te fixen zijn. Echter is dat het niet waard, want mijn belangrijkste tools (browsers en IDE) werken toch op elk OS exact hetzelfde. Thuis heb ik Windows 10, op werk dus OS X. Welke minor versie beide zijn weet ik niet; autoupdate werkt, het OS werkt, dus lekker belangrijk.

offtopic:
Quote is mijn frustie paraphrase. Origineel behulpzaam en netjes toegelicht door collega waarvoor dank, maar het ligt gewoon aan hoe onnodig ik de details/kennis/fixes ervaar en ik denk graag dat een groot deel van de potentiele gebruikers er zo in zit.

[ Voor 6% gewijzigd door Voutloos op 07-09-2016 12:03 ]

[RayNbow]

Hmm, WPF vindt 't niet zo leuk als je in een korte tijd heel veel BitmapImages aanmaakt (ook nog asynchroon en van afbeeldingen van 27 MB per stuk)... Ook heel fijn dat het stilletjes faalt, zodat je op een gegeven moment naar een lege ImageControl zit te kijken i.p.v. een foutmelding.

(Workaround: de boel throttlen en de kans creëren om eerdere asynchrone loads te cancellen.)

[.oisyn]

[Tjolk]

Dat is toch wel een aluminium unibody behuizing hoop ik? Met vacOS en een Appstore waar je voor $ 3,99 een stofzuigerzak kunt aanschaffen?

[DevWouter]

Ger schreef op woensdag 07 september 2016 @ 13:06:
Dat is toch wel een aluminium unibody behuizing hoop ik? Met vacOS en een Appstore waar je voor $ 3,99 een stofzuigerzak kunt aanschaffen?

Die stofzuigerzakken hadden ze wel, maar die zijn inmiddels uit productie genomen. Toen de perschef van apple om reactie gevraagd werd antwoorde hij met volgende: "Het apparaat is zo goed. Het apparaat is zo fantastisch. Het apparaat zuigt gewoon weg niet."

[Skyaero]

Ger schreef op woensdag 07 september 2016 @ 13:06:
Dat is toch wel een aluminium unibody behuizing hoop ik?

Superdun, zodat ie lekker buigt.

Met vacOS

Codenaam "Anteater"

en een Appstore waar je voor $ 3,99 een stofzuigerzak kunt aanschaffen?

Tikfoutje? Je bedoelt natuurlijk $ 39,90. En de stofzuigerzak heeft een unieke inkeping die geen enkele andere stofzuigerzak heeft, waardoor alleen originele Apple stofzuigerzak past.

Oh en in Apple winkel wordt je natuurlijk eerst leeggezogen door een hippie voordat je er een mag kopen

[Tjolk]

Skyaero schreef op woensdag 07 september 2016 @ 13:47:
[...]
Oh en in Apple winkel wordt je natuurlijk eerst leeggezogen door een hippie voordat je er een mag kopen

Apples implementatie van SaaS? Dat valt dermate dubbelzinnig op te vatten dat ik daar maar geen plaatje van Google.

[Hydra]

Bam! Het is woensdag en ik heb m'n sprint-taken af!

[Mercatres]

Hydra schreef op woensdag 07 september 2016 @ 15:08:
Bam! Het is woensdag en ik heb m'n sprint-taken af!

En de sprint loopt nog tot?

[.oisyn]

Hydra schreef op woensdag 07 september 2016 @ 15:08:
Bam! Het is woensdag en ik heb m'n sprint-taken af!

Slecht gescheduled dan

[Caelorum]

Ugh ik krijg ze dus al weken niet af. Toppunt was 1 taak die al 8 sprints van een week meeging. Komt doordat er telkens andere dingen even tussendoor moesten worden gedaan (zucht) of de klant besloot dat iets anders toch echt meteen moest worden gedaan (yes...)

[.Gertjan.]

Caelorum schreef op woensdag 07 september 2016 @ 15:19:
Ugh ik krijg ze dus al weken niet af. Toppunt was 1 taak die al 8 sprints van een week meeging. Komt doordat er telkens andere dingen even tussendoor moesten worden gedaan (zucht) of de klant besloot dat iets anders toch echt meteen moest worden gedaan (yes...)

Sprints en scrum zijn leuk als ze lopen zoals ze moeten lopen, loopt het in de soep dan is het echt zwaar ellendig... Klanten en stakeholders kunnen op dat moment namelijk wel haarfijn herinneren dat het doel van Scrum was om een product op te leveren, maar dat ze zelf de boel onder druk zetten met andere verzoeken vergeten ze even voor het gemak...

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Er zijn soms van die dagen dat ik liever banketbakker was geworden...

[Megamind]

Daarom zijn wij weer van Scrum afgestapt en Kanban gaan werken, scheelt een hoop gemieter. Week niet te zwaar inplannen en de vrijdag helemaal openhouden voor overflow.

[Tjolk]

Ik heb ook af en toe het idee dat Scrum over zijn hype heen aan het gaan is. Wij werken er hier niet mee maar hebben er wel met een schuin oog naar gekeken. We proberen de goede dingen ervan te gebruiken maar pragmatisch genoeg te blijven en niet te scrummen om maar te scrummen.

[.Gertjan.]

Megamind schreef op woensdag 07 september 2016 @ 16:07:
Daarom zijn wij weer van Scrum afgestapt en Kanban gaan werken, scheelt een hoop gemieter. Week niet te zwaar inplannen en de vrijdag helemaal openhouden voor overflow.

Die shortcut hebben we ook geprobeerd, maar we werden direct teruggefloten door "de business" dat ze daardoor het overzicht en de grote planning kwijt waren... Mijn commentaar dat door de absolute slachting van Scrum zoals we dat deden ook niet echt inzicht gaf, werd niet gewaardeerd

Dus we zijn weer terug naar Scrum...

[DevWouter]

Sprints zijn heerlijk, maar je moet wel iemand hebben die tegen de klant 10x "nee" durft te zeggen en als je toch "moet" dan vraag je wat de regels zijn betreft structureel overwerk. Als ze daar niet op willen gaan dan geef je aan dat je het spijtig vind maar dat je bij deze zowel de opleverdatum als de kwaliteit niet langer kan garanderen. De planning en verwachting die je hebt afgeven had namelijk niet in deze verandering voor zien.

Maar wat de meeste mensen vergeten is dat de uitvinders van sprints/scrum/XP/kanban ook goed kunnen plannen voordat men sprint/scrum/XP/kanban bedacht had.

[jbdeiman]

DevWouter schreef op woensdag 07 september 2016 @ 16:28:
Sprints zijn heerlijk, maar je moet wel iemand hebben die tegen de klant 10x "nee" durft te zeggen en als je toch "moet" dan vraag je wat de regels zijn betreft structureel overwerk. Als ze daar niet op willen gaan dan geef je aan dat je het spijtig vind maar dat je bij deze zowel de opleverdatum als de kwaliteit niet langer kan garanderen. De planning en verwachting die je hebt afgeven had namelijk niet in deze verandering voor zien.

Maar wat de meeste mensen vergeten is dat de uitvinders van sprints/scrum/XP/kanban ook goed kunnen plannen voordat men sprint/scrum/XP/kanban bedacht had.

Dat is niet per definitie waar, maar het gaat er juist om dat er een korte (dus overzichtelijke) planning gemaakt wordt voor de sprint: We hebben de komende 2 weken x storypoints (uren) beschikbaar en we hebben geschat dat puntje x en x zo lang zijn, waardoor deze gezamenlijk in de sprint opgepakt kunnen worden.

Doel is ook dat er 2 weken lang aan vooraf bepaalde punten wordt gewerkt, zodat die af zijn. Daarna kan weer opnieuw gekeken en geprioriteerd worden, omdat ook het inzicht/ de vraag van een klant kan wijzigen.

Dat het inzicht van een klant binnen die 2 weken alweer wijzigt en andere zaken belangrijk worden is dan best wel ernstig: Als die 2 weken (veel langer duurt een sprint doorgaans niet) niet gewacht kan worden om vervolgens met de nieuwe geprioriteerde zaken aan de slag te gaan gaat er aan de klantkant wat mis. => Ze weten dus eigenlijk zelf niet wat ze willen en veranderen continue van inzicht/ mening. Daar kun je als softwareleverancier nooit tegenop werken.

Het is daarmee juist een mooi middel (geen doel opzich! het hoeft niet 100% volgens zuivere scrum methodiek. RUP op maat, of Kanban zijn ook prima methoden en het kan per bedrijf verschillen wat passend is.

[Hydra]

Mercatres schreef op woensdag 07 september 2016 @ 15:13:
En de sprint loopt nog tot?

Volgende begint maandag. Maar ik werk niet op vrijdagen; dus ik heb iets meer dan een dag over.

.oisyn schreef op woensdag 07 september 2016 @ 15:13:
Slecht gescheduled dan

Nah. Sommige dingen waren, onverwacht, simpeler dan gedacht. En daarnaast hebben we een prima 'ready' backlog dus ik kan gewoon door.

Dit itt een ander team (waar ik weg wou): daar had ik regelmatig gewoon niks te doen in een sprint en geen backlog waaruit je dingen op kunt pakken.

Caelorum schreef op woensdag 07 september 2016 @ 15:19:
Ugh ik krijg ze dus al weken niet af. Toppunt was 1 taak die al 8 sprints van een week meeging. Komt doordat er telkens andere dingen even tussendoor moesten worden gedaan (zucht) of de klant besloot dat iets anders toch echt meteen moest worden gedaan (yes...)

Dan kun je sowieso beter gaan Kanbannen dan gaan Scrummen als je je niet vast kunt leggen op een sprint. Het voornaamste voordeel van sprints is de voorspelbaarheid; wat gaat wanneer af zijn. Dat werkt niet als er steeds brandjes tussendoor komen.

.Gertjan. schreef op woensdag 07 september 2016 @ 15:53:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Dat is geen Scrum maar ScrumBut

Een overstap in een bedrijf naar een agile methodiek als bijvoorbeeld Scrum is vaak vooral ingrijpend voor management. De mensen die het 'werk' doen doen liever gewoon ongestoord hun werk, en agile stimuleert dat alleen maar. Het zijn juist de managers en andere stakeholders die vaak erg moeten wennen aan de hands-off approach.

Daar gaat het dan ook vaak mis. Als er behalve je PO niet-technische mensen (of erger; managers) aan een stand-up meedoen doe je gewoon geen Scrum. Stand-ups zijn pigs-only.

[ Voor 61% gewijzigd door Hydra op 07-09-2016 16:55 ]

[DevWouter]

jbdeiman schreef op woensdag 07 september 2016 @ 16:47:
[...]

Dat is niet per definitie waar

Klopt, mijn verhaal was dan ook eerder over wat er in mijn ogen vaak fout gaat (beide partijen die zich niet kunnen committeren) en wat je nodig hebt om dat te kunnen veranderen.

Het "nee" verkopen is vaak ook een leermiddel voor de klant waardoor hij (in mijn ervaring) in de toekomst serieuzer is met zijn commitment. Dit gebeurt ook bij ontwikkelaars door te wijzen dat ze een datum beloofd hebben. Als je te makkelijk ingeschat hebt en daardoor te veel of te weining tijd heb dan zijn er ook gevolgen.

[Hydra]

DevWouter schreef op woensdag 07 september 2016 @ 16:59:
Het "nee" verkopen is vaak ook een leermiddel voor de klant waardoor hij (in mijn ervaring) in de toekomst serieuzer is met zijn commitment. Dit gebeurt ook bij ontwikkelaars door te wijzen dat ze een datum beloofd hebben. Als je te makkelijk ingeschat hebt en daardoor te veel of te weining tijd heb dan zijn er ook gevolgen.

Het is niet zozeer nee verkopen als meer de klant helpen de juiste beslissingen te maken. Veel bedrijven zijn daar (al dan niet met opzet) slecht in: de verkeerde keuzes van een klant leiden tot meer ontwikkeltijd (en dus vaak geld). Het is m.i. wel penny-wise-pound-foolish want de klant probeert natuurlijk wel experts in te huren.

Ik vind dan ook dat een bedrijf hier bij een klant op moet sturen en een duidelijke indicatie moet geven welke keuzes belangrijk zijn, welke uitgesteld kunnen worden en welke keuzes naar paden leiden waar een andere keuze gaat leiden tot veel tijdverlies. Een simpel rekensommetje als "keuze X leidt tot Y tijdverlies en dus Y * uurloon verlies aan geld maakt 't vaak overduidelijk.

Ik ken alleen veel developers die hier erg slecht in zijn; in termen van de klant denken. Die komen alleen met "dat kan niet" (onzin, alles kan, 't kost alleen vaak te veel geld). Mijn ervaring is dat een goeie technical lead in die gesprekken die deze problemen kan vertalen naar wat de klant begrijpt onmisbaar is.

[jbdeiman]

DevWouter schreef op woensdag 07 september 2016 @ 16:59:
[...]


Klopt, mijn verhaal was dan ook eerder over wat er in mijn ogen vaak fout gaat (beide partijen die zich niet kunnen committeren) en wat je nodig hebt om dat te kunnen veranderen.

Het "nee" verkopen is vaak ook een leermiddel voor de klant waardoor hij (in mijn ervaring) in de toekomst serieuzer is met zijn commitment. Dit gebeurt ook bij ontwikkelaars door te wijzen dat ze een datum beloofd hebben. Als je te makkelijk ingeschat hebt en daardoor te veel of te weining tijd heb dan zijn er ook gevolgen.

Ah, oké. Had ik dat verkeerd gelezen/ begrepen. Inderdaad is "nee" verkopen vaak erg lastig voor partijen. Wij hebben hier ook een omslag gemaakt en "nee" is nu wel een geaccepteerd antwoord. Het is ook heel simpel: We hebben feitelijk 4 officiële releases per jaar, maar we plannen met sprints/ kortere periodes dan kwartalen. We hebben voor een release een X aantal grote zaken gepland en heel veel kleine zaken. De grote onderdelen hebben we ons op ingelezen en weten we dat we kunnen doen in de release, tenzij er iets echt schokkends gebeurt. De kleine punten pakken we op als sprintvulling. Werkt prima.

[DevWouter]

Hydra schreef op woensdag 07 september 2016 @ 17:03:
<snip>
Ik ken alleen veel developers die hier erg slecht in zijn; in termen van de klant denken. Die komen alleen met "dat kan niet" (onzin, alles kan, 't kost alleen vaak te veel geld). Mijn ervaring is dat een goeie technical lead in die gesprekken die deze problemen kan vertalen naar wat de klant begrijpt onmisbaar is.

Bij mij hebben ze in elk geval afgeleerd om te vragen "kan dit?" want dat kent namelijk maar één antwoord: "Alles kan (mitst je maar genoeg geld tegen aangooit)".

Een mooi voorbeeld in vertalen vind ik "onderhoudskosten".
"Kunnen we dit toevoegen voor dit specifiek scenario?"
"Ja, maar dan worden de kosten van onderhoud wel een duur grapje. Beter is dit, dan heb je wel meer ontwikkelkosten maar dat is dan een eenmalige kostenpost"

Ook als ontwikkelaar ben je dan geneigd om anders te denken.
"Oh dit kan herschreven worden naar iets beter... Oh wacht... Het wordt maar één keer in het jaar gebruikt en het kost me zeker 16 uur... De kosten wegen niet op tegen de winst"

[Caelorum]

Hydra schreef op woensdag 07 september 2016 @ 16:47:
[...]
Dan kun je sowieso beter gaan Kanbannen dan gaan Scrummen als je je niet vast kunt leggen op een sprint. Het voornaamste voordeel van sprints is de voorspelbaarheid; wat gaat wanneer af zijn. Dat werkt niet als er steeds brandjes tussendoor komen.[...]

Mja, al die technieken zijn sowieso maar beperkt toepasbaar op een team waarbij vrijwel iedereen zowel ontwerpt, ontwikkelt als eigen ontwikkelde features test.
We zijn overigens al een jaar bezig het proces aan te passen zodat het ons beter uitkomt. Dat betekent dat de verwachtingen bij de klant worden bijgesteld en dat we steeds meer vanuit een "wij bepalen" principe werken. De klant wordt naar geluisterd, maar wij bepalen of, hoe en wanneer iets gaat gebeuren, met in acht neming de situaties waarin alle klanten zich bevinden.
Dat is alleen een lang proces, maar op de manier waarop wij ontwikkelen de enige vatbare denk ik (op korte termijn).

[Swedish Clown]

* Swedish Clown zet koffie, thee en chocolademelk klaar

Vandaag en morgen op de Erlang User Conference. Neem aan dat er geen Tweakers aanwezig zijn?

[DevWouter]

Caelorum schreef op woensdag 07 september 2016 @ 18:24:
[...]

Mja, al die technieken zijn sowieso maar beperkt toepasbaar op een team waarbij vrijwel iedereen zowel ontwerpt, ontwikkelt als eigen ontwikkelde features test.

Scrum/Agile/What-you-might-call-it zijn planningstools. De hoeveelheid resources en de specialisme van je resources zou niks mogen uitmaken. Ook als je in een team zit waarbij mensen op meerdere sprints van verschillende projecten tegelijk zijn gealloceerd mag het geen probleem zijn.

Het wordt alleen complexere om te doen (tip, kijk eens naar de client-server oplossing van http://hansoft.com/product/feature-list/). Goeie tooling (en dus niet Jira) kan dat voor je versimpeler.

[DevWouter]

En... Dit is een beetje de reden waarom ik moe begin te worden van Microsoft.



Dit is gewoon opdringen in mijn ogen. Ze weten al dat ik source control gebruik (GIT), maar toch hebben ze de behoefte om me er op te wijzen dat je ook VS Team Services kan gebruiken.

Begin me dan ook af te vragen wanneer Visual Studio Freemium uitkomt.

[.Gertjan.]

DevWouter schreef op woensdag 07 september 2016 @ 18:12:
[...]
Bij mij hebben ze in elk geval afgeleerd om te vragen "kan dit?" want dat kent namelijk maar één antwoord: "Alles kan (mitst je maar genoeg geld tegen aangooit)".

Ghehe, is ook mijn visie. Ik zeg ook dat alles kan, mits je de IT put maar diep genoeg graaft en er geld in blijft gooien. De vraag is alleen of het een goede besteding van het geld is. Maar goed als "de business" graag X wil en heeft daar Y euro voor over, prima, maar klaag dan niet over andere deliverables die vervallen.

Dat is een probleem wat het meeste optrad in de teams waar ik mee gewerkt heb:
> "Kunnen jullie functionaliteit Y2 ook nog meenemen?"
< "Kan, kost X uur en gaat voor deze/volgende release ten koste van functionaliteit Z"
> "Kan dat niet beide..."
<

Een mooi voorbeeld in vertalen vind ik "onderhoudskosten".
"Kunnen we dit toevoegen voor dit specifiek scenario?"
"Ja, maar dan worden de kosten van onderhoud wel een duur grapje. Beter is dit, dan heb je wel meer ontwikkelkosten maar dat is dan een eenmalige kostenpost"

Ook als ontwikkelaar ben je dan geneigd om anders te denken.
"Oh dit kan herschreven worden naar iets beter... Oh wacht... Het wordt maar één keer in het jaar gebruikt en het kost me zeker 16 uur... De kosten wegen niet op tegen de winst"

Die vraag moet je inderdaad aan beide kanten stellen. Ik reken ook regelmatig voor aan stakeholders wat hun change qua impact heeft en vraag ze ook of dat in verhouding staat tot wat ze bereiken met de wijziging. Vaak heeft men de neiging om persoonlijke pet-peeves naar voren te schuiven. Als je dan aangeeft dat hun pet-project 4 weken ontwikkeltijd kost dan denken ze (meestal) nog wel een keer na. Dit zijn ook van die dingen als: "op mijn OSX uit het jaar 0 met Safari 0.0 doet de rendering raar bij bepaalde 3d acties, please fix". Tja dan moet je heel de rendering onder de loep nemen en mogelijk herschrijven, dus kan een kostbare actie worden... Terwijl hij ook gewoon even de Mac kan updaten... In onze line of business is alles bij klanten ongeveer Windows, dus waarom bakken geld verslinden voor Safari (waar chrome het op een Mac wel weer prima doet).

En wat jij zegt over ontwikkelaars, oh my god, dat is zo waar... Hoe vaak ik in mijn team over-engineering zie. Dan worden complete factory patterns gebouwd waarin in principe maar 1 pad zit. Dan krijg je steevast te horen: "ja maar in de toekomst, bla bla bla...". Als je vervolgens vraagt of ze daar bij het plannen van het issue (en in de planningpoker) ook al rekening hiermee hadden gehouden wordt er steevast nee gezegd. Dus dan loopt men uit op een issue puur vanwege het over-engineren... En dat zie ik soms op de raarste plekken. Dan worden voor HTML/JS complete parsing engines bedacht, terwijl je dat ene stukje prima even met de hand kan inserten...

Het frappante is dan zelfs nog dat het vaak de juniors zijn neigen naar over-engineren. Ik heb zelf ook wel eens de neiging om iets te ver te gaan in mijn concepten, maar ik ben mij daar bewust van en kan dat afwegen en indien nodig parkeren (helpt ook dat ik weinig "grondwerk" meer doe, dus simpele dingen kan ik ook niet over-engineren). Maar de gedachten-trein van startende ontwikkelaars vind ik vaak wel interessant.

[Dido]

.Gertjan. schreef op donderdag 08 september 2016 @ 09:38:
Het frappante is dan zelfs nog dat het vaak de juniors zijn neigen naar over-engineren. Ik heb zelf ook wel eens de neiging om iets te ver te gaan in mijn concepten, maar ik ben mij daar bewust van en kan dat afwegen en indien nodig parkeren (helpt ook dat ik weinig "grondwerk" meer doe, dus simpele dingen kan ik ook niet over-engineren). Maar de gedachten-trein van startende ontwikkelaars vind ik vaak wel interessant.

Ja, als je tijdens je opleiding / traing te horen krijgt dat je patterns moet gebruiken, dat je anti-patterns moet vermijden en dat je geen technical debt moet creeren, dan is het niet zo heel gek dat je voor een hello world een volledige multi-tier SOA-compliant multithreading applicatie opzet met redundant HA persistence en loadbalancing. En uiteraard 8456 unittests en 736 integratietests.

[Ryur]

.Gertjan. schreef op donderdag 08 september 2016 @ 09:38:
[...]
Het frappante is dan zelfs nog dat het vaak de juniors zijn neigen naar over-engineren. Ik heb zelf ook wel eens de neiging om iets te ver te gaan in mijn concepten, maar ik ben mij daar bewust van en kan dat afwegen en indien nodig parkeren (helpt ook dat ik weinig "grondwerk" meer doe, dus simpele dingen kan ik ook niet over-engineren). Maar de gedachten-trein van startende ontwikkelaars vind ik vaak wel interessant.

Ik ben zelf ook nog een junior (heb 'pas' 10 jaar ervaring, en nu 3 jaar in het echte leven), en ik kom dit bij mijzelf ook regelmatig tegen.
Door mijn interesses van Design Patterns & de algemene onderhoudbaarheid van een software product merk ikzelf dat ik soms ook over-engineer. Gelukkig zijn in de gevallen waar ik dat deed achteraf wel nodig gebleken (dus uiteindelijk geen tijd verspilt, mogelijk op de korte termijn wel, maar op de lange termijn niet).

Maar dat is wel iets wat ik moet afleren (of het in de planning mee moet nemen).

[Dido]

Ryur schreef op donderdag 08 september 2016 @ 09:44:
Maar dat is wel iets wat ik moet afleren (of het in de planning mee moet nemen).

Dat is iets wat met ervaring komt, inderdaad. Is het nu nodig? Zo ja, dan moet je extra plannen. Een senior kan meestal ook iets beter aan de business uitleggen waarom die schijnbaar kleine feature nu opeens extra tijd kost. "We willen design pattern X implementeren" zegt de klant helemaal niets, maar "we willen het nu generiek opzetten, want dit is de derde club die iets dergelijks willen, en er zijn nog zes clubs die, als ze dit zien, ongetwijfeld ook zoiets willen. Dat gaat dus uiteindelijk geld schelen." begrijpen ze al eerder. En een senior kan ook iets makkelijker voor elkaar krijgen dat die extra investering nu niet volledig doorgerekend wordt naar de club die nu toevallig om de feature vraagt.

Eigen rant: goedwillende semi-seniors die niet alleen over-engineeren maar dat ook nog eens doen zonder helemaal de tools te begrijpen die ze gebruiken. En daarmee dus extra tijd spenderen om de applicatie moeilijker onderhoudbaar en minder stabiel te maken

[Ryur]

Er zijn nog genoeg dingen die met ervaring komen bij mij. En ik ben niet zo'n junior die denk alles al te weten (of tenminste dat hoop ik dat ik niet zo doe).
En dat vind ik zo leuk van dit topic: ik leer iedere dag er wel iets bij

[.Gertjan.]

Dido schreef op donderdag 08 september 2016 @ 09:44:
[...]

Ja, als je tijdens je opleiding / traing te horen krijgt dat je patterns moet gebruiken, dat je anti-patterns moet vermijden en dat je geen technical debt moet creeren, dan is het niet zo heel gek dat je voor een hello world een volledige multi-tier SOA-compliant multithreading applicatie opzet met redundant HA persistence en loadbalancing. En uiteraard 8456 unittests en 736 integratietests.

De grap is dat ze het niet eens echt aangeleerd krijgen door school. Spreek genoeg mensen die stage komen lopen of willen afstuderen die heel hard moeten denken wat design patterns zijn (serieus, sommige scholen hebben een zeer interessant curriculum, heb in het verleden zelfs gehoord dat je op de HAN kon kiezen tussen Databases of Game development... Tja, dan is het niet gek dat er weinig DB kennis te bespeuren is...).

Ze tijden hun (afstudeer)stage dan vaak wel ergens de klok gehoord maar geen idee waar de klepel hangt. Ze gaan vervolgens rondspeuren op internet en leren daar dat patterns super belangrijk zijn. Vervolgens gaan ze dat kunstje overal toepassen... Zie soms echt dingen gebeuren waarvan ik denk: "weet je zelf wel wat je daar doet", helaas is daar vaak "nee" het antwoord...

Blijft lastig en ben daar zelf ook nog naar aan het zoeken, maar het lijkt erop dat er 2 extremen zijn. Of ze doen er niets mee en vinden copy-paste prima of ze slaan volledig door...

Ryur schreef op donderdag 08 september 2016 @ 09:44:
[...]

Ik ben zelf ook nog een junior (heb 'pas' 10 jaar ervaring, en nu 3 jaar in het echte leven), en ik kom dit bij mijzelf ook regelmatig tegen.
Door mijn interesses van Design Patterns & de algemene onderhoudbaarheid van een software product merk ikzelf dat ik soms ook over-engineer. Gelukkig zijn in de gevallen waar ik dat deed achteraf wel nodig gebleken (dus uiteindelijk geen tijd verspilt, mogelijk op de korte termijn wel, maar op de lange termijn niet).

Maar dat is wel iets wat ik moet afleren (of het in de planning mee moet nemen).

Ik wil niet zeggen dat ik zwaar senior ben (11 jaar "echte ervaring"), maar het is iets wat je op een gegeven moment wel kan beoordelen. Natuurlijk zit je er wel eens naast, maar na verloop van tijd leer je vanzelf in te zien wanneer je echt te ver gaat of wanneer je misschien net dat stapje meer moet doen. Je kan dat dan niet echt beschrijven, maar je hebt een sterk gevoel wat de beste oplossing is. Dat krijg ik bij mijn eigen oplossingen, maar ook als ik in code van andere kijk.

Hoewel de neiging er zeker is om te snel te veel te willen, merk ik het wel op (waar andere niet snel zien dat ze een stapje te ver gaan). Als ik een simpel tooltje wil bouwen zie ik dat ik direct al mijn dependecy injection aan het inprikken ben en binnen een uur op 6 projecten binnen mijn solution zit... Daarom werk ik tegenwoordig vooral op de hoofd concepten en architectuur en niet meer daadwerkelijk in de detail implementatie, daar heb ik simpelweg het geduld niet meer voor en ga ik te snel veel te ver...

[DevWouter]

Ik denk dat het verschil tussen senior, medior en junior voornamelijk ligt in hoe goed je de business begrijpt en het effect dat je als ontwikkelaar hebt op de business.

Al schrijf je nog zulke fantastische code, als het effect op de business minimaal is zal je baas echt geen reden hebben om jouw als beter te behandelen dan die programmeur die crap code schrijft maar die wel effect heeft op de businness.

Op lange termijn heeft de slechte programmeur natuurlijk een negatief invloed op de business, maar tegen die tijd is hij senior en wordt er vanuit gegaan dat zijn "crap oplossing" beter is dan wat jij kan bedenken.

[.Gertjan.]

DevWouter schreef op donderdag 08 september 2016 @ 10:05:
Ik denk dat het verschil tussen senior, medior en junior voornamelijk ligt in hoe goed je de business begrijpt en het effect dat je als ontwikkelaar hebt op de business.

Al schrijf je nog zulke fantastische code, als het effect op de business minimaal is zal je baas echt geen reden hebben om jouw als beter te behandelen dan die programmeur die crap code schrijft maar die wel effect heeft op de businness.

Op lange termijn heeft de slechte programmeur natuurlijk een negatief invloed op de business, maar tegen die tijd is hij senior en wordt er vanuit gegaan dat zijn "crap oplossing" beter is dan wat jij kan bedenken.

Dat ligt denk ik heel erg aan de setting waar je in werkt. Hoewel het belangrijk is om de business te begrijpen, wordt dat niet altijd van je verwacht en is dat soms ook lastig te verwezenlijken. Zeker voor beginnende ontwikkelaars is het lastig de business te begrijpen. Het is wel belangrijk om de tool te begrijpen en te weten hoe deze werkt en waar nodig ook het waarom van bepaalde zaken te weten. Algemene nieuwsgierigheid brengt je daar heel ver.

Wij werken bijvoorbeeld in de internationale belastingen (saai.... ) en dat is een redelijk complexe markt. Zelf heb ik wel enige grip op de business (ik absorbeer domein kennis snel en ben ook nieuwsgierig naar het waarom van veel zaken), maar voor de junior ontwikkelaars is dat lastig. Uiteraard moeten ze wel een basic understanding hebben van het domein, maar ze hoeven niet te begrijpen wat de verschillende tax-accounting methodieken zijn en waarom ze verschillen. Ze moeten weten dat ze er zijn en dat de software daar rekening mee moet houden.

In veel sectoren heb je dus helaas behoefte aan "vertalers", die de complexe domeinkennis om kunnen zetten naar iets waar de developer aan kan relaten. Je moet ze niet in het duister houden, maar je kan ook niet verwachten dat het tax-experts worden. Overigens is dit ook weer afhankelijk van het ervaringsgat tussen de senior/medior/junior developers, hoe groter dat gat, hoe meer vertalingen nodig zijn.

Naarmate je meer senior wordt en meer richting de gehele scope verplaatst zul je sneller domeinkennis opdoen en de waarde daarvan in gaan zien. Maar er zijn ook genoeg technische richtingen waarbij je minder domein kennis nodig hebt. Dus je senior-rating is ook nog eens afhankelijk van welke richting je op gaat denk ik

[Hydra]

.Gertjan. schreef op donderdag 08 september 2016 @ 09:55:
De grap is dat ze het niet eens echt aangeleerd krijgen door school. Spreek genoeg mensen die stage komen lopen of willen afstuderen die heel hard moeten denken wat design patterns zijn (serieus, sommige scholen hebben een zeer interessant curriculum, heb in het verleden zelfs gehoord dat je op de HAN kon kiezen tussen Databases of Game development... Tja, dan is het niet gek dat er weinig DB kennis te bespeuren is...).

Ik vind dat bijna crimineel. Scholen doen dat om mensen aan te trekken. Tja leuk; maar als je mensen opleidt die niet aansluiten bij de vraag van de arbeidsmarkt dan heb je ze eigenlijk voorgelogen en ze 4 jaar van hun leven verspild. De kleine game dev markt in Nederland is er eentje waar je als dev redelijk veel concurrentie hebt en het is juist een markt waar je als dev erg veel hebt aan de 'hardcore' algorithmische vakken.

Ze tijden hun (afstudeer)stage dan vaak wel ergens de klok gehoord maar geen idee waar de klepel hangt. Ze gaan vervolgens rondspeuren op internet en leren daar dat patterns super belangrijk zijn. Vervolgens gaan ze dat kunstje overal toepassen... Zie soms echt dingen gebeuren waarvan ik denk: "weet je zelf wel wat je daar doet", helaas is daar vaak "nee" het antwoord...

En dan vaak grijpen ze naar de makkelijkste: Singletons. Terwijl dat gewoon een anti-pattern is.

[.Gertjan.]

Hydra schreef op donderdag 08 september 2016 @ 11:04:
En dan vaak grijpen ze naar de makkelijkste: Singletons. Terwijl dat gewoon een anti-pattern is.

En je zal verbaasd staan hoe fout men dat nog kan implementeren... Zie vaak genoeg achterlijkheden als:

C#:

class MySweetSingletonAbstractFactoryBuilderPatternDecorator
{
    private static MyPrecious _instance;
    public static MyPrecious GetSingleton()
    {
        return _instance ?? new MyPrecious();
        //or even better
        return new MyPrecious();
    }
}

Vooral de misuse van de ?? is briljant. Gevalletje van wel willen spelen met de grote jongens, maar geen idee hebben wat ze doen. Daarnaast denken sommige dat de blauwe lijntjes in VS/R# ter decoratie zijn opgenomen...

[DevWouter]

Hydra schreef op donderdag 08 september 2016 @ 11:04:
[...]
En dan vaak grijpen ze naar de makkelijkste: Singletons. Terwijl dat gewoon een anti-pattern is.

Singletons is een design-pattern, niet een anti-pattern. Echter zien we de design-pattern ontzettend vaak als er andere anti-patterns aanwezig zijn.

Het is een vaak gemaakte fout.

[kenneth]

.Gertjan. schreef op donderdag 08 september 2016 @ 12:18:

C#:

class MySweetSingletonAbstractFactoryBuilderPatternDecorator

Ik zag het niet Copypasta in VS en toen ik een foutmelding bij de declaratie zag had ik hem gelijk door

/me neemt nog wat caffeïne tot zich

[Hydra]

DevWouter schreef op donderdag 08 september 2016 @ 12:23:
Singletons is een design-pattern, niet een anti-pattern. Echter zien we de design-pattern ontzettend vaak als er andere anti-patterns aanwezig zijn.

Het is een vaak gemaakte fout.

Nee. Het is een vaak gemaakte fout om Singletons niet als anti-pattern te zien. Het is gewoon global state die vaak niet werkt zoals je hoopt in app servers, zorgt voor tight coupling en daardoor unit testen lastig maakt.

[Sardaukar]

Hydra schreef op donderdag 08 september 2016 @ 13:00:
[...]


Nee. Het is een vaak gemaakte fout om Singletons niet als anti-pattern te zien. Het is gewoon global state die vaak niet werkt zoals je hoopt in app servers, zorgt voor tight coupling en daardoor unit testen lastig maakt.

Dit! Global state maakt unit testen lastig.

Daarnaast weten veel mensen niet eens hoe ze een correcte singleton moeten schrijven.. En mocht je echt een singleton nodig hebben lijkt het mij makkelijker om dit via je dependency injection op te lossen.

Via bijvoorbeeld Autofac met

C#:

builder.RegisterType<UnitOfWork>().As<IUnitOfWork>().SingleInstance();

[RayNbow]

Singletons...

Heb ooit in het verleden met een codebase van een applicatie moeten werken die Singletons gebruikte... Heel fijn als je dan een keer meerdere instanties van die applicatie in 1 proces wil creëren.

[Hydra]

RayNbow schreef op donderdag 08 september 2016 @ 13:12:
Heb ooit in het verleden met een codebase van een applicatie moeten werken die Singletons gebruikte... Heel fijn als je dan een keer meerdere instanties van die applicatie in 1 proces wil creëren.

Of binnen 1 proces denkt dat je sowieso maar 1 singleton hebt

[DevWouter]

Hydra schreef op donderdag 08 september 2016 @ 13:00:
[...]


Nee. Het is een vaak gemaakte fout om Singletons niet als anti-pattern te zien. Het is gewoon global state die vaak niet werkt zoals je hoopt in app servers, zorgt voor tight coupling en daardoor unit testen lastig maakt.

Dat het geen fijne pattern is ben ik met je eens, maar dat maakt het nog geen anti-pattern. Dat mensen een design pattern niet weten hoe en wanneer ze het moeten toepassen zorgt er voor dat er mensen het als een anti-pattern zijn gaan beschouwen.

Ook global states zijn geen anti-pattern (hell, technisch gezien is je complete RAM een global state).

Echter het verkeerd gebruik ervan zorgt er wel voor dat je "Big ball of mud" of "Stovepipe System" in je code introduceert.

Het is oneerlijk om slechte ontwerp keuzes toe te schrijven aan een design pattern, anders worden interfaces dadelijk ook nog een anti-pattern.

[Dido]

Sardaukar schreef op donderdag 08 september 2016 @ 13:09:
En mocht je echt een singleton nodig hebben lijkt het mij makkelijker om dit via je dependency injection op te lossen.

En die IOC container die je gebruikt voor je dependency injection, da's geen singleton?

DevWouter schreef op donderdag 08 september 2016 @ 13:45:
Het is oneerlijk om slechte ontwerp keuzes toe te schrijven aan een design pattern, anders worden interfaces dadelijk ook nog een anti-pattern.

Eensch. Het meest voorkomende anti-pattern is misbruik van patterns.

Verwant daarmee natuurlijk het "when you're a hammer, every problem looks like a nail"-syndroom, oftewel een programmeur die een pattern of twee ontdekt probeert ze vervolgens op alles toe te passen.

[ Voor 45% gewijzigd door Dido op 08-09-2016 14:21 ]

[Hydra]

DevWouter schreef op donderdag 08 september 2016 @ 13:45:
Het is oneerlijk om slechte ontwerp keuzes toe te schrijven aan een design pattern, anders worden interfaces dadelijk ook nog een anti-pattern.

Ik vind het een rare discussie worden op deze manier. Singletons heb je eigenlijk niet nodig en zorgen vaak voor problemen. Dat maakt het m.i. een anti-pattern. Als jij er graag een andere definitie op na houdt, prima.

[Creepy]

Wikipedia somt het mooi op

In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects. The term comes from the mathematical concept of a singleton.

There are some who are critical of the singleton pattern and consider it to be an anti-pattern in that it is frequently used in scenarios where it is not beneficial, introduces unnecessary restrictions in situations where a sole instance of a class is not actually required, and introduces global state into an application.

[DevWouter]

Hydra schreef op donderdag 08 september 2016 @ 14:30:
[...]


Ik vind het een rare discussie worden op deze manier. Singletons heb je eigenlijk niet nodig en zorgen vaak voor problemen. Dat maakt het m.i. een anti-pattern. Als jij er graag een andere definitie op na houdt, prima.

Zie nu dat het zonder context eigenlijk niet te begrijpen was.

Wat ik probeerde duidelijk te maken is dat het onnodig of verkeerd gebruik maken van een een techniek (singletons en interfaces in dit geval) ongewenst is. Dat je ze "eigenlijk niet nodig hebt" is voor mij geen reden om het als een anti-pattern te bestempelen.

Echter in de praktijk heb ik ze maar een enkele keer echt nodig gehad en dat was meer om systeem-resources te managen welke om een bepaalde reden niet doorgegeven kon worden.

Maar goed, vermijden is het devies.

[F.West98]

Dido schreef op donderdag 08 september 2016 @ 09:44:
[...]

Ja, als je tijdens je opleiding / traing te horen krijgt dat je patterns moet gebruiken, dat je anti-patterns moet vermijden en dat je geen technical debt moet creeren, dan is het niet zo heel gek dat je voor een hello world een volledige multi-tier SOA-compliant multithreading applicatie opzet met redundant HA persistence en loadbalancing. En uiteraard 8456 unittests en 736 integratietests.

Inderdaad. Laatst nog eens minpunten gekregen omdat ik het onnodig vond om dingen te gaan overengineeren en daarom instanceof gebruikte. "Je laat nu niet zien dat je OOP kent."
Ik vind het zelf in mijn eigen projectjes altijd wel leuk om (security) (enorm) over te engineeren, vooral om er iets van te leren.

[Caelorum]

Hydra schreef op donderdag 08 september 2016 @ 11:04:
[...]
Ik vind dat bijna crimineel. Scholen doen dat om mensen aan te trekken. Tja leuk; maar als je mensen opleidt die niet aansluiten bij de vraag van de arbeidsmarkt dan heb je ze eigenlijk voorgelogen en ze 4 jaar van hun leven verspild. De kleine game dev markt in Nederland is er eentje waar je als dev redelijk veel concurrentie hebt en het is juist een markt waar je als dev erg veel hebt aan de 'hardcore' algorithmische vakken.
[...]

In dit geval werd het gamevak gebruikt als een tool om de student kennis te laten maken met het werken in verschillende teams aan 1 product, waarbij elk tram zij eigen specialisme heeft. Iets dat op veel andere opleidingen niet wordt gedaan.
Overigens is zover ik weet het nooit een keuze geweest tussen database en gamedev uit het eerste jaar. Dat waren (en zijn?) die je beide moest volgen.
Hoe dan ook heeft de HAN de gamevakken nooit gebruikt als een poging tot opleiden van, maar altijd om op een wat speelse manier bepaalde werkwijzes en concepten aan te leren.
Er valt verder wel veel negatiefs over de opleiding van de HAN zoals die vroeger was te vertellen hoor. Het was echt een redelijke waste of time waar je weinig concreets over programmeren leerde. De focus lag altijd op het leren samen werken, waardoor er medestudenten zijn afgestudeerd die amper een werkend programma konden produceren. Een simpele website met zoekfunctie was al te veel gevraagd. Laat staan zoiets als een commandline sudoku solver die een bestand inleest en de output print. Maar ach...

[Sardaukar]

Dido schreef op donderdag 08 september 2016 @ 14:18:
En die IOC container die je gebruikt voor je dependency injection, da's geen singleton?

Niet relevant toch? Ik zeg niet dat je geen singletons moet gebruiken: ik zei alleen maar dat als je een DI tool gebruikt je beter de functionaliteit daarvan kan gebruiken inplaats van zelf een crappy singleton implementatie te schrijven

[alienfruit]

Wij werken bijvoorbeeld in de internationale belastingen (saai.... ) en dat is een redelijk complexe markt. Zelf heb ik wel enige grip op de business (ik absorbeer domein kennis snel en ben ook nieuwsgierig naar het waarom van veel zaken

Dat vind ik nou altijd zo irritant bij sommige collega's. Ze moeten een Gateway service implementeren ben je vervolgens eerst 2-4 uur bezig om uit te leggen waarom het op een bepaalde manier moet. Heel makkelijk omdat die gegevens op het scherm moeten verschijnen en ik weet ook niet waarom de klant XYZ op die manier heeft opgeslagen in SAP. En nee, we gaan dit niet 'even' veranderen.

[F.West98]

Mag ik weer eens stoom afblazen?
- Ontwerp moeten implementeren dat niet compleet is omdat designer niet de hele applicatie te zien heeft gekregen
- Dat ontwerp dan zelf moeten uitbreiden zonder dingen fundamenteel te veranderen waardoor er uiteindelijk nu een heleboel hoverstates bij zijn gekomen
- Dat ontwerp zou zo een demonstratie van de mogelijkheden van flexbox kunnen zijn. Enige probleem: moet ook op IE11 (liefst 10) ondersteund worden.
- Dat ontwerp dan ook nog touchfriendly maken en responsive maken

[alienfruit]

Haha, Flexbox en IE11 wat een ge-eikel!!

[Laurens-R]

F.West98 schreef op donderdag 08 september 2016 @ 23:49:
Mag ik weer eens stoom afblazen?
- Ontwerp moeten implementeren dat niet compleet is omdat designer niet de hele applicatie te zien heeft gekregen
- Dat ontwerp dan zelf moeten uitbreiden zonder dingen fundamenteel te veranderen waardoor er uiteindelijk nu een heleboel hoverstates bij zijn gekomen
- Dat ontwerp zou zo een demonstratie van de mogelijkheden van flexbox kunnen zijn. Enige probleem: moet ook op IE11 (liefst 10) ondersteund worden.
- Dat ontwerp dan ook nog touchfriendly maken en responsive maken

Uhm... Welcome to the real world?

[DevWouter]

F.West98 schreef op donderdag 08 september 2016 @ 23:49:
Mag ik weer eens stoom afblazen?

Tuurlijk makker, deze hele thread ontleent zijn bestaansrecht aan het feit dat ontwikkelaars ook mensen zijn.

Overigens werkt flex (en de oude versie genaamd flexbox) niet op alle browsers. Ik wens je dan ook veel succes.

[Swedish Clown]

Dan blaas ik ook even stoom af.

Diarree, hoofdpijn en misselijk als een malle. Dat terwijl vandaag dag 2 van de Erlang User Conference en jaarlijks bedrijfsfeest vanavond is. Even het een en ander aan medicijnen naar binnen gegooid en kijken of het beter wordt voor ik besluit om thuis te blijven

[Ryur]

Brakkie41 schreef op vrijdag 09 september 2016 @ 08:27:
Dan blaas ik ook even stoom af.

Diarree, hoofdpijn en misselijk als een malle. Dat terwijl vandaag dag 2 van de Erlang User Conference en jaarlijks bedrijfsfeest vanavond is. Even het een en ander aan medicijnen naar binnen gegooid en kijken of het beter wordt voor ik besluit om thuis te blijven

Ik ken het. Had dat met het jaarlijkse kerstviering van het werk.
Sterkte, en hopelijk werken de medicijnen!

[cracking cloud]

Zijn er meer mensen die dit gelezen hebben: https://www.troyhunt.com/...-personal-data-is-leaked/ en dachten: wtf, bestaat dat nog in 2016? (vooral Strawberrynet en hun reactie)

[Tjolk]

Blijkbaar hebben ze daar geen ABP ofzo.

[Skyaero]

cracking cloud schreef op vrijdag 09 september 2016 @ 09:23:
Zijn er meer mensen die dit gelezen hebben: https://www.troyhunt.com/...-personal-data-is-leaked/ en dachten: wtf, bestaat dat nog in 2016? (vooral Strawberrynet en hun reactie)

Als je Troy's twitter een beetje volgt, zie je geregeld dit soort treurige gevallen voorbij komen. Soms heb ik het gevoel dat een hobbywebsite van een Tweaker betere beveiliging heeft dan de gemiddelde websites met klantinformatie.

Infosec heeft helaas nog te weinig aandacht. En dat is jammer, want hacking is letterlijk child's play, zoals Troy Hunt recentlijk demonstreerde op NDC Sydney (54:30, hoewel de hele presentatie fantastisch is)

[Vimeo: https://vimeo.com/180273195]

[DevWouter]

cracking cloud schreef op vrijdag 09 september 2016 @ 09:23:
Zijn er meer mensen die dit gelezen hebben: https://www.troyhunt.com/...-personal-data-is-leaked/ en dachten: wtf, bestaat dat nog in 2016? (vooral Strawberrynet en hun reactie)

Niet echt, ik heb voor een partij gewerkt met patientgegevens en toen kwam ik er ook achter dat ik te makkelijk dacht over beveiliging van persoonsgegevens. Die beveiliging was echter zeer strak geregeld op alle lagen die je kan bedenken.

Nu had die partij waar ik voor werkte de resources ervoor, maar ik kan goed begrijpen dat een kleinere partij die resources niet heeft omdat SEO, SEA en SEM hun aandacht opslokt. Het is natuurlijk niet juist, maar als het alternatief is dat je verlies gaat draaien en faliet gaat dan kan die verkeerde keuze snel gemaakt zijn.

Disclaimer: DevWouter en de partijen waar hij voor werkt of heeft gewerkt neemt security zeer serieus.

[jbdeiman]

F.West98 schreef op donderdag 08 september 2016 @ 18:22:
[...]

Inderdaad. Laatst nog eens minpunten gekregen omdat ik het onnodig vond om dingen te gaan overengineeren en daarom instanceof gebruikte. "Je laat nu niet zien dat je OOP kent."
Ik vind het zelf in mijn eigen projectjes altijd wel leuk om (security) (enorm) over te engineeren, vooral om er iets van te leren.

Wat ze eigenlijk vooral laten zien op je opleiding is dat ze zelf niet snappen hoe je moet ontwikkelen, jij geeft eigenlijk aan dat je het op een bepaalde manier doet en dat je er handig in bent.
Op opleidingen houden ze te veel vast aan "je moet het volgens deze methode doen", wat mij vrij achterhaald lijkt.

Het beste is vind ik een opdracht waarbij je iets moet maken, waarvoor je een pattern moet gebruiken. Je moet daarbij onderbouwen waarom je voor dat pattern hebt gekozen en een ander pattern (of een paar) niet hebt gekozen. Er is geen "goed of fout", of in elk geval zijn meerdere methoden goed. Alleen kunnen docenten daar vaak niet mee over weg.

Ik heb zelfs in mijn laatste poging voor een programmeervak maar eens gevraagd waarom de docent het niet goed vond. Hij gaf aan "dit kan nooit werken", maar we hebben samen de code ingevoerd en het werkt prima. Hij snapte het niet en dus is het fout. Dat is voor mij een enorme fout in het "informatica vak leren op een opleiding".

[Hydra]

F.West98 schreef op donderdag 08 september 2016 @ 18:22:
Inderdaad. Laatst nog eens minpunten gekregen omdat ik het onnodig vond om dingen te gaan overengineeren en daarom instanceof gebruikte. "Je laat nu niet zien dat je OOP kent."
Ik vind het zelf in mijn eigen projectjes altijd wel leuk om (security) (enorm) over te engineeren, vooral om er iets van te leren.

Instanceof is gewoon een code smell. Op een opleiding werken ze meestal in absolute termen (vermijd static, vermijd instanceof) gewoon omdat ze aan de meeste studenten die nuance nog niet kwijt kunnen. Dat ze je afraden om instanceof te gebruiken is volledig terecht.

[ThomasG]

Hydra schreef op vrijdag 09 september 2016 @ 11:53:
[...]

Instanceof is gewoon een code smell. Op een opleiding werken ze meestal in absolute termen (vermijd static, vermijd instanceof) gewoon omdat ze aan de meeste studenten die nuance nog niet kwijt kunnen. Dat ze je afraden om instanceof te gebruiken is volledig terecht.

Het zou ook heel goed kunnen dat het de bedoeling was om via een interface tegen objecten te praten. Dan is een instanceof dus sowieso niet de bedoeling, en dus "fout".

[Hydra]

DevWouter schreef op donderdag 08 september 2016 @ 16:21:
Wat ik probeerde duidelijk te maken is dat het onnodig of verkeerd gebruik maken van een een techniek (singletons en interfaces in dit geval) ongewenst is. Dat je ze "eigenlijk niet nodig hebt" is voor mij geen reden om het als een anti-pattern te bestempelen.

Lees je wel wat ik schrijf? Ik leg letterlijk uit dat er een hoop redenen zijn om Singletons niet te gebruiken. Het is geen kwestie van niet 'nodig' hebben (geen enkele design pattern heb je nodig). Het is een kwestie van je code gewoon slechter maken. Singletons in je code zijn kut. Klaar. Ze maken het onnodig moeilijk code te unit testen. Wat denk je dat makkelijker te testen is:

Java:

public class SomeDao {
    private final DbConnection connection;
    public SomeDao() {
        this.connection = ConnectionFactory.current();
    }
}

Of:

Java:

public class SomeDao {
    private final DbConnection connection;
    public SomeDao(final DbConnection connection) {
        this.connection = connection;
    }
}

En dan heb ik 't nog niet eens over Singletons in application servers.

ThomasG schreef op vrijdag 09 september 2016 @ 11:58:
[...]
Het zou ook heel goed kunnen dat het de bedoeling was om via een interface tegen objecten te praten. Dan is een instanceof dus sowieso niet de bedoeling, en dus "fout".

Kan. Ik weet niet wat de opdracht is (FWest post die natuurlijk niet, het is makkelijker om gewoon ff te zeiken ). Maar als je instanceof nodig hebt voor een stukje code moet je misschien eens goed kijken naar je design. Ik gebruik 't vrijwel alleen maar in test code.

Dido schreef op donderdag 08 september 2016 @ 14:18:
En die IOC container die je gebruikt voor je dependency injection, da's geen singleton?

Nope. Die zitten een stuk slimmer in elkaar. En daarnaast is het grootste nadeel van Singletons dat ze je code lastig te testen maken. DI als aanpak is daarin beter. Een IoC container regelt het DI voor je om te voorkomen dat je in je Main alles aan moet maken en door moet sturen.

Het probleem met Singletons als design pattern is dat ze gebruik proberen te maken van een paar aannames die niet waar zijn en daarnaast je dwingen dependencies te hard-coden. Daarom is, met de kennis van nu, een Singleton gewoon een anti-pattern (i.t.t. wat sommige mensen hier beweren). DI is, of je nu een IoC container gebruikt of niet, hoe dan ook beter omdat je dan je code tenminste modulair houdt.

[ Voor 38% gewijzigd door Hydra op 09-09-2016 12:05 ]

[.oisyn]

Dicht voor maintenance

En weer open, wat reacties afgesplitst naar [php] continue in een switch om conditie te her-evalueren. Voortaan dat soort discussies gewoon in een eigen topic plaatsen

[ Voor 82% gewijzigd door .oisyn op 09-09-2016 12:11 ]

[DevWouter]

Hydra schreef op vrijdag 09 september 2016 @ 11:58:
[...]


Lees je wel wat ik schrijf? Ik leg letterlijk uit dat er een hoop redenen zijn om Singletons niet te gebruiken. Het is geen kwestie van niet 'nodig' hebben (geen enkele design pattern heb je nodig). Het is een kwestie van je code gewoon slechter maken. Singletons in je code zijn kut. Klaar. Ze maken het onnodig moeilijk code te unit testen.

Ja, ik lees wat je schrijf en ik ben het ook eens met je. Het enige punt waar we van mening verschillen is of het design-pattern of een anti-pattern is. In het oorspronkelijke boek (Design Patterns: Elements of Reusable Objects) wordt in hoofdstuk 1 uitgelegd wanneer er sprake is van een design pattern. Vervolgens heeft het boek 8 pagina's nodig om Singleton te defineren.

Spijtig genoeg kent iedereen de verkorte versie van school of wikipedia, welke bepaalde punten vaak overslaan, en zodoende wordt het vaak verkeerd gebruikt. En eerlijkheid gebied me te zeggen dat ik er ook zo één was...

DI of IoC pakken ook een ander probleem aan dan een Singleton waardoor het appels met peren vergelijken wordt.

Enfin, het devies blijft niet gebruiken aangezien het probleem die je hebt zelden voldoet aan de eisen om singleton te gebruiken.

[Kevjoe]

DevWouter schreef op vrijdag 09 september 2016 @ 09:58:
[...]


Niet echt, ik heb voor een partij gewerkt met patientgegevens en toen kwam ik er ook achter dat ik te makkelijk dacht over beveiliging van persoonsgegevens. Die beveiliging was echter zeer strak geregeld op alle lagen die je kan bedenken.

Nu had die partij waar ik voor werkte de resources ervoor, maar ik kan goed begrijpen dat een kleinere partij die resources niet heeft omdat SEO, SEA en SEM hun aandacht opslokt. Het is natuurlijk niet juist, maar als het alternatief is dat je verlies gaat draaien en faliet gaat dan kan die verkeerde keuze snel gemaakt zijn.

Disclaimer: DevWouter en de partijen waar hij voor werkt of heeft gewerkt neemt security zeer serieus.

Ik heb voor een telecom-aanbieder gewerkt, en wij konden zomaar alles zien: alle wachtwoorden plaintext opgeslagen en opvraagbaar voor de klantendienst... niet echt netjes.
Ik ben er 1000% zeker van dat het nog steeds het geval is bij dat bedrijf.

[DevWouter]

Damn, nooit bij stil gestaan dat ik kon gebruik

[incaz]

Bij een antipattern denk ik aan een pattern dat je vooral niet moet gebruiken tenzij je een goede onderbouwing hebt waarom het echt niet anders kan. Dat lijkt me van toepassing op singletons? Ik zou dat best een antipattern durven noemen dan.

(Maar eigenlijk ben ik de singleton maar weinig tegenkomen, tenminste niet om me mee te bemoeien of door in de problemen te komen. Ik heb er ooit 1 geimplementeerd (zonder dat ik wist dat het een singleton was), verder nooit de behoefte gehad.)

[ThomasG]

incaz schreef op vrijdag 09 september 2016 @ 13:41:
Bij een antipattern denk ik aan een pattern dat je vooral niet moet gebruiken tenzij je een goede onderbouwing hebt waarom het echt niet anders kan. Dat lijkt me van toepassing op singletons? Ik zou dat best een antipattern durven noemen dan.

(Maar eigenlijk ben ik de singleton maar weinig tegenkomen, tenminste niet om me mee te bemoeien of door in de problemen te komen. Ik heb er ooit 1 geimplementeerd (zonder dat ik wist dat het een singleton was), verder nooit de behoefte gehad.)

Singleton is ook een anti-pattern. De enige reden om een Singleton te gebruiken, is luiheid en om geen globals of een super object te gebruiken. Het is hoe dan ook een ontwerpfout.

[Hydra]

DevWouter schreef op vrijdag 09 september 2016 @ 12:53:
Ja, ik lees wat je schrijf en ik ben het ook eens met je. Het enige punt waar we van mening verschillen is of het design-pattern of een anti-pattern is. In het oorspronkelijke boek (Design Patterns: Elements of Reusable Objects) wordt in hoofdstuk 1 uitgelegd wanneer er sprake is van een design pattern. Vervolgens heeft het boek 8 pagina's nodig om Singleton te defineren.

Spijtig genoeg kent iedereen de verkorte versie van school of wikipedia, welke bepaalde punten vaak overslaan, en zodoende wordt het vaak verkeerd gebruikt. En eerlijkheid gebied me te zeggen dat ik er ook zo één was...

Er bestaat zo iets als voortschrijdend inzicht. Het GoF boek is ergens in de negentiger jaren geschreven. Er is een hoop veranderd in die tijd. Ik heb zelf ook een vak Design Patterns gehad en dat boek ligt hier ook op zolder (en ik zal het ook niet wegdoen, hoewel het m.i. outdated is). Toen het geschreven werd, waren dingen als unit testen en mocking vooral theoretisch. IoC containers bestonden niet in Java land. De servlet spec is van na de publicatie van dat boek. Toen dat geschreven is, kon met gewoon niet voorzien dat er hele specifieke problemen waren met sommige design patterns.

Daarbij komt dat een Singleton extreem simpel te begrijpen is. En nu is een Singleton in principe een goed ding, de praktische implementatie daarvan in dat boek gaat gewoon compleet voorbij aan de problemen met classloaders en applicatie servers om nog maar niet te spreken over testing. Singletons breken volledig met de SOLID design principles.

Dat het volgens het GoF boek een 'design pattern' is maakt niet uit; het boek is meer dan 20 jaar oud. Er zijn in die tijd een hoop dingen waarvan we terugkijkend zien dat 't misschien toch niet zo'n goed idee was. Dit neemt niet weg dat er een hoop patterns nog steeds enorm nuttig zijn: Singleton is er alleen eentje die dat helemaal niet is en zelf schade toebrengt.

DI of IoC pakken ook een ander probleem aan dan een Singleton waardoor het appels met peren vergelijken wordt.

Dat is ook heel erg niet wat ik zeg. Ik zeg dat Singletons DI 'stuk' maken. Niet dat ze hetzelfde doen.

Wat Singletons betreft zijn er twee mogelijkheden: je begrijpt de problemen en gebruikt ze nooit of je begrijpt de problemen niet en luistert naar de slimme mensen die je vertellen dat je ze nooit moet gebruiken

[ Voor 10% gewijzigd door Hydra op 09-09-2016 14:02 ]

[DevWouter]

Hydra schreef op vrijdag 09 september 2016 @ 13:59:
Wat Singletons betreft zijn er twee mogelijkheden: je begrijpt de problemen en gebruikt ze nooit of je begrijpt de problemen niet en luistert naar de slimme mensen die je vertellen dat je ze nooit moet gebruiken

Dan zitten we op één en dezelfde lijn.

[Sebazzz]

Hydra schreef op vrijdag 09 september 2016 @ 13:59:
[...]

Eens dat GoF wel wat stoffig is. Abstract factories gebruik ik tegenwoordig ook praktisch nooit meer

[F.West98]

Hydra schreef op vrijdag 09 september 2016 @ 11:53:
[...]


Instanceof is gewoon een code smell. Op een opleiding werken ze meestal in absolute termen (vermijd static, vermijd instanceof) gewoon omdat ze aan de meeste studenten die nuance nog niet kwijt kunnen. Dat ze je afraden om instanceof te gebruiken is volledig terecht.

Er is een verschil tussen (sterk) afraden en 3 minpunten geven op een relatief grote opdracht.
Anyhow, het ging om een stukje draw-logica. "Normale" implementatie van het programma heeft één type object te drawen en dan kan je het gewoon tussen andere draw dingen zetten. Ik had het uitgebreid naar twee object types. Ik had gewoon een draw functie kunnen definiëren in de parent (abstract) class/interface en die kunnen callen maar daarmee werd er dan view logic in het model gestopt. Aangezien in het hele vak werd gehamerd op MVC leek me dat niet verstandig. Het implementeren van losse viewmodels werd overkill en minder overzichtelijk dus heb ik voor de instanceof compromis gekozen, met vermelding van deze afweging in het report.
Nee het is niet netjes, maar ook geen 3 minpunten waard imo. Gaat trouwens om zelfde opdracht als paar maanden geleden met die empty catch blabla.. Uiteindelijk van een 5 naar een 6,5 gegaan omdat hij de rest van de code toch wel vrij goed vond voor een eerstejaarsstudent dus vak alsnog gehaald, ben allang tevreden

[Sardaukar]

F.West98 schreef op vrijdag 09 september 2016 @ 16:09:
[...]
Nee het is niet netjes, maar ook geen 3 minpunten waard imo. Gaat trouwens om zelfde opdracht als paar maanden geleden met die empty catch blabla.. Uiteindelijk van een 5 naar een 6,5 gegaan omdat hij de rest van de code toch wel vrij goed vond voor een eerstejaarsstudent dus vak alsnog gehaald, ben allang tevreden

Empty catches zijn ook ruk

[ThomasG]

F.West98 schreef op vrijdag 09 september 2016 @ 16:09:
[...]

Er is een verschil tussen (sterk) afraden en 3 minpunten geven op een relatief grote opdracht.
Anyhow, het ging om een stukje draw-logica. "Normale" implementatie van het programma heeft één type object te drawen en dan kan je het gewoon tussen andere draw dingen zetten. Ik had het uitgebreid naar twee object types. Ik had gewoon een draw functie kunnen definiëren in de parent (abstract) class/interface en die kunnen callen maar daarmee werd er dan view logic in het model gestopt. Aangezien in het hele vak werd gehamerd op MVC leek me dat niet verstandig. Het implementeren van losse viewmodels werd overkill en minder overzichtelijk dus heb ik voor de instanceof compromis gekozen, met vermelding van deze afweging in het report.
Nee het is niet netjes, maar ook geen 3 minpunten waard imo. Gaat trouwens om zelfde opdracht als paar maanden geleden met die empty catch blabla.. Uiteindelijk van een 5 naar een 6,5 gegaan omdat hij de rest van de code toch wel vrij goed vond voor een eerstejaarsstudent dus vak alsnog gehaald, ben allang tevreden

Jij loopt gewoon van alles in elkaar te hacken, ook al is het extra. Als je zoiets doet, doe het dan goed. Of laat het anders achterwegen..

[.oisyn]

F.West98, je loopt hier nou al een jaar of 4 te bitchen op alles en iedereen mbt school en het ligt nooit aan jezelf. Misschien wordt het tijd om tot de conclusie te komen dat het wél aan jezelf ligt?

[F.West98]

.oisyn schreef op vrijdag 09 september 2016 @ 17:03:
F.West98, je loopt hier nou al een jaar of 4 te bitchen op alles en iedereen mbt school en het ligt nooit aan jezelf. Misschien wordt het tijd om tot de conclusie te komen dat het wél aan jezelf ligt?

Zit ik nu te bitchen dan? Ik ben het helemaal eens met de punten, instanceof is niet netjes een een empty catch al helemaal niet. Ik zeg alleen dat een 5 voor die twee dingen wellicht enigszins overdreven was, wat de docent dus ook vond achteraf. Ik zeg dat ik nu dus tevreden ben met mijn cijfer. Hoe is dat zeuren dat het de schuld van school is dat ik zelf stom een empty catch heb gemaakt?

[Hydra]

Ik kan je in ieder geval aanraden dit eens te lezen en te zorgen dat je zelf niet in deze pitfall dondert. Je posts hebben alle tekenen in ieder geval.

[DevWouter]

Het artikel waar Hydra naar verwijst is een klassieker en zeker één die ik zou aanbevelen.

Wat ik zo hoor is dat jij graag je kunsten wilt laten zien en daarom meer doet waarom gevraagd wordt. Als de taak is om twee getallen bij elkaar op te tellen dan moet je geen quantum-rekenmachine maken

Doe de opdracht zoals het van je verlangd wordt en niet meer of minder. Alles wat je extra doet geeft je namelijk geen extra punten terwijl het wel voor punten aftrek kan zorgen.

Zo heeft (godzijdank) een docent mij ook een keer terug gefloten omdat ik een beam-tracer wilde bouwen ipv een ray-tracer. Was ik toen helemaal niet blij mee (want ik "kon het") maar eigenlijk had hij compleet en volledig gelijk en zat ik gewoon fout.

[incaz]

Wonderlijk hoe men meent steeds zo'n belerende toon uit de kast te moeten trekken richting F.West - kritiek is niet gewoon kritiek op de inhoud van de code ofzo, nee, het heeft toch steeds de ondertoon 'luister naar je meerderen, wij zijn ouder.' Er wordt door anderen volgens mij heel wat meer gebitcht, en ook nog wel eens onterechter, maar daar voelt men zich niet zo geroepen om steeds weer de ander op z'n plaats te zetten.

Mwah, nee.

Daarnaast: als je tijdens je studententijd niet meer mag ontdekken door dingen fout te doen, wanneer dan wel? IEDEREEN hier heeft fouten moeten maken, shortcuts genomen, dingen te hard gecodeerd en teveel gecoupled, te slordig opgelost, en in reactie ook weer overengineered... dat heet ontwikkelen. Zullen we mensen (zowel jongere als oudere) gewoon het recht geven om die stappen te doorlopen zonder daar meteen zo neerbuigend over te doen?

Interessant is immers niet dat iemand wel of niet een lege catch kan schrijven, en ook niet dat 'ie daar fiks op afgestraft wordt, maar vooral dat men inzicht en feeling krijgt voor waar en wanneer welke afweging gerechtvaardigd is. Een goed gesprek is dan een stuk belangrijker dan de cijfers, en een goed gesprek waarin je mensen de ruimte geeft om hun eigen mening te uiten en te ontwikkelen is ook belangrijker dan het eenrichtingsverkeer over 'zo moet het.' Ik heb voor de volgende generatie programmeurs graag mensen die zelfstandig kritisch kunnen nadenken, in plaats van blind de dogma's op te dreunen.

[RayNbow]

incaz schreef op vrijdag 09 september 2016 @ 21:03:
Daarnaast: als je tijdens je studententijd niet meer mag ontdekken door dingen fout te doen, wanneer dan wel? IEDEREEN hier heeft fouten moeten maken, shortcuts genomen, dingen te hard gecodeerd en teveel gecoupled, te slordig opgelost, en in reactie ook weer overengineered... dat heet ontwikkelen.

Tuurlijk mag dat. Het wordt alleen beloond met een lager cijfer.

[F.West98]

Hydra schreef op vrijdag 09 september 2016 @ 18:34:
Ik kan je in ieder geval aanraden dit eens te lezen en te zorgen dat je zelf niet in deze pitfall dondert. Je posts hebben alle tekenen in ieder geval.

Ik ken die post, en ik heb door dat mij dat zomaar kan gebeuren. Ik probeer dat natuurlijk te voorkomen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

DevWouter schreef op vrijdag 09 september 2016 @ 19:06:
Wat ik zo hoor is dat jij graag je kunsten wilt laten zien en daarom meer doet waarom gevraagd wordt. Als de taak is om twee getallen bij elkaar op te tellen dan moet je geen quantum-rekenmachine maken

Doe de opdracht zoals het van je verlangd wordt en niet meer of minder. Alles wat je extra doet geeft je namelijk geen extra punten terwijl het wel voor punten aftrek kan zorgen.

Meestal wil ik dat wel, maar doe ik het niet. Maar in dit geval heeft de docent meerdere keren expliciet aangegeven dat de opdracht een "sandbox" is waarin je jouw kunsten moet tonen. De opdrachtbeschrijving is daarin een minimale vereiste, maar ze zien het liefst uitbreidingen daarop. Eerder heeft dit mij ook bonuspunten opgeleverd, dus vandaar.

incaz schreef op vrijdag 09 september 2016 @ 21:03:
Wonderlijk hoe men meent steeds zo'n belerende toon uit de kast te moeten trekken richting F.West - kritiek is niet gewoon kritiek op de inhoud van de code ofzo, nee, het heeft toch steeds de ondertoon 'luister naar je meerderen, wij zijn ouder.' Er wordt door anderen volgens mij heel wat meer gebitcht, en ook nog wel eens onterechter, maar daar voelt men zich niet zo geroepen om steeds weer de ander op z'n plaats te zetten.

Inderdaad. Geef vooral kritiek op mijn code, graag juist! Dat gezeur over "wij zijn ouder en we weten het beter" is één van de redenen dat ik hier steeds minder vaak stoom afblaas, omdat het elke keer weer neerkomt op "welkom in de grote wereld" en "zo is het nou eenmaal".

[armageddon_2k1]

Skyaero schreef op vrijdag 09 september 2016 @ 09:56:
[...]


Als je Troy's twitter een beetje volgt, zie je geregeld dit soort treurige gevallen voorbij komen. Soms heb ik het gevoel dat een hobbywebsite van een Tweaker betere beveiliging heeft dan de gemiddelde websites met klantinformatie.

Infosec heeft helaas nog te weinig aandacht. En dat is jammer, want hacking is letterlijk child's play, zoals Troy Hunt recentlijk demonstreerde op NDC Sydney (54:30, hoewel de hele presentatie fantastisch is)

[video]

Nice. Leuk om te zien dat de ING website in zijn praatje voorbijkomt :-)

[DevWouter]

F.West98 schreef op vrijdag 09 september 2016 @ 21:38:
[...]

Ik ken die post, en ik heb door dat mij dat zomaar kan gebeuren. Ik probeer dat natuurlijk te voorkomen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Ik wil best wel een keer codereview met je doen. Overigens is het niet zo dat we continue met scrum, unit testing of het smaakje-van-de-dag bezig zijn. Elke ontwikkelaar is met regelmaat bezig met het stront scheppen, echter hoor je ons er niet over.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

incaz schreef op vrijdag 09 september 2016 @ 21:03:
Wonderlijk hoe men meent steeds zo'n belerende toon uit de kast te moeten trekken richting F.West - kritiek is niet gewoon kritiek op de inhoud van de code ofzo, nee, het heeft toch steeds de ondertoon 'luister naar je meerderen, wij zijn ouder.' Er wordt door anderen volgens mij heel wat meer gebitcht, en ook nog wel eens onterechter, maar daar voelt men zich niet zo geroepen om steeds weer de ander op z'n plaats te zetten.

Ik zie eerder als "advies van mensen die ook dom waren"

[F.West98]

DevWouter schreef op zaterdag 10 september 2016 @ 00:50:
[...]


Ik wil best wel een keer codereview met je doen. Overigens is het niet zo dat we continue met scrum, unit testing of het smaakje-van-de-dag bezig zijn. Elke ontwikkelaar is met regelmaat bezig met het stront scheppen, echter hoor je ons er niet over.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Met als enige verschil dat "jullie" er überhaupt mee bezig zijn. Natuurlijk gaat niet alles altijd helemaal volgens plan, hoor vaak genoeg anderen hier klagen over slechte code, vervelende collega's, enzovoorts.

[ElkeBxl]

F.West98 schreef op vrijdag 09 september 2016 @ 21:38:
[...]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

DevWouter schreef op zaterdag 10 september 2016 @ 00:50:
[...]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[armageddon_2k1]

DevWouter schreef op zaterdag 10 september 2016 @ 00:50:
[...]


Ik wil best wel een keer codereview met je doen. Overigens is het niet zo dat we continue met scrum, unit testing of het smaakje-van-de-dag bezig zijn. Elke ontwikkelaar is met regelmaat bezig met het stront scheppen, echter hoor je ons er niet over.

Eeuuuhmm... dat is niet helemaal waar. Genoeg mensen die hier constant aan het zeiken zijn over hun werk en welke achterlijke marketing-managers / klanten / recruiters / juniors / mediors / seniors ze wel niet hebben. En wie bedoel je met ons? Het elite-clubje waar F.West nog niet bij hoort omdat ie te jong is? . Ik denk dat je voor jezelf moet spreken hier. Dat jij niet klaagt is prima, maar dat betekent niet dat er meteen een waarde-oordeel vast zit aan iemand die he wel doet Overigens, in de topic-warning:

Dit topic is niet de plaats om te lopen helpdesken. De Coffee Corner is primair bedoeld als uitlaatklep voor iedereen in de Devschuur® en niet als vraagbaak.

Ik ben geen programmeur / ontwikkelaar, maar ik heb ook regelmatig last van bovenstaande dingen, maar mij hoor je er niet over.

Firesphere plaatst hier ook regelmatig halve mail-wisselingen met klanten/recruiters waar ie ze schoffeert. Prima natuurlijk, daar is dit de uitlaatklep voor. Je wil niet weten wat voor achterlijke mails ik af en toe krijg alleen die plaats ik niet hier. Het is een beetje inherent aan het werkveld. Dus mij hoor je er niet over.... ben ik nu superieur aan Firesphere? Denk het niet.

[ Voor 27% gewijzigd door armageddon_2k1 op 10-09-2016 08:55 ]

[DevWouter]

armageddon_2k1 schreef op zaterdag 10 september 2016 @ 08:47:
[...]

Eeuuuhmm... dat is niet helemaal waar. Genoeg mensen die hier constant aan het zeiken zijn over hun werk en welke achterlijke marketing-managers / klanten / recruiters / juniors / mediors / seniors ze wel niet hebben. En wie bedoel je met ons? Het elite-clubje waar F.West nog niet bij hoort omdat ie te jong is? . Ik denk dat je voor jezelf moet spreken hier. Dat jij niet klaagt is prima, maar dat betekent niet dat er meteen een waarde-oordeel vast zit aan iemand die he wel doet

Ik bedoel het dagelijkse gezwoeg, zoals de klant gerust stellen of die ene klote bug oplossen. De verhalen die ik hier lees zijn meer van de uitschieters die we noemenswaardig vinden (of althans dat hoop ik, want anders is het wel heel treurig gesteld met mijn baan ).
Dat bedoel ik dan ook met "stront scheppen", het is smerig werk, maar we doen het omdat het bij het vak hoort

Ik zou niet willen spreken over een clubje, maar er is wel een verschil in ervaring. Dat is logisch gezien hij nog niet de kans heeft gehad om het te ervaren. Het zou vreemd zijn als we dat gaan negeren.

Verder probeer ik zo min mogelijk mensen te beoordelen zeker online waar het toch lastig is. Iedereen is vrij om te doen wat hij wilt in dit topic en als dat mij niet bevalt dan ga ik wel iets anders doen

[Firesphere]

F.West98 schreef op vrijdag 09 september 2016 @ 21:38:
[...]

Ik ken die post, en ik heb door dat mij dat zomaar kan gebeuren. Ik probeer dat natuurlijk te voorkomen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[...]

Inderdaad. Geef vooral kritiek op mijn code, graag juist! Dat gezeur over "wij zijn ouder en we weten het beter" is één van de redenen dat ik hier steeds minder vaak stoom afblaas, omdat het elke keer weer neerkomt op "welkom in de grote wereld" en "zo is het nou eenmaal".

Ik zou zeggen, deel eens wat? Dan krijg je feedback. Alleen maar roepen, maar niet een echt volledig programma of opdracht delen, is lastig om echt nuttige feedback op te geven.

[Hydra]

incaz schreef op vrijdag 09 september 2016 @ 21:03:
Wonderlijk hoe men meent steeds zo'n belerende toon uit de kast te moeten trekken richting F.West - kritiek is niet gewoon kritiek op de inhoud van de code ofzo, nee, het heeft toch steeds de ondertoon 'luister naar je meerderen, wij zijn ouder.' Er wordt door anderen volgens mij heel wat meer gebitcht, en ook nog wel eens onterechter, maar daar voelt men zich niet zo geroepen om steeds weer de ander op z'n plaats te zetten.

Ik weet niet of dit ook op mijn reactie slaat maar dat is zeker m'n bedoeling niet. Als het belerend overkomt; excuses.

F.West98 schreef op vrijdag 09 september 2016 @ 21:38:
Ik ken die post, en ik heb door dat mij dat zomaar kan gebeuren. Ik probeer dat natuurlijk te voorkomen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Dit is echt een kwestie van in het juiste bedrijf terechtkomen. Ik denk dat ik hier wel wat mensen aan 't steigeren krijg maar als je bij een doorsnee PHP web dev bedrijf aan de slag gaat is de kans gewoon erg groot dat je in een dergelijke situatie terecht komt. Als je echt grote complexe systemen gaat bouwen kom je er gewoon niet mee weg om niet te testen e.d. Die systemen zijn veel en veel te groot voor een enkel persoon om 100% te kennen. Dus als je in zo'n systeem iets aanpast heb je gewoon safeguards nodig om te voorkomen dat er aan de andere kant dingen omvallen: tests.

Je hebt een beetje de bovenkant van de piramide met bedrijven die dit werk erg serieus nemen, goed kijken naar de laatste ontwikkelingen op gebied van continuous integration e.d., en daaronder een hele grote berg bedrijven die maar een beetje aanbroddelen.

Je hebt nog alle tijd om te zorgen dat je in een 'goed' bedrijf terecht komt maar het is wel iets wat je zelf moet doen. Dus wees ook in een interview gewoon kritisch: ik vraag altijd hoe de houding is t.o.v. testing, TDD, version control, deployment, CI, etc. Teveel 'black marks' en het is een no-go voor mij. Je kunt namelijk wel denken dat je dat in je eentje gaat veranderen maar over het algemeen hebben dergelijke bedrijven daar helemaal geen zin in. Die kloten liever gewoon verder met hun eigengebakken PHP 'framework' met jquery test loze frontends.

[ Voor 12% gewijzigd door Hydra op 10-09-2016 13:00 ]

[Firesphere]

Hydra schreef op zaterdag 10 september 2016 @ 12:55:
[...]


Dit is echt een kwestie van in het juiste bedrijf terechtkomen. Ik denk dat ik hier wel wat mensen aan 't steigeren krijg maar als je bij een doorsnee PHP web dev bedrijf aan de slag gaat is de kans gewoon erg groot dat je in een dergelijke situatie terecht komt. Als je echt grote complexe systemen gaat bouwen kom je er gewoon niet mee weg om niet te testen e.d. Die systemen zijn veel en veel te groot voor een enkel persoon om 100% te kennen. Dus als je in zo'n systeem iets aanpast heb je gewoon safeguards nodig om te voorkomen dat er aan de andere kant dingen omvallen: tests.

Je hebt een beetje de bovenkant van de piramide met bedrijven die dit werk erg serieus nemen, goed kijken naar de laatste ontwikkelingen op gebied van continuous integration e.d., en daaronder een hele grote berg bedrijven die maar een beetje aanbroddelen.

Je hebt nog alle tijd om te zorgen dat je in een 'goed' bedrijf terecht komt maar het is wel iets wat je zelf moet doen. Dus wees ook in een interview gewoon kritisch: ik vraag altijd hoe de houding is t.o.v. testing, TDD, version control, deployment, CI, etc. Teveel 'black marks' en het is een no-go voor mij. Je kunt namelijk wel denken dat je dat in je eentje gaat veranderen maar over het algemeen hebben dergelijke bedrijven daar helemaal geen zin in. Die kloten liever gewoon verder met hun eigengebakken PHP 'framework' met jquery test loze frontends.

Ik weet niet of "het juiste bedrijf" het correcte antwoord is hier. Zoals ik in m'n vorige post beschreef ben ik van werkgever gewisseld, beginnende bij een bedrijf dat "absoluut geen idee had hoe het moet", naar nu in een positie waar ik team lead ben, me totaal niet druk hoef te maken over deployments etc., een geweldig operations team om directe issues op te vangen en constant leer over hoe je team dynamics moet benaderen en ben ik veel meer bezig met anderen uit te leggen hoe dingen het beste gedaan kunnen worden etc.
Mijn tijd bij mijn eerste werkgever is enorm waardevol geweest voor mij, als leerschool.
Een slechte leerschool waar je goede kennis uit opdoet, is ook een leerschool geweest achteraf.

Ik moet wel toegeven, dat ik niet terug wil naar 1 van m'n vorige werkgevers, om de punten die je noemt. Wel zou ik terug gaan naar m'n laatste werkgever, omdat het daar gewoon leuk werken was en we uitdagende projecten hadden.
En die twee balanceren elkaar prima. Ze staan ook absoluut open voor verbeteringen etc.

En voordat je gaat roepen "ja maar jij werkt vast alleen met SilverStripe", nou nee, ik werk ook met Python op de RPi, bijvoorbeeld, met Flask, full integration en integrated testing, ik werk hier met java en Solr, maar hoofdzakelijk werk ik met mensen.

spoiler:

Ik kan de "WTF jij en samenwerken" etc. kreten hier horen! Schreeuw niet zo hard, Ik probeer te slapen!

[F.West98]

Firesphere schreef op zaterdag 10 september 2016 @ 12:30:
[...]

Ik zou zeggen, deel eens wat? Dan krijg je feedback. Alleen maar roepen, maar niet een echt volledig programma of opdracht delen, is lastig om echt nuttige feedback op te geven.

Ik deel hier weinig omdat dit het topic daarvoor niet is. Maargoed, je bent natuurlijk vrij om op mijn GitHub profiel te kijken. Enkele projecten waar ik zelf wel blij mee ben: 1 (nog niet volledig af, maar wel blij met de networking dingen) 2 (hier ben ik echt blij mee) 3 (met dank aan RobIII voor enkele verbeteringen) 4 (ouder project)
Ik heb ook veel serverside dingen (de API voor 2 en 4 bijvoorbeeld) in een private TFS staan, wellicht dat ik die ook ooit nog eens op GH zet.

Hydra schreef op zaterdag 10 september 2016 @ 12:55:
[...]


Dit is echt een kwestie van in het juiste bedrijf terechtkomen. Ik denk dat ik hier wel wat mensen aan 't steigeren krijg maar als je bij een doorsnee PHP web dev bedrijf aan de slag gaat is de kans gewoon erg groot dat je in een dergelijke situatie terecht komt. Als je echt grote complexe systemen gaat bouwen kom je er gewoon niet mee weg om niet te testen e.d. Die systemen zijn veel en veel te groot voor een enkel persoon om 100% te kennen. Dus als je in zo'n systeem iets aanpast heb je gewoon safeguards nodig om te voorkomen dat er aan de andere kant dingen omvallen: tests.

Je hebt een beetje de bovenkant van de piramide met bedrijven die dit werk erg serieus nemen, goed kijken naar de laatste ontwikkelingen op gebied van continuous integration e.d., en daaronder een hele grote berg bedrijven die maar een beetje aanbroddelen.

Je hebt nog alle tijd om te zorgen dat je in een 'goed' bedrijf terecht komt maar het is wel iets wat je zelf moet doen. Dus wees ook in een interview gewoon kritisch: ik vraag altijd hoe de houding is t.o.v. testing, TDD, version control, deployment, CI, etc. Teveel 'black marks' en het is een no-go voor mij. Je kunt namelijk wel denken dat je dat in je eentje gaat veranderen maar over het algemeen hebben dergelijke bedrijven daar helemaal geen zin in. Die kloten liever gewoon verder met hun eigengebakken PHP 'framework' met jquery test loze frontends.

Ja dat klopt. Het probleem is dat de serieuzere bedrijven vaak geen zin hebben in studenten die niet voorspelbaar beschikbaar zijn. Ik werk tot nu toe altijd volgens een 0-urencontract en echt alleen zodra ik tijd heb. Serieuzere, grotere bedrijven hebben harde deadlines en dan kan ik daar moeilijk(er) aankomen met "ja sorry ik kon écht niet meer want heb vorige week 5 tentamens gehad".
Ik ga denk ik wel voor volgende zomer het goed aanpakken bij een serieuzer bedrijf, want zo'n periode van enkele weken/maanden constante beschikbaarheid werkt een stuk beter in dat geval.

[ Voor 4% gewijzigd door F.West98 op 10-09-2016 14:08 ]