Blonko!

Hier lezen we het triest verhaal van iemand die 2 jaar lang aan een rewrite van een site gewerkt heeft, die van PHP kwam, en dat ze in Rails wilden maken. Een goede programmeur ingehuurd, en beginnen werken. Twee jaar later is de programmeur vertrokken, en heeft de eigenaar zelf in 2 maanden de rewrite gedaan, terug in PHP (van 90k lijnen code naar 12k lijnen; niet slecht ).

Rails is de heilige graal niet. Tuurlijk is rails de heilige graal niet, het is een framework, en lost dus specifieke problemen op, die met een dergelijk framework opgelost kunnen worden. Het is ook geen analist, of een tester, of een programmeur voor jou. Het is een framework. Een stuk software schrijven staat en valt met een goede analyse, en een gerichte aanpak, met voldoende rustmomenten. Ik heb even door de site gelopen, en om hier 2 jaar aan te werken lijkt me heel sterk overdreven. Ik weet natuurlijk niet wat er allemaal achter schuilt.

Op puntje 4 (schaalbaarheid), kan ik enkel maar *zucht* zeggen.

Verder haalt hij aan dat de overgang mooi en geleidelijk is kunnen verlopen. Ik zie niet in waarom dit niet met Ruby of Rails ook kon. De site is duidelijk opgedeeld in verschillende stukken, elk vrij onafhankelijk van elkaar. Aangezien er veel met elkaar moet samenwerken zal er wel iets van documentatie zijn die het gedrag van elke koppeling beschrijft. Deze documentatie leidt naar tests, deze tests leiden naar zekerheid… Qua integratie spreekt Rails perfect XML-RPC, REST en Soap, en is ActiveResource eenvoudig uit te breiden om nog extra “talen” te spreken.

De toon die ik oppik uit het artikel geeft wel aan dat de gebruiker niet echt zich wou schikken naar de Rails-regels. In punt 5 en 6 geeft hij aan dat zijn database niet goed is, dat hij Rails heeft aangepast en dat hij maar niet af wou stappen van de gewoonte om zelf de SQL te schrijven. Als je iets wil gebruiken, dan zal je je moeten schikken naar de regels van het “iets”. De 95-table database had hij via migraties kunnen omzetten naar een model dat geschikter is voor rails, zijn plugins had hij goed kunnen maken via tests, en zijn slechte gewoonte van SQL te willen schrijven… tjah.

Verder haalt hij aan dat hij, mocht hij de software vervangen, hij al zijn personeel (85 man) zou moeten hertrainen. Hmm. Waarom moet dat, als ze de flow/UI gelijk houden?

Het probleem dat ik vooral zie is dat de persoon moeite heeft om af te stappen van de PHP, en waar je zelf wel snel je eigen lib kan voor schrijven voor één project. Wanneer je echter meerdere projecten hebt, allemaal van een andere aard, maar binnen hetzelfde (web), dan is een framework heel handig. Let op, ik zeg niet dat Rails de heilige graal is, dat zeker niet. Maar het zorgt er wel voor dat ik geen SQL meer hoef te schrijven, dat ik een schitterende OO-taal heb om in te werken, en dat ik tests heb leren appreciëren. Maar… zelf schrijf ik ook nog wekelijks PHP, dus zo slecht is het nu ook weer niet .

Je zou denken dat elke persoon die vertoeft op het Internet ondertussen wel weet dat er meer rommel rondgaat dan iets anders. Vandaag kregen we opnieuw een mail in onze mailbox:

Naam: Jean --knip--
Emailadres: j--knip--
Telefoon: 593--knip--
Vraag: Sirs,Madams,
is it true my E-Mail won money at:www.euromillion.be ?
  i'm waiting your response please.
  Thanks

Zoals altijd neem ik de tijd om op deze vragen te antwoorden (veel andere crap blijft gewoon onbeantwoord, maar deze mensen dienen hiertegen beschermd te worden). Hieronder mijn antwoord, het kan als inspiratie dienen voor anderen die hetzelfde probleem hebben:

Hello,

we never sent you any notice about you winning money at euromillion.be; I assume our address was used as the senders address (this is very easy with email). Be aware that there are many fraudulent people using email and the internet to get personal information or money from you, or both.

