dinsdag, januari 31, 2006

Nunit, succes or failure

De mooiste momenten op een dag zijn de de momenten wanneer je mond tekenfilmisch open valt. Zo ook deze keer. Ik had wat code aangepast en ging de Unit test draaien met NUnit. En wat bleek:

Alle tests waren succesvol. De test in zijn geheel was een failure. WTF?!?

Nu doet NUnit wel vaker vage dingen: Application Exceptions op de CLR bijvoorbeeld. Maar dit was ik nog niet tegengekomen.

Uiteindelijk heb ik het probleem gevonden en opgelost: mijn Teardown method throwde een exception en dat mag niet foei!

maandag, januari 30, 2006

http://del.icio.us/ bookmarking made easy

Wat ik nu tegen kom: http://del.icio.us/

Snel en simpel sites bookmarken met een firefox plugin en kijken wat andere mensen gebookmarked(?) hebben. briljant!

Jaap, de wereldwijze

Vandaag een verhaal met een moraal waar ik laatst aan moest denken toen ik een discussie had met een collega. Waar ik het precies gehoord heb weet ik niet meer. Ik heb het in ieder geval niet zelf verzonnen.

Het verhaal begint met Jaap. Jaap is op wereldreis. Hij heeft al flink veel van de wereld gezien en op zijn reis komt hij langs een klein dorp in de bergen. In dat kleine dorp zijn ze helemaal door het dolle heen. Zelden hebben ze contact met mensen buiten het dorp, zelf komen ze amper het dorp uit. En het is helemaal zeldzaam dat er iemand van buitenaf het dorp binnenkomt. De dorpelingen zijn ontzettend gastvrij en geven een groot feest ter ere van de komst van Jaap.



De volgende morgen als Jaap zijn roes heeft uitgeslapen gaat hij eens rondwandelen in het dorp. Hij komt langs een akker vol met graan wat allang ge-oogst had moeten worden. Jaap vraagt aan een dorpeling: "Waarom is dat graan nog niet ge-oogst?". "Nou", zegt de dorpeling. "In dat akker zit een monster, niemand van ons durft er meer in."

Jaap, nog helemaal dankbaar voor de gastvrijheid besluit het probleem op te lossen. Hij loopt het maaiveld in op zoek naar het monster. Wat blijkt: er zit geen monster, er groeit gewoon een grote pompoen. Jaap pakt een stok en slaat de pompen kapot. Zelfvoldaan stapt hij met de stukken het akker af. Trots laat hij het zien aan de dorpelingen: "Ik heb het monster verslagen!". Direct wordt hij aangevallen door alle dorpelingen en vermoord. Iemand die dat monster heeft kunnen verslaan moet zelf nog wel nog een groter monster zijn!



De volgende dag komt Jasper aan in het dorp, ook voor hem wordt een groot feest gegeven. Mede voor zijn komst. Het ritueel herhaalt zich: ook hem wordt het verhaal van het monster verteld. Hij loopt het akker in en ziet daar ook de pompoenen. Hij loopt het akker weer uit en verteld de dorpelingen wat hij gezien heeft. Hij stelt voor om samen het monster te verdrijven. Samen met een paar dappere dorpelingen pakt hij stokken en lopen het akker in. Daar aangekomen slaan ze samen de pompoenen kapot. Als ze eenmaal het veld uitkomen, gaat het nieuws als een lopen vuurtje rond. Al snel is Jasper de held van het dorp en wordt er wederoom een feest gegeven. En de dorpelingen? die zijn niet meer bang voor deze monsters!


Moraal van het verhaal: met welke goede bedoelingen je je hulp en advies ook geeft, als je geen rekening houdt met de omstandigheden en de manier waarop je het brengt heeft het geen enkel effect, behalve dat je je eigen geloofwaardigheid in gevaar brengt.

vrijdag, januari 27, 2006

Oursourcen, is India echt het paradijs?

Outsourcen is helemaal in. Na de fabrieken en de callcenters hebben nu ook software bedrijven de lage loonladen ontdekt. Of het zo'n goed idee is om software te outsourcen betwijfel ik.

If it's a core business function -- do it yourself, no matter what. --

Pick your core business competencies and goals, and do those in house. If you're a software company, writing excellent code is how you're going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication.




Tuurlijk het klinkt allemaal mooi: lage kosten en snel resultaat, wie wil dat nou niet?

