|
||||||
|
Trac 0.11 is eindelijk gereleased. Ik denk niet dat we nog nieuwe projecten in Trac gaan doen, maar voor bestaande projecten heeft het misschien wel wat nuttige nieuwe features. Met name de workflow in het ticket systeem is iets waar ik nog naar wil kijken.
Ik kwam een artikel tegen met een soort Ruby versie van Seaside. De code heb ik uitgeprobeerd en op github geplaatst. Het is van een sessie met Avi Bryant, waar hij de Seaside concepten probeert uit te leggen aan de hand van Ruby code. De code en het artikel maken heel duidelijk dat de concepten bijna haaks staan op die van Rails. Op dit moment is Rails vele malen succesvoller dan Seaside, maar dat zegt weinig over wat 'beter' is, omdat Seaside gewoon minder gebruikt wordt vanwege Squeak. In dit infoq artikel zegt DHH wat meer over de verschillen tussen Seaside en Rails. We hebben vandaag het oude kantoor ontruimd in het Post CS gebouw en daarna nog even in Club 11 met elkaar gelunched. We waren er niet vaak, maar ik zal het wel missen. Het uitzicht, de sfeer en feit dat ik een eigen plek had midden in Amsterdam. Ik heb jarenlang dagelijks de metro en/of de trein gepakt op Amsterdam CS en de omgeving is door de jaren heen behoorlijk vertrouwd geraakt waardoor ik mij meteen thuis voelde in Post CS. Een eigen kantoor buiten huis voelde wel goed, je kunt beter een scheiding maken tussen prive en werk. Ik ben niet actief opzoek, maar hou mijn ogen nog wel een beetje open voor een andere leuke kantoorruimte. Bij het zoeken naar een blog engine zat ik eerst te zoeken in de Rails hoek. Typo, Mephisto en Radiant waren alternatieven, maar waarom moest het speciaal Rails zijn? WordPress wordt immers veel meer gebruikt en ondersteund. Het voldoet volledig aan mijn eisen en zolang ik zelf geen code hoef aan te passen, boeit het toch niet in welke taal een applicatie gebouwd is. Dat is tenminste het argument dat we steeds gebruiken als we Ruby on Rails bij een klant aanbieden. Misschien moeten we dit eerst op ons zelf toepassen: keuzes maken op basis van functionele eisen en niet op basis van technologie. Het is wel de eerste PHP applicatie die ik deploy, maar de installatie was vrij simpel. Kwestie van WordPress op de juiste plek uitpakken en een database aanmaken. Daarna het installatie script volgen en je bent online. Ik moet nu wel nog een goed thema uitzoeken. Een van de leuke dingen van WordPress is de hoeveelheid plugins. Dit blog gaat over coderen en het is handig als de code er ook netjes uitziet. Ik kon verschillende syntaxhighlighting plugins uitproberen en heb uiteindelijk gekozen voor codebox. Deze ondersteund in elk geval ook Smalltalk. Voor Google analytics gebruik ik ook een plugin. Met EHT-Graphiz kan ik simpele diagrammen maken in mijn posts. Ik was zeer tevreden met Subversion, totdat we op ons project in alle wijsheid besloten om tegelijk aan twee releases te werken. Als Agile aanhanger ben ik daar niet zo blij mee, je begint pas aan de volgende release als de huidige opgeleverd is, dat houdt het simpel. Het wees me echter wel op de beperkingen van Subversion. Om parallel te kunnen werken hebben we een branch gemaakt in Subversion en hiervoor ook een automated build gemaakt in Teamcity. Ik wilde echter ook alle wijzigingen van main line aan het eind van de dag laten mergen met de branch. De volgende release zal immers ook alles van de huidige release moeten hebben en aangezien er heel veel afhankelijkheden waren, wilde je dat de extra branch zoveel mogelijk up to date was. Maar mergen in subversion is niet triviaal. Je moet zelf bijhouden vanaf welke revisie is gemerged en je krijgt alle wijzigingen in een keer met een algemene commit message. Je verliest dus de informatie over de individuele commits.
[graphviz name=Graph01]
node [
fontname = "Bitstream Vera Sans"
fontsize = 10
];
A -> B -> C-> D -> merged_with_trunk
A-> E -> F -> G -> merged_with_trunk
merged_with_trunk ->H
G -> J
H -> merged_trunk
J-> merged_trunk
[/graphviz]
Een tweede manko van Subversion in ons proces was, dat we eisten dat een commit de build niet breekt. Bij elke commit start het build proces en als testen falen moeten deze meteen gefixed worden. In wezen is dit prima, maar er was een complex stukje code met performance problemen, waar we een beetje met trial en error naar de beste oplossing aan het zoeken waren. Er werd in dit proces heel wat code geschreven en weer weggegooid zonder te committen en hierdoor krijg je aan het eind een grote commit met een algemene commit message. Een gerelateerde beperking is het ontbreken van offline commits. Als je offline bent kun je niet committen en dan krijg je ook weer grote commits met veel wijzigingen en een algemene commit message. Niet handig als je weleens wat in de trein doet. Kleine atomaire commits met een duidelijke commit message vind ik essentieel voor het kunnen onderhouden van de code. Als de tool dit niet in alle situaties mogelijk maakt, moeten we maar eens verder shoppen. De keuze is in wezen al gemaakt door de Ruby on Rails community: Git.
Steeds die verbaasde gezichten en misschien wel tijd om een keer voor eens en voor altijd uit te leggen waarom ik op een Mac werk. Ik ben in elk geval niet de enige. Wat heb ik aan een Mac als software developer? In de eerste plaats heb ik een waslijst aan programmeertalen en tools waaronder:
Deze worden zonder extra kosten meegeleverd en ondersteund, dus ook met patches en security updates. Geen serieuze database, maar ik kan nog wel Oracle, PostgreSQL of Mysql downloaden en installeren. Dit is vooral mogelijk omdat het OS X besturingssysteem gebaseerd is op een Unix kernel. Wel leuk al die tools die ik tot mij beschikking hebt, maar voor wie ontwikkel ik dan mijn software? Hoe krijg ik brood op de plank? Maar de Mac is ook geschikt voor het bouwen van innovatieve web toepassingen, lees: 'the next web 2.0 social network thingy'. Denk aan Digg, Twitter, Wakoopa, Netlog, enz. Linux/BSD is meestal het hosting platform en de mac sluit daar goed op aan. Zelf werk ik aan Ruby on Rails web applicaties voor o.a. webshops en startups. De applicaties hosten we dan op een Linux Debian omgeving. Ik kan natuurlijk ook gewoon software voor het mac platform zelf schrijven. Dit is een kleinere markt, maar het groeit wel gestaag en een niche markt kan ook winstgevend zijn. Heb er nog geen ervaring mee, maar met XCode schijnt het vrij makkelijk te zijn om een goed uitziende applicatie te bouwen. And last but not least: de iPhone en de iPod Touch. Dit is een totaal nieuwe markt waar we nog veel innovatie kunnen verwachten. Heb me al aangemeld voor de iPhone Developers Program en ben benieuwd wat allemaal mogelijk is straks. Maar software ontwikkeling op de mac mag dan hel leuk zijn en niet veel kosten, overstappen heeft wel een prijs:
|
||||||
|
Copyright © 2010 soemirno - All Rights Reserved |
||||||
