Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

De Devschuur Coffee Corner - Iteratie ⓫ Vorige deelOverzicht

Pagina: 1 ... 51 52 53 Laatste
Acties:

  • Antrax
  • Registratie: april 2012
  • Laatst online: 20-09 15:36
quote:
Brakkie41 schreef op maandag 18 september 2017 @ 08:51:
[...]


Zou eerder zeggen dat er tegenwoordig genoeg mensen zijn die verwachten dat alles maar voor hen geregeld wordt en in de schoot geworpen wordt. Wat is er mis met knetterhard werken en blijven leren totdat je bereikt heb wat je wenst te bereiken?


[...]


Niks. Maar ik heb het idee dat je zijn punt mist. (Of ik dat kan natuurlijk ook...)
Dat is juist wat ik bedoelde :P

Nintendo FC: SW-6670-3316-6323


  • Brakkie41
  • Registratie: november 2010
  • Nu online

Brakkie41

Turning coffee into software!

quote:
Antrax schreef op maandag 18 september 2017 @ 08:52:
[...]

Dat is juist wat ik bedoelde :P
Ik merk vooral (via mijn vriendin als Operations Manager) dat de "nieuwe" generatie hier moeite mee heeft. Lui van tussen de 18-25 jaar. Niet om ze allemaal over één kam te scheren maar hoor met name over die "generatie" dergelijke klachten. Misschien toch maar weer de opvoedende tik toestaan? }) ;)

Zelf 28 jaar, universiteit met rechtsachtergrond en enorm hard gewerkt, de afgelopen 4 jaar om mezelf om te scholen tot Software Developer :) 4 jaar geleden als doel gesteld om door te stromen vanuit een analytische positie binnen ons bedrijf tot de Engineering afdeling. 2 jaar terug de mogelijkheid gekregen en behoor (TROTS) tot de 2-3% van 450 Engineers die geen Computer Science (gerelateerde) achtergrond hebben :)

Hard work, pays off! d:)b (Toegegeven, het heeft me bijna me vriendin gekost maar dat is goed gekomen uiteindelijk :P )

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator DevschuurŽ
quote:
Brakkie41 schreef op maandag 18 september 2017 @ 09:00:
[...]
Ik merk vooral (via mijn vriendin als Operations Manager) dat de "nieuwe" generatie hier moeite mee heeft. Lui van tussen de 18-25 jaar. Niet om ze allemaal over één kam te scheren maar hoor met name over die "generatie" dergelijke klachten. Misschien toch maar weer de opvoedende tik toestaan? }) ;)
Ik denk dat het wel meevalt, het is denk meer gewoon de leeftijdscategorie. Of het zijn de mensen die sowieso al niet de motivatie gehad hebben om hun opleiding af te maken ( Immers op je 18e zal je meestal nog geen HBO opleiding afgerond hebben ), of het zijn de starters op de arbeidsmarkt. Ik denk persoonlijk dat het helemaal niet zo veel anders is dan vroeger, maar meer de perceptie van mensen die zelf ouder worden ;)

Woy wijzigde deze reactie 18-09-2017 09:31 (4%)

“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.”


  • Laurens-R
  • Registratie: december 2002
  • Laatst online: 22:30
Ik denk ook dat het wel meevalt, of wij hebben binnen ons bedrijf gewoon een kneitergoede recruiter, die precies weet wat voor volk ze binnen haalt :)

  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 20-09 12:25

TheNephilim

Wtfuzzle

quote:
Brakkie41 schreef op maandag 18 september 2017 @ 09:00:

Zelf 28 jaar, universiteit met rechtsachtergrond en enorm hard gewerkt, de afgelopen 4 jaar om mezelf om te scholen tot Software Developer :) 4 jaar geleden als doel gesteld om door te stromen vanuit een analytische positie binnen ons bedrijf tot de Engineering afdeling. 2 jaar terug de mogelijkheid gekregen en behoor (TROTS) tot de 2-3% van 450 Engineers die geen Computer Science (gerelateerde) achtergrond hebben :)

Hard work, pays off! d:)b (Toegegeven, het heeft me bijna me vriendin gekost maar dat is goed gekomen uiteindelijk :P )
Als ik dit zo lees heb ik vrij weinig gedaan, terwijl ik net een jaartje ouder ben dan jij :p. Vast een gebrek aan richting/visie oid. gezien jouw heldere doelstelling.

VILF Gaming


  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
quote:
Nog plannen je in de 21e eeuw te begeven? ;) Ik snap echt niet dat mensen heden ten dage nog met die meuk werken.
quote:
CodeCaster schreef op zaterdag 16 september 2017 @ 12:34:
Wat als er twee features op hun eigen branch ontwikkeld worden, dezelfde onderdelen raken en bij terugmergen subtiel een bug introduceren? Unit tests zijn leuk, maar vangen niet alles af, en integratietesten gaat doorgaans nog steeds met de hand.
Tja. Daar gaat het al fout. Testen moeten geautomatiseerd zijn en continue mee draaien in je build. Wij werken ook op feature branches (deze worden naar dev gemerged, dev wordt naar master gemerged voor releases) en daar draaien continue unit tests, integration tests en systeem tests tegenaan.
quote:
Features worden op hun eigen branch gereviewd en getest. Wiens verantwoordelijkheid is het om beide issues na het mergen nogmaals te testen?
Daar heb je software voor. Mensen zijn volledig ongeschikt als testers.

  • whoami
  • Registratie: december 2000
  • Laatst online: 23:45
quote:
Hydra schreef op maandag 18 september 2017 @ 10:38:
[...]


Nog plannen je in de 21e eeuw te begeven? ;) Ik snap echt niet dat mensen heden ten dage nog met die meuk werken.
Technisch gezien dateert SVN uit de 21ste eeuw :P

  • alienfruit
  • Registratie: maart 2003
  • Laatst online: 22:47

alienfruit

the alien you never expected

Sinds wanneer is + in je emailadres een ongeldige mailadres? Stomme NS.nl website :((

  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
quote:
whoami schreef op maandag 18 september 2017 @ 10:45:
Technisch gezien dateert SVN uit de 21ste eeuw :P
Wow. Dat dat in 2004 gereleased is. Voor m'n gevoel is het veel ouder maar dan waren we in die tijd (toen we van VS naar SVN gingen) behoorlijk cutting edge. Niet meer met gelockte files zitten als een collega er niet was, was een grote plus :D
quote:
alienfruit schreef op maandag 18 september 2017 @ 10:45:
Sinds wanneer is + in je emailadres een ongeldige mailadres? Stomme NS.nl website :((
Sinds prutsers e-mail validatie regexes van internet plukken.

Hint: e-mail kun je niet valideren met regexes.

Hydra wijzigde deze reactie 18-09-2017 11:12 (3%)


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:10
quote:
Hydra schreef op maandag 18 september 2017 @ 11:12:
[...]

Hint: e-mail kun je niet valideren met regexes.
Wij checken tegenwoordig enkel of er een @ inzit (en beide kanten niet leeg). Anders is er altijd wel een uitzondering die niet werkt, maar wel een daadwerkelijk werkend email adres is. En anders komt de email gewoon niet aan.

ThomasG wijzigde deze reactie 18-09-2017 11:27 (3%)


  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
quote:
ThomasG schreef op maandag 18 september 2017 @ 11:26:
[...]
Wij checken tegenwoordig enkel of er een @ inzit.
Ja, deden wij ook. En toen gingen we maar checken of precies 1 inzit want anders krijg je relatief veel gebruikers die typefouten maken. Maar hoe dan ook is de enige valide manier gewoon een mailtje sturen met een activatielink.

  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator DevschuurŽ
quote:
Hydra schreef op maandag 18 september 2017 @ 11:28:
[...]
En toen gingen we maar checken of precies 1 inzit want anders krijg je relatief veel gebruikers die typefouten maken.
Zelfs dan keur je al valide e-mail adressen af, al is het natuurlijk niet heel gebruikelijk om
"dasfad @ dfadfd"@domain.ext

Als mail adres te hebben ;)

“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.”


  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
quote:
Woy schreef op maandag 18 september 2017 @ 11:39:
Zelfs dan keur je al valide e-mail adressen af, al is het natuurlijk niet heel gebruikelijk om
"dasfad @ dfadfd"@domain.ext

Als mail adres te hebben ;)
Ja klopt. Ik vond het ook een te simpele keuze aangezien client side validatie (het sturen van gebruikers) en server side validatie (correctheid) gewoon twee aparte zaken zijn die toevallig redelijk wat overlap hebben. Maar het plan is toch in de nabije toekomst e-mails te gaan sturen dus tot dan hebben de mensen met dergelijke rare adressen gewoon ff pech :)

  • _Moe_
  • Registratie: mei 2006
  • Laatst online: 19-09 12:34
quote:
Hydra schreef op maandag 18 september 2017 @ 12:57:
... Maar het plan is toch in de nabije toekomst e-mails te gaan sturen dus tot dan hebben de mensen met dergelijke rare adressen gewoon ff pech :)
Ik verschiet er altijd van dat dit geen standaard manier van werken is.

RTFM!


  • Sebazzz
  • Registratie: september 2006
  • Laatst online: 20-09 09:27
quote:
Hydra schreef op maandag 18 september 2017 @ 10:38:
[...]


Nog plannen je in de 21e eeuw te begeven? ;) Ik snap echt niet dat mensen heden ten dage nog met die meuk werken.
Wat is er mis met SVN dan? Het werkt. It ain't broken.

Het enige is dat langlopende branches wat vervelend zijn in het VCS. Voor de rest doet het wat het moet doen. CVS is echt kapot maar SVN voldoet volgens mij nog prima aan de wensen die we hebben.

[Website en online portfolio]


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:10
quote:
Sebazzz schreef op maandag 18 september 2017 @ 13:35:
[...]

Wat is er mis met SVN dan? Het werkt. It ain't broken.

Het enige is dat langlopende branches wat vervelend zijn in het VCS. Voor de rest doet het wat het moet doen. CVS is echt kapot maar SVN voldoet volgens mij nog prima aan de wensen die we hebben.
SVN is centralised en Git is decentralised.Alleen al hierom is Svn voor ons waardeloos.

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 02:40

.oisyn

Moderator DevschuurŽ

Demotivational Speaker