De 5 grootste risico's die ik zie zijn:
- Diefstal van code
- Specificaties en kwaliteit van code
- Plannen
- Communicatie problemen
- Change management

Diefstal van code:

Op het moment dat je heel de applicatie uitbesteed aan een andere partij heb je de kans dat die partij er met jouw code vandoor gaat. Of anders met de concepten erachter. Dat hebben we gezien met Microsoft en IBm in de jaren 80. En kortgeleden nog met de rechtzaak tussen Heineken en Philips over de beertender\perfect draft. De enige manier om dit risico beheersbaar te houden: laat ze kleine afgebakentende onderdelen maken die opzichzelf weinig kunnen. Maar wat is dan de winst van outsourcen? Kun je die onderdelen dan niet beter als component inkopen?

Specificaties en kwaliteit van code:

Wanneer je code gaat uitbesteden zal de specificatie heel duidelijk en eenduidig moeten zijn. Beide partijen moeten weten wat er gemaakt wordt en hoe. Dit vraagt een flinke tijdsinvestering vooraf, zeker als je organisatie hier niet op ingericht is en specificaties vaak veranderen. Daarnaast zul je een manier moeten hebben om te testen of de geleverde code aan de specificaties voldoet.

Plannen:

In een project is een bepaald stuk code vaak afhankelijk van andere stukken code. Sommige zaken moeten nu eenmaal na elkaar en kunnen niet tegelijkertijd. Dit zul je goed moeten plannen. Maar de enige die weet hoe lang een feature precies duurt is de programmeur zelf. Wat de ene programmeur in 10 min, doet een ander 5 dagen over. Afhankelijk van ervaring en kennis. Mensen die zonder detail specificaties zeggen hoe lang iets duurt liegen.

Communicatie problemen:

Iedereen die met een multi-site ontwikkel team gewerkt heeft kent het probleem: communicatie! Ook al spreek je dezelfde taal als je niet fysiek in dezelfde kamer bent gaat het communiceren al lastiger dan iemand die naast je staat. Zeker als je moet overleggen over de details van hoe iets geimplemteerd moet worden. Laat staan als je een andere taal spreekt en zelfs in een andere tijdzone leeft. Je moet een goede Project Manager zijn om Multi-Site ontwikkeling goed te kunnen managen.



Change management:

Eind goed al goed, je hebt een stukje software ge-outsourced en het product is opgeleverd. Hoera. Alleen nu blijkt er een fout in te zitten in de aangeleverde code. En iedere programmeur weet hoe moeilijk het is om code van anderen te lezen. Dus mag je naar India bellen om uit te leggen wat er fout zit en dat ze het op moeten lossen, of nog leuker mensen zijn dol enthousiast maar willen 1 kleine wijziging..


Kortom: Outsourcen zal best lukken mits:
- Je heel goed kunt plannen
- Je een heel goede project manager hebt die alles in de hand heeft
- Je duidelijke specicificaties hebt
- Je heldere testprocedures hebt

En dan schat ik de kans op succes nog maar op 50%. En een groot deel van het geld wat je bespaard ben je kwijt aan die goede Project Manager, de communictie en controle. (Dat voortraject van specificaties en goed plannen moet je zoiezo doen natuurlijk ;) )

Kortom huur gewoon een aantal goede Programmeurs in, 2 goede programmeurs verzetten evenveel werk als 20 middelmatige, en maak het jezelf gemakkelijk.

The only exception to this rule, I suspect, is if your own people are more incompetent than everyone else, so whenever you try to do anything in house, it's botched up. Yes, there are plenty of places like this. If you're in one of them, I can't help you.

donderdag, januari 26, 2006

Klantbelevenis

Gisteren hebben we een soort intake gesprek gehad bij een hypotheekadviseur. De setting is vrij duidelijk. wij hebben geen verstand van hypotheken, het is een domein waar we nog volkomen onbekend in zijn. Bij de adviseur ligt de taak om ons wegwijs te maken in deze wereld zodat wij weloverwogen beslissingen kunnen nemen. In mijn werk als programmeur kom ik dit ook regelmatig tegen: dat ik mensen wegwijs moet maken zodat ze goede beslissingen kunnen nemen. Ik heb dan ook goed opgelet.

