Nederlands (NL-nl)English (United Kingdom)
Verslag Rascal workshop
Gepubliceerd door freek   

Dit verslag is geschreven door Jeroen van den Bos (@jvandenbos) . Bedankt Jeroen!

In het indrukwekkende pand van TTY in het hartje van Amsterdam organiseerde Devnology haar tiende maandelijkse bijeenkomst. Het doel deze avond was om de metaprogrammeertaal Rascal te leren kennen door er met z'n allen een aantal problemen mee op te lossen -- de beste manier om een programmeertaal te leren kennen is tenslotte om er iets nuttigs mee te doen.

Jurgen Vinju starte het programma met een korte introductie over de achtergrond van de taal Rascal, waarin hij vooral inging op waar je het nou voor zou kunnen gebruiken. Een belangrijke conclusie is dat het domein van Rascal erg groot is: van software analyse tot de implementatie van refactorings en van grootschalige automatische migratie tot de ontwikkeling en constructie van volledige compilers voor domein-specifieke talen.

Daarna richtte Jurgen zich op praktische details om met Rascal aan de slag te gaan. Om het makkelijk te maken om met de taal te beginnen lijkt de syntax sterk op Java. Vrijwel alle bekende constructies zijn aanwezig, behalve de object-georienteerde, die ontbreken vrijwel volledig. Naast de vertrouwde syntax zijn er dan heel veel functies, zowel in de taal zelf als in de bijgeleverde bibliotheken die de specifieke metaprogrammeertaken vergemakkelijken. Zaken als het automatisch extraheren van feiten uit Java-projecten, ingebouwde ondersteuning voor het visitor-pattern, het simpel definieren en werken met bomen van datastructuren en het visualiseren van allerlei relaties.

Tijd voor actie! Jurgen stelde voor om eerst even de syntax te oefenen door een programma te schrijven dat alle priemgetallen teruggeeft tussen 1 en 100. Een aantal minuten later al waren er diverse oplossingen, waarvan de volgende de uitdrukkingskracht van Rascal goed laat zien:

[p | p <- [1..100], all(i <- [2..p], p != i ==> p % i !=0)]

Het echte werk lonkte: het analyseren van een Java project. Door de functies om allerlei feiten uit een Eclipse Java project te extraheren heb je in een paar statements een flinke dataset tot je beschikking waarmee je door middel van uitgebreide analyses (die veelal qua vorm sterk lijken op de voorbeeldregel hierboven) andere datasets kunt opbouwen. Om uiteindelijk inzicht te krijgen in de resultaten kan dan de visualisatiebibliotheek van Rascal worden aangeroepen, die in veel gevallen via een enkele aanroep een aangeleverde datastructuur omzet in een te kiezen visualisatie, van pie charts en diagrammen tot word clouds of complexere plaatjes.

Het mag duidelijk zijn dat Rascal een speciale domein-specifieke taal is. Waar veel DSLs een zeer beperkte uitdrukkingskracht hebben (vaak om de focus heel smal te houden) is Rascal een zeer omvangrijke en breed inzetbare taal. Dit zorgt ervoor dat de metaprogrammeur zich niet hoeft in te houden in het soort analyses dat hij wil uitvoeren. Het domein-specifieke zit hem hier dan ook duidelijk in alles dat er extra in of bij de taal wordt geleverd. Deze functies zijn puur gericht op het domein van Rascal en zorgen ervoor dat je je niet overmatig hoeft bezig te houden met zaken als data importeren of resultaten visualiseren. Dat gaat allemaal vrijwel vanzelf. Zo kun je al je aandacht richten op het schrijven van effectieve analyses.

Dat deden de Devnology bezoekers dan ook zeer fanatiek, waardoor er flink wat t-shirts zijn uitgedeeld voor het snelst oplossen van een van de opgaven. Uiteindelijke winnaars van de avond waren echter het duo @Rick en @Frank, die het tijdens de bijeenkomst op zich namen om een bug in de Windows-versie van Rascal ter plekke op te lossen.