quote:
ThomasG schreef op maandag 18 september 2017 @ 13:48:
[...]
SVN is centralised en Git is decentralised.Alleen al hierom is Svn voor ons waardeloos.
Heel goed, voor jullie. Maar dat gegeven alleen maakt SVN niet per definitie waardeloos :). Ik moet er niet aan denken dat wij decentralized zouden gaan werken :X al zou dat voor louter de code wel een nuttige feature zijn.

If we can hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate.


  • Laurens-R
  • Registratie: december 2002
  • Laatst online: 22:30
quote:
.oisyn schreef op maandag 18 september 2017 @ 13:52:
[...]


Heel goed, voor jullie. Maar dat gegeven alleen maakt SVN niet per definitie waardeloos :). Ik moet er niet aan denken dat wij decentralized zouden gaan werken :X al zou dat voor louter de code wel een nuttige feature zijn.
Kan ik me voorstellen met al die enorme assets die bij game development om de hoek komen kijken. Ik weet dat Perforce (of gebruiken jullie dat niet?) ook een Git "module" heeft tegenwoordig. Hebben ze daar wat verzonnen op de challenges van game development icm GIT, of is het gewoon een extraatje voor diegenen die het willen?

  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 20-09 12:25

TheNephilim

Wtfuzzle

Git LFS is denk ik een oplossing voor bijv. grote assets in games, of niet?

VILF Gaming


  • Alex)
  • Registratie: juni 2003
  • Laatst online: 00:15
Zijn er hier eigenlijk mensen die Microsoft's GVFS gebruiken?

We are shaping the future


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 02:40

.oisyn

Moderator DevschuurŽ

Demotivational Speaker

quote:
Laurens-R schreef op maandag 18 september 2017 @ 13:56:
[...]


Kan ik me voorstellen met al die enorme assets die bij game development om de hoek komen kijken. Ik weet dat Perforce (of gebruiken jullie dat niet?) ook een Git "module" heeft tegenwoordig.
De Perforce server heeft een Git backend. Dat voelt dus een beetje achterstevoren, want je blijft gecentraliseerd werken. Je combineert zeg maar de nadelen van Perforce met de nadelen van Git 8)7
quote:
TheNephilim schreef op maandag 18 september 2017 @ 13:59:
Git LFS is denk ik een oplossing voor bijv. grote assets in games, of niet?
Ken ik eerlijk gezegd niet, maar het probleem met assets is vooral dat ze zo goed als niet te mergen zijn. Je wílt dus ook gewoon een centrale server met 1 tijdlijn.

.oisyn wijzigde deze reactie 18-09-2017 14:28 (26%)

If we can hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate.


  • nemo55
  • Registratie: februari 2004
  • Laatst online: 20-09 17:41
Momenteel gebruiken wij git, maar het heeft zeker nadelen zodra je met binaries gaat lopen rotzooien in grotere teams. Binnenkort wil ik eens kijken aar PlasticSCM (https://www.plasticscm.com/). Iemand daar toevallig al ervaring mee? Deze lijkt wat voordelen van Git en Perforce te combineren.

  • Merethil
  • Registratie: december 2008
  • Laatst online: 22:25
quote:
.oisyn schreef op maandag 18 september 2017 @ 14:27:
[...]

De Perforce server heeft een Git backend. Dat voelt dus een beetje achterstevoren, want je blijft gecentraliseerd werken. Je combineert zeg maar de nadelen van Perforce met de nadelen van Git 8)7


[...]

Ken ik eerlijk gezegd niet, maar het probleem met assets is vooral dat ze zo goed als niet te mergen zijn. Je wílt dus ook gewoon een centrale server met 1 tijdlijn.
Gebruiken jullie TFS? Kan ooit een screenshot van jouw werkomgeving herinneren waarin ik volgens mij VS zag.

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 02:40

.oisyn

Moderator DevschuurŽ

Demotivational Speaker

quote:
Merethil schreef op maandag 18 september 2017 @ 14:55:
[...]


Gebruiken jullie TFS? Kan ooit een screenshot van jouw werkomgeving herinneren waarin ik volgens mij VS zag.
Nee. VS als ontwikkelomgeving, Perforce voor versioning en TestTrack of Jira als issue tracker.

If we can hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate.


  • Merethil
  • Registratie: december 2008
  • Laatst online: 22:25
quote:
.oisyn schreef op maandag 18 september 2017 @ 14:57:
[...]


Nee. VS als ontwikkelomgeving, Perforce voor versioning en TestTrack of Jira als issue tracker.
Ah kon ik niet helemaal opmaken uit de eerdere reacties. Thanks!

  • Soundless
  • Registratie: november 2008
  • Laatst online: 20-09 12:49
Hoe doen jullie dit icm met migrations?
Stel dat je v1.2.0 hebt gereleaset en ontwikkelingen voor 1.3.0 lopen al een tijdje. Vervolgens moeten er fixes op de 1.2.0 uitgevoerd worden, waardoor er een 1.2.1 ontstaat. De fixes bevatten ook migrations.

Hoe krijgen jullie deze migrations ook in de 1.3.0? Ik snap dat je gewoon de migrations kan doormergen naar de 1.3.0 maar als de migrations voor 1.2.1 effect hebben op de migrations die je al in de ontwikkeling van 1.3.0 hebt gedaan, zit je dus met gebakken peren.

Dit hele probleem heb je dus ook als iedereen op feature branches gaat werken.

Ik ben dus wel benieuwd hoe iedereen omgaat met migrations en source control/releases.

  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:10
quote:
Soundless schreef op maandag 18 september 2017 @ 16:13:
Hoe doen jullie dit icm met migrations?
Stel dat je v1.2.0 hebt gereleaset en ontwikkelingen voor 1.3.0 lopen al een tijdje. Vervolgens moeten er fixes op de 1.2.0 uitgevoerd worden, waardoor er een 1.2.1 ontstaat. De fixes bevatten ook migrations.

Hoe krijgen jullie deze migrations ook in de 1.3.0? Ik snap dat je gewoon de migrations kan doormergen naar de 1.3.0 maar als de migrations voor 1.2.1 effect hebben op de migrations die je al in de ontwikkeling van 1.3.0 hebt gedaan, zit je dus met gebakken peren.

Dit hele probleem heb je dus ook als iedereen op feature branches gaat werken.

Ik ben dus wel benieuwd hoe iedereen omgaat met migrations en source control/releases.
Dat hangt af van de situatie. Als het kan forken we de oudste integration branch (waar de bug in zit) naar een bugfix branch, fixen het daar, en mergen het in de branches die het nodig hebben. En anders doen we een cherry-pick met -x.

  • ElkeBxl
  • Registratie: oktober 2014
  • Laatst online: 20-09 07:49

ElkeBxl

Brusselse tassendraagster

Wij werken gewoon altijd in 1 gigantische branch. Als iedereen dan vaak genoeg incheckt en get latest doet, zie je snel genoeg op wie je kwaad moet worden :Y) Als er al bugfixes moeten gebeuren voor de volgende grote release, maken we soms eens een branch aan om daarop de fix te doen maar dan moet het echt al aan het branden zijn eer we dat mogen doen.

Members only:
Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Without nipples, boobs are pointless - 365 project - In mijn hoofd is het alle dagen Kerstmis - What type of bees make milk? Boobies!


  • Soundless
  • Registratie: november 2008
  • Laatst online: 20-09 12:49
quote:
ThomasG schreef op maandag 18 september 2017 @ 16:19:
[...]
Dat hangt af van de situatie. Als het kan forken we de oudste integration branch (waar de bug in zit) naar een bugfix branch, fixen het daar, en mergen het in de branches die het nodig hebben. En anders doen we een cherry-pick met -x.
Dus in sommige gevallen moeten jullie alle migrations die erna komen aanpassen?

Simpel voorbeeld:
Je hebt een tabel met 1 kolom (kolom A).
In de 1.2.1 migration wordt die hernoemd naar kolom B

De 1.3.0 kent kolom B nog niet (die heet nog kolom A) dus alle migrations die je al hebt gedaan voor de 1.3.0 verwijzen naar kolom A.
Als je nu dus 1.2.1 wil mergen naar 1.3.0, moet je alle migrations aanpassen.


Is dit hoe jullie werken? Wij werken iig op het moment (ook?) zo, maar het bevalt ons niet echt vanwege o.a. bovenstaand voorbeeld.

  • kenneth
  • Registratie: september 2001
  • Niet online

kenneth

achter de duinen

Update voor VS2017. Ok, updaten maar!
quote:
Please update Visual Studio Installer before proceeding.
-O-

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • Soundless
  • Registratie: november 2008
  • Laatst online: 20-09 12:49
quote:
ElkeBxl schreef op maandag 18 september 2017 @ 16:21:
Wij werken gewoon altijd in 1 gigantische branch. Als iedereen dan vaak genoeg incheckt en get latest doet, zie je snel genoeg op wie je kwaad moet worden :Y) Als er al bugfixes moeten gebeuren voor de volgende grote release, maken we soms eens een branch aan om daarop de fix te doen maar dan moet het echt al aan het branden zijn eer we dat mogen doen.


***members only***
Dit is ook hoe wij op het moment werken, maar we zijn aan het 'upgraden'. Dus we willen zsm zo veel mogelijk hierin veranderen. We zien namelijk dat dit heel vaak fout gaat en de releases ook vaak vertraagd :p

  • Styxxy
  • Registratie: augustus 2009
  • Laatst online: 02:33
Mijn eerste pull request op GitHub (Microsoft Docs) is geaccepteerd *O*.

Ervoor steeds passieve gebruiker van github geweest :).

Styxxy wijzigde deze reactie 18-09-2017 19:35 (12%)


  • Neko Koneko
  • Registratie: december 2006
  • Laatst online: 20-09 18:53
quote:
kenneth schreef op maandag 18 september 2017 @ 16:25:
Update voor VS2017. Ok, updaten maar!


[...]
-O-
Dat is volgens mij altijd al zo geweest :P

edit: in VS2017 althans

Neko Koneko wijzigde deze reactie 19-09-2017 07:54 (5%)


  • Brakkie41
  • Registratie: november 2010
  • Nu online

Brakkie41

Turning coffee into software!

quote:
Styxxy schreef op maandag 18 september 2017 @ 19:35:
Mijn eerste pull request op GitHub (Microsoft Docs) is geaccepteerd *O*.

Ervoor steeds passieve gebruiker van github geweest :).
Congrats! Keep it up! Altijd fijn om je naam in commit logs te hebben staan bij Ooen Source projecten d:)b

