Counterculture

Afgelopen zaterdag hoorde ik de hele dag muziek spelen uit het park naast mijn woning (Park Transwijk). Dat wekte mijn nieuwsgierigheid en de belangstelling van significante ander, die het op de computer vond waar het vandaan kwam. De bron was het ‘Counterculture’ festival. ’s Avonds zijn we er even naar toe geweest. Denk dat behoorlijk leuke tijd zou kunnen doorbrengen als ik me wat fitter voelde en beter ingepland.

Het festival leek niet bijzonder druk, wellicht was wat ‘commerciele promotie’ ook wel op zijn plaats geweest om het zo te zeggen.
Sfeer leek me goed, erg veel langharig tuig naast veel kaalgeschoren vrouwen.
Typisch waren de krakershonden. Er waren nog enkele jonge kinderen en zwangere vrouwen (tussen rook en drank) om het burgelijk te zeggen, de nieuwe antiegeneratie komt er ook aan.
Al met al toch jammer dat ik er niet eerder was, leek me gezellig ondanks.
Gelukkig is er nog genoeg te doen, deze week is het Festival aan het werf! Iedere avond voorstellingen door heel Utrecht.

Whitebook over build-management

Woei! Er staat een artikel van mij online op de website van mijn werkgever! Het schrijven was een redelijke bevalling, maar het staat het er nu! De naam van het artikel is Build-Management.

Programmeerfrustaties

Ik programmeer nu behoorlijke tijd al in Java binnen een aantal projecten, en meer en meer begin ik me frusteren aan een aantal punten. Nogal wat zaken die volgens mij veranderd of zouden moeten verdwijnen.

• Geen XML meer. Sinds enkele jaren wordt sluipenderwijs bijna overal XML voor gebruikt: als communicatieprotocol, als opslagformaat, voor configureren en zelfs om te programmeren. XML is gebaseerd op eind-jaren-60 ontwikkelde SGML, vooral ontwikkeld om makkelijk door toen trage computers verwerkt te kunnen worden. Het protocol is vreselijk inefficiënt, zowel om te typen en als gegevens transport.
  Voor communicatie is xml vreselijk inefficiënt. Er zijn veel efficiëntere protocollen voor communicatie, die eveneens open zijn. Los daarvan, in de meeste gevallen wordt een XML-gebaseerd protocol alleen gebruikt omdat een enkele incompentente systeembeheerders/managers denken dat dit veiliger is.
  Alleen voor opslag heeft XML zo zijn nu, maar dan kan gewoon een standaard gebruikt worden.
  Voor programmeren moet XML al helemaal niet gebruikt worden, net als voor configureren. Computers zijn al sinds jaar en dag snel genoeg om de meest ingewikkelde (programmeer)talen te interpreteren, zoals b.v. Ruby, Basic, Java, Haskell. Ingewikkeld voor de computer bedoel ik, maar voor de gebruiker is zo’n taal juist veel makkelijker. Waarom de gebruiker veel werk laten doen, als de computer dat kan doen? In een subset van een taal als Ruby of Java is het veel makkelijker een programma te configureren of te declareren, of een build-systeem op te zetten.
• Geen consultancy-ware! Heel vaak wordt een enorm duur softwaresysteem verkocht, dat vervolgens alleen maar bruikbaar is met consultants. In bijna alle gevallen lijkt zelf bouwen achteraf nauwelijks duurder.
• De reden vaak dat 80% van de functionaliteit die zo’n applicatie aanbiedt, al bestaat als open-source of goedkope componenten. De overige 20% zijn (in het gunstige geval) domeinkennis, over logistiek of telefonie of e-learning. Veel goedkoper is het dan, iemand in te huren die de domeinkennis heeft, en verder een goed programma zelf op te bouwen.
  Of gewoon een beter programma te kopen. Meestal is een programma erg duur, om alle consultants ervoor te betalen die het programma moeten verkopen en vervolgens configureren, installeren, aanpassen, als je daar ook al niet extra voor moet betalen.
• Hier op bouwend, software zou zo simpel mogelijk moeten zijn als het maar kan, ook ontwikkelsoftware en libraries. Als wat automatisch kan, zou ook automatisch moeten gebeuren.
  Ik ben al vaak een programma tegengekomen waar het een hels karwei was om het überhaupt op te zetten.
  Wat die programma’s uiteindelijk moeten doen, was functioneel behoorlijk simpel. Als het programma makkelijk configureren baar was met een makkelijke taal, out-of-the-box al goed functioneerde voor meest voorkomende gevallen, helder en gestructureerd opgezet en gedocumenteerd, kon in een fractie van de tijd hetzelfde gedaan worden.
• Gebruik van multi-core processoren. Zelfs desktopcomputers hebben al meerdere procesors of ‘cores’. Dat wil zeggen dat een computer echt twee taken tegelijk kan uitvoeren. Om een programma sneller te laten lopen, moeten het programma over meerdere threads (wat grof en enigszins incorrect gezegd, ‘miniprogramma’s) verdeeld worden.
  Helaas zijn de meeste programeertalen, laat staan programmeurs daar nauwelijks op ingesteld. Meeste mensen denken dat het vanzelf goed gaat: als je een website of webapplicatie hebt, zijn er per definitie heel veel gelijktijdige gebruikers. Op die manier kun je de computer ook makkelijk taken laten verdelen, geef iedere groep gebruikers zijn eigen processor.Probleem alleen is, dat dit alleen goed gaat zolang een website veel meer gebruikers heeft dan processors. Zolang een computer maar 4 of 16 processors heeft, zal dit snel het geval zijn. Maar wat als en processor 64 of 128 processors of cores heeft?
  Geen rekening houden met multi-coreprocessors, is vergelijkbaar met de 640KB limiet destijds die IBM-computers en DOS hadden . Ooit leek die hoeveelheid geheugen zo groot, dat het niet nodig leek daar rekening mee te houden.

Toevoeging: ik heb een aparte pagina van dit artikel gemaakt, en ik heb mezelf voorgenomen die ook bij te houden.