Als je zelf de podcasts van .NET Rocks wilt beluisteren, die zijn hier te vinden: https://dotnetrocks.com/
Let op: dit zijn oude afleveringen over .NET 3.5. De meeste zaken zullen dus redelijk verouderd zijn. Laten we het erop houden dat je de afleveringen kunt overslaan en als er een echt interessante uitzending is, dan noem ik dat expliciet.
PC 351: In deze uitzending is Rick Strahl te gast die het over Ajax en jQuery heeft. Toen (in 2008) nog redelijk nieuw, Carl wist nog niet van het bestaan van jQuery. Destijds een informatieve podcast, maar inmiddels zijn de meeste browsers redelijk "gelijk" qua implementatie, dus heb je geen jQuery meer nodig om browserverschillen af te vangen. Veel front-end developers zullen je ook afraden om jQuery nog te gebruiken. Die zaken zijn misschien verouderd, Rick zijn website is nog steeds online en de blogs worden regelmatig bijgewerkt. Interessant om nog eens door te nemen: weblog.west-wind.com
PC 352: Eric Brechner is te gast, hij spreekt over zijn blogs die hij online zet en het boek dat hij gepubliceerd heeft (op basis van die columns), Hard Code. Elke maand zet hij een artikel op zijn site en dat doet hij al vanaf 2001. Hij werkt bij Microsoft, als je aan bepaalde voorwaarden voldoet kun je een sabbatical krijgen: 12 weken vrij. Toen is hij gestart met zijn blog. Zijn blog staat nog steeds online en wordt ook nog steeds actief bijgewerkt: imwrightshardcode.com. In deze uitzending komen "Controlling your boss for fun en profit", "Crash dummies: resilience" (waar heel veel reacties op gekomen zijn).
PC 353: Carl meldt dat stand-up comedy held George Carlin overleden is. Hier ging een belletje bij mij rinkelen, een hele tijd geleden had ik daar volgens mij wat filmpjes van gezien, als ik me niet vergis op advies van mijn collega Henk Walgemoed. Ik ben nog even op Youtube gaan kijken, als je dit fragment bekijkt, dat is toch fantastisch! Terechte boosheid, een boodschap die met humor maar wel met feitelijke informatie wordt gebracht. Ik had graag een optreden van George live mee willen maken. Bij de ingekomen brieven een compliment van een luisteraar voor Carl, die bij een event zijn muzikale talent tentoonstelde. Hij deed dat met een versie van "Eyes of the world". Ik kende dat nummer niet (je leert nog eens wat van deze podcasts), het is van de Gratefull Dead. Onderwerp van deze uitzending is de Smart Client en daarover wordt gediscussieerd door een panel bij TechEd 2008. Bekende namen in het panel. ClickOnce van Microsoft wordt hierbij genoemd. Een applicatie die op je desktop draait, maar via online connecties geüpdate kan worden. Wat ik zo mooi vind is dat je ook "terug kunt naar een vorige versie". Dus als je nieuwe versie problemen heeft en "je moet je werk gewoon doen", dan ga je terug naar je vorige versie en wacht je af tot er weer een stabiele versie uitgebracht wordt. Ik heb even gekeken de techniek is er nog steeds en wordt beschreven op deze pagina van Microsoft.
PC 354: Donald Belcham en Kyle Baley zijn te gast, onderwerp is Brownfield Applications. Ze hebben hier een boek over geschreven (Brownfield Application Development in .NET), vooral de "infrastructuur-elementen" komen ter sprake. Een greenfield applicatie is een programma wat je helemaal "nieuw" opzet, iets wat software developers het liefste doen. Maar vaak moeten ze in een bestaand project/code spitten om zaken te fixen of uibreidingen te maken. Al gauw wordt gesproken over "legacy", maar Donald en Kyle vonden dat niet de juiste term. Dat is meer als je met "oudere programmeertalen" moet werken, dus bijvoorbeeld als je nu een project aangeleverd krijgt wat in Cobol geprogrammeerd is. Een "brownfield applicatie" zou een redelijk nieuw programma kunnen zijn, of zelfs code van een applicatie die nog niet uitgebracht is. Als er verkeerde implementatiebesluiten genomen zijn, in verband met een verstreken deadline en "het snel werkend moeten maken" van de applicatie niet de juiste paden qua programmeren volgen, ook dat zijn bf applicaties. Een leuke uitzending om te beluisteren. Veel developers duiken in de aangeleverde code om de bug te fixen of de nieuwe feature te implementeren, maar vaak moet je eerst naar het overkoepelende geheel kijken. Heb je wel de meest recente code? Zit het in source-control? Zit er testcode bij? Kun je de code op je eigen machine (redelijk) snel compileren en laten draaien? En kun je releasen? Donald of Kyle geeft het voorbeeld van iemand die een opdracht gekregen heeft, aan de projectmanager aan de telefoon vraagt: hoe kan ik aan de broncode komen en het vervolgens als een ZIP-bestand in zijn mail ontvangt... Donald en/of Kyle hebben ook het Toyota-boek gelezen, wat over lopende bandwerk gaat. Maar daar zitten principes in die ook hier gelden. Als het testen van je build 10 minuten duurt, kan een developer besluiten om maar 1x per dag code in te gaan checken en niet elke keer als zijn feature-/bugfixing "af" is. Het principe is dat je meteen zijn flow stopt en dat probleem gaat fixen. Als de testtijd weer teruggebracht is naar ongeveer 2 minuten kan die fix gereleased worden en heeft ook de rest van het team hier profijt van. Donald zijn blog is te bekijken op www.igloocoder.com. Op het eerste gezicht interessante artikelen om te lezen, jammer dat het meest recente artikel rond 2018 is...
In deze uitzending komt ook ter sprake dat het niet altijd handig is om een bestaande applicatie helemaal te gaan verbouwen. Zo wordt het voorbeeld gegeven van Netscape. Je had versie 4, toen werd het besluit genomen om de volgende versie helemaal opnieuw te bouwen. Dat werd versie 6, ontwikkeling heeft 3 jaar geduurd. En het was een mislukking. Ook worden er nog wat metrieken genoemd zoals code-coverage (welk deel van je code wordt getest?). Ook een mooi voorbeeld: percentage van 70% werd gehaald. Vervolgens werd een stuk code verwijderd wat niet meer gebruikt werd (die had code-coverage van 100%). Vervolgens daalt de coverage van de hele applicatie naar 46%. Het team wil starten om allemaal testen toe te gaan voegen om weer op die 70% te komen, maar Donald/Kyle geven aan dat je beter eerst je "ondergrens-percentage" beter kunt verlagen en in de loopt van de tijd kunt zorgen dat dit weer verhoogd wordt.
PC 355: Laat ik het meteen droppen: een interessante uitzending! Ted Faison is te gast en hij praat over "events". Als developer ben je daar wel mee bekend, maar waarschijnlijk met "de basics". Dus hoe je zaken aan een event koppelt en dat is het dan. De intellisense in Visual Studio die aangeeft wat je kunt doen/gebruiken. Want een "delegate", dat blijft wel een beetje een abstracte term. Ted legt uit hoe zaken "los" van elkaar kunnen werken, waardoor een coördinator ervoor zorgt dat een event doorgegeven wordt aan de code die er wat mee moet doen. Hoe Microsoft eist dat je bij het implementeren van een event-handler de parameters altijd moeten erven van EventArgs en hoe Ted daar een fanatiek tegenstander van is (als je een int of string wilt doorgeven, dan zou dat moeten kunnen volgens hem). Hij geeft als voorbeeld dat je voor 100 verschillende events dan ook 100 extra classes moet maken die alleen maar het transporteren van bepaalde data nodig zijn. Ook het mee geven van het object zelf (in C# volgens mij de 1e paramter, de object sender) vindt hij een slechte manier van coderen. Dan moet je in de functie die zaken gaat afhandelen eerst code optuigen om te zien wat het binnenkomende object is en vervolgens ook daar nog functies op aan gaan roepen: "tight coupling", je plakt daarmee (onnodig) dingen aan elkaar vast. Een goed voorbeeld van hem is ook dat een view eigenlijk event-driven zou moeten zijn. Dat zijn Windows Forms niet (en Razor Views ook niet), dus als je een pixel aanpast moet je elke keer compilen-runnen, compilen-runnen. Met een event-driven implementatie zou je de view direct moeten kunnen bekijken. Concurrency en threading komen ook voorbij. Carl noemt het voorbeeld hoe hij in VB een timer-control op het formulier zette om op die manier "extra acties uit te voeren". Richard herkent dat (heeft het ook gedaan) en dat geldt ook voor mij. Het gevaar van threads en locking/deadlocks komt voorbij, dus als je een event afhandelt en je gaat "buiten de grenzen van de applicatie", dan moet je rekening houden dat er ook acties terug komen (je kunt dus zaken niet locken). Vroeger had je als je vanuit een background-thread iets uitvoerde op de main-thread de boel "hing". In de nieuwere .NET versies wordt daarop gecontroleerd en wordt een exceptie opgeworpen. Waarschijnlijk zijn teveel programmeurs tegen dat probleem aangelopen ;) En de BackgroundThread in .NET wordt besproken, een mooie gestructureerde manier om taken op de achtergrond te laten draaien. Ted heeft meerdere boeken geschreven, het boek wat over events gaat is Event-Based Programming met de ondertitel: Taking Events to the Limit. Hij wil met dit boek programmeurs laten zien wat je met event kunt, dat is veel meer dan de gemiddelde ontwikkelaar weet.
PC 356: Deze uitzending is bij Teched 2008 gemaakt, wederom met een panel waarbij het gaat over "xml literals". Een feature die alleen in VB.NET zit (en niet in C#). Je kunt een soort "inline XML" in je code hebben. Hoewel sommigen in eerste instantie hier vieze gezichten bij trokken omdat ze de associatie met classic ASP en inline zaken trokken, zijn die mensen later toch bijgetrokken en vinden ze het toch een "coole feature". Ik heb nog mijn twijfels over het in je code opslaan van data, maar een deel van de discussie, over het in code opbouwen van je XML met AddNode e.d., dat maakt totaal onoverzichtelijk wat je nu aan het maken bent. En als iemand anders (of jij zelf na een half jaar) weer met die code aan de slag moet, dan snap je het beter als je de XML ziet, dan dat je het opbouwt. Ik begrijp ook dat het gecompileerd wordt en dat je met intellisense acties kunt uitvoeren. En het is sowieso beter dan de oude manier dat je een "string" maakt met de XML daarin en daarop ging werken. Foutgevoelig en helemaal niet handig. Ook XSLT wordt nog genoemd, dat is voor transformatie, op het werk werd dat gebruikt om data om te bouwen naar HTML (best knap gedaan). Op deze pagina van learn.microsoft.com kun je meer over de literals lezen.
PC 357: In deze uitzending is Nathan Pocock te gast, onderwerp is OPC en factory automation. Vroeger werd alle software voor machines geschreven voor de PLC (programmable logical controller). Geen toetsenbord, geen muis, geen display. Elke keer werd hetzelfde "script" uitgevoerd. De bedrijven die de PLC zaken leverden hadden allemaal hun eigen programmeertechnieken. Dus leverancier A had product A, leverancier B had product B. Omdat ze het werk niet aankonden en ieder zijn eigen ding deed, zijn ze om tafel gaan zitten om te zorgen dat er een standaard kwam. De O stond eerst voor OLE, maar inmiddels staat de afkorting voor Open Platform Communication. Er is een officiële foundation voor opgericht die hier online gevonden kan worden. Door op een soort interface te bouwen zorg je dat alle bedrijven kunnen samenwerken. Richard benadrukt nog even dat het een stuk analoog-digitaal is. Dus je stuurt de "puls" om een poortje te sluiten, daar volgt een mechanische actie op door de PLC uitgevoerd. Alleen, de eerste keer is 1 puls voldoende, maar een volgende keer, door bepaalde oorzaken sluit het poortje niet goed en zijn er meerdere pulsen nodig. Hoe weet je of jouw opdracht uitgevoerd is en daarbij ook "goed" uitgevoerd? Hier komen een paar mooie voorbeelden op. Nathan noemt een voorbeeld waarbij de bouwers dat ook wilden en daarom vroegen om een lamp aan te sluiten, zodat gecontroleerd kon worden dat de boel gesloten was. Omdat deze lamp op een switch werd aangesloten hadden ze daar nog steeds niets aan. Carl noemt zijn universele Philips afstandsbediening. Met een knop kan hij "alles aanzetten". Maar als de TV al aan staat.... dan gaat die dus uit. En Richard heeft het over "Three Mile Island". Dat zei mij niets, maar via Wikipedia lees ik dat dit een ongeluk met een kernreactor in Amerika in 1979 was. Interessant stuk om te lezen. Ook het deel dat "de persoon die dienst had een deel van het alarm niet gezien heeft door zijn dikke buik". Er komt hier ook ter sprake dat je een soort "keep-alive-connectie" in stand moet houden, want als je ergens in dit DCOM verhaal de verbinding kwijt bent, dan moet je 6 minuten wachten voor je weer een connectie op kunt zetten. Dit is een hard-coded configuratiewaarde van Microsoft omdat in het verleden er vanuit gegaan werd, dat een verbinding die met "ver weg" gemaakt moet worden behoorlijk lang kan duren. Nathan noemt nog de website softwaretoolbox.com, ik zie bij de downloads dat daar OPC gerelateerde software staat.
PC 358: Deze uitzending is afkomstig van TechEd 2008. Wederom een panel op het podium, onderwerp is Software Quality. Een levendige discussie, op zich kun je deze uitzending wel overslaan. Een panellid geeft aan dat het niet mogelijk is om op voor een project te pair-programmeren (2 ontwikkelaars die "samen" de code schrijven), er nog 2 testers per programmeur de boel moeten testen en dan ook de boel nog test-driven wordt, dus dat voor 1 regel code 3 regels testcode gemaakt worden. Dat maakt het onbetaalbaar. De grote gemene deler uit de discussie is dat "beter gevraagd/onderzocht moet worden wat de klant wil hebben". Het credo "de klant weet niet wat hij wil" is eigenlijk een vertaling van "we hebben niet genoeg onderzocht wat de klant wil" en ook niet het laten zien aan de klant wat er mogelijk is. Een panellid geeft een eigen voorbeeld. Hij wil een andere laptop kopen, dat wordt een Lenovo. Hij wil weten "hoe de achterkant eruit ziet". Op de site kun je de laptop 360 graden draaien en dat zo dus zien. Maar... als hij draait, duurt dat 5 seconden en dat gaat "schoksgewijs". Hij heeft dus 10 minuten nodig gehad om te zien hoe de laptop er aan de achterkant uit ziet. Op de computer van de ontwikkelaar zal het vast prima gewerkt hebben, maar als iemand een nieuwe pc wil kopen, geeft dat een indicatie dat die persoon "een oud bakje heeft". De klant heeft gevraagd "ik wil dat je op de site de laptop helemaal kunt draaien". De developer heeft het gebouwd, op zijn pc laten zien en de klant zegt "ja, dat wil ik". Dit is een prima voorbeeld. Want na een maand komt de klant bij de service-afdeling, we krijgen allemaal klachten van bezoekers dat het draaien niet vooruit te branden is, dit is een bug. Nee, zegt service "zo heeft het altijd gewerkt en jullie zijn er akkoord mee gegaan, dus het is een feature". Dat is ook wat bij het panel ter sprake komt, de kosten van kwaliteit. En van wijzigingen. Want "even die ene regel code vervangen", dat houdt in dat de testers ook moeten valideren of alles nog werkt zoals beschreven. Zal eventueel documentatie aangepast moeten worden. Moet misschien trainingsmateriaal aangepast worden. Moet een release uitgevoerd worden. En als er een OTAP-model is, moet ook naar al die omgevingen uitgerold worden. Richard komt met het voorbeeld van een klant die een stuk software had, waarbij elk uur een server herstart moest worden. Maar de klant vond dat geen probleem, het hoorde bij de "activiteiten van die applicatie". Dan is er ook nog een schrijver van het boek Software is Shit (????) die met allemaal analogieën komt. Deze geeft hij als voorbeeld dat je een probleem krijgt, iets bouwt en het later laat zien en de klant zegt: dat vroeg ik, maar dit wil ik niet. Zo komt hij met het verhaal dat zijn vader arts is en er een patiënt bij hem komt die aangeeft dat hij "geen grote boodschap kwijt kan". Hij krijgt laxeerpillen. Een week later terug, nog niet. Dus extra zware pillen, nog niet. Een operatie, niets te vinden. De dokter is de wanhoop nabij en vraagt eens "wat doe je voor werk"? De patiënt zegt: "ik ben muzikant". Ohh..... zegt de dokter, hier heb je 10 euro, dan kun je wat eten kopen.
PC 359: Brian Randell is te gast die het over Hyper V en virtualisatie. Een aantal jaren geleden was hij ook te gast in een uitzending over dit onderwerp. Microsoft heeft Hyper V inmiddels werkend, boel zit nog in de beta-fase. Zo kun je een Windows versie aanschaffen die Hyper V heeft. Maar als je de andere versie heeft, daar gaat hyper v nooit op werken: dit zit allemaal op kernel-niveau. In deze uitzending komt ook naar voren dat USB nog niet werkt.
PC 360: Ted Neward en Joel Pobar zijn te gast, ze hebben het over rotor 2.0. Dat is de nieuwe versie van rotor. Toen Microsoft hun CLR open source wilde maken, hebben ze dat met rotor gedaan. GC (garbage collection) en de JIT (just in time compiler) zaten daar niet in, daar had Microsoft een andere implementatie voor aangeleverd. Carl vraagt wat het verschil is tussen Rotor en met reflection de broncode bekijken. Joel legt uit dat in sommige gevallen functies in de unmanaged code wordt aangeroepen, en dat zie je als een soort "func call" in die reflection code terug. Wat er echt gebeurt kun je in rotor wel terugvinden. En natuurlijk heb je ook nog Mono, dat is een implementatie van .NET voor Linux (en Mac). Online is de broncode van Rotor nergens meer te vinden. Ted en Joel zijn met een boek bezig, ze geven aan dat dit als PDF op microsoft.com te downloaden is. Wat nog wel even goed is om hier te benoemen is het Garbage Collection-deel. Chris Sells had zijn bedenkingen bij de huidige implementatie. In de CLR wordt na verloop van tijd de Garbage Collector uitgevoerd. Maar je hebt ook implemenaties: geen referenties meer naar een object: dan meteen opruimen. Chris dacht dat dit effectiever was. Dus hij heeft met rotor een implementatie gemaakt. En kwam er toen achter dat het een heeeel stuk trager was. Een perfecte manier om te bevestigen dat een juiste keuze gemaakt is (of juist niet).