Afgelopen weekend heeft één persoon een branch gemerged gericht op de migratie richting Erlang OTP 20. Top d:)b Beetje jammer alleen dat het een breaking change is voor dev machines. Source dus opnieuw compilen en bijna een uur verder voordat je aan de bak kan -O-

Brakkie41 wijzigde deze reactie 19-09-2017 08:29 (27%)

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”


  • Neko Koneko
  • Registratie: december 2006
  • Laatst online: 20-09 18:53
Ik weet niet of mijn branching gewoontes goed zijn, ik heb een MAIN branch (gebruikt Git btw) en een Develop branch. Project wordt gebouwd vanaf de MAIN branch, ik werk zoveel mogelijk op de Develop branch die ik om de zoveel tijd naar de MAIN branch merge. In zekere zin voelt het als overkill (ik werk alleen op dit project en ik build alleen op de build server als ik lokaal geen fouten krijg) maar aan de andere kant voelt het wel fijn dat ik op deze manier minder makkelijk dingen kan slopen. Zit nog te overwegen om voor features/bugfixes etc ook aparte branches te maken welke ik dan eerst naar develop merge en daarna naar MAIN.

Ik hoop nog steeds dat ik ooit een sloofje tweede ontwikkelaar krijg op mijn project en dan wil ik het mezelf alvast goed aangeleerd hebben. O+

  • Styxxy
  • Registratie: augustus 2009
  • Laatst online: 02:33
Ik ben het nog niet echt gewoon. Ik had een fork van de master en daarop dan changes gedaan. Maar bij elke pull request komen mijn vorige changes (die reeds geaccepteerd waren) terug zichtbaar "te mergen".

Ik snap er nog niet veel van :) .

(Ik ben gewend om met TFS (VC) te werken.)

Styxxy wijzigde deze reactie 19-09-2017 09:24 (8%)


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:10
quote:
Neko Koneko schreef op dinsdag 19 september 2017 @ 09:21:
Ik weet niet of mijn branching gewoontes goed zijn, ik heb een MAIN branch (gebruikt Git btw) en een Develop branch. Project wordt gebouwd vanaf de MAIN branch, ik werk zoveel mogelijk op de Develop branch die ik om de zoveel tijd naar de MAIN branch merge. In zekere zin voelt het als overkill (ik werk alleen op dit project en ik build alleen op de build server als ik lokaal geen fouten krijg) maar aan de andere kant voelt het wel fijn dat ik op deze manier minder makkelijk dingen kan slopen. Zit nog te overwegen om voor features/bugfixes etc ook aparte branches te maken welke ik dan eerst naar develop merge en daarna naar MAIN.

Ik hoop nog steeds dat ik ooit een sloofje tweede ontwikkelaar krijg op mijn project en dan wil ik het mezelf alvast goed aangeleerd hebben. O+
Zelfs als je alleen werkt is het handig om niet direct op develop te werken. Soms wil je namelijk om verschillende redenen aan meerdere dingen tegelijk werken die een langere tijd duren (bijvoorbeeld voorbereiden op dependency upgrades, maar API is veranderd; dus dingen refactoren; of een nieuwe feature duurt langer dan gedacht, en je wilt ondertussen iets anders toevoegen). Als je dat direct op develop doet, loopt alles door elkaar, heb je mogelijk geen develop branch die werkt, en kun je in de tussentijd geen (althans, niet gemakkelijk) werkende wijzigingen naar master pushen.

ThomasG wijzigde deze reactie 19-09-2017 09:30 (4%)


  • simon
  • Registratie: maart 2002
  • Laatst online: 21:29
quote:
Neko Koneko schreef op dinsdag 19 september 2017 @ 09:21:
Ik weet niet of mijn branching gewoontes goed zijn, ik heb een MAIN branch (gebruikt Git btw) en een Develop branch. Project wordt gebouwd vanaf de MAIN branch, ik werk zoveel mogelijk op de Develop branch die ik om de zoveel tijd naar de MAIN branch merge. In zekere zin voelt het als overkill (ik werk alleen op dit project en ik build alleen op de build server als ik lokaal geen fouten krijg) maar aan de andere kant voelt het wel fijn dat ik op deze manier minder makkelijk dingen kan slopen. Zit nog te overwegen om voor features/bugfixes etc ook aparte branches te maken welke ik dan eerst naar develop merge en daarna naar MAIN.

Ik hoop nog steeds dat ik ooit een sloofje tweede ontwikkelaar krijg op mijn project en dan wil ik het mezelf alvast goed aangeleerd hebben. O+


Probeer Git Flow eens.. Voor ons/mij werkt het goed

|>


  • Antrax
  • Registratie: april 2012
  • Laatst online: 20-09 15:36
quote:
simon schreef:
Probeer Git Flow eens.. Voor ons/mij werkt het goed
Dit gebruik ik ook in veel van mijn projecten.

Ik zit alleen met bugfixes/algemene improvements in mijn maag. Heb je hiervoor een branch naam? of een prefix en wat zet je na de prefix als branch naam? In die branch zullen voornamelijk kleine dingen opgelost worden zoals psr-4 issues, kleine service problemen of andere issues.

Kortom een soort backlog waarvan geen sprint is :)

Nintendo FC: SW-6670-3316-6323


  • simon
  • Registratie: maart 2002
  • Laatst online: 21:29
quote:
Antrax schreef op dinsdag 19 september 2017 @ 10:27:
[...]
Dit gebruik ik ook in veel van mijn projecten.

Ik zit alleen met bugfixes/algemene improvements in mijn maag. Heb je hiervoor een branch naam? of een prefix en wat zet je na de prefix als branch naam? In die branch zullen voornamelijk kleine dingen opgelost worden zoals psr-4 issues, kleine service problemen of andere issues.

Kortom een soort backlog waarvan geen sprint is :)
Voor een bugfix kun je toch een individuele hotfix aanmaken? Ik zou niet een losse branch met bugfixes maken die zo van je master of develop langzamerhand diverged.

|>


  • Alex)
  • Registratie: juni 2003
  • Laatst online: 00:15
quote:
Antrax schreef op dinsdag 19 september 2017 @ 10:27:
[...]
Ik zit alleen met bugfixes/algemene improvements in mijn maag. Heb je hiervoor een branch naam? of een prefix en wat zet je na de prefix als branch naam?
Het ticketnummer? Branches delete je toch weer wanneer je klaar bent.

We are shaping the future


  • gekkie
  • Registratie: april 2000
  • Laatst online: 22:45
wvttktjes ?

  • TJHeuvel
  • Registratie: mei 2008
  • Niet online
quote:
.oisyn schreef op maandag 18 september 2017 @ 14:27:
[...]

De Perforce server heeft een Git backend. Dat voelt dus een beetje achterstevoren, want je blijft gecentraliseerd werken. Je combineert zeg maar de nadelen van Perforce met de nadelen van Git 8)7


[...]

Ken ik eerlijk gezegd niet, maar het probleem met assets is vooral dat ze zo goed als niet te mergen zijn. Je wílt dus ook gewoon een centrale server met 1 tijdlijn.
Alleen al de .svn map is hier 50GB, misschien toch maar over gaan naar zo een setup. Helaas is er bij zo een kleine studio veel minder ruimte om aan de workflow te werken.

TJHeuvel wijzigde deze reactie 19-09-2017 11:02 (6%)

Freelance Unity3D developer


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 02:40

.oisyn

Moderator DevschuurŽ

Demotivational Speaker

@TJHeuvel 50GB, wat een luxe :D. 2,1TB hier :'(

If we can hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate.


  • TJHeuvel
  • Registratie: mei 2008
  • Niet online
De source control map? Die artiesten tegenwoordig, niet normaal meer!

Freelance Unity3D developer


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 02:40

.oisyn

Moderator DevschuurŽ

Demotivational Speaker

Ja. En dan heb je nog eens 1,3TB nodig voor de intermediate data om de content te bouwen.



Recruiters :z
quote:
Naast ervaring met Data en programmeren in C++, heeft hij ook ervaring met:
  • Algol, APLsv, C, FORTRAN, Java, Javascript, PHP, Python, R, MatLab, Mathematica, Latex, Sage, Apache, nginx, MySQL en Symfony
Riiight... 8)7

.edit: ook nog eens op mijn werk emailadres, die deel ik nooit met anderen }:|
.edit2: oh lol ik lees de mail verkeerd. Hij vraagt aan mij of ik plaats heb voor iemand met die skills. In regio Leiden 8)7. Waarom mailt ie mij in godsnaam.

.oisyn wijzigde deze reactie 19-09-2017 11:59 (84%)

If we can hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate.


  • Ger
  • Registratie: juni 2007
  • Laatst online: 20-09 16:19
Wat is iTunes toch een rukprogramma. :(

Het enige Apple apparaat in huis is al jaren een iPod Nano (6e generatie). Op zich een prima apparaat, en doet al vele jaren zijn werk goed. Voor de vakantie weer wat CD's opmikken, dockingstation mee en lang leve de lol. Enkele keer heeft Mrs. Ger hem ook gebruikt tijdens het sporten.
offtopic:
Was de reden om hem aan te schaffen eigenlijk, maar het aantal vakanties is hoger geweest dan het aantal keer dat ze ermee gesport heeft


Enniewee: Gemiddeld 1x per jaar zwengel ik iTunes weer aan (onder Windows, want Linux is geen vriendjes met Apple) en dan begint de ellende weer: hoe doe hell kom ik bij een eenvoudig overzicht van CD's die op de iPod staan? Ah, bibliotheek. Hop, hetgeen wat eraf mag aanklikken, verwijderen. Mooi.

Oeps. Toch niet.

Nee, dat was alleen de bibliotheek. Dat heeft geen pepernoot te maken met wat er op mijn apparaat staat natuurlijk. Klik op apparaat -> muziek. Krijg je een lijst van alle losse nummers. Jeuj, van 20 cd's stuk voor stuk de boel uitvinken.

Nou ja, eerst maar eens het zwikkie importeren dan van CD's die niet in de bibliotheek staan. Uurtje verder (waren behoorlijk wat CD's) weer eens uitzoeken hoe het toch gemakkelijker kan. Apple wordt toch immers geprezen om haar software, nietwaar? Intuďtief, gemakkelijk, enzo?

Goed. Google to the rescue.