Na de kennismaking kwam het formuleren van de klantvraag: "Hoi, we willen misschien een huis kopen, we snappen niets van hypoyheken kun je ons het een en ander uitleggen?". Al met al een mooie open vraag waar je veel kanten mee opkunt. We begonnen met de standaard vragen: "Wat is het inkomen? Hebben jullie al een huis op het oog?" en daarna kwam de vragenlijst. De vragenlijst was een soort enquete waarbij op elke vraag een antwoord gegeven moest worden en aangeven moest woorden of het duidelijk was wat er gevraagd werd. Afhankelijk van de antwoorden kwamen er nieuwe vragen in volgende schermen (routing heet dat, of niet Nielsz? ;) ).



En dit vind ik briljant: simpel en effectief tegelijk. Wij beantwoorden de vragen die voor ons van toepassing zijn. We slaan niets over en de bank heeft van ons een digitaal profiel wat ze altijd kunnen opvragen. En de volgende keer als we daar komen en de situatie misschien veranderd is, pakken we dat profiel er weer bij, veranderen de waarden en rekenen het opnieuw door.

Na het invullen van de vragenlijst krijgen we een mooie rapport over het hoe en wat zodat we het rustig kunnen nalezen en met anderen kunnen overleggen. En alleen door het gebruik van zo'n simpele tool staan de eisen aan het te leveren product al vast. En kun je daarna toetsen of het geleverde product aan de eisen voldoet.

Om terug te koppelen naar de software wereld: dit is een perfecte manier om te zorgen dat je requirements hebt. Samen met de klant loop je de vragenlijst door. Daarna opslaan en je hebt het altijd bij de hand. En dan kun je lekker software gaan bouwen aan de hand van deze requiremets. Wel moet je zorgen dat je de juiste vragen stelt, maar daarvoor ben je expert over je eigen domein.

Ik zeg niet dat requirements zorgen voor een tevreden klant, maar daar begint het wel.

Linkmania

Een overzicht van interressante links die ik de laatste dagen tegen ben gekomen:

How to choose an open source CMS: Welke Open Source CMS-en zijn er? En hoe kies je de juiste?

Populaire tags: google deed een onderzoek onder een miljard pagina's welke tags populair zijn.


Firefox Plugins: Ieder zichzelf respecterende internet gebruiker gebruikt het. Maar hoe maak je nu zo'n handige plugin?

www.Ipban.nl: hoe kom je van die lastige bezoekers af die je site onder spammen? Ipban regelt het centraal. Geband op 1 site? geband op alle sites!

woensdag, januari 25, 2006

Mooie blog

Volgens een post die ik gelezen heb via usarchy.com moet je zorgen dat je je publiek vermaakt op je blog. Alleen dan komen ze terug en kun je je publiek uitbreiden. Nu ben ik zelf niet ontzettend grappig dus wil ik het anders proberen. Bij elke blog komt een mooie plaatje. Rechtstreeks gejat van google:
Mooi he?
Voor mij zijn de voornaamste redenen voor deze blog dat ik dingen van me af moet schrijven. Vaak dingen die bij mij opkomen als ik in de auto zit en niemand heb om ze tegen te roepen. Daarnaast is het een mooie oefening om communicatiever te worden, iets wat nooit kwaad kan als techneut.

Om deze blog toch wat waarde mee te geven: mijn oud collega Alex heeft een blog over SiteCore. Check it out!

En om de blog van Dirkie ook te pluggen heb ik via lexxe gezocht op de "what is the next killer application". De uitkomst? Mobiliteit! Dat je het weet!

dinsdag, januari 24, 2006

Puzzelen!

I offer to play a card game with you using a normal deck of 52 cards. the rules of the game are that we will turn over two cards at a time. if the cards are both black, they go into my pile. if they are both red, they go into your pile. if there is one red and one black, they go into the discard pile. we repeat the two card flipping until we've gone through all 52 cards. whoever has more cards in their pile at the end wins. i win if there is a tie. if you win, i pay you a dollar. how much would you pay to play this game?

Dit en nog meer raadseltjes (geschikt voor sollicitatie gesprekken) staan op: http://www.techinterview.org/

maandag, januari 23, 2006

Beslissingen nemen

Het nemen van beslissingen is niet moeilijk. In tegenstelling tot goede beslissingen nemen, dat is ontzettend moeilijk. Of eigenlijk onmogelijk, je kan namelijk nooit met alles weten. Het enige wat je hebt is je gezonde verstand. En daar moet je het mee doen. Wanneer weet je of je een goede beslissing hebt genomen? Achteraf altijd achteraf. Daarom is leren van de geschiedenis zo belangrijk. En stiekem weten we dat allemaal maar toch is het nemen van een beslissing niet zo makkelijk als het bladeren in geschiedenisboeken. En dat komt door ons gevoel.