I assume you were victim to a fraud; I strongly advise you not to answer any emails enqueries about winning money in lotteries you never played in. Always check with the correct authorities (for euromillions, that would be the Française des jeux in France, or Lotto in Belgium).

General rule: if it is to good to be true, it is not true. If you’re in doubt, just use the internet to search for it. I used “email fraud euromillion” on google.be, and it gave me the following result: http://www.consumerfraudreporting.org/sweepsscam_EuroMillion4.php.

Sorry to ruin your day…

Kind regards,
Bernard Grymonpon
Openminds BVBA

Vreemd genoeg krijgen we deze vragen soms enkele malen per maand. Je zou toch denken dat iedereen weet dat dit ofwel niet kan, of slim genoeg is om dat snel even zelf te controleren via een eenvoudige telefoon of een zoekopdracht op google.

De pagina die als eerste hit gevonden werd, had een belgisch GSM-nummer als contactadres. Ik hoop dat de politie hier toch ten minste iets aan doet.

Jaja, we waren weer goed bezig…

Een “vergelijking” tussen Rails en Java. Vrij grappig om te lezen, zeker als je de comments even doorleest. Veel mensen hebben een heel slecht gevoel voor humor; ook al ligt het er vingerdik op.

Een posting over de hele dag, aangezien ik er deze middag niet toe geraakt ben om in een dood moment een posting te maken.

De eerste sessies waren keynotes, en waren ofwel saai (welke ik dus niet gevolgd heb), ofwel heel intressant, zoals “Best Practices”. Er werden enkele technieken en methodes uitgelegd welke je best kan volgen in het programmeren van Rails en Ruby (en eigenlijk in elke OO taal). Zo kwam “skinny controllers, fat models” natuurlijk terug langs, maar waren er ook enkele zaken waarvan we konden zeggen “tiens, da doen we zelf ook”. Handig om te zien dat wat je doet, blijkbaar als een “best practice” gezien wordt, zonder dat je dat op voorhand wist.

De eerste echte sessie ging over “Hydra“, wat eigenlijk gewoon een term is voor het uitsplitsen van je model, en het gebruik van ActiveResource om je data niet enkel lokaal aan te spreken, maar ook bvb data van op derde systemen aan te spreken. Het moet zelfs geen Rails-applicatie zijn aan de andere kant, zolang die maar een bepaalde structuur spreekt wat gemakkelijk te lezen en om te vormen is. Er werd als voorbeeld een Atom-feed gegeven als invoerbron. Deze techniek hadden we al even van ver bekeken, maar nu gaan we deze sterk overwegen om in te voegen in een recent project.

De tweede sessie die ik bijwoonde ging over “slingshot” van Joyent, dat een mogelijkheid biedt om een rails-applicatie zonder enige aanpassing te gaan gebruiken als een desktop-applicatie, en deze de mogelijkheid te geven om te syncroniseren met de centrale applicatie. Er zijn nog wat ruwe kantjes aan, maar het idee is zeker goed, en een goed alternatief voor bvb Flex. Zeker iets om in de gaten te houden, en binnen 6 maand nog eens te evalueren.

De eerste sessie in de namiddag sprak over een Rails-stack, maar daar heb ik amper twee zinnen van gehoord. Het was niet echt intressant, en Jan daagde me uit tot een spelletje Civ4, waar ik gretig op inging (de boog kan niet altijd gespannen zijn).

De tweede namiddagsessie ging over continuous validation, waarbij de testserver de code doorlopend test. Hierboven werd er gebruik gemaakt van een plugin om de pagina’s echt in browsers te laden, en deze dan te gaan testen. Intressant, maar mijn concentratie was niet altijd on-par.

De derde namiddagsessie was ronduit triest. De talk over Presenters leek zeer intressant, maar het enige wat ik te weten gekomen ben is het feit dat Presenters gewoon niet werken. Nobel van de spreker om het toe te geven, maar een sessie van 45 min maar voor 25 min vullen, en niet zeggen wat er fout ging, of wat er allemaal niet goed was aan het idee is ronduit debiel.

De laatste reeks hebben we niet meer bijgewoond, er was niet zoveel intressants, en zo konden we iets vroeger naar het appartement.