Blijkt dus dat je dus niet via de standaard navigatiebalk bij het overzicht kan komen wat ik zoek. Ook niet via het menu. Nee, ik moet onder het menu in een balk met 3 kleine knoppen op een grijs vierkantje met daarin een antraciet vierkantje klikken. Want dat lijkt natuurlijk spréékend op een iPod nano. 8)7

En als ik dan vanaf daar op muziek klik, krijg ik het overzicht wat ik wilde, en was het een kwestie van vinkjes zetten.

Echt, degene die dacht dat dit een goed idee was mogen ze een nekschot geven. Met jeukpoeder, want kogels geven zoveel rotzooi :> .

Voorts ben ik van mening dat boostmoderaties vernietigd moeten worden


  • gekkie
  • Registratie: april 2000
  • Laatst online: 22:45
quote:
Ger schreef op dinsdag 19 september 2017 @ 11:31:
Wat is iTunes toch een rukprogramma. :(
Ik maar denken dat de Apple een beetje spijt had van het akkefietje met Eva in het paradijs en derhalve pron uit iTunes verbannen had ?

Achja als er nog eens iemand komt met de Apple het summum van design en gebruiksvriendelijkheid is, heb je een leuk puzzeltje voor diegene :+.

gekkie wijzigde deze reactie 19-09-2017 11:43 (20%)


  • ZaZ
  • Registratie: oktober 2002
  • Laatst online: 01:03

ZaZ

Tweakers abonnee

quote:
.oisyn schreef op dinsdag 19 september 2017 @ 11:16:
Waarom mailt ie mij in godsnaam.
Om te vragen of je plaats hebt voor iemand met die skills.
Dat vertel je net zelf. 8)

Geen poes, maar een muis


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 02:40

.oisyn

Moderator DevschuurŽ

Demotivational Speaker

@ZaZ Klemtoon op de "mij" ;)

If we can hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate.


  • ZaZ
  • Registratie: oktober 2002
  • Laatst online: 01:03

ZaZ

Tweakers abonnee

Heerlijk rustig in mijn mailbox vandaag, gewoon nog helemaal geen mails gehad!
Had ik nog een filter actief staan.
Filter weg -> BOEM 20 mails die ik nu in een keer mag wegwerken :/

Geen poes, maar een muis


  • Woy
  • Registratie: april 2000
  • Niet online

Woy

Moderator DevschuurŽ
quote:
.oisyn schreef op dinsdag 19 september 2017 @ 11:16:
Waarom mailt ie mij in godsnaam.
Waarschijnlijk omdat de rest van het bedrijf hem al genegeerd heeft ;)

“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.”


  • whoami
  • Registratie: december 2000
  • Laatst online: 23:45
quote:
.oisyn schreef op dinsdag 19 september 2017 @ 11:16:
Ja. En dan heb je nog eens 1,3TB nodig voor de intermediate data om de content te bouwen.


Riiight... 8)7

.edit: ook nog eens op mijn werk emailadres, die deel ik nooit met anderen }:|
.edit2: oh lol ik lees de mail verkeerd. Hij vraagt aan mij of ik plaats heb voor iemand met die skills. In regio Leiden 8)7. Waarom mailt ie mij in godsnaam.
Dat is toch de omgekeerde wereld momenteel :P
Normaal wordt je om de oren geslagen met job-aanbiedingen.

  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:10
quote:
whoami schreef op dinsdag 19 september 2017 @ 14:28:
[...]

Dat is toch de omgekeerde wereld momenteel :P
Normaal wordt je om de oren geslagen met job-aanbiedingen.
Er is geen zelfrespecterend bedrijf dat zulke recruiters inhuurt. Die recruiters proberen zichzelf in stand te door zowel bedrijven voor een vacature als werknemers/zoekende voor een aanbieding. Volgens mij is er helemaal niemand die op ze zit te wachten, vooral omdat het allemaal ongevraagd is.

  • Rutix
  • Registratie: augustus 2009
  • Laatst online: 20-09 12:56