Een paar maanden terug heb ik een moeilijke beslissing genomen. Ik ben van baan gewisseld. Ik wist wat ik achterliet en ik wist niet wat ik terugkreeg. Ik had een beeld, maar ik wist het niet. We noemen dat gokken: ergens op inzetten waarvan je de uitkomst niet weet. Bij het maken van persoonlijke keuzes kun je moeilijk leren van anderen, iedereen is immers uniek. Daarom heb ik voor mezelf een ander manier van beslissingen nemen. Ik beeld me voor een tijdje in dat ik de beslissing genomen heb, dat houdt ik een paar dagen vol, en kijk dan hou ik me eronder voel. Voelt het goed dan doe ik het, voelt het slecht dan doe ik het niet.

De beste manier om te bepalen of je de juiste keuze hebt gemaakt is terugkijken: zou ik indezelfde situatie weer dezelfde keuze maken?
  • Zou ik weer voor dezelfde vrouw kiezen? JA!
  • Zou ik weer voor het samenwonen kiezen? JA!
  • Zou ik weer voor de universiteit kiezen? Nee!
  • Zou ik weer voor dezelfde auto kiezen? Nee!
En dan komt de moeilijke: zou ik weer kiezen voor een overstap van baan? Ik weet het (nog) niet. Als ik eerlijk ben heb ik de keuze voor de andere baan niet op mijn gevoel gemaakt, maar op mijn verstand. Bang dat mijn gevoel gevoed zou zijn voor de angst voor verandering die ik heb. Ik ben nu bijna 3 maanden werkzaam in mijn nieuwe baan en maak de tussenbalans: ik mis mijn collega's en de sfeer van mijn oude werkplek, ik heb ontzettend veel bijgeleerd hoe je software moet maken.

Maar 1 van de belangrijkste dingen die de laatste dagen door mijn hoofd spookt: Tijdens mijn evalutatie kreeg ik te horen dat ik me meer met dingen mag bemoeien, ik ben te stil. En voor iedereen die met me samengewerkt heeft zal dat een grote verrassing zijn. IK ben namelijk de grootste bemoeial die er is. Zelf schrok ik er ook van, het kan alleen maar betekenen dat ik niet op mijn gemak ben.

Ligt het aan de lange reistijd? Het hoge niveau van het werk? Ligt het aan het feit dat ik als inhuur me niet druk kan maken om het bedrijf? Of zit ik gewoon niet op mijn plek? Heb ik gewoon het verkeerde bedrijf getroffen of is detachering niets voor mij? Ik weet het niet, het werken voelt niet goed, maar het voelt ook niet goed om nu al op te geven. De komende weken/maanden zal het hopelijk allemaal duidelijk worden.

donderdag, januari 19, 2006

Tijd vangen in een foto


Normaal gesproken zijn foto's moment opnames. Een weergave van ruimte op een specifiek tijdstip. Nu kun je leuke effecten bereiken door meerdere foto's na elkaar te maken en die te PhotoShoppen, maar vandaag kwam ik via SlashDot wel op een heel mooi idee uit.

Iemand had het idee om van een simpele Flatbed scanner een 100 mega pixel digitale camera te maken. Maar toen hij de foto's bekeek was het resultaat wel heel bijzonder: in de foto's zat de tijd gevangen. En bewegingen van bijvoorbeeld bussen zijn heel mooi zichtbaar.
Voor meer info en achtergronden: http://www.scannerphotography.com/

Edit: door de drukte vandaag is zijn server plat, hier is een mirror.

dinsdag, januari 17, 2006

Deel 2: Printen in .NET

Ik heb nu zo'n vijf uurtjes werk in mijn "Printing engine" zetten. En ik moet zeggen ik ben best trost op het resultaat. De features die ik nu heb:

* Header en Footer tekst op alle pagina's, inclusief tekst centreren
* Printen van DataTables in kolommen
* Afbreken van DataTables en doorgaan op volgende pagina
* Verschillende breedtes van kolommen bij datatables
* Automatisch uitvullen van kolommen

Wat ik nog wil:
* paginanummering
* Printen key-value pairs in rijen

