In de auto naar het werk, prima manier om de podcasts van Scott te beluisteren. Maar toen kwam corona om de hoek kijken, werkten we een flink aantal weken thuis en luisterde ik dus geen podcasts. Halverwege mei gingen we weer 1 dag in de week naar het werk, dus de frequentie is nog steeds niet optimaal, de laatste 10 podcasts die ik behandeld heb dateren van begin maart. Dus ik heb het anders aangepakt. Omdat ik de "virtuele 11-stedentoch wandeling" loop, loop ik wekelijks minimaal 20 kilometer. Dus de podcasts op mijn iPod gezet en tijdens het wandelen beluisteren, dan komt er weer wat meer tempo in!
Als je zelf de podcasts van Scott wilt beluisteren, die zijn hier te vinden: https://hanselminutes.com/archives
PC 161: een trip down memory-lane, de tijd dat je nog moest inbellen in het tijdperk "voor het internet" op BBS-en. Ik heb dat niet gedaan (mijn eerste thuis-internet-ervaring was in de tijd dat je inbelde via je 56k6 modem en je dus thuis niet kon bellen of gebeld kon worden), maar vond het wel een leerzame/interessante uitzending. Zeker het luisteren waard! Scott noemt nog even de Wikipedia-link: https://en.wikipedia.org/wiki/Mustang_Software, de PDF die je kunt downloaden: https://hewgill.com/mustang/MustangHistory.pdf en de documentaire die je online kunt zien: http://www.bbsdocumentary.com/
PC 162: uitzending over Powershell versie 2, wat standaard al in Windows 7 zit. Scott heeft op zijn blog een eigen categorie voor Powershell die ik nog eens ga doorlopen: https://www.hanselman.com/blog/archives.aspx#PowerShell
PC 163: software metrics met Patrick Smacchia. Je hebt verschillende metrieken en applicaties. ndepend.com bijvoorbeeld. Volgens mij heeft Scott eerder met deze persoon gesproken, het is een Fransman, dus het is inspannend werk om naar zijn Engels te luisteren. Het gaat erom, zijn er tools om te kunnen zien of je code "goed" is. Behalve ndepend zijn in deze uitzending geen andere tools benoemd.
PC 164: Silverlight 3 met Tim Heuer. Silverlight is deprecated, wordt bijna nergens meer gebruikt. Deze uitzending kun je overslaan.
PC 165: het werken met legacy-code met Michael Feathers, hij heeft hier een boek over geschreven. Door veel side-effecten zijn mensen bang om bestaande code te refactoren. Test-systemen komen ook voorbij, xUnit wordt ook genoemd. Michael noemt hierbij ook dat je je code "bij" moet houden. Wat betekent dat je ook je nuget-packages e.d. bij moet werken, zodat je niet teveel achter gaat lopen.
PC 166: Windows Presentation Foundation (WPF) uitgelegd door Ian Griffiths. Als je daarmee een programma maakt, werk je gauw met "views" en "code-behind"-bestanden om het programma te maken. Dat is niet de juiste manier, want hierbij heb je geen losse classes en die zou je wel moeten hebben. Want Scott loopt nu ergens vast met zijn applicatie en ook is de applicatie nu niet testbaar. ViewModel is wat er gebruikt moet worden. De tool Snoop wordt genoemd en Spy++. Ian Griffiths heeft samen met Chris Sells het boek "programming WPF" geschreven, dus mocht je hiermee aan de slag gaan, dan is het aan te raden om of dat boek te lezen of je eerst in de online documentatie te verdiepen: docs van Microsoft.
PC 167: convention over configuration door Jeremy Miller van codebetter.com. Hij spreekt over NHibernate. Hiermee kun je jouw database-structuur koppelen aan objecten in de C# code. Primary key, staat in de database, maar je moet het zelf allemaal nog aangeven. Laat de ORM-mapper op basis van de structuur zelf bepalen hoe het moet werken en waarbij je zelf dan nog bepaalde zaken kunt "overrulen". Inversion of Control containers, MVC. De naming-convention van MVC is dat de URL structuur /home, /account is en de C# class is HomeController en AccountController. Hierdoor hoef je bij nieuwe controllers niet zelf de zaken aan routering (bv. tests) toe te voegen. Jeremy noemt Storyteller, code staat op Github, waarmee je documentatie over je code kunt maken (?). Maar eens testen om te zien wat het nu doet. Boo wordt genoemd, een (beter) leesbare taal voor .NET.
PC 168: cross-platform-ontwikkelen met Mono en Banshee met Aaron Bockover. Aaron werkt bij Novell aan Banshee, wat werkt met Mono. Het is een soort open-source iTunes. Je hebt de website: http://banshee.fm/. Hier kun je ook de source-code vinden. Omdat mijn git clone in Windows niet werkte nog even gaan zoeken, ik kwam uit op deze locatie: https://gitlab.gnome.org/Archive/banshee/. Aaron noemt ook F-Spot (programma voor afbeeldingen) en TomBoy (applicatie om notities te maken). TomBoy staat op Github: https://github.com/tomboy-notes/tomboy . Je kunt in deze lijst trouwens een overzicht van Mono-programma's vinden, hier heb ik ook F-Spot en Tomboy gevonden. Documentatie over Mono staat hier: link. De Mono Addins kun je ook in je eigen C# project toevoegen. Voor iTunes wordt Bonjour gebruikt, in deze uitzending wordt gesproken over ZeroConf, die pagina staat in het archief, dus lijkt verouderd. Ook de Github-locatie geeft de indruk dat het om een verouderd project gaat: https://github.com/mono/Mono.Zeroconf. Bij het bouwen van Banshee is gebruik gemaakt van Boo (wat we in PC 167 ook al noemden).
PC 169: unit-testing met Roy Osherove. Hij heeft een boek geschreven (the art of Unit Testing) en ook veel resources op zijn website staan. Er zijn 3 basis-items voor een goede unit-test: "trustworthyness". Vertrouw jij de uitkomst van jouw unit-tests? Als je test een "fail" geeft, vind je dat OK? Als je na zo'n uitslag in je code gaat spitten om te zien wat er aan de hand is of je weet zeker dat het onjuist is, dan vertrouw je jouw test niet. "maintainability". Elke keer als je jouw code bijwerkt, en je bent vervolgens een uur bezig om je testen aan te passen, dan worden de kosten te hoog en vervolgens worden de testen niet meer onderhouden. Dus je hebt er niets meer aan en de tijd die er in het verleden in is gestoken is weggegooid. "readability". De tester snapt niet wat er allemaal in de test en/of code gebeurt en moet alles stap voor stap gaan debuggen. Je hebt "unit-testen" en "integration-tests". Alle unit-testen moeten groen zijn. Beide test-types moeten gescheiden zijn, omdat integration-tests nog wel eens willen falen door afhankelijkheden. Roy gebruikt losse projecten per type project. Alle code die in jouw beheer zijn, dat zijn unit-tests. Dus externe packages, daar kun jij niets aan doen. Mocks, fakes en stubs. Fakes zien eruit als echte objecten, maar zijn het niet. Afhankelijk van het gebruik is het een mock of een stub. Een stub moet ervoor zorgen dat je programma werkt, een mock is een object waar je zaken tegen gaat valideren. Je test altijd maar 1 ding, dus maximaal 1 mock. Je kunt wel meerdere stubs hebben. Testen mogen niet afhankelijk van elkaar zijn (als je eerst test 2 runt, doet het niet en dan test 1, maar als je eerst test 1 runt en daarna test 2 (en doet het wel), dan ruimt test 1 de zaken niet goed op).
PC 170: Scott spreekt met Nate Kohari over kanban-board voor agile-development met het product "AgileZen". Nu ik erop Google zie ik dat het product een tijd geleden overgenomen is door Rally Software. Kanban is een bord met werk-items. Je hebt geen sprints. Met scrum worden veel zaken uitgewerkt, op backlog geplaatst en op een later tijdstip uitgevoerd. Of moet het dan opnieuw ingeschat worden door alle reeds doorgevoerde wijzigingen. Of is het punt niet meer nodig (tijd voor het inschatten is dus weggegooid). Met een kanban-bord hou je de hoeveelheid taken beperkt. Zitten checks op hoe lang een punt staat te wachten tot de volgende persoon het oppakt. Maakt statistieken, waardoor sales ongeveer weet wanneer een ingediende aanvraag wordt opgepakt.