De presentatie en opgaven van deze avond zijn te vinden op de website van Rascal.

     

 
Follow-up Pacman kata
Gepubliceerd door Arne Timmerman   

Een week geleden werd het kantoor van Marktplaats omgedoopt tot een ware Dojo. In korte iteraties werd er door 19 softwareontwikkelaars in deze Dojo een Kata uitgevoerd, met het einddoel om een werkende Pacman applicatie te bouwen. Wanneer er zo'n grote groep met specialisten werkt aan een gezamenlijke oplossing ontstaat er als vanzelfsprekend discussie over stijl en design van software. Kunnen we de klasse Field niet beter Game noemen? Waarom maken we geen aparte Pacman klassen, die de verantwoordelijkheid kent van de bewegingen van het beestje?

Een tweetal Martial Coding artists hebben de Kata thuis voortgezet in hun eigen favoriete taal, om na te denken over alternatieve oplossingen. Het eindresultaat willen wij jullie niet onthouden. In de oplossing van Eduard kan je zien hoe de oplossing van het probleem wordt vormgegeven in een object-geörienteerd ontwerp, geschreven in Perl, zonder gebruik te maken van Test Driven Development. De uitwerking van Jaap laat zien dat Python zich, net als Ruby, uitstekend leent voor testgedreven ontwikkeling van een bewegend (!) Pacman figuurtje. 

Heb jij een alternatief design voor het 'Pacman probleem', of een leuke oplossing in een andere taal? Laat het weten als reactie op deze post, of stuur een mailtje naar secretariaat@devnology.nl.

 
Verslag Coding Dojo
Gepubliceerd door freek   

Dit verslag is geschreven door Mark Giesen. Bedankt Mark!

Woensdag 6 januari kwamen 19 Martial Coding Artists samen in de Dojo van Marktplaats in Amsterdam. Een perfect bereikbare locatie, tenminste als het niet net was gaan sneeuwen. De volgende dag bleek uit mails en krant dat precies de tijd die wij bij Marktplaats doorbrachten mensen gewoonweg vast stonden op o.a. de A10, rondom ons heen. Wij merkten net wat extra drukte en waarschuwingen bij aankomst, maar nadat wij eenmaal uitgevochten en geborreld waren, waren de wegen ook weer redelijk begaanbaar en had dus alleen de rest van de wereld daar last van gehad.

Eigenlijk kwamen we natuurlijk voor de pizza's en cola en daar was in ruime mate in voorzien van vegetarisch tot carnivorisch, behalve die zonder kaas. Op donderdag hebben nagenoeg alle medewerkers van Marktplaats nog een koude punt als lunch kunnen nuttigen.

Als je denkt dat dit een paar man zijn voor zo'n site-je, think again. Daar zit een grote zaal vol mensen. Van ontwikkelaars tot sales en nog veel meer. Altijd erg leuk om een nieuw bedrijf te kunnen bekijken en dan helemaal zo'n bedrijf dat iedereen kent. Leuk ook om te horen over de wilde plannen met Hadoop, MapReduce en GigaSpaces, bijna jammer dat ik geen Javaan ben.