Wat ook leuk zou zijn maar wat ik niet perse nodig heb:
* ondersteuning van int's, float's etc in datatables (nu zijn alleen strings ondersteund)
* opgave van Font per header regel
* bugfixen zodat table header niet alleen op een pagina komt te staan (afbreek bug)
* totale aantal pagina's berekenen
* ondersteuning voor niet afbreekbare printables (images?)
* ondersteuning voor kolommen die te breed worden voor het scherm
* iets met PODCasts, AJAX of RSS -> dat is in ;)


Zie screenshots!

Ik kan alles beter! (printen in .net)

Echt waar! Ik ben de beste! Het is dat ik geen tijd heb anders had ik heel windows opnieuw geschreven maar dan goed! Ja ik dacht ik vertel het maar gelijk, dat ik de beste ben, anders was je er waarschijnlijk zelf wel achter gekomen over een aantal maanden. En dan kan ik het beter zelf vertellen. Scheelt toch weer tijd!

Het bovenstaande klinkt raar, maar dat is eigenlijk wat je zegt als je weigert frameworks en tools van anderen te gebruiken, puur omdat je te eigenwijs bent of omdat je geen zin hebt om je in te lezen. En daarom verspil je kostbare regels code aan functionaliteit die al bestaat.( 90 euro p/u delen door 90 regels code p/u, uren vallen tegen elkaar weg, 90 euro voor 90 regels is 1 euro per regel. En dan ga ik gemakshalve uit van een gemiddelde van 90 code regels per uur. En volgens mij is dat nog aan de hoge kant en ligt het eerder tegen de 30 regels per uur wat 3 euro per regel code maakt.). Dan wordt eigenwijs zijn ineens erg duur.

Om op het printen in .net terug te komen. Ik ben bezig met een applicatie en in deze applicatie wil ik rapporten kunnen printen. Nu zit daarvoor in Visual Studio een mooie tool: Crystal Reports. Man o Man wat een onvriendelijk programma is dat! Ik heb er beroepshalve mee gewerkt en het is een drama. Vraag het iemand die ermee gewerkt heeft (pas jij maar even 8 rapporten aan :S) en die zal het beamen of is niet goed wijs, of wordt betaald door Crystal Reports om onwaarheden te verkondigen.

Ik wil dus printen en ik wil dus geen gebruik maken van crystal reports. Dus prijsbewust als ik ben ga ik op zoek naar een goede, goedkope reporting engine. En omdat ik voor mezelf aan het werk ben ligt mijn uurprijs erg laag. Naderd nul zogezegd. Het pakket mag dus niets kosten: open source! Daarnaast moet het inleren korter zijn dan de tijd die ik er voor nodig heb om de functionaliteit die ik nodig heb zelf te schrijven( +/- 8 uur) . Ik heb gezocht en gezocht en gezocht. En ik kan dus werkelijk waar niets vinden wat: en .NET, en Open Source en flexibel/eenvoudig genoeg is. Dus dat wordt zelf bouwen...

Om een flexibel systeem te hebben heb ik het volgende bedacht: In principe is afdrukken op papier hetzelfde als afdrukken op het scherm. Met 1 uitzondering: je hebt geen scrollbalken voor als je over de rand gaat. Nu is een scherm met elementen vrij simpel opgebouwd. Je hebt een hoop componenten waar tegen je zegt: teken je zelf in dat gebied van het scherm. Val je buiten het scherm? Teken jezelf dan niet. Val je gedeeltelijk buiten het scherm, teken jezelf dan gedeeltelijk. Simpel he! Hetzelfde kun je ook doen met printen.
1 Zeg tegen het component: teken jezelf, deze ruimte heb je daar voor.
2 Selecteer het volgende component
3 Goto 1.
Simpel! Het enige wat lastig is zijn componenten die niet op de pagina passen: hop naar de volgende pagina! En componenten die maar gedeeltelijk op een pagina passen: teken jezelf gedeeltelijk, de rest gaat naar de volgende pagina.
Daar zul je even moeten rekenen om te bepalen waar de pagebreak komt.

Op deze manier printen is heel simpel. Elk component is zelf verantwoordelijk om zich af te drukken binnen het gebied wat hem toegewezen is. Als hij klaar is geeft hij informatie terug over hoeveel ruimte hij nu eigenlijk ingenomen heeft. Deze informatie wordt weer gebruik om het volgende gebied te kunnen berekenen. Al met al een leuke vingeroefening, flink wat ervaring rijker met printen in .NET. En wie weet misschien kan ik ooit mijn reporting engine verhandelen! Tot die tijd: houdoe!

