23 maart 2013
Kinderpulp
De man achter Studio 100, het Vlaamse mega-kinderimperium van onder andere Kabouter Plop en K3, werd vandaag geinterviewd in de Volkskrant. Hij heet Gert Verhulst; oudere lezers herinneren hem zich wellicht van het TV-programma 'Samson en Gert'. Daarin speelde hij Gert.
Ik moet het gehele interview nog lezen, maar in de flard die ik al wel las stond iets dat ik opvallend vond. Hij zei, dat zijn hersenen altijd sneller werken dan de mensen om hem heen. Op de vraag waneer hij voor het laatst verrast werd, antwoordde hij dat hij zich dat niet kon herinneren.
Ik vond dat interessant, omdat mij het vermogen verrast te worden juist bij uitstek een eigenschap lijkt die past bij het maken van kinderprogramma's. Eerlijk gezegd vond ik het maar een beetje een cynisch antwoord. Wie niet verrast wordt, is naar mijn idee eenvoudigweg niet nieuwsgierig genoeg.
Dat Gert een slimme man is, staat buiten kijf. Studio 100 is een ongekend groot en sterk bedrijf. Je kunt K3 en Kabouter plop weinig verheffend vinden, je kunt er tegelijkertijd niet omheen dat kinderen er geen genoeg van krijgen.
Wat ik jammer aan vind, is dat deze programma's niet uitdagen. Er worden geen vragen gesteld. Een kind leert er niets van. Het is hersenloos vermaak. Pizza die achteloos naar binnen wordt geschoven. Als kinderen er al iets van leren, dan is het consumeren.
In die zin is het een prachtige spiegel van de consumptiemaatschappij. Ouders tellen grof geld neer om hun kinderen bezig te houden met domme pulp. Want de kinderen vragen erom, en hun vriendjes en vriendinnetjes krijgen het ook.
Het geeft ook niet. Je hoeft je kind heus niet elke dag broccoli te voeren. Niks mis met pizza op zijn tijd. Wel ben ik van mening dat het goed is om een kind uit te dagen. Te stimuleren. Ga maar lekker in de blupsie spelen, kikkervisjes vangen. Klim eens in een boom. Val eens een gat in je knie. Stel kinderen vragen. Kijk ook eens naar Sesamstraat. Of, beter nog, Het Klokhuis. (Het Klokhuis is naar mijn mening een van de allerbeste programma's ooit, ik kijk er zelfs nu al allang geen kind meer ben nog steeds graag naar.) Een kind dat Kabouter Plop kijkt leert niets, behalve een spraakgebrek. En de kern van kind-zijn, is dat je leert. Sterker, de kern van mens-zijn, is dat je leert. Blijf nieuwsgierig. Het leven is op zijn mooist als je je erover blijft verbazen.
Van Gert Verhulst zal het waarschijnlijk niet komen. Die wordt niet meer verrast. Arme Gert.
26 februari 2013
20 februari 2013
Doorgestoken kaart
In een poging ‘matchfixing’ tegen te gaan lanceert de KNVB een nieuw wapen: de doorgestoken kaart. Met ingang van het komend seizoen zullen scheidsrechters niet twee, maar drie kaarten in de borstzak hebben.
Er is nog veel onduidelijk over de doorgestoken kaart, maar er circuleren inmiddels vele hardnekkige geruchten. Zeker lijkt, dat bij een doorgestoken kaart beide ploegen een willekeurig aantal punten in meerdering of mindering wordt gebracht. De formule hiervoor is strikt geheim, maar de BMI van de langste doelman, de ascendant van de oudste clubvoorzitter alsmede de afstand in zeemijlen tot het ouderlijk huis van de donkerste spits zullen vrijwel zeker meewegen.
Onduidelijk is ook nog wanneer de kaart precies getrokken zal worden. Het ligt voor de hand aan te nemen dat dit zal zijn bij al te sportief gedrag van spelers, zoals het uitblijven van schwalbes. Ook afwijkend gedrag van trainers kan een doorgestoken kaart tot gevolg hebben. Wanneer een trainer in plaats van ‘blinde graflul’ ineens ‘sambal bij, rare poepchinees?’ roept, kan dit aanleiding zijn voor sancties.
Anonieme bronnen binnen Chinese goksyndicaten reageren verrast en verheugd. “Eenvoudigweg kopen van een wedstrijd wordt moeilijker. Hierdoor heeft ook de gewone man weer een kans. En de competitieuitslag wordt weer een loterij. Dat spreekt de meeste van onze deelnemers erg aan.” Wel wordt gevreesd voor hogere ‘roaming’ kosten.
De KNVB heeft officieel nog geen mededelingen gedaan. Een goedgemutste woordvoerder laat weten dat ‘men de kat niet op nummer 56 wil binden’.
15 januari 2013
DigiD
"Linda Voortman van GroenLinks vindt dat het imago van DigiD naar de haaien is.", zo viel op te tekenen uit berichtgeving.
En waarom dan wel? Omdat DigiD even offline was nadat een security-lek was ontdekt. Security-lek! Klinkt ernstig. En liefst uren offline. Gompie. Jeetje. Schande! Kamervragen!
Nu ben ik de laatste om hoog op te geven over ICT bij het Rijk. Maar mevrouw Voortman is een schoolvoorbeeld van politici en klepels en populisme. Meewaaien op elke media-hype en daarmee diezelfde hype voeden. En mevrouw Voortman bevuilt haar eigen nest, want DigiD is een overheidsdienst, diezelfde overheid die haar jaarlijks bijna een ton toestopt, maar van haar niet kan eisen dat ze er iets zinnigs voor terugdoet.
Wie een heel klein beetje verstand heeft van ICT en de berichtgeving niet alleen via koppen uit de Telegraaf heeft gevolgd, die weet dat de soep lang niet zo heet wordt gegeten. Sterker nog, dat DigiD naar mijn mening te prijzen is.
Want wat was nou het schokkende geval? Een aantal dagen voordat DigiD voor onderhoud off-line ging, is een veiligheidslek gevonden in Ruby on Rails (RoR). Ruby wat? Dat zegt niemand iets, natuurlijk. RoR is de technologie waarmee de DigiD dienst is gebouwd. Vergelijk het met uw eigen computer, of telefoon. Op uw computer staat bijvoorbeeld Windows, op uw telefoon staat bijvoorbeeld Android. En op uw computer en telefoon kunt u applicaties installeren, nietwaar? Voor sommige van die applicaties is het nodig dat u beschikt over bepaalde hulpprogramma's. Zoals bijvoorbeeld Flash, of Java, of .NET. RoR kunt u wel vergelijken met zo'n hulpprogramma, maar dan op de website van DigiD, niet op uw computer.
RoR is dus een applicatie, met een duur woord een 'ontwikkelplatform'. En dat platform bleek lek. Niets bijzonders. Er worden zo vaak fouten gevonden in software. Hoe vaak heeft u -al dan niet bewust- uw Windows al wel niet ge-updated? Een notoire lekkenkampioen is Java, de populairste ontwikkelomgeving die er bestaat. Miljarden apparaten op deze planeet draaien applicaties ontwikkeld in Java.
Tot zover de technische details. Ik maak het nog wat simpeler: stel dat een computersysteem een auto is. Dus uw computer is een auto, uw telefoon is een auto, DigiD is een auto. En de fabrikant van uw auto laat u weten dat er een probleem is met een motoronderdeel van die auto. Wat doet u dan?
De meesten van ons, particulier of bedrijf, doen niets. Die zeggen 'hij rijdt nog, dus zo'n vaart zal het niet lopen.' Om achteraf met de gebakken peren te zitten. Maar een verstandig mens zet de auto stil en vervangt het kapotte onderdeel.
Dat is wat men bij DigiD heeft gedaan. Ze zijn gestopt en hebben een motoronderdeel vervangen. In de tussentijd konden ze niet doorrijden - de DigiD site was dus even niet te bereiken.
Wat mevrouw Voortman beweert slaat dus nergens op. DigiD trof hier geen schuld; het vermeende 'beveiligingsprobleem' lag namelijk niet aan hen. En ze hebben relatief snel en adequaat gehandeld om het probleem te verhelpen. Dat ze daarvoor even offline moesten, dat is niet meer dan logisch; sterker, het is een verstandig besluit. Want als de een of andere gek in de tussentijd met succes misbruik van de DigiD dienst zou hebben gemaakt, dan waren de rapen pas echt gaar geweest.
Ik roep mevrouw Voortman dan ook met klem op om niet zulke populistische larie de wereld in te helpen. Alvast bedankt.
En waarom dan wel? Omdat DigiD even offline was nadat een security-lek was ontdekt. Security-lek! Klinkt ernstig. En liefst uren offline. Gompie. Jeetje. Schande! Kamervragen!
Nu ben ik de laatste om hoog op te geven over ICT bij het Rijk. Maar mevrouw Voortman is een schoolvoorbeeld van politici en klepels en populisme. Meewaaien op elke media-hype en daarmee diezelfde hype voeden. En mevrouw Voortman bevuilt haar eigen nest, want DigiD is een overheidsdienst, diezelfde overheid die haar jaarlijks bijna een ton toestopt, maar van haar niet kan eisen dat ze er iets zinnigs voor terugdoet.
Wie een heel klein beetje verstand heeft van ICT en de berichtgeving niet alleen via koppen uit de Telegraaf heeft gevolgd, die weet dat de soep lang niet zo heet wordt gegeten. Sterker nog, dat DigiD naar mijn mening te prijzen is.
Want wat was nou het schokkende geval? Een aantal dagen voordat DigiD voor onderhoud off-line ging, is een veiligheidslek gevonden in Ruby on Rails (RoR). Ruby wat? Dat zegt niemand iets, natuurlijk. RoR is de technologie waarmee de DigiD dienst is gebouwd. Vergelijk het met uw eigen computer, of telefoon. Op uw computer staat bijvoorbeeld Windows, op uw telefoon staat bijvoorbeeld Android. En op uw computer en telefoon kunt u applicaties installeren, nietwaar? Voor sommige van die applicaties is het nodig dat u beschikt over bepaalde hulpprogramma's. Zoals bijvoorbeeld Flash, of Java, of .NET. RoR kunt u wel vergelijken met zo'n hulpprogramma, maar dan op de website van DigiD, niet op uw computer.
RoR is dus een applicatie, met een duur woord een 'ontwikkelplatform'. En dat platform bleek lek. Niets bijzonders. Er worden zo vaak fouten gevonden in software. Hoe vaak heeft u -al dan niet bewust- uw Windows al wel niet ge-updated? Een notoire lekkenkampioen is Java, de populairste ontwikkelomgeving die er bestaat. Miljarden apparaten op deze planeet draaien applicaties ontwikkeld in Java.
Tot zover de technische details. Ik maak het nog wat simpeler: stel dat een computersysteem een auto is. Dus uw computer is een auto, uw telefoon is een auto, DigiD is een auto. En de fabrikant van uw auto laat u weten dat er een probleem is met een motoronderdeel van die auto. Wat doet u dan?
De meesten van ons, particulier of bedrijf, doen niets. Die zeggen 'hij rijdt nog, dus zo'n vaart zal het niet lopen.' Om achteraf met de gebakken peren te zitten. Maar een verstandig mens zet de auto stil en vervangt het kapotte onderdeel.
Dat is wat men bij DigiD heeft gedaan. Ze zijn gestopt en hebben een motoronderdeel vervangen. In de tussentijd konden ze niet doorrijden - de DigiD site was dus even niet te bereiken.
Wat mevrouw Voortman beweert slaat dus nergens op. DigiD trof hier geen schuld; het vermeende 'beveiligingsprobleem' lag namelijk niet aan hen. En ze hebben relatief snel en adequaat gehandeld om het probleem te verhelpen. Dat ze daarvoor even offline moesten, dat is niet meer dan logisch; sterker, het is een verstandig besluit. Want als de een of andere gek in de tussentijd met succes misbruik van de DigiD dienst zou hebben gemaakt, dan waren de rapen pas echt gaar geweest.
Ik roep mevrouw Voortman dan ook met klem op om niet zulke populistische larie de wereld in te helpen. Alvast bedankt.
13 januari 2013
PowerShell
-nerd-alert!-
Ah, keuzes. Voor een klant werd ik gevraagd een import te doen vanuit een CSV bestand naar de database-applicatie waarin ben gespecialiseerd, Commence.
Dat begon heel simpel, maar werd al snel akelig complex. Commence, zo moet u weten, is niet erg gangbaar. Een van de redenen daarvoor is dat het niet ODBC-compliant is. Que? Het is niet standaard. Je kunt er niet, zoals met MySQL, of MS SQL Server, of MS Access een 'verbinding' mee maken en leuke dingen met queries doen. Het heeft zelfs geen fatsoenlijke importfunctie. Commence Is Gewoon Bestwel Raar. Het is ook geweldig, maar niet als je het wilt koppelen aan een ander systeem.
Wel heeft het een API. Que? Een API is een manier om via het ene programma met het andere programma te praten. Zei ik dat Commence raar was? Nee, dan heb je de API niet bestudeerd! Klopt, hè? Gelukkig kan ik er na 14 jaar mee lezen en schrijven (ha, een kostelijke nerdwoordspeling). Die vaardigheid deel ik met een man of 5 hooguit in Nederland. Het is heerlijk om hyperspecialist te zijn in een applicatie die bijna niemand kent. Pft.
Nu goed, een ingewikkelde import dus. Klant levert een nogal complex CSV bestand aan. Aan mij de taak om de gegevens ervan in een aantal tabellen te frommelen, en deze ook nog een beetje kloppend aan elkaar te knopen. Oh wacht, de klant levert het niet aan. Ik moet het zelf gaan ophalen van een internet locatie. 'Is er een fijne webservice via REST of SOAP of zo?' zult u vragen. Neen, die is er niet. CSV het is, en die CSV moet via het antieke maar fijne FTP worden opgehaald. Daar heb je gelukkig programmaatjes voor, maar ik bouw liever niet nog een extra stap in, dus het liefst haal ik het bestand zelf even op.
Tot zover de inleiding.
Ik moet dus 2 dingen oplossen:
Eén ervan is met VBScript. Daar ben ik behoorlijk goed in. VBScript is echter niet zo goed met internet. Een hoop dingen kunnen wel, maar zijn erg omslachtig. En VBScript is met zoals dat zo mooi heet 'deprecated'. Dat wil zeggen dat het nog wel bestaat, maar dat het uitgefaseerd zal gaan worden. Een soort computer-Sanskriet, zo u wilt.
Een mooi moment om mij eens te verdiepen in iets meer contemporains. Dat kan een 'echte' programmeertaal zijn. Ik spreek VB6 want ik ben oud, en een woordje C#.NET. Maar de klant wil een 'quick-and-dirty' oplossing, dus dat is geen optie. Dus wordt het een gescripte oplossing. Eentje die door Windows 'native' wordt ondersteund. PHP en Python en zo nog een paar vallen dus af. Blijven over VBScript, JavaScript en PowerShell.
Ik beheers JavaScript wel een beetje, maar ik voel me er niet zo in thuis. Eenvoudige taken zoals string-manipulaties en datum-manipulaties zijn er al snel overdreven complex in. Vind ik. En daarvan ga ik er veel nodig hebben. En JavaScript is verdomd moeilijk te lezen.
Blijft over PowerShell. Nooit wat mee gedaan, maar bijzonder krachtig, omdat je ermee direct toegang hebt tot .NET. Que? .NET is kort door de bocht een collectie van krachtige gereedschappen waarmee je van alles kunt doen. Het ophalen van een bestandje via FTP is met .NET een peulenschil vergeleken met VBScript. Ook heeft het krachtige instrumenten om gegevens heen en weer te smijten. Interessant genoeg om eens een keer mee te stoeien.
Zo gezegd, zo gedaan. Met frisse moed opende ik PowerShell ( Start | powershell). Ik kreeg een fijne DOS-prompt-achtige omgeving te zien. Dat ging hem niet worden, zelfs in DOS schreef ik geen BAT files via de command-prompt. Gelukkig bestaan er ook GUI omgevingen, en ik installeerde het fijne gratis PowerGUI.
First things first: eens kijken hoe we met Commence kunnen communiceren.
In VBScript gaat dat alsvolgt:
Set cmc = CreateObject("Commence.DB")
In PowerShell schrijf je:
$cmc = New-Object -ComObject Commence.DB
So far, so good.
Nu even de naam opvragen van de actieve database.
In VBScript doe je dat met:
naam = cmc.Name
In PowerShell doe je dat met
$naam = $cmc.Name
Maar wacht. Wat blijkt? De object-variable $cmc in PowerShell weet niets van Commence. Dat is gek! Want als ik doe:
$ie = New-Object -ComObject InternetExplorer.Application
dan krijg ik netjes alle eigenschappen en methoden van Internet Explorer te zien als ik '$ie.' typ.
Wat blijkt? (Lang verhaal dat ik u zal besparen) Wanneer ik het equivalent van cmc.Name in VBScript wil doen in PowerShell, dan moet ik schrijven:
$naam = [System.__ComObject].InvokeMember("Name",[System.Reflection.BindingFlags]::GetProperty,$null,$cmc,$null)
Ik sta dus voor de volgende keus: kies ik voor VBScript:
Set cmc = CreateObject("Commence.DB")
naam = cmc.Name
Of kies ik voor PowerShell:
$cmc = New-Object -ComObject Commence.DB
$naam = [System.__ComObject].InvokeMember("Name",[System.Reflection.BindingFlags]::GetProperty,$null,$cmc,$null)
Als ik mij was, dan wist ik het wel. Dan maar computer-Sanskriet :)
Ah, keuzes. Voor een klant werd ik gevraagd een import te doen vanuit een CSV bestand naar de database-applicatie waarin ben gespecialiseerd, Commence.
Dat begon heel simpel, maar werd al snel akelig complex. Commence, zo moet u weten, is niet erg gangbaar. Een van de redenen daarvoor is dat het niet ODBC-compliant is. Que? Het is niet standaard. Je kunt er niet, zoals met MySQL, of MS SQL Server, of MS Access een 'verbinding' mee maken en leuke dingen met queries doen. Het heeft zelfs geen fatsoenlijke importfunctie. Commence Is Gewoon Bestwel Raar. Het is ook geweldig, maar niet als je het wilt koppelen aan een ander systeem.
Wel heeft het een API. Que? Een API is een manier om via het ene programma met het andere programma te praten. Zei ik dat Commence raar was? Nee, dan heb je de API niet bestudeerd! Klopt, hè? Gelukkig kan ik er na 14 jaar mee lezen en schrijven (ha, een kostelijke nerdwoordspeling). Die vaardigheid deel ik met een man of 5 hooguit in Nederland. Het is heerlijk om hyperspecialist te zijn in een applicatie die bijna niemand kent. Pft.
Nu goed, een ingewikkelde import dus. Klant levert een nogal complex CSV bestand aan. Aan mij de taak om de gegevens ervan in een aantal tabellen te frommelen, en deze ook nog een beetje kloppend aan elkaar te knopen. Oh wacht, de klant levert het niet aan. Ik moet het zelf gaan ophalen van een internet locatie. 'Is er een fijne webservice via REST of SOAP of zo?' zult u vragen. Neen, die is er niet. CSV het is, en die CSV moet via het antieke maar fijne FTP worden opgehaald. Daar heb je gelukkig programmaatjes voor, maar ik bouw liever niet nog een extra stap in, dus het liefst haal ik het bestand zelf even op.
Tot zover de inleiding.
Ik moet dus 2 dingen oplossen:
- CSV bestand ophalen
- CSV bestand verwerken
Eén ervan is met VBScript. Daar ben ik behoorlijk goed in. VBScript is echter niet zo goed met internet. Een hoop dingen kunnen wel, maar zijn erg omslachtig. En VBScript is met zoals dat zo mooi heet 'deprecated'. Dat wil zeggen dat het nog wel bestaat, maar dat het uitgefaseerd zal gaan worden. Een soort computer-Sanskriet, zo u wilt.
Een mooi moment om mij eens te verdiepen in iets meer contemporains. Dat kan een 'echte' programmeertaal zijn. Ik spreek VB6 want ik ben oud, en een woordje C#.NET. Maar de klant wil een 'quick-and-dirty' oplossing, dus dat is geen optie. Dus wordt het een gescripte oplossing. Eentje die door Windows 'native' wordt ondersteund. PHP en Python en zo nog een paar vallen dus af. Blijven over VBScript, JavaScript en PowerShell.
Ik beheers JavaScript wel een beetje, maar ik voel me er niet zo in thuis. Eenvoudige taken zoals string-manipulaties en datum-manipulaties zijn er al snel overdreven complex in. Vind ik. En daarvan ga ik er veel nodig hebben. En JavaScript is verdomd moeilijk te lezen.
Blijft over PowerShell. Nooit wat mee gedaan, maar bijzonder krachtig, omdat je ermee direct toegang hebt tot .NET. Que? .NET is kort door de bocht een collectie van krachtige gereedschappen waarmee je van alles kunt doen. Het ophalen van een bestandje via FTP is met .NET een peulenschil vergeleken met VBScript. Ook heeft het krachtige instrumenten om gegevens heen en weer te smijten. Interessant genoeg om eens een keer mee te stoeien.
Zo gezegd, zo gedaan. Met frisse moed opende ik PowerShell ( Start | powershell). Ik kreeg een fijne DOS-prompt-achtige omgeving te zien. Dat ging hem niet worden, zelfs in DOS schreef ik geen BAT files via de command-prompt. Gelukkig bestaan er ook GUI omgevingen, en ik installeerde het fijne gratis PowerGUI.
First things first: eens kijken hoe we met Commence kunnen communiceren.
In VBScript gaat dat alsvolgt:
Set cmc = CreateObject("Commence.DB")
In PowerShell schrijf je:
$cmc = New-Object -ComObject Commence.DB
So far, so good.
Nu even de naam opvragen van de actieve database.
In VBScript doe je dat met:
naam = cmc.Name
In PowerShell doe je dat met
$naam = $cmc.Name
Maar wacht. Wat blijkt? De object-variable $cmc in PowerShell weet niets van Commence. Dat is gek! Want als ik doe:
$ie = New-Object -ComObject InternetExplorer.Application
dan krijg ik netjes alle eigenschappen en methoden van Internet Explorer te zien als ik '$ie.' typ.
Wat blijkt? (Lang verhaal dat ik u zal besparen) Wanneer ik het equivalent van cmc.Name in VBScript wil doen in PowerShell, dan moet ik schrijven:
$naam = [System.__ComObject].InvokeMember("Name",[System.Reflection.BindingFlags]::GetProperty,$null,$cmc,$null)
Ik sta dus voor de volgende keus: kies ik voor VBScript:
Set cmc = CreateObject("Commence.DB")
naam = cmc.Name
Of kies ik voor PowerShell:
$cmc = New-Object -ComObject Commence.DB
$naam = [System.__ComObject].InvokeMember("Name",[System.Reflection.BindingFlags]::GetProperty,$null,$cmc,$null)
Als ik mij was, dan wist ik het wel. Dan maar computer-Sanskriet :)
Abonneren op:
Posts (Atom)