Nadat wij genoeg hadden van de pizza's zijn we aan de Dojo begonnen. Willem van den Ende, Marc Evers en Rob Westgeest (ofwel de mannen van QWAN) hadden een RandoriKata voorbereid. Eigenlijk een onmogelijke naam, omdat Randori en Kata precies de twee tegengestelde methodieken zijn in Japanse martial arts. Een Kata is een strak gechoreografeerde oefening die heel vaak wordt uitgevoerd waardoor je daar steeds beter in wordt. Randori daarentegen betekent letterlijk "chaos nemen" en staat juist voor de vrijheid van het niet volgen van kata's. Toch is het een goede naam gebleken. Er wordt namelijk een applicatie ontwikkeld in zeer korte iteraties. Deze avond was een iteratie vijf minuten, veel iteratiever kun je het niet krijgen. Iedere iteratie moest er eerst door de man achter de knoppen een falende test geschreven worden die vervolgens door de co-piloot werkend moest worden gemaakt, TDD dus. Zolang er met de test gewerkt werd kon de hele groep invloed uitoefenen op de te bouwen test en dus op de te bouwen functionaliteit. Zodra deze falende test netjes faalde draaide de prioriteit om naar het fixen van de falende test. Over design mocht niet meer worden getwist, alleen over hoe die test zo snel mogelijk werkend moest worden gemaakt. Zodra de vijf minuten om waren werd één van de ontwikkelaars gewisseld en begonnen we weer van voor af aan. Zo zie je goed de Kata: test schrijven en implementeren. Ook Randori was goed te zien in de discussie van de groep en door het steeds wisselen van toetsenist. Dit allemaal met babysteps om het wel binnen 5 minuten af te kunnen ronden. Dit leverde wel wat discussie op. Een babystep is de meest kleine volgende stap richting einddoel. Het lijkt soms alsof je je hoofd moet uitschakelen omdat je het gevoel hebt dat je best weet wat de volgende 3 steps zijn en die wil je in één keer doen. Het consequent doorvoeren levert wel eenvoudige keuzes op, eenvoudig terugdraaien en weinig ingewikkelde discussies. Aan de andere kant bekruipt je toch het gevoel dat je onnodig klein bezig bent en dat het sneller moet kunnen.

Wat leren we hier nu van? Dit was mogelijk de interessantste vraag van de avond. Voor mij persoonlijk was het vooral de taal Ruby. Voor mij bijna volledig nieuw en volgens de kenners van vanavond hebben we alles de revue laten passeren, dus nu ben ik ook een Ruby crack. Ergens in m'n achterhoofd knaagt wat twijfel, maar dat laat ik natuurlijk nooit meer merken. Zolang ik er geen project in hoef te doen.... Vooral het onderdeel "NIET discussiëren" was voor sommigen de grote les van de avond. We hebben het dan niet eens over of ze gelijk hadden of niet, maar over regels kunnen volgen en meningsverschillen inslikken als de tijdsdruk daarom vraagt.

Andere leerden vooral van de verschillende keuzes die mensen maken of dat TDD helpt of juist tegenzit in zo'n omgeving. Voor weer anderen was de Coding Dojo techniek an sich de grote winst en zien ze zichzelf dit gebruiken in hun dagelijks leven om een moeilijk probleem te tackelen of om bepaalde principes in een groep in de vingers te krijgen. Tot slot de Babysteps, voor m'n gevoel zijn die een beetje ondergesneeuwd die avond, maar misschien waren er ook wel veel lessen. Ik ben benieuwd of je dit principe een keer in een echt project een paar weken kan doorvoeren om te zien of het bijdraagt aan snelheid en accuratesse.

Zo heeft iedereen deze avond er wel iets uit gehaald wat van waarde is. Of dat precies is wat de voorbereiders er hoopten in te leggen weet ik niet, maar met zoveel winst mag het in ieder geval een geslaagde avond genoemd worden. Na nog een paar afzakkertjes in bar/restaurant Dauphine zijn we allen weer een stukje slimmer huiswaarts gegaan.


     

De sourcecode voor deze nieuwe Pacman kata vind je terug op http://github.com/mostalive/pacman




 
<< Begin < Vorige 11 12 13 14 15 16 17 18 19 20 Volgende > Einde >>

Pagina 19 van 30

Bijeenkomsten

Prijzen sponsors

JetBrains logo



Foto's

Bekijk alle foto's van Devnology op Flickr.

Waarom bijeenkomsten?

Bijeenkomsten van Devnology zijn erop gericht enthousiaste ontwikkelaars bijeen te brengen om kennis en ervaring uit te wisselen, te discussiëren en te netwerken - geek to geek.

Over ons

Vanuit Devnology willen wij vooral kijken naar concepten binnen software ontwikkeling. Als zich nieuwe ontwikkelingen voordoen zullen we vooral kijken naar het concept erachter en deze in een breed kader van eerdere technieken en/of bestaande platformen plaatsen. Lees meer...