zondag, januari 15, 2006

Het softwarebedrijf waar ik wil werken.

Al een tijdje volg ik Joel on Software en met veel plezier. Zeker een aanrader voor elke software engineer. Joel is een man, een man met een plan: "Een softwarebedrijf starten waar elke software engineer zou willen werken." En dan vooral hijzelf. Hoe zou zo'n bedrijf eruit zien? Nou voor mij zo:
  • Ruime kamers per persoon, af te sluiten met een deur
  • Leuke, uitdagende opdrachten
  • Leuke gezellige, slimme collega's waar veel van te leren valt
  • Flexible werktijden
  • Eigen verantwoordelijkheid
  • Mogelijkheid tot uitbreiden van kennis
  • Management met maar 1 doel voor ogen: kwaliteit leveren. En daar alles op inricht
  • Korte reistijd
Maar waar vind je zo'n bedrijf? Misschien moet ik toch een micro-ISV worden; een Micro Independent Software Vendor. Een software product op de markt zetten en die via internet gaan verkopen aan je klanten. Hoe start je een micro-ISV? daar heeft Joel een mooie checklist voor gemaakt:

Number One. Don’t start a business if you can’t explain what pain it solves, for whom, and why your product will eliminate this pain, and how the customer will pay to solve this pain.
- CHECK, dat zit wel goed, plannen genoeg voor mooie software producten.

Number Two. Don’t start a business by yourself. If you can’t even convince one friend that your idea has merit, um, maybe it doesn’t?
- MMM, dit gaat moeilijker worden, mijn vrienden hebben mij al vaker plannen horen maken. En die weten ook wat er vaak van terecht komt. Zal moeilijk worden ze te overtuigen.

Number Three. Don’t expect much at first. People never know how much money they’re going to make in the first month when their product goes on sale.
- CHECK, geen probleem. Ik bouw het product in mijn vrije tijd terwijl ik gewoon mijn reguliere baan houdt. En vanuit daar ga ik het uitbouwen en steeds minder werken. Moet te doen zijn!

Nu nog iemand zo gek vinden die samen met me wil beginnen, alleen is ook maar alleen! En dan los (na het trouwen natuurlijk ;) en dan het perfecte bedrijf voor Software Engineers starten. Joel heeft genoeg tips hoe het moet. En over 5 jaar? Over 5 jaar zit ik op de bahama's! ik zie het wel zitten!

Hoe ziet jullie perfecte bedrijf eruit?

vrijdag, januari 13, 2006

.Net File encryption probleem

Ik heb een probleem. Ik heb er natuurlijk meer dan 1. Maar over 1 wil ik het in deze blog hebben.

Ik ben bezig met een applicatie. Deze applicatie berekend de kosten van een product. Een product bestaat uit een aantal artikelen. En deze artikelen hebben een prijs. Om de berekening uit te voeren moet het programma de prijs weten. En om het programma flexibel te houden: ik wil niet bij elke prijswijziging een nieuwe versie van het programma uitbrengen, komt de prijs informatie in een losse file. Alleen: de prijs informatie is gevoelige informatie en mag niet zonder meer in de handen van de concurrentie vallen.

Dus wat doe je dan: je encrypt de inhoud van de file. En je zorgt dat dat file een checksum oid heeft zodat foute decrypts opgemerkt worden. In .NET is dit allemaal geen probleem. Het programma decoded de file en ik kan werken met de gegevens. Voor het decoden heeft het programma de sleutel nodig waarmee het bestand ge-encrypted is.

En hier zit gelijk het probleem. Welke sleutel ik ook kies, en hoe lang hij ook is: hij is beschikbaar in het programma. Ergens staat een regel met: string key = "xjfhdfdsgfjsdgfjdgfhgsdfjgsdj";
En met een simpele decompile is de sleutel zo te vinden. En de gebruiker heeft beschikking over het programma en de DLL's anders heeft het programma weinig nut.

Het enige wat ik kan doen is te zorgen dat het programma niet bij de concurrentie komt en dat ze alleen de files met de prijzen hebben. Anders weet ik het ook niet. Ik kan de code wel obfuscaten maar dan staat er ergens: string ___3773 = "xjfhdfdsgfjsdgfjdgfhgsdfjgsdj". Niet heel erg lastig. Ook kan ik de code in een char array stoppen en wat trucjes mee uithalen. Maar dat is nog steeds valse veiligheid. Aangezien alle code om de key te ontcijferen zoiezo in het programma moet zitten..