lekker dan ik ben al 2 weken ziek, en sinds dit weekend echt volop last van mijn kaak. Dus gisteren maar naar de dokter gegaan en blijkt dus dat ik kaakholteontsteking op. :( Gelukkig wel een antibiotica kuur gekregen waardoor het snel over moet gaan maar nog steeds geen pretje.

Nothing to see here!


  • Styxxy
  • Registratie: augustus 2009
  • Laatst online: 02:33
quote:
Rutix schreef op dinsdag 19 september 2017 @ 15:05:
lekker dan ik ben al 2 weken ziek, en sinds dit weekend echt volop last van mijn kaak. Dus gisteren maar naar de dokter gegaan en blijkt dus dat ik kaakholteontsteking op. :( Gelukkig wel een antibiotica kuur gekregen waardoor het snel over moet gaan maar nog steeds geen pretje.
Klinkt zeer onaangenaam. Veel beterschap gewenst!

  • ElkeBxl
  • Registratie: oktober 2014
  • Laatst online: 20-09 07:49

ElkeBxl

Brusselse tassendraagster

quote:
Rutix schreef op dinsdag 19 september 2017 @ 15:05:
lekker dan ik ben al 2 weken ziek, en sinds dit weekend echt volop last van mijn kaak. Dus gisteren maar naar de dokter gegaan en blijkt dus dat ik kaakholteontsteking op. :( Gelukkig wel een antibiotica kuur gekregen waardoor het snel over moet gaan maar nog steeds geen pretje.
Damn, sterkte :s

Iemand koffie? :p

Without nipples, boobs are pointless - 365 project - In mijn hoofd is het alle dagen Kerstmis - What type of bees make milk? Boobies!


  • Brakkie41
  • Registratie: november 2010
  • Nu online

Brakkie41

Turning coffee into software!

quote:
Rutix schreef op dinsdag 19 september 2017 @ 15:05:
lekker dan ik ben al 2 weken ziek, en sinds dit weekend echt volop last van mijn kaak. Dus gisteren maar naar de dokter gegaan en blijkt dus dat ik kaakholteontsteking op. :( Gelukkig wel een antibiotica kuur gekregen waardoor het snel over moet gaan maar nog steeds geen pretje.
Lekker dan. Klinkt pijnlijk of niet? Sterkte!
quote:
Lekker! Vriendin werkt vanmorgen vanuit huis en aangezien we net de slaapkamer hebben geverfd slapen we ff een paar dagen in de woonkamer dus geen koffie kunnen maken vanmorgen -O-

Brakkie41 wijzigde deze reactie 20-09-2017 08:32 (34%)

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”


  • dev10
  • Registratie: april 2005
  • Laatst online: 20-09 16:47
quote:
ThomasG schreef op dinsdag 19 september 2017 @ 14:41:
[...]
Er is geen zelfrespecterend bedrijf dat zulke recruiters inhuurt. Die recruiters proberen zichzelf in stand te door zowel bedrijven voor een vacature als werknemers/zoekende voor een aanbieding. Volgens mij is er helemaal niemand die op ze zit te wachten, vooral omdat het allemaal ongevraagd is.
Over recruiters gesproken: ik ben pas benaderd door een recruiter die netjes aangaf dat hij in opdracht werkte van bedrijf X en ik helemaal in het plaatje paste. Nu kende ik het bedrijf toevallig en het klopt ook dat ze op zoek zijn naar een developer. Ik heb hem hem vriendelijk bedankt, maar nog wel een compliment gegeven dat hij me op een nette manier benaderde.

Op zoek naar een nieuwe baan als PHP ontwikkelaar? Stuur me een DM.


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:10
quote:
dev10 schreef op woensdag 20 september 2017 @ 09:09:
[...]


Over recruiters gesproken: ik ben pas benaderd door een recruiter die netjes aangaf dat hij in opdracht werkte van bedrijf X en ik helemaal in het plaatje paste. Nu kende ik het bedrijf toevallig en het klopt ook dat ze op zoek zijn naar een developer. Ik heb hem hem vriendelijk bedankt, maar nog wel een compliment gegeven dat hij me op een nette manier benaderde.
Ongetwijfeld dat er ook recruiters zijn die het wel op een normale/eerlijke manier doen. Maar er zitten er gewoon veel bij die het verpesten voor de rest. Vaak (niet altijd, maar vaak) gebeurt het ook dat de recruiter belt met "ik werk in opdracht van [een groot bedrijf]" terwijl het de vacature van de website heeft geplukt en het bedrijf van niets weet, maar wel opzoek is.

  • TheNephilim
  • Registratie: september 2005
  • Laatst online: 20-09 12:25

TheNephilim

Wtfuzzle

Nog even inhakend op de git-discussie hier; ik krijg nu de vraag om even een schaduw toe te voegen achter een bepaald vlak op de website. Hoe doen jullie dat in git? :+

In een eigen branch, met als naam ticket/issue nummer oid? Of gewoon mee in de develop branch gezien het geen belangrijke/breaking wijziging is?

VILF Gaming


  • Alex)
  • Registratie: juni 2003
  • Laatst online: 00:15
Dat hangt af van je werkwijze.

Als het in één commit kan neem ik meestal niet de moeite om een branch te maken, daarin te wijzigen, en de branch weer terug te mergen... dat levert alleen maar zooi op in de reflog. Ga je een rebase doen, dan blijft er uiteindelijk maar één change over in de logs en dan had je het net zo goed meteen op develop kunnen doen.

We are shaping the future


  • Antrax
  • Registratie: april 2012
  • Laatst online: 20-09 15:36


:Y

Antrax wijzigde deze reactie 20-09-2017 11:02 (4%)

Nintendo FC: SW-6670-3316-6323


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

quote:
Hydra schreef op maandag 18 september 2017 @ 10:38:
[...]
Tja. Daar gaat het al fout. Testen moeten geautomatiseerd zijn en continue mee draaien in je build. Wij werken ook op feature branches (deze worden naar dev gemerged, dev wordt naar master gemerged voor releases) en daar draaien continue unit tests, integration tests en systeem tests tegenaan.
Maar dat is dus het klassieke kip-en-eiprobleem van legacy-codebases: er zijn geen tests dus formeel kun je niks aanpassen, en je kunt geen tests maken omdat de applicatie daar niet voor ontworpen is.

Je móet refactoren om te kunnen testen, maar je moet tests kunnen draaien om te waarborgen dat de huidige functionaliteit blijft werken, ook ná jouw wijzigingen.

Het lijkt me ontzettend fijn om bij een opdrachtgever terecht te komen waar testen goed is geregeld, maar ik kom de volgende zaken tegen:

• TDD: geprobeerd aan het begin, maar niet vol te houden, zeker op "greenfield" / "POC"-projecten waarbij het einddoel niet duidelijk is en de programmeerfase de ontwerpfase vervangt. Je kunt geen tests schrijven als het eindresultaat niet duidelijk is.
• Unit tests: er wordt uitgebreid getest of constructors en public methods de juiste exceptions throwen op null-arguments, maar de basale businesslogica wordt niet afgevangen. Ook complexere scenario's, met name complexe data-dependencies (user heeft een aantal stappen uitgevoerd, resulterend in een bepaalde dataset die bepaald gedrag tot gevolg moet hebben) worden niet getest omdat de setup van die data zo moeilijk is.
• BDD met Cucumber / SpecFlow / Selenium: er worden een paar scripts geschreven om te demoën hoe geweldig het wel niet is dat de manager ook tests kan schrijven door tekstjes te typen, een developer besteedt een paar dagen om de te testen elementen op te zoeken op naam, en het project wordt abandoned as-is omdat het efficiënter (in zowel tijd als geld) is om een tester door de UI te laten klikken.

Alles staat of valt met een Definition of Ready, het schrijven van acceptatiecriteria. Dat probeer ik altijd dus als eerste door te voeren als ik op een opdracht begint. Ik ga niet werken op basis van een ticket met enkel een titel. Ga eerst maar eens zitten nadenken wat het eindresultaat moet zijn.
quote:
Daar heb je software voor. Mensen zijn volledig ongeschikt als testers.
Wat een mooie Maarten van Rossem-uitspraak weer. :) Om iets te kunnen testen, moet je de input, acties en output omschrijven. Of je dit nu doet in een testplan voor een mens, of in een unit- of integratietest: als je een scenario niet omschrijft, dan wordt het niet getest. Zolang de testomschrijving goed is en de tester secuur werkt en alles afvinkt en/of noteert, doet handmatig testen niet onder voor een geautomatiseerde test.

Afgezien van de snelheid uiteraard.

Maar daar had ik het allemaal niet over. Ik vroeg hoe er moet worden omgegaan met gelijktijdig ontwikkelde features voor dezelfde release, die elkaar achteraf in de weg blijken zitten. Is dat een planningsprobleem?

As always, we are nailed to a cross of our own construction.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
quote:
CodeCaster schreef op woensdag 20 september 2017 @ 11:08:
Maar dat is dus het klassieke kip-en-eiprobleem van legacy-codebases: er zijn geen tests dus formeel kun je niks aanpassen, en je kunt geen tests maken omdat de applicatie daar niet voor ontworpen is.

Je móet refactoren om te kunnen testen, maar je moet tests kunnen draaien om te waarborgen dat de huidige functionaliteit blijft werken, ook ná jouw wijzigingen.
Dit snap ik niet. Je kunt gewoon beginnen?
quote:
Het lijkt me ontzettend fijn om bij een opdrachtgever terecht te komen waar testen goed is geregeld, maar ik kom de volgende zaken tegen:

• TDD: geprobeerd aan het begin, maar niet vol te houden, zeker op "greenfield" / "POC"-projecten waarbij het einddoel niet duidelijk is en de programmeerfase de ontwerpfase vervangt. Je kunt geen tests schrijven als het eindresultaat niet duidelijk is.
Ook compleet niet mee eens. Ik zit zelf op een greenfield project waar we gewoon een kneiterhoge coverage hebben. Waarom? Omdat we hier gewoon met goeie developers zitten die snappen dat een agile codebase betekent dat je veel tests hebt en juist niet weinig. Als je weinig tests hebt is de onzekerheid bij wijzigingen groter en gaat er meer mis.
quote:
• Unit tests: er wordt uitgebreid getest of constructors en public methods de juiste exceptions throwen op null-arguments, maar de basale businesslogica wordt niet afgevangen. Ook complexere scenario's, met name complexe data-dependencies (user heeft een aantal stappen uitgevoerd, resulterend in een bepaalde dataset die bepaald gedrag tot gevolg moet hebben) worden niet getest omdat de setup van die data zo moeilijk is.
Ook weer compleet uit de lucht gegrepen. Er is geen enkele reden dat je geen business logica kan testen in unit tests. Getters / setters testen is nutteloos, de input / output van functies is je doel.

"Het is moeilijk" is geen excuus; dan moet je het makkelijker maken. Als je geen DI gebruikt bijvoorbeeld maar je objectboom in je klasses opbouwt dan doe je het gewoon verkeerd. TDD zorgt juist voor testbare code omdat je meteen merkt of iets niet testbaar is.
quote:
• BDD met Cucumber / SpecFlow / Selenium: er worden een paar scripts geschreven om te demoën hoe geweldig het wel niet is dat de manager ook tests kan schrijven door tekstjes te typen, een developer besteedt een paar dagen om de te testen elementen op te zoeken op naam, en het project wordt abandoned as-is omdat het efficiënter (in zowel tijd als geld) is om een tester door de UI te laten klikken.
Komt weer neer op "het is te moeilijk". Als je TDD al te lastig vindt is BDD helemaal lastig ja, dat geloof ik best. Maar het komt allemaal op hetzelfde neer; je test gebruiken als design van je code. TDD is niet unit tests schrijven, dan doe je geen TDD. TDD, Test Driven Design, houdt in dat je tests gebruikt om je software te designen. Dat je dan meteen nuttige tests hebt is een handig bij-effect.

Ik snap overigens niet waarom je Selenium op een hoop gooit; dat heeft weer geen fluit met BDD te maken.
quote:
Wat een mooie Maarten van Rossem-uitspraak weer. :) Om iets te kunnen testen, moet je de input, acties en output omschrijven. Of je dit nu doet in een testplan voor een mens, of in een unit- of integratietest: als je een scenario niet omschrijft, dan wordt het niet getest. Zolang de testomschrijving goed is en de tester secuur werkt en alles afvinkt en/of noteert, doet handmatig testen niet onder voor een geautomatiseerde test.
Precies. En dat doen testers nooit. Ja; nooit. Ik ken geen enkele tester die puur als een machine elke keer hetzelfde script uitvoert; elke release. Dat waar we machines voor uitgevonden hebben omdat dat zo extreem saai en eentonig is dat alleen een machine het echt dag in dag uit kan doen. Dit kunnen mensen niet.
quote:
Maar daar had ik het allemaal niet over. Ik vroeg hoe er moet worden omgegaan met gelijktijdig ontwikkelde features voor dezelfde release, die elkaar achteraf in de weg blijken zitten. Is dat een planningsprobleem?
Nee, het is een test probleem. Wij hebben continue features die elkaar 'in de weg' zitten en dat levert hier ook geen problemen op. We hebben netjes onze CI/CD op orde en zien over het algemeen meteen als er iets stuk is. Enige punt wat daarin niet meedraait is de front-end en daar zie je dus dat handmatig testen gewoon weer tot problemen leidt.
quote:
.oisyn schreef op dinsdag 19 september 2017 @ 11:16:
Leiden 8)7. Waarom mailt ie mij in godsnaam.
Lead of architect in je functie titel? Da's waarom. Als ik op een project als "Software Architect" zit krijg ik die mailtjes regelmatig. Als ik ergens als "Software Engineer" zit niet :*)

Hydra wijzigde deze reactie 20-09-2017 11:25 (3%)


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

quote:
Nogmaals, ik heb het hier over de gemiddelde opdracht bij het gemiddelde softwarehuis of inhouse developmentteam. De gemiddelde developer is nu eenmaal gemiddeld, en zal code van gemiddelde kwaliteit opleveren en al blij zijn als het compileert.

Ik probeer dat niveau te ontstijgen, maar in je eentje krijg je, zelfs als externe die het allemaal beter zou moeten weten, maar lastig een team mee, zeker als het zwaard waarmee zij zwaaien "senioriteit door leeftijd of werkduur" is.
quote:
Dit snap ik niet. Je kunt gewoon beginnen?
Nee, dat kan niet. Ik heb het over een ontestbare codebase die alles inderdaad new()'t in de code zelf, in plaats van nette interfaces en IoC. Je hebt dus een ongetest, fragiel product dat eerst op de schop moet om het testbaar te krijgen, waarbij je mogelijk zaken breekt.
quote:
Ook compleet niet mee eens. Ik zit zelf op een greenfield project waar we gewoon een kneiterhoge coverage hebben. Waarom? Omdat we hier gewoon met goeie developers zitten die snappen dat een agile codebase betekent dat je veel tests hebt en juist niet weinig. Als je weinig tests hebt is de onzekerheid bij wijzigingen groter en gaat er meer mis.
Emphasis mine; zie eerste paragraaf.
quote:
Ook weer compleet uit de lucht gegrepen. Er is geen enkele reden dat je geen business logica kan testen in unit tests. Getters / setters testen is nutteloos, de input / output van functies is je doel.
Ik zeg niet dat het onmogelijk is. Het is juist het doel van unittests om business logica te testen. Ik zeg dat dat het gemiddelde scenario is dat ik tegenkom.
quote:
Komt weer neer op "het is te moeilijk". Als je TDD al te lastig vindt is BDD helemaal lastig ja, dat geloof ik best. Maar het komt allemaal op hetzelfde neer; je test gebruiken als design van je code. TDD is niet unit tests schrijven, dan doe je geen TDD. TDD, Test Driven Design, houdt in dat je tests gebruikt om je software te designen. Dat je dan meteen nuttige tests hebt is een handig bij-effect.
Dat snap ik; maar wederom, zie bovenstaande uitleg. Ik kan nog zoveel discussies voeren en presentaties geven; als "het werkt toch?" het criterium is, ga je de kwaliteit nooit verhogen.

Volgens mij vergeet jij in je reacties nog steeds dat jij degene bent die in een uitzonderingssituatie zit, bij je consultancybureau dat kwaliteit hoog in het vaandel heeft staan en met developers met passie voor het vak.

Dan kun je zeggen dat het voor mij weer eens tijd is voor een nieuwe opdracht, maar volgens mij is het overal, met een enkele uitzondering, hetzelfde liedje.

As always, we are nailed to a cross of our own construction.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
quote:
CodeCaster schreef op woensdag 20 september 2017 @ 11:30:
Nogmaals, ik heb het hier over de gemiddelde opdracht bij het gemiddelde softwarehuis of inhouse developmentteam. De gemiddelde developer is nu eenmaal gemiddeld, en zal code van gemiddelde kwaliteit opleveren en al blij zijn als het compileert.
Reden te meer je zooi goed te testen dan :)
quote:
Nee, dat kan niet. Ik heb het over een ontestbare codebase die alles inderdaad new()'t in de code zelf, in plaats van nette interfaces en IoC. Je hebt dus een ongetest, fragiel product dat eerst op de schop moet om het testbaar te krijgen, waarbij je mogelijk zaken breekt.
Ja dat bedoel ik dus; refactoren die hap. "Maar we krijgen geen tijd daarvoor". Tja. dan moet je je manager overtuigen dat je een hoop agility mist omdat je niet of nauwelijks tests hebt. Ik heb ook ervaring met dat soort codebases en daar zie je dat ze op een gegeven moment niks meer gedaan krijgen omdat elke change de hele boel doet instorten. Als je manager dan toch blijft vinden dat je moet door gaan met duct-tapen dan heb je een slechte manager en het leven is te kort om te werken voor slechte managers :)
quote:
Dat snap ik; maar wederom, zie bovenstaande uitleg. Ik kan nog zoveel discussies voeren en presentaties geven; als "het werkt toch?" het criterium is, ga je de kwaliteit nooit verhogen.
Ah okay, ik heb je dan verkeerd begrepen.
quote:
Dan kun je zeggen dat het voor mij weer eens tijd is voor een nieuwe opdracht, maar volgens mij is het overal, met een enkele uitzondering, hetzelfde liedje.
Wij hebben hier minder last van omdat we vaker zelf kunnen kiezen voor welke projecten we gaan. We worden ook bij projecten gehaald om dat soort dingen op te lossen. En als de bestaande devs niet willen dan gaan we weer weg. Als ze niks willen leren; prima :)

  • Soundless
  • Registratie: november 2008
  • Laatst online: 20-09 12:49
quote:
TDD: Test-Driven Development

Wij zijn zelf ook langzaam onze tests aan het automatiseren. En dan niet zo zeer unit-tests maar meer UI-tests.
Zelfs met de 2 tests die we nu non-stop hebben draaien, hebben we al een aantal dingne gevonden die we anders niet zo 1-2-3 hadden kunnen vinden.

In een perfecte wereld zouden we ook unit-tests voor alles hebben. Wie weet wordt dat een volgende stap die we gaan zetten.

Soundless wijzigde deze reactie 20-09-2017 11:45 (51%)


  • .oisyn
  • Registratie: september 2000
  • Laatst online: 02:40

.oisyn

Moderator DevschuurŽ

Demotivational Speaker

quote:
Hydra schreef op woensdag 20 september 2017 @ 11:20:
Lead of architect in je functie titel? Da's waarom. Als ik op een project als "Software Architect" zit krijg ik die mailtjes regelmatig. Als ik ergens als "Software Engineer" zit niet :*)
Ja, maar we zitten niet in regio Leiden ;)

If we can hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
quote:
Joh.
quote:
In een perfecte wereld zouden we ook unit-tests voor alles hebben. Wie weet wordt dat een volgende stap die we gaan zetten.
Da's geen "perfecte wereld". Bij software hoort tests. Zonder tests heb je halve software. Heck, geen software. Tijd geleden een 'pissige' blog post over geschreven ook.

  • Soundless
  • Registratie: november 2008
  • Laatst online: 20-09 12:49
quote:
Het ging mij er meer om dat je de term TDD een andere betekenis leek te geven.
quote:
Da's geen "perfecte wereld". Bij software hoort tests. Zonder tests heb je halve software. Heck, geen software. Tijd geleden een 'pissige' blog post over geschreven ook.
Tests ja. Niet perse unit-tests.

  • Devilly
  • Registratie: januari 2009
  • Laatst online: 20-09 17:47
quote:
Hydra schreef op woensdag 20 september 2017 @ 12:00:
Da's geen "perfecte wereld". Bij software hoort tests. Zonder tests heb je halve software. Heck, geen software. Tijd geleden een 'pissige' blog post over geschreven ook.
Dan zijn mijn hobbyprojecten geen software, maar toveren wel iets op het scherm. Het is magisch. :o

  • .oisyn
  • Registratie: september 2000
  • Laatst online: 02:40

.oisyn

Moderator DevschuurŽ

Demotivational Speaker

quote:
Hydra schreef op woensdag 20 september 2017 @ 12:00:
Tijd geleden een 'pissige' blog post over geschreven ook.
Goede blog, jammer van de schrijffouten. Je zou kunnen stellen dat je je blog niet... getest hebt? *badum tss* :+

If we can hit that bullseye, the rest of the dominoes will fall like a house of cards. Checkmate.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
quote:
Bike-shedding blijft een prachtige hobby.
quote:
.oisyn schreef op woensdag 20 september 2017 @ 12:42:
Goede blog, jammer van de schrijffouten. Je zou kunnen stellen dat je je blog niet... getest hebt? *badum tss* :+
Zeker getest en gepeer-reviewed. Maar dit waren helaas menselijke processen. Dus als je ff de schrijffouten laat weten (graag!) dan patch ik deze ff en zwengel ik de CI/CD pipeline aan ;)

Hydra wijzigde deze reactie 20-09-2017 12:44 (51%)


  • Soundless
  • Registratie: november 2008
  • Laatst online: 20-09 12:49
quote:
Hydra schreef op woensdag 20 september 2017 @ 12:42:
[...]
Bike-shedding blijft een prachtige hobby.
[...]
Het is een redelijk belangrijk detail. Ik ben het met je eens dat testen en ontwikkelen hand in hand gaan. Maar testen is wmb breder dan unit-tests. Zolang er een testprocedure is, vallen imo 'handmatige tests' ook in deze categorie.

  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
quote:
Soundless schreef op woensdag 20 september 2017 @ 12:48:
Het is een redelijk belangrijk detail. Ik ben het met je eens dat testen en ontwikkelen hand in hand gaan. Maar testen is wmb breder dan unit-tests.
Ik zeg toch nergens dat dat niet het geval is? :) Jij brengt zelf nota bene in dat in een perfecte wereld overal unit tests voor zijn. Dat zijn jouw woorden.

Hydra wijzigde deze reactie 20-09-2017 12:54 (14%)


  • EddoH
  • Registratie: maart 2009
  • Niet online

EddoH

Backpfeifengesicht

:O

Think before you die


  • dev10
  • Registratie: april 2005
  • Laatst online: 20-09 16:47
quote:
TheNephilim schreef op woensdag 20 september 2017 @ 10:35:
Nog even inhakend op de git-discussie hier; ik krijg nu de vraag om even een schaduw toe te voegen achter een bepaald vlak op de website. Hoe doen jullie dat in git? :+

In een eigen branch, met als naam ticket/issue nummer oid? Of gewoon mee in de develop branch gezien het geen belangrijke/breaking wijziging is?
Wij hanteren het volgende systeem:

- Master is altijd deployable. Hierin worden alleen de sprint branches en eventuele hotfixes gemerged.
- Iedere sprint een nieuwe branch met als naam sprint-{nummer} vanaf de master
- De epics hebben een eigen branch vanaf master met naam epic-{ticketnummer}
- Iedere user story wordt gemaakt vanaf of de sprint branch, of de epic branch.

Voordat er een pull-request aangemaakt wordt, wordt er eerst een rebase gedaan met de target branch. Dit doen we ook voordat de sprint branch gemerged wordt naar master. Voor ons heeft dit als voordeel dat eventuele mergeconflicten worden opgelost door degene die met het ticket bezig is geweest.

De reden waarom we voor dit model hebben gekozen, is dat je een hele cleane historie krijgt waarbij je precies kunt zien wat er per sprint gedaan is. Voordat ik hier kwam werken, werden alle tickets die gereleased werden in een keer gemergedt, waardoor je onwijs veel merge-conflicten kreeg en de historie er eigenlijk uit ging zien als Guitar Hero. Nu ziet onze historie er zo uit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
*       <-- De meest linkse lijn is de master branch
|\
| *     <-- Deze lijn is de sprint branch
| |\
| | *   <-- Dit is een commit van een ticket die naar de sprint branch gaat
| |/
| *
| |\
| | *   <-- Dit is een epic branch die weer losse tickets heeft
| | |\
| | | *
| | |/
| | *
| | |\
| | | *
| | |/
| | *
| |/
| *
|/
*

Op zoek naar een nieuwe baan als PHP ontwikkelaar? Stuur me een DM.


  • EddoH
  • Registratie: maart 2009
  • Niet online

EddoH

Backpfeifengesicht

Voor als je er zeker van wilt zijn dat je mail opvalt:



De invalid signature melding is overigens ook grappig gezien de inhoud van het bericht :+

Think before you die


  • Tarkin
  • Registratie: juni 2006
  • Laatst online: 20-09 15:53

Tarkin

Fe Fan

Afgezien van je stijl moet ik je deze keer helemaal gelijk geven Hydra.

Met de stelling komen dat je in een greenfield project niet kan testen. Wanneer kan je dan wel in godsnaam testen?

En testen moeten niet geschreven worden als de code al bestaat, dan ben je nl legacy shit aan het testen en daar klaag je ook over :) Testen moeten vooraf geschreven worden. TDD first!

  • Styxxy
  • Registratie: augustus 2009
  • Laatst online: 02:33
quote:
Tarkin schreef op woensdag 20 september 2017 @ 15:08:
Afgezien van je stijl moet ik je deze keer helemaal gelijk geven Hydra.

Met de stelling komen dat je in een greenfield project niet kan testen. Wanneer kan je dan wel in godsnaam testen?

En testen moeten niet geschreven worden als de code al bestaat, dan ben je nl legacy shit aan het testen en daar klaag je ook over :) Testen moeten vooraf geschreven worden. TDD first!
Ik moet CodeCaster toch eerder gelijk geven, ik zit in een gelijkaardige situatie als hem.
Success met legacy omgevingen...

En management overtuigen; tja, die zien enkel maar kosten.

  • Tarkin
  • Registratie: juni 2006
  • Laatst online: 20-09 15:53

Tarkin

Fe Fan

quote:
Styxxy schreef op woensdag 20 september 2017 @ 15:27:
[...]

Ik moet CodeCaster toch eerder gelijk geven, ik zit in een gelijkaardige situatie als hem.
Success met legacy omgevingen...

En management overtuigen; tja, die zien enkel maar kosten.
Momenteel bezig in zo'n legacy omgeving. Core product is nergens getest. Alles wat wij er bij aanbouwen is weldegelijk deftig getest en daar zijn we dan ook zeker van het gedrag.

Ondertussen ook al geleerd om de juiste vragen op een sollicitatie te stellen. Meer als een gesprek vriendelijk beëindigd toen ze vertelden dat ze TDD en Agile eerder als een leidraad zagen dan als een must (lees, we schrijven een testje als we echt niet anders kunnen en we doen toch elke dag een status meeting, dat is toch agile?) => naar zo'n omgeving ga ik zeker niet meer terug

Voting with your feet is soms de enige manier.

  • Styxxy
  • Registratie: augustus 2009
  • Laatst online: 02:33
quote:
Tarkin schreef op woensdag 20 september 2017 @ 15:35:
[...]
Momenteel bezig in zo'n legacy omgeving. Core product is nergens getest. Alles wat wij er bij aanbouwen is weldegelijk deftig getest en daar zijn we dan ook zeker van het gedrag.
Inderdaad, volledig "losse" ontwikkeling doen we ook met unit testen (maar geen TDD).
Unit testen moet je ook als hulpmiddel zien om kwaliteit en zekerheid te introduceren; het moet geen doel op zich zijn.

Wij testen vaak ook niet individuele methods, maar zullen eerder een "systeemtest" maken als unit test (met externe componenten zoals database etc gemockt). Het zijn eerder unit tests dat een kruising van unit tests en integratietesten maken.

Styxxy wijzigde deze reactie 20-09-2017 15:52 (19%)


  • Tarkin
  • Registratie: juni 2006
  • Laatst online: 20-09 15:53

Tarkin

Fe Fan

Dus je gaat eerst je implementatie schrijven, dat manueel testen en als dat allemaal goed werkt ga je testen schrijven?

Is het dan niet veel simpeler om eerst je test te schrijven, dan je implementatie (en zorgen dat je test groen is) en indien die weerkerende cycle volledig is, éénmalig manueel testen? Veel sneller volgens mij. en ook veel robuuster. door test first te werken zorg je er ook voor dat je nadenkt over je implementatie. iets wat niet gebeurt als je achteraf testen schrijft, dan test je gewoon af wat je al geschreven hebt.

  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

quote:
Tarkin schreef op woensdag 20 september 2017 @ 15:08:
Afgezien van je stijl moet ik je deze keer helemaal gelijk geven Hydra.

Met de stelling komen dat je in een greenfield project niet kan testen. Wanneer kan je dan wel in godsnaam testen?

En testen moeten niet geschreven worden als de code al bestaat, dan ben je nl legacy shit aan het testen en daar klaag je ook over :) Testen moeten vooraf geschreven worden. TDD first!
Wat ik bedoel is dat er een aanvraag komt ŕ la "Bouw maar een API die dit-en-dat object exposed aan andere teams, met ongeveer deze operaties". Dan kun je fijn TDD, BDD, whatever gaan werken, maar de eerste de beste versie die je laat zien aan het implementerende team wordt afgeschoten omdat zij op basis van het gebruiken ervan pas kunnen bedenken hoe ze het precies willen gaan gebruiken.

Daar zit je dan met je tests die je software perfect afdekken, maar met je software die niet voldoet aan de vraag van de consumers.

En ja, dat is een plannings- en specificatieprobleem, absoluut.

As always, we are nailed to a cross of our own construction.


  • Styxxy
  • Registratie: augustus 2009
  • Laatst online: 02:33
quote:
Tarkin schreef op woensdag 20 september 2017 @ 15:52:
Dus je gaat eerst je implementatie schrijven, dat manueel testen en als dat allemaal goed werkt ga je testen schrijven?

Is het dan niet veel simpeler om eerst je test te schrijven, dan je implementatie (en zorgen dat je test groen is) en indien die weerkerende cycle volledig is, éénmalig manueel testen? Veel sneller volgens mij. en ook veel robuuster. door test first te werken zorg je er ook voor dat je nadenkt over je implementatie. iets wat niet gebeurt als je achteraf testen schrijft, dan test je gewoon af wat je al geschreven hebt.
Neen. Schrijven code en unit tests samen. De ene schrijft eerst zijn unit test en dan code, de andere omgekeerd (waarbij zo goed als iedereen eerder eerst code maakt en dan unit tests). Het pure TDD idiom doe ik niet; maar ik ontwikkel wel samen met unit tests.

Vaak teken ik eerst het systeem uit, dan schrijf ik code en als ik tevreden ben van mijn code maak ik daar tests op. Je moet niet op voorhand unit tests schrijven hoor...

  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
quote:
CodeCaster schreef op woensdag 20 september 2017 @ 15:54:
Wat ik bedoel is dat er een aanvraag komt ŕ la "Bouw maar een API die dit-en-dat object exposed aan andere teams, met ongeveer deze operaties". Dan kun je fijn TDD, BDD, whatever gaan werken, maar de eerste de beste versie die je laat zien aan het implementerende team wordt afgeschoten omdat zij op basis van het gebruiken ervan pas kunnen bedenken hoe ze het precies willen gaan gebruiken.
Ik maak altijd eerst een service die canned responses teruggeeft voordat ik ga implementeren. Die kunnen ze reviewen en ondertussen bouw ik de tussenliggende lagen. Dat valt prima te combineren. Daarbij; je bepaalt toch samen hoe zo'n API eruit moet zien? Klinkt een beetje als een gevalletje over de muur smijten van requirements en dan achteraf klagen als het niet werkt.

Als je dan naderhand iets over 't hoofd gezien hebt; prima. Maar het grootste deel van wat het moet doen hebben we afgetimmerd. En als Pietje later bedenkt dat 'ie in plaats van een naam aparte voornaam / achternaam velden wil; prima. Dat reworken we dan wel.

En ja, het is gewoon een specificatieprobleem. Ik bespeur aan zowel jouw kant als (vooral) aan de kant van de anderen een soort "ik weet het ook niet meer" gemixt met een gezonde dosis "fuck it". Te veel mensen die te lang op dezelfde plek zitten. Het is ook lastig om je druk te maken over kwaliteit als je de enige bent in een organisatie.

  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:10
quote:
Styxxy schreef op woensdag 20 september 2017 @ 15:55:
[...]

Neen. Schrijven code en unit tests samen. De ene schrijft eerst zijn unit test en dan code, de andere omgekeerd (waarbij zo goed als iedereen eerder eerst code maakt en dan unit tests). Het pure TDD idiom doe ik niet; maar ik ontwikkel wel samen met unit tests.

Vaak teken ik eerst het systeem uit, dan schrijf ik code en als ik tevreden ben van mijn code maak ik daar tests op. Je moet niet op voorhand unit tests schrijven hoor...
Maar dat is handig. Stel je maakt een Comparator, dan kun je die al testen voordat je hem daadwerkelijk implementeert. In principe is van alles bekend wat het moet doen, en juist niet. Ik kom er bij mijn unit tests vaak achter dat ik niet helemaal tevreden ben, of een ontwerpfout aan het maken ben. En dan is het dus prettig als ik daar vroeg achter kom.

  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

quote:
ThomasG schreef op woensdag 20 september 2017 @ 16:06:
[...]
Maar dat is handig. Stel je maakt een Comparator, dan kun je die al testen voordat je hem daadwerkelijk implementeert. In principe is van alles bekend wat het moet doen, en juist niet. Ik kom er bij mijn unit tests vaak achter dat ik niet helemaal tevreden ben, of een ontwerpfout aan het maken ben. En dan is het dus prettig als ik daar vroeg achter kom.
En we hebben het hier over een niveau of tig hoger.

Natuurlijk kun je een string splitter, een regex of een comparator die wat properties van een object vergelijkt prima unittesten. Je kunt de positieve en negatieve inputs op een bierviltje kwijt en voilá, je testcases.

Het probleem waar het hier om gaat is slecht omschreven business requirements. Volledige applicaties die worden gebouwd op basis van een omschrijving van één regel, in een mailtje, of zo je wil, een bierviltje.

In plaats van dat men gaat steigeren en zegt "Ik programmeer geen letter voordat jij opschrijft wat je wil", en ze daarbij desnoods ook begeleidend, gaat men bouwen en ontwerpen tegelijk, aanpassingen makend terwijl er nog gecompileerd wordt. En dát is niet te testen, mondt uit in ontestbare spaghetticode en zorgt voor overspannen ontwikkelaars en een team dat te bang is om wijzigingen uit te voeren omdat men met een fucking fragiel product zit.

Elke. Keer. Weer.
quote:
Hydra schreef op woensdag 20 september 2017 @ 16:01:
[...]
Te veel mensen die te lang op dezelfde plek zitten. Het is ook lastig om je druk te maken over kwaliteit als je de enige bent in een organisatie.
:Y

CodeCaster wijzigde deze reactie 20-09-2017 16:17 (19%)

As always, we are nailed to a cross of our own construction.


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:10
quote:
CodeCaster schreef op woensdag 20 september 2017 @ 16:11:
[...]

En we hebben het hier over een niveau of tig hoger.

Natuurlijk kun je een string splitter, een regex of een comparator die wat properties van een object vergelijkt prima unittesten. Je kunt de positieve en negatieve inputs op een bierviltje kwijt en voilá, je testcases.

Het probleem waar het hier om gaat is slecht omschreven requirements. In plaats van dat men gaat steigeren en zegt "Ik programmeer geen letter voordat jij opschrijft wat je wil", gaat men bouwen en ontwerpen tegelijk, aanpassingen makend terwijl er nog gecompileerd wordt. En dát is niet te testen, mondt uit in ontestbare spaghetticode en zorgt voor overspannen ontwikkelaars en een team dat te bang is om wijzigingen uit te voeren omdat men met een fucking fragiel product zit.

Elke. Keer. Weer.
Maar dat is een probleem dat weinig met testen te maken heeft. Er wordt dan gewoon niet (goed) nagedacht over wat er nu eigenlijk gemaakt moet worden. Dat is ook meteen de reden waarom veel (software) projecten veel te duur uitvallen, en de klant niet tevreden is. Het consult en ontwerp, voorzover dat er was, is dan gewoon niet goed gegaan. Wij hebben een project van voor mijn tijd, dat ook zo ontstaan is. En daar hebben we nu nog steeds problemen mee, omdat het niet kan wat het eigenlijk moet doen (doordat er toen gewoon niet is nagedacht).

  • Styxxy
  • Registratie: augustus 2009
  • Laatst online: 02:33
quote:
Hydra schreef op woensdag 20 september 2017 @ 16:01:
[...]
Te veel mensen die te lang op dezelfde plek zitten. Het is ook lastig om je druk te maken over kwaliteit als je de enige bent in een organisatie.
:Y

Met dan de dooddoener : zo doen we het al 15 jaar en nog "nooit" problemen mee gehad.

  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

quote:
Styxxy schreef op woensdag 20 september 2017 @ 16:23:
[...]

:Y

Met dan de dooddoener : zo doen we het al 15 jaar en nog "nooit" problemen mee gehad.
Het is toch ook geen probleem dat elke release drie dagen kost, inclusief overwerk ("maar pizza's!"), onnodige stress, databaserestores midden in de nacht en een overbelaste helpdesk voor de week na de uitrol?
quote:
ThomasG schreef op woensdag 20 september 2017 @ 16:17:
[...]
Maar dat is een probleem dat weinig met testen te maken heeft. Er wordt dan gewoon niet (goed) nagedacht over wat er nu eigenlijk gemaakt moet worden. Dat is ook meteen de reden waarom veel (software) projecten veel te duur uitvallen, en de klant niet tevreden is. Het consult en ontwerp, voorzover dat er was, is dan gewoon niet goed gegaan. Wij hebben een project van voor mijn tijd, dat ook zo ontstaan is. En daar hebben we nu nog steeds problemen mee, omdat het niet kan wat het eigenlijk moet doen (doordat er toen gewoon niet is nagedacht).
Dat is dus een beetje het punt. Als er geen specs zijn, is er niks te testen. En als het ontestbaar is én er zijn geen specs, zit je in een spagaat: waar moet je beginnen?

CodeCaster wijzigde deze reactie 20-09-2017 16:33 (49%)

As always, we are nailed to a cross of our own construction.


  • ThomasG
  • Registratie: juni 2006
  • Laatst online: 23:10
quote:
CodeCaster schreef op woensdag 20 september 2017 @ 16:30:
[...]

Het is toch ook geen probleem dat elke release drie dagen kost, inclusief overwerk ("maar pizza's!"), onnodige stress, databaserestores midden in de nacht en een overbelaste helpdesk voor de week na de uitrol?
Dat is gewoon onderdeel van de functieomschrijving :+

  • kenneth
  • Registratie: september 2001
  • Niet online

kenneth

achter de duinen

Best leuk, dat Advent of Code (Ik weet, laat :+). Oplossingen waar je met brute-forcen er net wel mee wegkomt maar vervolgens met een kleine verandering in het tweede deel wordt gedwongen na te denken en (shudder) nieuwe dingen te leren. Nu een oplossing verbeterd van 14'20 naar 39ms :o

Over de helft, hierna Project Euler maar eens bekijken.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


  • Hydra
  • Registratie: september 2000
  • Laatst online: 20:26
Zeker een aanrader. Als vastgeroeste Java dev wordt je aardig gedwongen je informatica skills een beetje van stal te halen.
quote:
CodeCaster schreef op woensdag 20 september 2017 @ 16:30:
Het is toch ook geen probleem dat elke release drie dagen kost, inclusief overwerk ("maar pizza's!"), onnodige stress, databaserestores midden in de nacht en een overbelaste helpdesk voor de week na de uitrol?
Ik wil best een keer indien nodig m'n handen uit de mouwen steken. Maar als ik suggesties geef om een release te verbeteren en deze worden dan in de wind geslagen moet je niet later bij mij aankomen om over te gaan werken. Ik heb je tig tijd geleden uitgelegd wat er mis is en hoe we dat kunnen oplossen. Dat jouw app niet live gaat morgen maar over een week is dan echt enorm niet mijn probleem.

Ik doe die shit niet meer. Als het ze niet bevalt gaan ze maar op zoek naar een andere Java dev met 15 jaar ervaring. Gek genoeg doen ze dat dan ook weer niet.
quote:
Dat is dus een beetje het punt. Als er geen specs zijn, is er niks te testen.
Als er geen specs zijn, is er niks te bouwen.

Hydra wijzigde deze reactie 20-09-2017 17:44 (84%)


  • gekkie
  • Registratie: april 2000
  • Laatst online: 22:45
quote:
Hydra schreef op woensdag 20 september 2017 @ 17:42:
Als er geen specs zijn, is er niks te bouwen.
Tsja dan krijg je het probleem nog dat je specs hebt en Specs.

Moet je weer de specs te specificeren :+

gekkie wijzigde deze reactie 20-09-2017 18:26 (9%)


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

quote:
Hydra schreef op woensdag 20 september 2017 @ 17:42:
[...]


Als er geen specs zijn, is er niks te bouwen.
Geloofden maar meer mensen dat. :) Ik heb de afgelopen jaren honderdduizenden regels code geschreven zien worden op basis van globaal mondeling overleg, zonder in te gaan op details. Of sprint plannings van een paar uur, waarbij het besprokene niet wordt vastgelegd, en men dus maar afgaat op het geheugen van de deelnemers.

Als dat gebeurt, spec ik zelf retroactief in m'n tickets. Ben je het niet eens met de opgeleverde functionaliteit? Had je zelf het ticket moeten aanvullen, en niet een ticket met enkel een titel, of erger (!), een gecopy-pasted mailtje in de body in de sprint moeten slepen.

CodeCaster wijzigde deze reactie 20-09-2017 19:42 (7%)

As always, we are nailed to a cross of our own construction.


  • Brakkie41
  • Registratie: november 2010
  • Nu online

Brakkie41

Turning coffee into software!

quote:
CodeCaster schreef op woensdag 20 september 2017 @ 19:42:
[...]

Geloofden maar meer mensen dat. :) Ik heb de afgelopen jaren honderdduizenden regels code geschreven zien worden op basis van globaal mondeling overleg, zonder in te gaan op details. Of sprint plannings van een paar uur, waarbij het besprokene niet wordt vastgelegd, en men dus maar afgaat op het geheugen van de deelnemers.

Als dat gebeurt, spec ik zelf retroactief in m'n tickets. Ben je het niet eens met de opgeleverde functionaliteit? Had je zelf het ticket moeten aanvullen, en niet een ticket met enkel een titel, of erger (!), een gecopy-pasted mailtje in de body in de sprint moeten slepen.
Lever je dan zelf "half-bakken" functionaliteit af onder het mom van "had je maar betere specs moeten aanleveren" of ga je terug naar de Product Manager/opdrachtgever om meer/betere specs aan te leveren?

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”


  • CodeCaster
  • Registratie: juni 2003
  • Niet online

CodeCaster

👌👀 good shit ✔💯

quote:
Brakkie41 schreef op woensdag 20 september 2017 @ 21:31:
[...]


Lever je dan zelf "half-bakken" functionaliteit af onder het mom van "had je maar betere specs moeten aanleveren" of ga je terug naar de Product Manager/opdrachtgever om meer/betere specs aan te leveren?
Dat is natuurlijk niet zo zwart-wit te zeggen. Het hangt ook erg van het soort bedrijf en hun werkwijze af.

Doorgaans ben ik echt de beroerdste niet om hiaten in de specs te bespreken waar ik achter kom tijdens het implementeren, maar als het aan mij ligt, ga ik met de product owner of projectmanager zitten om te bespreken wat ze nou precies willen, daarna maak ik het ticket af qua tekst, en overleg dan met een collega over de implementatie alvorens ook maar te beginnen.

Maar soms zijn het echt gevallen waarvan je achteraf hoort van zaken die je alleen met bijzonder inhoudelijke kennis had kunnen voorspellen, en waar je in de implementatie dus geen rekening mee had kunnen houden - let wel, als externe. Dan geef ik dus ook gewoon aan dat ze zulke gevallen érgens moeten omschrijven.

Als het "common knowledge" had moeten zijn voor dat vakgebied, maak dan een Wiki aan of zo.

As always, we are nailed to a cross of our own construction.


  • Brakkie41
  • Registratie: november 2010
  • Nu online

Brakkie41

Turning coffee into software!

quote:
CodeCaster schreef op woensdag 20 september 2017 @ 21:39:
[...]

Dat is natuurlijk niet zo zwart-wit te zeggen. Het hangt ook erg van het soort bedrijf en hun werkwijze af.

Doorgaans ben ik echt de beroerdste niet om hiaten in de specs te bespreken waar ik achter kom tijdens het implementeren, maar als het aan mij ligt, ga ik met de product owner of projectmanager zitten om te bespreken wat ze nou precies willen, daarna maak ik het ticket af qua tekst, en overleg dan met een collega over de implementatie alvorens ook maar te beginnen.

Maar soms zijn het echt gevallen waarvan je achteraf van gevallen hoort die je alleen met bijzonder inhoudelijke kennis had kunnen voorspellen, en waar je in de implementatie dus geen rekening mee had kunnen houden - let wel, als externe. Dan geef ik dus ook gewoon aan dat ze zulke gevallen érgens moeten omschrijven.

Als het "common knowledge" had moeten zijn voor dat vakgebied, maak dan een Wiki aan of zo.
Duidelijk en helemaal mee eens :) T.a.v het overleggen, pairen jullie niet met je collega's bij bepaalde implementaties dan? Hier geld overigens grotendeels hetzelfde principe. Als je als PM of PMO niet de juiste specificaties levert, kunnen wij niet aan de slag. Of we doen een deel waarvan we zeker weten dat dat wel vaststaaten de rest wordt geblokt :)

Wij pairen/mobben met name bij complexe implementaties en implementaties waar veel beslissen genomen moeten worden t.a.v. de architectuur. Business, zegt "wij willen A". Het is aan ons hoe wij A willen bereiken. Met name dan is pairen/mobben een goede tool om gezamenlijk tot een oplossing te komen en geen gezeur achteraf te krijgen dat bepaalde team members het niet eens zijn met de implementatie. Simpelweg, 2 man hebben eraan gewerkt en tenzij je met hele sterke argumenten komt, wij zijn na meerdere iteraties bij deze (beste) oplossing gekomen :)

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”

Pagina: 1 ... 51 52 53 Laatste


Apple iPhone X Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*