:strip_exif()/u/33451/kirk_bones.gif?f=community)
Glass Eye Photography | Zelfbouw wireless fightstick | Mijn puzzel site
/u/89193/crop5913059561374.png?f=community)
Ok dan ben ik weer eens te kort door de bocht. Mijn referentiekader: wij zitten met 4-en aan 4 geschakelde bureaus. Geen officieel onderscheid in senioriteit behalve dat 1 min of meer 'junior' is
Hoeder van het Noord-Meierijse dialect
/u/518735/crop590c368ed64a4_cropped.png?f=community)
:strip_icc():strip_exif()/u/383603/Untitled.jpg?f=community)
Bij kan niemand direct pushen naar master. Ons model is PR naar "integration", zodra tests en build passen wordt er door Jenkins gemerged naar "stable". Elke dag om 17 uur wordt er een tag aangemaakt door Jenkins op de laatste merge van Stable en wordt uitgebreide performance tests en een hot code upgrade uitgevoerd op een replica van productie. Als alles happy is, wordt de dag erna, stable als ff merge naar master geschopt.
Devs hebben enkel rechten op integration branch. Al het andere is Jenkins de enige die merge rechten heeft
Aantal devs op dit project is 45 devs op 1 repo plus een stuk of 30 submodules (waar ieder team zijn eigen merge proces beheert)
Always looking for developers wanting to work with Erlang.
:strip_icc():strip_exif()/u/37911/zlao.jpg?f=community)
Mijn op Ollanders gerichte framework heet dan ook Strontium.IO .. met als adagium .. Poep In is Poep Uit(overigens is geen Poep in ook Poep uit, maar dat is een implementatie detail).
/u/454206/crop562d2ccb2479a.png?f=community)
Mijn productie omgeving in containers stoppen. Ik denk dat ik hier het hele weekend mee bezig ben. Had ik mij maar beter voorbereid 
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
:strip_icc():strip_exif()/u/137799/pp.jpg?f=community)
/u/189240/av70.png?f=community)
Wij zitten op SVN en zooooo jammer dat TeamCity voor dat VCS geen first-class branching ondersteuning is 
Ik zou bijna willen kijken of ik een soort gesynchroniseerde git repo speciaal voor TeamCity opzetten, behalve dat TeamCity ook moet kunnen taggen en we het revisienummer ook opnemen in de software.
Ik zou bijna willen kijken of ik een soort gesynchroniseerde git repo speciaal voor TeamCity opzetten, behalve dat TeamCity ook moet kunnen taggen en we het revisienummer ook opnemen in de software.
[ Voor 48% gewijzigd door Sebazzz op 16-09-2017 12:21 ]
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
/u/86654/crop68d4ff30987a8.png?f=community)
Ik maak nu een paar jaar op diverse werkplekken gebruik van Git met Git Flow. Ik blijf, ook met die flow, integratie lastig vinden.
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.
Features worden op hun eigen branch gereviewd en getest. Wiens verantwoordelijkheid is het om beide issues na het mergen nogmaals te testen?
Maar wellicht z'n eigen topic waard. Al heb ik nu ook een déjà-vu, want volgens mij heb ik dit wel eens eerder gepost.
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.
Features worden op hun eigen branch gereviewd en getest. Wiens verantwoordelijkheid is het om beide issues na het mergen nogmaals te testen?
Maar wellicht z'n eigen topic waard. Al heb ik nu ook een déjà-vu, want volgens mij heb ik dit wel eens eerder gepost.
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
:strip_exif()/u/80759/monstermania_small.gif?f=community)
Bugs door merges kunnen altijd optreden denk ik.:
Ik maak nu een paar jaar op diverse werkplekken gebruik van Git met Git Flow. Ik blijf, ook met die flow, integratie lastig vinden.
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.
Features worden op hun eigen branch gereviewd en getest. Wiens verantwoordelijkheid is het om beide issues na het mergen nogmaals te testen?
Maar wellicht z'n eigen topic waard. Al heb ik nu ook een déjà-vu, want volgens mij heb ik dit wel eens eerder gepost.
Wat helpt is dat de CI/CD omgeving zo is ingericht dat je binnen zeer korte tijd een nieuwe build naar productie kunt uitrollen. Het project waar ik momenteel werkzaam ben heeft dit bijzonder netjes ingericht, waardoor ieder applicatie/service de gehele deployment straat binnen 30 minuten kan doorlopen.
Wellicht dat er omgevingen zijn waar dit sneller kan, maar ik vind 30 minuten (sommige services zelfs binnen 18 minuten als de bugs eenvoudig zijn te fixen en de services klein/eenvoudig) al behoorlijk snel!
Battle.net - Jandev#2601 / XBOX: VriesDeJ
/u/81985/crop566b00b43645a.png?f=community)
Dat is juist wat ik bedoelde
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
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?:
[...]
Dat is juist wat ik bedoelde
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!
(Toegegeven, het heeft me bijna me vriendin gekost maar dat is goed gekomen uiteindelijk )
Always looking for developers wanting to work with Erlang.
:strip_icc():strip_exif()/u/6143/rincewind.jpg?f=community)
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:
[...]
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?
[ Voor 4% gewijzigd door Woy op 18-09-2017 09:31 ]
“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.”
:strip_icc():strip_exif()/u/73625/Tetris_failure_ava_forum.jpg?f=community)
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
/u/155568/usericon.png?f=community)
Als ik dit zo lees heb ik vrij weinig gedaan, terwijl ik net een jaartje ouder ben dan jij:
Zelf 28 jaar, universiteit met rechtsachtergrond en enorm hard gewerkt, de afgelopen 4 jaar om mezelf om te scholen tot Software Developer
Hard work, pays off!
. Vast een gebrek aan richting/visie oid. gezien jouw heldere doelstelling.
/u/12668/hydra.png?f=community)
Nog plannen je in de 21e eeuw te begeven?
Ik snap echt niet dat mensen heden ten dage nog met die meuk werken.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.
Daar heb je software voor. Mensen zijn volledig ongeschikt als testers.
https://niels.nu
Technisch gezien dateert SVN uit de 21ste eeuw:
[...]
Nog plannen je in de 21e eeuw te begeven?
https://fgheysels.github.io/
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:
Technisch gezien dateert SVN uit de 21ste eeuw
Sinds prutsers e-mail validatie regexes van internet plukken.
Hint: e-mail kun je niet valideren met regexes.
[ Voor 3% gewijzigd door Hydra op 18-09-2017 11:12 ]
https://niels.nu
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.”
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:
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
https://niels.nu
Ik verschiet er altijd van dat dit geen standaard manier van werken is.:
... 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
RTFM!
Wat is er mis met SVN dan? Het werkt. It ain't broken.:
[...]
Nog plannen je in de 21e eeuw te begeven?
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.
[Te koop: 3D printers] [Website] Agile tools: [Return: retrospectives] [Pokertime: planning poker]
:strip_icc():strip_exif()/u/12461/crop65b195553d948.jpg?f=community)
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 
al zou dat voor louter de code wel een nuttige feature zijn.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Kan ik 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?:
[...]
Heel goed, voor jullie. Maar dat gegeven alleen maakt SVN niet per definitie waardeloos
:strip_icc():strip_exif()/u/87691/avatar_alex.jpg?f=community){kind=avatar}
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
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.
[ Voor 26% gewijzigd door .oisyn op 18-09-2017 14:28 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_icc():strip_exif()/u/284419/Mexican%2520Wolf%2520Klein.jpg?f=community)
Gebruiken jullie TFS? Kan ooit een screenshot van jouw werkomgeving herinneren waarin ik volgens mij VS zag.:
[...]
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
[...]
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.
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
:strip_exif()/u/627282/charmander-kerst.gif?f=community)
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 
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.
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! - What type of bees are scary? BoooOOOOOooobeees! - Cactusliefhebster
:strip_icc():strip_exif()/u/36003/crop584e9e5c223bd.jpeg?f=community)
Update voor VS2017. Ok, updaten maar!
Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.
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:
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
***members only***
/u/313216/crop679f937b7f4c1_cropped.png?f=community)
Mijn eerste pull request op GitHub (Microsoft Docs) is geaccepteerd 
.
Ervoor steeds passieve gebruiker van github geweest.
.Ervoor steeds passieve gebruiker van github geweest
.
[ Voor 12% gewijzigd door Styxxy op 18-09-2017 19:35 ]
:strip_exif()/u/199617/chidori.gif?f=community)
Dat is volgens mij altijd al zo geweest:
Update voor VS2017. Ok, updaten maar!
[...]
edit: in VS2017 althans
[ Voor 5% gewijzigd door Neko Koneko op 19-09-2017 07:54 ]
End-users are clingy complaining dipshits who will never ever be grateful for any concession you make. The moment you shut out their shrill, tremulous voices, the happier you will be for it.
Congrats! Keep it up! Altijd fijn om je naam in commit logs te hebben staan bij Ooen Source projecten:
Mijn eerste pull request op GitHub (Microsoft Docs) is geaccepteerd
Ervoor steeds passieve gebruiker van github geweest
Afgelopen weekend heeft één persoon een branch gemerged gericht op de migratie richting Erlang OTP 20. Top
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
[ Voor 27% gewijzigd door Swedish Clown op 19-09-2017 08:29 ]
Always looking for developers wanting to work with Erlang.
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.
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.
End-users are clingy complaining dipshits who will never ever be grateful for any concession you make. The moment you shut out their shrill, tremulous voices, the happier you will be for it.
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.)
Ik snap er nog niet veel van
.(Ik ben gewend om met TFS (VC) te werken.)
[ Voor 8% gewijzigd door Styxxy op 19-09-2017 09:24 ]
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.:
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.
[ Voor 4% gewijzigd door ThomasG op 19-09-2017 09:30 ]
:strip_icc():strip_exif()/u/50076/dosto_60.jpg?f=community)
:
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.
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
.Gertjan.: Ik ben een zelfstandige alcoholist, dus ik bepaal zelf wel wanneer ik aan het bier ga!
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.:
[...]
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
|>
:strip_exif()/u/261638/Happy2.gif?f=community)
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.:
[...]
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
[...]
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.
[ Voor 6% gewijzigd door TJHeuvel op 19-09-2017 11:02 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Ja. En dan heb je nog eens 1,3TB nodig voor de intermediate data om de content te bouwen.
Recruiters
[q]Naast ervaring met Data en programmeren in C++, heeft hij ook ervaring met:
.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. Waarom mailt ie mij in godsnaam.
Recruiters
[q]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
.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
. Waarom mailt ie mij in godsnaam.
[ Voor 84% gewijzigd door .oisyn op 19-09-2017 11:59 ]
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
/u/224026/crop5a1c1a6fcf1b1.png?f=community)
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.
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.
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
.
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
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.
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
.
Tjolk is lekker. overal en altijd.
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 ?:
Wat is iTunes toch een rukprogramma.
Achja als er nog eens iemand komt met de Apple het summum van design en gebruiksvriendelijkheid is, heb je een leuk puzzeltje voor diegene
.
[ Voor 20% gewijzigd door gekkie op 19-09-2017 11:43 ]
:strip_icc():strip_exif()/u/68028/crop5c0ef8207f712_cropped.jpeg?f=community)
Om te vragen of je plaats hebt voor iemand met die skills.
Dat vertel je net zelf.
Lekker op de bank
@ZaZ Klemtoon op de "mij"
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
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
Had ik nog een filter actief staan.
Filter weg -> BOEM 20 mails die ik nu in een keer mag wegwerken
Lekker op de bank
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.”
Dat is toch de omgekeerde wereld momenteel:
Ja. En dan heb je nog eens 1,3TB nodig voor de intermediate data om de content te bouwen.
Riiight...
.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
Normaal wordt je om de oren geslagen met job-aanbiedingen.
https://fgheysels.github.io/
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.:
[...]
Dat is toch de omgekeerde wereld momenteel
Normaal wordt je om de oren geslagen met job-aanbiedingen.
:strip_icc():strip_exif()/u/315253/boy-tweakers.jpg?f=community)
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.
Gelukkig wel een antibiotica kuur gekregen waardoor het snel over moet gaan maar nog steeds geen pretje.
Nothing to see here!
Klinkt zeer onaangenaam. Veel beterschap gewenst!:
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.
Damn, sterkte:
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.
Iemand koffie?
Without nipples, boobs are pointless - 365 project - In mijn hoofd is het alle dagen Kerstmis - What type of bees make milk? Boobies! - What type of bees are scary? BoooOOOOOooobeees! - Cactusliefhebster
Lekker dan. Klinkt pijnlijk of niet? Sterkte!:
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.
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
[ Voor 34% gewijzigd door Swedish Clown op 20-09-2017 08:32 ]
Always looking for developers wanting to work with Erlang.
:strip_icc():strip_exif()/u/141741/crop5dd6aa7923c3f_cropped.jpeg?f=community)
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?
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?
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.
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?
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Dit snap ik niet. Je kunt gewoon beginnen?
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.
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.
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.
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.Wat een mooie Maarten van Rossem-uitspraak weer.
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.
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:
Leiden
[ Voor 3% gewijzigd door Hydra op 20-09-2017 11:25 ]
https://niels.nu
https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...
Reden te meer je zooi goed te testen dan
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
Ah okay, ik heb je dan verkeerd begrepen.
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
https://niels.nu
Ja, maar we zitten niet in regio Leiden:
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
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Goede blog, jammer van de schrijffouten. Je zou kunnen stellen dat je je blog niet... getest hebt? *badum tss*
Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.
Bike-shedding blijft een prachtige hobby.
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:
Goede blog, jammer van de schrijffouten. Je zou kunnen stellen dat je je blog niet... getest hebt? *badum tss*
[ Voor 51% gewijzigd door Hydra op 20-09-2017 12:44 ]
https://niels.nu
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.
[ Voor 14% gewijzigd door Hydra op 20-09-2017 12:54 ]
https://niels.nu
/u/296460/beaker_s.png?f=community)
Wij hanteren het volgende systeem::
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?
- 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 | | |\ | | | * | | |/ | | * | | |\ | | | * | | |/ | | * | |/ | * |/ * |
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
De invalid signature melding is overigens ook grappig gezien de inhoud van het bericht
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!
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.:
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
Success met legacy omgevingen...
En management overtuigen; tja, die zien enkel maar kosten.
Dit topic is gesloten.