Hoe zouden jullie dit oplossen?

dinsdag, januari 10, 2006

Ja, ze wil!

En ik ook! Het hoge woord is eruit: Mijn vriendin en ik gaan trouwen. Deze zomer nog!
En nadat we iedereen het heugelijke nieuws hebben verteld kan ik er nu ook op mijn blog over schrijven ;)

Afgelopen vrijdag zijn we in ondertrouw gegaan. Zelf wonen we in Den Bosch. Eerst moesten we naar Eindhoven stadskantoor om onze geboorteaktes op te halen. Daarna terug racen naar Den Bosch om daar in ondertrouw te gaan. En nadat dat was goedgekeurd konden we weer terug naar Eindhoven om daar een trouwdatum te prikken.

Onderstaand een foto van de mooie trouwzaal in Eindhoven:

zondag, januari 08, 2006

Hoe een kip een muis vangt.


of: wat te doen met oude hardware
Nieuwsgierig geworden door de titel? Lees deze post en alles wordt duidelijk :)

Sinds enige tijd hebben we last van muizen. We wisten er langer dat ze er zaten. s' nachts hoorden we wel eens wat lopen in het plafond en iedereen in de buurt heeft een kat: dat is meestal wel een duidelijk teken. Nu zijn wij (mijn vriendin en ik) in het algemeen vredelievend. Een mug doen we meestal nog wel kwaad, maar veel groter moet het niet worden dus waren we van plan de muizen te gedogen, wat anders kun je doen in een vooroorlogse woning waarbij je niet weet of het jouw muizen zijn of die van die buren?. Dit gedoogbeleid veranderde echter abrupt toen we last kregen.
En last betekent in mijn geval dat mijn vriendin tijdens het ontbijt (6:30 in de morgen) ineens begint te gillen: Muis! Muis! Muis!

Toen was de maat vol en hebben we 2 muizenvallen geplaatst. De volgende dag was het gelijk raak. Hans vs Muizen: 1 - 0. Kort daarna zat ook de 2e muizenval vol. Hans vs Muizen 2 -0!
Dat ging de goede kant op. Trots en voldaan was ik. Dit kon niets anders zijn dan een glansrijke overwinning. Totdat ik vanmiddag tijdens het werken weer door mijn vriendin werd opgeschrikt: Muis! Muis! Muis! En inderdaad er zat een piepklein muisje onder een kastje.
Na flink wat heen en weer geren. Brainstorms over de beste aanpak van het beestje vangen en af en toe gegil van mijn vriendin. Hebben we het beestje uiteindelijk in een hoek kunnen krijgen achter de pc's. Wij daar kijken: beestje weg!

Na veel gezoek bedacht ik me opeens dat de kast vanachter open was en inderdaad het muisje zat in de kast. Voorzichtig de kast onder het bureau vandaan gehaald en via gehannes de muis in een stevige tas gekregen. Wat bleek daarna: er zaten 2 muizen in de computer kast! Ook de 2e muis in de tas weten te krijgen en hup naar het bokjespark hier in de buurt. Mijn vriendin vond het beest ineens schattig (van afstand). Wij naar het bokjespark en onder toeziend oog van een aantal peuter en hun ouders de muisjes vrijgelaten. De 1 muis begon aan een wilde tocht, en na een tijdje was hij uit het zicht verdwenen. De 2e muis heeft 4 seconden in vrijheid geleefd, toen werd hij, onder toeziend oog van alle toeschouwers, doodgepikt door een kip. De ouders waren meer geschokt dan de peuters: "kijk papa! Kip heeft honger!". Nooit geweten dat kippen muisjes opeten...
Hans vs Muizen 4-0

Terug naar huis, na het eten even op de bank tv kijken en verbaasd keek ik op toen ik weer een muisje rond zag scharrelen in huis. Zou het vandaag dan toch 4-1 worden? Na deze muis een tijd genegeerd te hebben dook hij opeens op bij mijn bureau. En niet geheel verrast... Ook hij zat in de computer! Waar oude hardware wel niet goed voor is. Ook deze muis is vrijgelaten, niet in de buurt bij kippen ;) en hopelijk zijn we nu van het ongedierte af. Voor de geinterresseerden nog wat foto's: