kjempekjekt.com

Events i Ruby

Torbjørn — Tue, 09 Mar 2010 05:54:09 +0000

Ruby har ikke events slik som vi er vandt med fra .Net. Det er derimot ikke særlig vanskelig å implementere noe som ligner. Jeg begynte å eksperimentere litt, og her følger en slags log over hva jeg har forsøkt. Jeg har ikke landet på noen “best practice”, og det er heller ikke noe rocket science her - men jeg tror følgende kodesnutter kan være insteressante, særlig om man ikke er så veldig erfaren med Ruby enda.

Iterasjon 1

Jeg ønsker å implementere en Counter-klasse. Den skal ha en metode som heter increment som jeg kan kalle x antall ganger, hvor x er en limit jeg setter. Når limiten er nådd vil jeg at Counter-objektet informerer meg om dette ved å fyre av et event. Her er koden for klassen, samt litt kode som viser hvordan den brukes:

1 class Counter
2 def initialize limit
3     @limit = limit
4     @count = 0
5 end
6 def on_limit_reached= delegate
7     @on_limit_reached_delegate = delegate
8 end
9 def increment
10     @count += 1
11     @on_limit_reached_delegate.call if @count == @limit
12 end
13 end
14
15 c = Counter.new(5) # create a new counter
16 c.on_limit_reached = lambda{ puts ‘Limit reached‘ }
17 4.times { c.increment } # count up to limit -1
18 puts ‘Limit not reached yet‘
19 c.increment # one more time, limit is now reached

Output:

Limit not reached yet
Limit reached

Løsninger er altså at vi lager en closure i linje 16 (også kalt lambda, kodeblokk, anonym metode, etc) som man sender til on_limit_reached= metoden. Counter-klassen tar vare på en referanse til denne closuren. Når limiten er nådd eksekveres den så i linje 11.

Merk at jeg glemte å legge til en test for om delegaten er satt, så koden i linje 11 vil feile om den ikke har noen lyttere (lover å skjerpe meg).

Iterasjon 2

Løsningen i iterasjon 1 støtter bare én lytter – hvis flere legges til vil den bare erstatte den første. Jeg ønsker derfor å utvide Counter for dette, og denne gangen husket jeg å legge til en test for om det er noen som lytter før jeg “fyrer av eventet”:

1 class Counter
2 def initialize limit
3     @limit = limit
4     @count = 0
5 end
6 def on_limit_reached= delegate
7     @limit_reached_delegates ||= []
8     @limit_reached_delegates << delegate
9 end
10 def increment
11     @count += 1
12     if @count == @limit
13       @limit_reached_delegates.each {|d| d.call } if @limit_reached_delegates
14     end
15 end
16 end
17
18 c = Counter.new(5) # create a new counter
19 c.on_limit_reached = lambda{ puts ‘I was informed about limit reached‘ }
20 c.on_limit_reached = lambda{ puts ‘I was also informed about limit reached‘ }
21 4.times { c.increment } # count up to limit -1
22 puts ‘Limit not reached yet‘
23 c.increment # one more time, limit is now reached

Output:

Limit not reached yet
I was informed about limit reached
I was also informed about limit reached

Counter har nå et array av delegater: @limit_reached_delegates. Når limiten er nådd kaller jeg alle sammen. Jeg fikk desverre ikke til å bruke += for å legge til eventer, noe som ville ha virket riktigere for C#-utviklere.

Iterasjon 3

Det er på tide å legge opp støtte for flere eventer; jeg ønsker nå å bli fortalt hver gang telleren inkrementeres, og legger derfor opp en on_increment= metode. Jeg vil også sende med verdien på counteren i eventet.

1 class Counter
2 def initialize limit
3     @count, @limit = 0, limit
4     @event_handlers = {}
5 end
6 def on_limit_reached= delegate
7     (@event_handlers[:limit_reached] ||= []) << delegate
8 end
9 def on_increment= delegate
10     (@event_handlers[:increment] ||= []) << delegate
11 end
12 def increment
13     @count += 1
14     @event_handlers[:increment].each {|d| d.call(@count) } if @event_handlers[:increment]
15     if @count == @limit
16       @event_handlers[:limit_reached].each {|d| d.call } if @event_handlers[:limit_reached]
17     end
18 end
19 end
20
21 c = Counter.new(5) # create a new counter
22 c.on_limit_reached = lambda{ puts ‘Limit reached‘ }
23 c.on_increment = lambda{|count| puts “Counter was incremented to #{count}“ }
24 5.times { c.increment }

Output:

Counter was incremented to 1
Counter was incremented to 2
Counter was incremented to 3
Counter was incremented to 4
Counter was incremented to 5
Limit reached

Jeg har nå brukt en Hash(-tabell) til å holde rede på alle handlerne – denne opprettes i linje 4. Den litt hårete syntaksen på linje 7 og 10 legger inn en ny array for en gitt event-nøkkel om arrayet ikke finnes enda, før den legger delegaten til arrayet. Deretter kan jeg trigge increment-eventet hver gang increment kalles (linje 14). Legg merke til at jeg sender inn @count når jeg kaller delegaten, og kan derfor bruke den i closuren i linje 23.

Iterasjon 4

Det ble litt mye “bråk” i Counter-klassen for å holde rede på event-handlerene i iterasjon 3, og jeg forsøker derfor å trekke ut denne logikken (Single Responsibility Principle). Jeg lager en Ruby-modul som jeg kan mikse inn i Counter (vi kaller det en mixin, som er Ruby’s løsning på multippel arv, noe vi ikke har i .Net). Modulen har nå handler-hashen, og brukes også til å trigge eventene:

1 module Events
2 def add_handler event, delegate
3     @event_handlers ||= {}
4     (@event_handlers[event] ||= []) << delegate
5 end
6 def raise_event event, *args
7     @event_handlers[event].each {|d| d.call(*args) } if @event_handlers[event]
8 end
9 end
10
11 class Counter
12 include Events
13 attr_reader :limit
14 def initialize limit
15     @count, @limit = 0, limit
16 end
17 def on_limit_reached= delegate
18     add_handler(:limit_reached, delegate)
19 end
20 def on_increment &delegate
21     add_handler(:increment, delegate)
22 end
23 def increment
24     @count += 1
25     raise_event(:increment, self, @count)
26     raise_event(:limit_reached) if @count == @limit
27 end
28 end
29
30 c = Counter.new(5) # create a new counter
31 c.on_limit_reached = lambda{ puts ‘Limit reached‘ }
32 c.on_increment do |sender, count|
33 puts “Counter was incremented to #{count}“
34 puts “#{sender.limit - count} left..“
35 end
36 5.times { c.increment }

Output:

Counter was incremented to 1
4 left..
Counter was incremented to 2
3 left..
Counter was incremented to 3
2 left..
Counter was incremented to 4
1 left..
Counter was incremented to 5
0 left..
Limit reached

Jeg valgte også å endre litt på on_increment for å illustrere en annen måte å lage closures på, som nok er mere vanlig i Ruby. I stedet for å bruke lambda-metoden kan jeg nå lage en kodeblokk ved hjelp av ‘do’ og ‘end’ (do og end kan byttes ut med { og } om man foretrekker det). Jeg sender også med selve counter-objektet som et argument til handleren (’self’ i linje 25 tilsvarer ‘this’ i C#), som jeg så kan bruke til å beregne hvor mange increments som gjenstår – fordi jeg har definert en reader for limit-variabelen (linje 13).

Iterasjon 5

En annen approch jeg ville teste ut var å opprette en generisk Event-klasse. Jeg droppet da Events-modulen, selv om jeg kunne ha brukt dem i kombinasjon. I dette eksempelet har jeg sneket inn litt dynamisk evaluering også – se om du skjønner hva jeg gjør på linje 17 og 32.

1 class Event
2 def initialize
3     @handlers = []
4 end
5 def raise *args
6     @handlers.each {|h| h.call(*args)}
7 end
8 def << handler
9     @handlers << handler
10 end
11 end
12
13 class Counter
14 attr_reader :limit
15 def initialize limit
16     @count, @limit = 0, limit
17     events :limit_reached, :increment
18 end
19 def on_limit_reached= delegate
20     @limit_reached << delegate
21 end
22 def on_increment &delegate
23     @increment << delegate
24 end
25 def increment
26     @count += 1
27     @increment.raise(self, @count)
28     @limit_reached.raise if @count == @limit
29 end
30 private
31 def events *attr
32     attr.each {|e| eval(“@#{e} = Event.new“)}
33 end
34 end
35
36 c = Counter.new(5) # create a new counter
37 c.on_limit_reached = lambda{ puts ‘Limit reached‘ }
38 c.on_increment do |sender, count|
39 puts “Counter was incremented to #{count}“
40 puts “#{sender.limit - count} left..“
41 end
42 5.times { c.increment }

(Output som i iterasjon 4)

Jeg håper dette fungerte som eksempler på hvordan man kan kode med events i Ruby, og at du lærte litt underveis. Spørsmål til koden mottas og besvares med største fornøyelse.

Slette/tømme MSMQ-køer med IronRuby

Torbjørn — Sun, 07 Mar 2010 20:44:25 +0000

Utviklingsavdelingen i PSWinCom har akkurat begynt å lære seg Ruby, og jeg har derfor kodet noen scripts som jeg har dokumentert ganske grundig - sånn at det går an å lære noe av å lese dem. Dette er et faktisk IronRuby-script jeg bruker for å slette eller tømme alle private MSMQ-køer på lokal maskin (vi jobber mye med køer, og trenger ofte å rydde opp miljøet).

Så i tilfelle dette kan hjelpe andre – her er koden:

1 =begin
2 This is a comment
3
4 Ruby scans scripts from top to bottom. This means it should make
5 sense when you to read it that way too.
6
7 The scull and bones art is contained in something called a
8 here-document. Google it if you want to know more…
9
10 (I had to escape the backslashes, so it looks a bit off in the
11 source, but the output should be nice.)
12 =end
13 puts <<EOF
14                _______________
15               /               \\
16              /                 \\
17             /                   \\
18             |   XXXX     XXXX   |
19             |   XXXX     XXXX   |           PSWinCom MSMQ IronRuby script
20             |   XXX       XXX   |
21             |         X         |           —————————–
22             \\__      XXX      __/
23               |\\     XXX     /|                  A L L   Q U E U E S
24               | |           | |
25               | I I I I I I I |             —————————–
26               | I I I I I I |
27               \\_             _/            Hope you know what you’re doing
28                 \\_         _/
29                   \\_______/
30           XXX                    XXX
31          XXXXX                  XXXXX
32          XXXXXXXXX         XXXXXXXXXX
33                 XXXXX   XXXXX
34                    XXXXXXX
35                 XXXXX   XXXXX
36          XXXXXXXXX         XXXXXXXXXX
37          XXXXX                  XXXXX
38           XXX                    XXX
39
40 EOF
41
42 =begin
43 The Actions class contains a method for each of the available
44 command line options. To add another option it should be enough
45 to expand this class with a new method.
46 =end
47 class Actions
48 # You create “static” methods (we actually call it class methods)
49 # by applying ’self.’ in front of the method name. Here self refer
50 # to the class, and it could also be written ClassName.method_name.
51 def self.list queue # method named “list”, takes one argument “queue”
52     puts queue.path
53 end
54 def self.delete queue
55     puts “Deleting #{queue.path}..“
56     MessageQueue.delete queue.path
57 end
58 def self.purge queue
59     puts “Purging #{queue.path}..“
60     queue.purge
61 end
62 def self.exit
63     puts “Usage: ir all_queues.rb action“
64     puts “       where action in [list|delete|purge]“
65     Kernel.exit(0) # This is a nice way of ending a script
66 end
67 end # class Actions ends here..
68
69 =begin
70 The rest of the script is not contained in a class. You may feel dirty
71 the first couple of times you do this, but it’s fine - I promise!
72 =end
73
74 mode = $*.shift # get the first command line option passed to this script
75 Actions.exit unless mode # call exit if no mode (if mode == nil)
76
77 =begin
78 Load the .Net dll.
79 This is the only line of the script that will look strange to a normal
80 Ruby-developer that haven’t used IronRuby.
81 =end
82 load_assembly ‘System.Messaging‘
83
84 =begin
85 By including the System::Messaging namespace in this script, I’m able to
86 use the classes in the namespace directly. If I hadn’t done this I would
87 have to use System::Messaging::MessageQueue instead of just MessageQueue.
88
89 Notice that when Ruby was parsing the Actions class, which use the
90 MessageQueue class, the System.Messaging.dll was not jet loaded, and the
91 namespace not yet included. That is fine however - when actual execution
92 enters the Actions class’s queue methods (when the methods are called),
93   the namespace will be there.
94 =end
95 include System::Messaging
96
97 =begin
98 Getting queues. MessageQueue.get_private_queues_by_machine in ruby corresponds
99 to MessageQueue.GetPrivateQueuesByMachine in C#.
100 =end
101 all_queues = MessageQueue.get_private_queues_by_machine(‘.‘) # ‘.’ == local machine
102
103 # Let user know if there are no queues to perform action on
104 puts “No queues available“ if all_queues.length == 0
105
106 =begin
107 The following line is very similar to C#’s List.ForEach(Action action).
108 For each queue I call the appropriate action. I do this by sending the
109 command line option (mode) as a message to the Actions class. The method
110 with the correct name will be called. The second argument will become the
111 argument to the actual method.
112 =end
113 all_queues.each {|queue| Actions.send(mode, queue) }
114
115 puts ‘.‘ # Just an end-of-program indicator

For å for eksempel liste alle køene eksekverer man “ir all_queues.rb list” i kommandolinjen (all_queues.rb er navnet på skriptet og ir er IronRuby). Skriptet benyttes på egen rissiko, jeg tar ikke ansvar for tapte data eller andre problemer som måtte oppstå

Hvilket dynamiske programmeringspråk du skal lære deg

Torbjørn — Thu, 04 Mar 2010 22:14:14 +0000

Sett at jeg har overtalt deg til å lære dynamisk programmering, f.eks. da du leste artikkelen om at du MÅ beherkse et dynamisk språk. Spørsmålet du stiller deg da er: Hvilket språk skal jeg velge? Og jeg hjelper deg gjerne med det også.

Her finner du en oversikt over det som i dag er de mest populære, dynamiske programmeringsspråkene, sammen med mine meninger om hvilke egenskaper de har, og hvorfor du eventuelt skal velge dem. De er sortert etter popularitet – de mest omtalte og brukte språkene er på toppen av listen. Ta gjerne en titt på blogposten om trender innen programmeringsspråk i 2010 om du vil se nærmere på rangeringen.

PHP

PHP er for tiden på tredjeplass i TIOBE’s liste over populære programmeringsspråk. Men for guds skyld – ikke velg PHP til å lære deg dynamisk programmering! Det du gjør i PHP kan du få til i språk som Python og Ruby om du vil, men det fungerer ikke den andre veien. Har du behov for å utvikle i PHP så lærer du deg det i tillegg, men ikke som en erstatning for en orntlig språk. Det er med på denne listen for kompletthets skyld, og kun det.

Mulig jeg ikke vet hva jeg snakker om, men la oss uansett gå raskt gå videre…

Python

Python er et programmeringsspråk som så verdens lys sent på 80-tallet. Python-kode er svært konsis, legger vekt på lesbarhet, og har en syntaks som appellerer til mange utviklere. Det er et objektorientert språk, men støtter også det funksjonsbasert paradigmen. I motsetning til de fleste andre språk legger python betydning i innrykk – man bruker indentering for å angi blokker/programstruktur, og behøver derfor ikke avslutte klasser, metoder osv med “end” eller krøllparantes eller lignende.

Her er en Hello World-klasse i Python, og bruken av den for å skrive ut “Hello, T-Man”. Den kompakte stilen er herlig!

    1 class Greeter:
    2 def hello(self, name):
    3     print ‘Hello,‘, name
    4
    5 g = Greeter()
    6 g.hello(‘T-Man‘)

I tillegg til den vanlige implementasjonen i C, finnes Python også på .Net-plattformen i form av IronPython og på Java-plattformen i form av Jython. Om man behersker Python kan man dermed utnytte dynamisk programmering der også, noe som bør appelere til eksisterende .Net eller Java-utviklere.

Dessuten er Python det primære språket på Google App Engine, så hvis du vil utnytte den plattformen kan det være et lurt valg (selv om App Engine nå også støtter Java-plattformen, inkludert alle språkene som kjører der). Python er mye brukt til webutvikling generelt, og det mest populære rammeverket for denslags ser ut til å være django – The Web framework for perfectionists with deadlines.

Vil du vite mer om Python tar du turen til python.org.

Perl

Da Perl dukket opp i 1987 var det som et skriptspråk for UNIX, og det er kjent for å ha en spesiell styrke når det kommer til prosessering av tekst. Språket har siden utviklet seg en god del, og har influert en rekke andre språk, som f.eks. Python og Ruby. Perl kalles “the Swiss Army chainsaw of programming languages”.

Jeg våger meg ikke på noe eksempel-kode, da jeg aldri har kodet en linje Perl i hele mitt liv. Min oppfatning er at Perl er litt utdatert, men om du har lyst til å ta en titt vil du finne det du trenger på perl.org.

JavaScript

Vi har alle brukt det, om ikke mer så har de fleste av oss i alle fall klippet og limt snutter fra nettet. Men JavaScript er faktisk et spennende, dynamisk språk som brukes til mer enn bare klientside-funksjonalitet i websider. Det finnes en rekke avarter som f.eks. ActionScript i Adobe Flash, JScript på Microsoft-plattformen m.m. Man kan bruke JavaScript som skriptspråk i OpenOffice, og med verktøy som Titanium fra appcelerator kan man lage desktop og mobil-klienter vha HTML, CSS og JavaScript. Men først og fremst er det et språk for å lage dynamiske websider, og det har tatt av på nytt de siste årene nå som browserene begynner å bli bedre og mere kompatible med hverandre.

Det er derimot et litt rotete språk, og derfor ikke noe jeg ville ha valgt for å lære meg dynamisk programmering. Om du er av en annen mening bør du skaffe deg boken JavaScript: The Good Parts og lære det orntlig.

Ruby

Ruby er det språket som har arvet mest fra legendariske Smalltalk, og hevder å være det mest objektorienterte språket man har i dag. Det ble utviklet midt på 90-tallet av Yukihiro “Matz” Matsumoto, og er det programmeringsspråket jeg valgte for å lære meg dynamisk programmering. Matz ville lage et språk uten overraskelser, som skulle være en fornøyelse å bruke – fokuset er flyttet bort fra å programmere for maskinen, og mot å programmere for mennesker.

Ruby on Rails, et rammeverk for høy-effektiv webutvikling, er sansynligvis det som har gjort Ruby så populært som det er i dag, men det finnes et hav av andre verktøy og biblioteker også. Ruby-syntaksen egner seg dessuten godt til å lage domenespesifike språk som kan la seg forstå av mindre tekniske personer, og brukes derfor ofte til embedding.

“Ruby on Rails is an open-source web framework that’s optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.”

Du har sansynligvis allerede sett endel ruby-kode på denne bloggen, men her er et lite eksempel til. Her demonstreres bl.a. at man ikke behøver å deklarere instansvariabler (@name) – det er bare til å begynne å bruke dem, og anta at de er der når man trenger dem.

    1 class Greeter
    2 def initialize(name)
    3     @name = name.capitalize
    4 end
    5 def salute
    6     puts “Hello #{@name}!“
    7 end
    8 end
    9
   10 g = Greeter.new(“world“)
   11 g.salute # Output “Hello World!”

Som Python finnes også Ruby på både .NET-plattformen (i form av IronRuby) og på Java-runtimen (JRuby) i tillegg til den “vanlig” implementasjonen i C.

Er du interessert i Ruby kan du begynne på ruby-lang.org.

Objective-C

Objective-C er en slags blanding av C og Smalltalk, dvs. hardcore, low-level kombinert med elegant og dynamisk objektorientering. Språket har fått sin renessanse på grunn av at det er det primære programmeringsspråket for Apple’s Mac OS X og iPhone OS. Hvis det er din greie kan det sikkert være et spennende språk, selv om mange sier det er litt gammeldags og tungt å jobbe med. Selv synes jeg det ser litt gresk ut :-/

Jeg finner ikke noen kanonisk skilde til Objective-C, men Mac OS X Reference Library har en brukbar introduksjon.

Lua

Lua er et lettvekts, prototype-basert språk som er designet for å være utvidbart. Som JavaScript er mye av inspirasjonen hentet fra Scheme – JavaScript og Lua har derfor mye til felles, selv om syntaksen er ganske anderledes.

Lua har blitt populært fordi det har blitt embeddet som skriptspråk i World of Warcraft og mange andre spill. Hvis du er en gamer kan dette selvsagt være inspirerende, men også om du ønsker å lage programvare som skal være utvidbar og derfor skal hoste sin egen skripting-motor. Lua har god performance, og lar seg bl.a. lett integrere med C++.

Igjen har jeg ingen erfaring med dette programmeringsspråket, og skal ikke prøve meg på no eksempel. For mer info om Lua kan du gå til lua.org.

Groovy

Groovy er et objektorientert, dynamisk språk du finner på Java-plattformen. Version 1.0 ble lansert så sent som i 2007, og det har ikke fått så veldig stor markedsandel enda (plass #40 på TIOBE’s liste). Inspirasjonen er hentet fra Java, Python, Ruby og lignende språk. Blant annet er Java-kode ofte også gyldig groovy-kode (ifølge wikipedia), og man kan bruke alle eksisterende Java-biblioteker i Groovy.

Her er litt kode:

    1 class Greeter {
    2 def name
    3 Greet(who) {
    4     name = who[0].toUpperCase() + who[1..-1]
    5 }
    6 def salute() {
    7     println “Hello $name!”
    8 }
    9 }
   10
   11 g = new Greeter(‘world’)
   12 g.salute()   // Outout “Hello World!”

Her demonstreres bl.a. Ruby/Python-style ranges (slutten av linje 4), dynamisk evaluering av streng mot variablenavn (såkalt interpolering - linje 7) og fullstendig fravær av type-deklarering.

Er du glad i Java-plattformen og vil lære dynamisk programmering kan du ta en titt på groovy.codehaus.org.

Jeg håper og regner med du fant noe som appelerte her. Lykke til med valget!

Du må beherske et dynamisk språk

Torbjørn — Wed, 03 Mar 2010 05:10:17 +0000

Jeg vil si det så sterkt: Hvis du ikke behersker et dynamisk programmeringsspråk, slik at du er i stand til å designe fullverdige software-løsninger i det, da er du ikke en ferdig utdannet utvikler! [1]

Det har vært mye buzz rundt dynamiske språk de siste årene, og mange utviklere, spesielt i Agile-miljøer, migrerer over fra statiske språk til dynamiske. For å forstå hvorfor dette skjer er det viktig å vite hva vi mener med et dynamisk språk, og hvilke fordeler og ulemper det bringer med seg. Denne artikkelen er en god start for deg som ikke vet så alt for mye om temaet.

Hva mener vi med Dynamic?

Når vi sier at noe er STATIC mener vi at ting er definert og avgjørelser tas ved compile-time, mens DYNAMIC impliserer at det samme skjer i runtime. Det er derimot ingen språk som er fullstendig statiske, og heller ingen som er fullstendig dynamiske – de fleste språk befinner seg et sted mellom disse ytterpunktene.

Egenskaper som gjør et språk dynamisk er ting som dynamisk typing, dynamisk dispatch, introspection, dynamisk kompilering og dynamisk loading. I språk som er mer dynamiske kan man f.eks. gjøre ting som å endre hvordan typer ser ut – legge til metoder o.l. - mens programmet kjører.

De dynamiske spåkene begynte for alvor å vokse frem på 80-tallet – og språk som Larry Wall’s Perl og Guido van Rossum’s Python hadde stor betydning for internetts vekst på 90-tallet. De dynamske egenskapene hadde derimot en ulempe: Dårlig performance! Grunnen til at de dynamiske språkene har blitt mer populære de siste 10 årene er at vi nå har fått raskere og bedre maskinvare, som gjøre at vi i mange sammenhenger kan se bort fra at programmene kjører noe tregere relativt til kompilert, statisk kode.

Mange språk utvikler seg i dynamisk retning

Programmeringsspråk utvikler seg hele tiden. De som ikke gjør det er i praksis døde. Og samtidig som dynamiske språk som Perl, Python og Ruby har blitt mer populære, har andre språk beveget seg i en mer dynamisk reting.

C# har for eksempel en rekke dynamiske egenskaper. Du lager dynamiske programmer om du bl.a. benytter deg av reflection (introspection). Det er bare det at reflection er mye enklere i språk som i utgangspunktet er designet for det. Generics er også en nokså dynamisk feature, som gir inntrykk av løsere typing i koden. Type inference – bruk av “var” – gir C# en dynamisk følelse. Og sist men ikke minst innfører man i .NET 4.0 Dynamic, en type hvor metodekall ikke evalueres før runtime (dynamic dispatch), slik at C# bedre kan kommunisere med mere dynamiske språk.

Ved å beherske et dynamisk språk vil man lære seg teknikker som gjør en til en bedre utvikler også når man jobber i mere statiske språk.

PS: Det dynamiske språktreet er ikke komplett, men viser de mest sentrale språkene, og hvordan de i hovedsak har påvirket hverandre.

Fordeler ved dynamiske språk

Jeg mener vi må innse at både statiske og dynamiske språk er viktige. Statiske språk gir en høy grad av kontroll – det er lettere å analysere koden og forutse hva som vil skje i runtime. Det er derimot vist gjentatte ganger at dynamiske språk gjør deg mere produktiv; man kan implementere mer funksjonalitet raskere, og med mindre kode.

Dynamiske språk er også mer fleksible, smidige om du vil, og egner seg til problemer hvor løsning i utgangspunktet er ukjent. Flere velger derfor å prototype i dynamiske språk, for så å implementere endelig løsning i et mere statisk språk om performance og sikkerhet er viktig.

En annen ting man oppdager når man går fra statisk til dynamisk programmering er at skillet mellom data og kode opphører – data og funksjonalitet smelter bedre sammen. Det er litt vanskelig å forklare dette uten et dypdykk, så jeg tror det må bli en fremtidig blogpost.

Et siste område hvor dynamiske språk egner seg spesielt godt er embedding. Sett at du skal utvikle et system hvor det meste skal være fast, og egner seg for et statisk språk. Men du ser at det kan bli behov for å kunne endre visse forretningsregler etter at systemet er tatt i bruk. Tradisjonelt vil man forsøke å forutse disse endringene, og lage et innfløkt konfigurasjonssystem for å dekke behovet. I stedet kan man utvikle selve systemet i C#, men kode forretningsreglene i et dynamisk språk. Den dynamiske koden vil evalueres når den behøves, og kan når som helst endres og utvides uten at man behøver å rekompilere og publisere en ny versjon.

I ytterste konsekvens kan man eksponere et API internt i applikasjonen som de dynamiske kodesnuttene kan få tilgang til – man har da laget et scriptbart system, og man kan lene seg tilbake og se på mens tredjepartsutviklere utvider funksjonaliteten i systemet ditt i retninger du selv ikke kunne ha forrutsett.

Er dynamisk kode bedre enn statisk?

Det kan hevdes at dynamiske språk oppfordrer deg som utvikler til å skrive bedre kode. Et sentralt poeng er at man ikke har en kompilator å støtte seg på, og viktigheten av enhetstester er derfor mye større. I “de dynamske miljøene” er man også mer opptatt av eleganse og enkel kode. Gjennom å praktisere dynamisk kode vil du øke forståelsen av hva kvalitet er for noe, og det vil forbedre din statiske kode også.

Den andre siden av dette er at man ikke lenger har tilgang på mange av de verktøyene man har vendt seg til som f.eks. C#-utvikler: intellisense, god refakturerings-støtte, statisk analyse osv. Visual Studio, ReSharper o.l. gjør oss produktive, og det er en viss overgang å ikke ha disse lengre – man kan føle seg litt naken en stund.

Videre lesing

Til slutt har jeg funnet frem et par “research papers” for dem som er interessert i utviklingen av dynamiske språk.

The End of the Cold War Between Programming Languages:
“Static typing is a powerful tool to help programmers express their assumptions about the problem they are trying to solve and allows them to write more concise and correct code. Dealing with uncertain assumptions, dynamism and (unexepected) change is becoming increasingly important in a loosely couple distributed world. Instead of hammering on the differences between dynamically and statically typed languages, we should instead strive for a peaceful integration of static and dynamic aspect in the same language. Static typing where possible, dynamic typing when needed!”

On the Revival of Dynamic Languages:
“The programming languages of today are stuck in a deep rut that has developed over the past 50 years. Although we are faced with new challenges posed by enormous advances in hardware and internet technology, we continue to struggle with old-fashioned languages based on rigid, static, closed-world file-based views of programming.”

Fotnote:
[1] Jeg hevder ikke at jeg vet når du kan kalle deg ferdig utdannet - bare at det å beherske et dynamisk språk må inngå i den definisjonen. Joe Armstrong, utvikleren av Erlang, sier f.eks. at det tar 30 år å lære å programmere (i boken Coders at Work).

Referanse:
Randal exploring dynamism (InfoQ)

Jeg, Polyglot

Torbjørn — Tue, 02 Mar 2010 06:02:03 +0000

WikiPedia: Polyglot - someone who aptly and with a high level of fluency uses many languages.

Her skulle du nå ha lest en lengre artikkel om betydningen av å lære mange, ulike programmeringsspråk, men det viser seg at Live Writer hadde bestemt seg for å spise opp den teksten. Her er derfor selve essensen:

Da jeg for over et år siden begynte å for alvor ta tak i min egen utvikling, hadde jeg en lang liste med rammeverk, biblioteker og teknologier jeg ønsket å lære meg – som WCF, WPF, WF, NHibernate, CSLA.NET, nServiceBus m.m. Dette endret seg derimot raskt – min forståelse av hva som er viktig ble mere moden – og jeg begynte i stedet å fokusere på basis-ferdigheter som god objektorientering og testdreven utvikling.

Jeg begynner nå å ane hva neste steg blir; jeg har nemlig blitt veldig opptatt av språk og programmeringsparadigmer. Jeg har begynt å forstå hvorfor erfarne utviklere hevder at man hele tiden må lære seg flere programmeringsspråk. Jeg har også begynt å se hvor mye det er å lære av historien vår. Dette markerer en endring i hva jeg er opptatt av, og jeg spår at det vil komme flere blogposter om språk-relaterte tema her fremover.

Selv om jeg har vært borti mange språk og teknologier siden jeg kodet min første if i AMOS BASIC, har mitt fokus de siste åtte årene utelukkende vært C# og .Net-plattformen. Det er for snevert for en profesjonell utvikler. Mens slagordet mitt i 2009 var “.Net Ninja” har jeg i år bestemt meg for å bli en polyglot, en som behersker en rekke, ulike språk. Jeg tror det vil gi meg en dypere kunnskap om programmering, og gi meg en allsidighet som vil gjøre meg bedre i praksis også.

.Net-nyheter fra Bergen

Torbjørn — Sun, 28 Feb 2010 21:19:33 +0000

Som vanlig skjer det mye i .Net-miljøet i Bergen. Her er noen høydepunkt akkurat nå..

Mark Nijhof, styremedlem i NNUG Bergen, annonserte på bloggen sin fredag at han slutter i Reaktor og starter sitt eget firma: Cre8tive Thought. Mark er kjent for å ha sterke meninger, og er opptatt av software craftsmanship-verdier. Han legger opp til å både ta utviklingsoppdrag (enten som utvikler eller teamleder) og coaching-oppdrag. Hvis du ønsker at teamet ditt skal bli litt mere smidig, så kan du f.eks. leie inn Mark til å hjelpe dere til å ta i bruk parprogrammering, få bedre utbytte av testdreven utvikling, eller ta en gjennomgang av arkitektur og design, og vurdere om koden er fleksibel nok i forhold til endringer.

Styrelederen i NNUG Bergen, Jon Arild Tørresdal, har også ting på gang. Han er nemlig med som foreleser på vårens MSDN Live, og vil informere folk i Stavanger, Bergen, Trondheim og Oslo om Windows Identity Foundation. MSDN Live kommer til Bergen 23. april, og vil også omhandle Azure, SharePoint 2010, TFS og SIlverlight 4.

Skal du på QCon London – og det er bare en drøy uke igjen nå – så må du melde deg på den sosiale kvelden NNUG Bergen har stelt i stand på torsdagen. Vi inviterer alle som har lyst til å bli med på en uhøytidelig samling på en lokal pub, hvor du vil få anledning til å spandere øl og snakke med blant andre Corey Haines, Udi Dahan, Dan North, Oren Eini (a.k.a. Ayende Rahien) og Jon Skeet. Dette er en Unik Mulighet – for hvor ofte får du mulighet til å diskutere med en av verdens fremste .Net-arkitekter, mannen bak Behaviour-Driven Development, geniet bak RhinoMocks, og den mest kjente StackOverflow-brukeren på en og samme kveld? For ikke å snakke om den sympatiske Corey, som for tiden er selve personifiseringen av Software Craftsmanship.

Udi Dahan kommer forresten til Bergen i april, og vil holde foredrag for NNUG’s medlemmer siste onsdagen i måneden (medlemskap er fortsatt uforpliktende og gratis). Deretter har vi overtalt ham til å holde et todagers kurs om SOA og DDD – det er trolig fortsatt ledige plasser om du vil være med..

Det har forresten vært endel snakk om at selveste Kent Beck muligens kommer til Bergen i mars, også han for å besøke NNUG og kanskje holde et kurs. Og jeg har ikke hørt noe annet enn at dette fortsatt er planen. NNUG hadde et stjernespekket år i fjor, men 2010 ser sålangt ikke ut til å bli noe dårligere. Følg med på nnug.no.

En agurktest

Torbjørn — Wed, 24 Feb 2010 07:30:07 +0000

Om du ikke har levd under en stein det siste året så har sansynligvis hørt om Aslak Hellesøys Cucumber.

“Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid - all rolled into one format.“

“Cucumber works with Ruby, Java, .NET, Flex or web applications written in any language. It has been translated to over 30 spoken languages.“

Men du har kanskje ikke testet det selv? Jeg tenkte derfor jeg kunne gjøre en rask demonstrasjon ved å skrive en akseptansetest for tjenesten jeg lagde i blogpostene om en minimal http-server i .Net / Ruby. Normalt vil man selvsagt beskrive featurene først, og så implementere dem og bruke cucumber til å bevise at de fungerer, men for enkelhets skyld tester jeg her altså min eksisterende tjeneste. Det spiller forøvrig ingen rolle om jeg tester .Net-varianten eller Ruby-varianten – jeg vil la akseptansetesten aksessere tjenesten direkte over http, og da er jo grensesnittet uansett det samme.

Det første jeg må gjøre er å beskrive tjenesten i form av en feature med tilhørende scenarier. Virker dette litt gresk anbefaler jeg at du leser deg litt opp på Behaviour-Driven Development (BDD).

File: features\add_service.feature:

1 Feature: Add-service
2 In order to save cycles on client CPUs
3 As an IT manager
4 I want a central server that can add numbers
5
6 Scenario: Add a string of numbers
7     When I send 9,11,33,100 to the add service
8     Then the response should be “The answer is 153″
9
10 Scenario: Add a single number
11     When I send 1 to the add service
12     Then the response should be “The answer is 1″

Feature-filen er input til cucumber, som vil analysere stegene i scenariene og forsøke å eksekvere dem. Men foreløpig skjønner cucumber lite, så vi må skrive litt kode for å definere stegene.

File: features\add_service_steps.rb:

1 require ‘open-uri‘
2 require ‘spec/expectations‘
3
4 When /I send (.*) to the (.*) service/ do |argument, service|
5 open(“http://127.0.0.1:4567/#{service}?#{argument}“) do |response|
6 @data = response.read
7 end
8 end
9
10 Then /the response should be “([^\”]*)“/ do |expected|
11 @data.should == expected
12 end

Sånn, det er alt som trengs. Jeg lager et “When I send X to the Y service”-steg som gjør en forespørsel til tjenesten min og sender de definerte argumentene. Cucumber tar seg av å bytte ut X og Y med argumentene og navnet på tjenesten. “Then the response should be Z”-steget gjør en assert mot det forventede svaret som er beskrevet i scenariene.

Legg merke til at det er to forskjellige DSL’er (domenespesifike språk) i bruk her – en ekstern DSL for å definere features, og en intern Ruby-DSL (intern som i “er gyldig ruby-kode) for å definere stegene.

Når jeg kjører cucumber nå får jeg følgende output:

C:\Users\tormar\ruby_projects\httpListener>cucumber

Feature: Add-service
        In order to save cycles on client CPUs
        As an IT manager
        I want a central server that can add numbers

Scenario: Add a string of numbers
When I send 9,11,33,100 to the add service
Then the response should be “The answer is 153“

Scenario: Add a single number
When I send 1 to the add service
Then the response should be “The answer is 1“

2 scenarios (2 passed)
4 steps (4 passed)
0m0.122s

Alle scenariene for Add-servicen passerte (hvis ikke hadde det dukket opp endel rødt i output). Kult?

Hvis du er alergisk mot Ruby så finnes det også et prosjekt som heter SpecFlow som er en port av cucumber til .Net. Men det er absolutt å anbefale å benytte the real thing, gjerne med IronRuby på .Net-plattformen.

En minimal http-server i Ruby

Torbjørn — Mon, 22 Feb 2010 07:46:04 +0000

I denne oppfølgingsposten til En minimal http-server i .Net viser jeg hvordan jeg raskt kan sette opp en tilsvarende løsning i Ruby. Jeg skal altså implementere en tjeneste som lytter på http, og som responderer på ulike argumenter. Løsningen skal være enkel å utvide med flere “respondere” – det skal ikke være nødvendig å editere eksisterende kode for å håndtere nye typer forespørsler (se forrige post om du vil vite mer om oppgaven).

Ruby shipper med mange, nyttige moduler - blant annet en søt, liten tjeneste som heter WEBrick, som kan brukes ganske likt som .Net’s HttpListener egentlig. I følgende program setter jeg opp en server til å lytte på port 8081:

   1 require ‘webrick’
   2 include WEBrick
   3 
   4 #DSL method for defining responders
   5 def respond_to config
   6     key = config[:key]
   7     $server.mount_proc(key) do |request, response|
   8         response.body = yield request.query.to_s
   9     end
   10 end
   11 
   12 def load_responders
   13     responder_definitions = Dir.glob(”*.responder”)
   14     responder_definitions.each { |d| load d }
   15 end
   16 
   17 $server = HTTPServer.new( :Port => 8081 )
   18 load_responders
   19 trap(”INT”) { $server.shutdown }
   20 $server.start

Servicen opprettes i linje 17, og i neste linje kaller jeg en metode jeg har kalt load_responders. Den henter alle filer med .responder extension, og kjører innholdet. Responder-filene i sin tur benytter respond_to metoden definert fra linje 5 til å konfigurere WEBrick.

Sidenote: Jeg implementerte først en løsning med en SimpleHttpServer-klasse og en klasse for å representere respondere. Etter å ha tenkt meg litt om så jeg derimot at det bare ble en masse stafasje, og at koden ikke kommuniserte så veldig godt hva den gjorde. Enkelhet er et av de viktigste budene for smidige utviklere, og Ruby lar meg skrelle bort ganske mye. Så etter å ha slettet 30 linjer kode følte jeg meg mer komfortabel. Om du vil se en mere objektorientert løsning kan du ta en titt på Building a DSL in Ruby, part II fra bloggen Technology as if People Mattered, som var en viktig inspirasjonskilde til denne bloggposten.

Nedefor er responder-filen for add-tjenesten. Se forrige post for å se hvordan denne responderen ser ut i .net. Som du kanskje ser er dette rett og slett et kall til respond_to. Som argument til metoden sendes nøkkelen “/add”, som er det responderen skal håndtere (ref bruk av attributtet RespondTo i .Net-løsningen). Resten er en kodeblokk som tar som input argumentene fra requesten, og returnerer et svar. Denne kodeblokken brukes til å håndtere forespørselen (magien ligger i “yield” i linje 8 i programmet over).

   1 respond_to :key => “/add” do |arguments|
   2     sum = 0
   3     numbers = arguments.split(’,')
   4     numbers.each { |n| sum += n.to_i }
   5     “The answer is #{sum}”
   6 end

Koden i denne responderen er litt C#-ish, jeg har gjort nøyaktig det samme som jeg gjorde i C#-varianten, bare oversatt det til Ruby. For å gjøre den mere rubyesque benytte vi et par array-metoder som Ruby har arvet fra SmallTalk: map (som egentlig er en alias fro collect, men jeg liker map bedre) tar et array, kjører en gitt transformasjon på hvert element (i dette tilfellet eksplisit konvertering til integer), og returnerer et nytt array med resultatet. Dette føles nok ikke så fremmed for .Net-utviklere lengre, nå som vi har vendt oss til Linq, som tilbyr samme funksjonalitet via Select-metoden.

Det andre trikset er metoden inject. Den kan brukes til å “samle informasjon” fra et array, i dette tilfellet summen av alle argumentene. Dermed kan spesifikasjonen av add-responderen modifiseres til å se slik ut:

   1 respond_to :key => “/add” do |arguments|
   2     numbers = arguments.split(’,').map {|arg| arg.to_i}
   3     “The answer is #{numbers.inject {|x,n| x+n }}”
   4 end

Resultatet er altså at jeg på 20 linjer har satt opp en dynamisk webserver som jeg kan utvide ved å legge til flere .responder-filer. Definisjonen av hver responder er veldig konsis og grei, og står på ingen måte tilbake for .Net-løsningen. I Ruby har jeg ikke behøvd å definere interface for respondere, og lastingen av dem – som er basert på fil-extension i stedet for refleksion og attributter – er mye enklere. Når du tar med i betraktning at jeg ikke engang behøver å kompilere Ruby-løsningen, så er det ikke vanskelig for meg å foretrekke denne når jeg får behov for å raskt sette opp web-tjenester av ulik art f.eks. for å simulere tjenester jeg skal integrere mot.

Sinatra entrer scenen

Å bruke WEBrick til dette her er ganske “low level” (på samme måte som HttpListener var det). I .NET-verden har vi rammeverk for webutvikling på et høyere nivå som blant andre WebForms, ASP.NET MVC, FubuMVC og MonoRail (det er egentlig alle jeg vet om). Ruby har også dette; det desidert mest kjente er Ruby on Rails, som gjør deg ekstremt produktiv så sant du er villig til å følge Rails konvensjoner og måter å gjøre ting på. Ramaze er et rammeverk med mye større frihet, hvor man kan velge mellom et hav av moduler og måter å gjøre ting på. Begge disse baserer seg i hovedsak på Model-View-Controller paradigmet.

Sinatra er et tredje ruby-biblotek som er ganske nyttig til å utvikle mindre websider og tjenester. Det minner mye om det jeg har gjort i denne artikkelen, og ved å bruke Sinatra kan jeg forenkle tjenesten min ganske mye (som om den ikke var enkel nok allerede).

Sinatra-versjonen av selve tjenesten min ser slik ut:

   1 require ’sinatra’
   2 Dir.glob(”*.responder”).each { |d| load d }

Ved å inkludere sinatra-bibloteket startes automatisk en webserver. Det eneste jeg da trenger er å dynamisk laste alle responder-filene. Jeg har slått sammen linje 13 og 14 fra det orginale skriptet, og står dermed igjen med én require og én kodelinje.

Responder-filen ser nesten ut som tidligere, men kallet til respond_to, som jeg selv definerte, har vi nå et kall til sinatras get-metode (’get’ som i REST-metoden get):

   1 get “/add” do
   2     numbers = params.to_s.split(’,').map {|arg| arg.to_i}
   3     “The answer is #{numbers.inject {|x,n| x+n }}”
   4 end

Dermed har jeg gått fra 24 til 6 linjer. Det er latterlig lite!

Og den tilsvarende C#-løsningen fra forrige post var på over 170 linjer. Det finnes selvfølgelig mere optimale løsninger, men jeg har vært en C#-utvikler i åtte år, og 170 liner ++ var det jeg havnet på. Jeg har vært Ruby-utvikler på hobbybasis i et par måneder, og landet på 6 linjer. Det MÅ jo si noe om Ruby og dynamisk programmering!

En minimal http-server i .Net

Torbjørn — Thu, 18 Feb 2010 09:32:54 +0000

.Net-rammeverket er fullt av moduler for å lage webtjenester; du kan bruke WebForms eller ASP.NET MVC, SOAP web services eller WCF, RIA services eller Astoria data services, alt etter dagsform og hvilket behov du har. Noen ganger kan det derimot være greit å vite hvordan man på aller enklest måte kan lage en http-basert server. I Chrome-vinduet under ser du hvordan jeg aksesserer en “no-fuss” service som kan fortelle meg hva klokka er…

I denne artikkelen presenterer jeg den ikke så veldig godt kjente klassen HttpListener (i System.Net namespacet), og viser hvordan man enkelt kan bruke den til å lage en slags webserver. Denne teknikken kan være aktuell om man f.eks. skulle trenge å raskt mocke opp noen webservicer som ikke følger de vanlige standardene, eller om man skal lage moduler som kommuniserer over http med en proprietær protokoll.

Men jeg har mer på lur: Http-serveren jeg presenterer her er designet for å være utvidbar, og bruker derfor STRATEGY PATTERN i håndteringen av forespørslene. Du vil også få se hvordan jeg kombinerer attributter og reflection for å kunne dynamisk legge til ny adferd uten å måtte editere eksisterende kode.

Her følger selve server-klassen: SimpleHttpServer. Det sentrale skjer i linje 30 til 33, hvor jeg oppretter en HttpListener, registrerer adresse og port for lytting, og starter å lytte. Dette tilsvarer mer eller mindre hvordan Internet Information Server (IIS) selv registrerer seg for lytting mot operativsystemet.

    9 public class SimpleHttpServer
   10 {
   11     private string _address;
   12     private int _port;
   13     private ResponderFactory _dispatcher;
   14     public SimpleHttpServer(string address, int port, ResponderFactory dispatcher)
   15     {
   16         _port = port;
   17         _address = address;
   18         _dispatcher = dispatcher;
   19     }
   20 
   21     private HttpListener _httpListener;
   22     public void Start()
   23     {
   24         StartHttpListener();
   25         while (true)
   26             WaitForRequestThenHandle();
   27     }
   28     private void StartHttpListener()
   29     {
   30         _httpListener = new HttpListener();
   31         _httpListener.Prefixes.Add(
   32             String.Format(“http://{0}:{1}/”, _address, _port));
   33         _httpListener.Start();
   34     }
   35     private void WaitForRequestThenHandle()
   36     {
   37         var incomingRequestContext = _httpListener.GetContext();
   38 
   39         ThreadPool.QueueUserWorkItem((state) =>
   40         {
   41             try
   42             {
   43                 var context = state as HttpListenerContext;
   44                 var url = context.Request.Url;
   45                 var encoding = context.Request.ContentEncoding;
   46 
   47                 var result = _dispatcher
   48                     .GetResponder(GetCommandKey(url, encoding))
   49                     .RespondTo(GetCommandArguments(url, encoding));
   50 
   51                 Respond(context, encoding, result);
   52             }
   53             catch (Exception ex)
   54             {
   55                 // Don’t want the service to die, just log it..
   56                 Console.WriteLine(ex.ToString());
   57                 // Could then responde with some error code…
   58             }
   59         },
   60         incomingRequestContext);
   61     }
   62 
   63     private static string GetCommandKey(Uri url, Encoding encoding)
   64     {
   65         // AbsolutePath always starts with a ‘/’
   66         return HttpUtility.UrlDecode(url.AbsolutePath.Substring(1), encoding);
   67     }
   68     private static string GetCommandArguments(Uri url, Encoding encoding)
   69     {
   70         // Query always starts with a ‘?’, but may be null
   71         return url.Query != null && url.Query.Length > 1
   72                         ? HttpUtility.UrlDecode(url.Query.Substring(1), encoding)
   73                         : string.Empty;
   74     }
   75     private static void Respond(HttpListenerContext context, Encoding encoding, string result)
   76     {
   77         var bytes = encoding.GetBytes(result);
   78         context.Response.ContentLength64 = bytes.Length;
   79         context.Response.OutputStream.Write(bytes, 0, bytes.Length);
   80         context.Response.StatusCode = 200; // everything is ok  
   81         context.Response.Close();
   82     }
   83 }

Etter å ha opprettet HttpListener kjører jeg en uendelig løkke som mottar innkommende forespørsler og håndterer dem (en robust implementasjon ville også hatt en Stop-metode som terminerte løkken). Kallet til GetContext() i linje 37 returnerer når en request mottas, og så bruker jeg ThreadPool til å spawn’e en ny tråd som håndterer den og svarer tilbake.

Denne serveren bruker selve URL’en til å avgjøre hva den skal gjøre. I eksempelet i starten av artikkelen var requesten http://127.0.0.1:8081/time?. Alt etter domenet og porten men før spørsmålstegnet bruker jeg til å avgjøre hvilken Responder som skal brukes. Det er her STARTEGY pattern kommer inn i bildet – en responder er en klasse som implementerer interfacet Responder…

    5 public interface Responder
    6 {
    7     string RespondTo(string arguments);
    8 }

    5 public interface ResponderFactory
    6 {
    7     Responder GetResponder(string responderKey);
    8 }

Argumentene som sendes til responderen er alt som kommer etter spørsmålstegnet i requesten. HttpListener støtter mye mer enn dette, men alt jeg er interessert i denne gangen er selve URL’en.

SimpleHttpServer ble initialisert med en ResponderFactory. Denne vil - gitt en nøkkel - returnere riktig responder. Ta en titt til på serveren om du ikke fikk det helt med deg første gangen, spesielt linje 47 til 49.

En første versjon av ResponderFactory (den faktiske implementasjonen kommer lengre nede) kunne vært en klasse som uansett nøkkel returnerte en UnknownCommandResponder:

    5 public class UnknownCommandResponder : Responder
    6 {
    7     private string _request;
    8     public UnknownCommandResponder(string request)
    9     {
   10         _request = request;
   11     }
   12     public string RespondTo(string arguments)
   13     {
   14         return String.Format(“Unknown command: ‘{0}’ with arguments ‘{1}’”, 
   15             _request, 
   16             arguments);
   17     }
   18 }

Det kan være greit å ha en slik default strategi/responder til å svare på alle mulige ting man måtte finne på å etterspørre. Her ser du den i aksjon:

Opprette flere tjenester: Attributter og reflection

Før jeg legger til den første “fornuftige” responderen oppretter jeg et .net-attributt. Det trenger ikke være noe mer avansert enn å lage en klassen som arver fra Attribute.

    6 public class RespondToAttribute : Attribute
    7 {
    8     public string Key { get; set; }
    9     public RespondToAttribute(string key) { 
   10         Key = key; 
   11     }
   12 }

Jeg har laget svært få attributter i min karriære, men det er en teknikk som kan gi veldig elegante løsninger om det brukes riktig. Måten jeg bruker det på her er ganske vanlig. Og enkel! Den vil rett og slett la meg legge til nye respondere uten at jeg behøver å endre noen eksisterende kode.

Men first thing first: Når jeg implementerer mine respondere vil RespondToAttribute la meg spesifisere hvilken nøkkel hver responder gjelder for. Her er f.eks. en enkel responder som legger sammen en rekke med tall separert med komma:

    6 [RespondTo(“add”)]
    7 public class Add : Responder
    8 {
    9     public string RespondTo(string arguments)
   10     {
   11         int result = 0;
   12         Array.ForEach(arguments.Split(‘,’),
   13             (arg) => result += Int32.Parse(arg));            
   14         return string.Format(“The answer is {0}”, result);
   15     }
   16 }

(Det er en konvensjon i .Net at man slipper å skrive “Attribute”-delen av attributt-navnet. Dermed blir linje 6 så fin.., denne klassen “responderer på add”.)

Når jeg gjør ting som dette er det typisk endel implisitte regler jeg må følge. I dette tilfelle vil det for eksempel ikke gi mening om mer enn én klasse responderer på “add”. Nøkkelen må med andre ord være unik. For å håndheve slike regler oppretter jeg som regel validerende enhetstester. Følgende test bruker reflection til å hente ut alle typer i prosjektet, samle opp alle RespondToAttributes fra typene, og sjekke at de er unike..

   12 [Test]
   13 public void Should_all_be_unique()
   14 {
   15     var keys = new List<string>();
   16     var allTypes = Assembly.GetExecutingAssembly().GetTypes();
   17     foreach (var t in allTypes)
   18     {
   19         var attribute = Attribute
   20             .GetCustomAttribute(t, typeof(RespondToAttribute))
   21             as RespondToAttribute;
   22 
   23         if (attribute == null)
   24             continue;
   25 
   26         if (keys.Contains(attribute.Key))
   27             Assert.Fail(attribute.Key + ” appear more than once!”);
   28 
   29         keys.Add(attribute.Key);
   30     }
   31 }

Og denne samme teknikken vil jeg bruke når jeg implementerer den endelige ResponderFactory-klassen. Den oppretter en dictionary med nøkler mappet til respondere (eller mer nøyaktig mappet til funksjoner som oppretter respondere).

    7 public class ReflectiveResponderFactory : ResponderFactory
    8 {
    9     private Dictionary<string, Func<Responder>> _dispatchTable;
   10 
   11     public ReflectiveResponderFactory()
   12     {
   13         _dispatchTable = new Dictionary<string, Func<Responder>>();
   14         Array.ForEach(Assembly.GetExecutingAssembly().GetTypes(),
   15             (type) => AddDispatchIfResponder(type, GetResponderInfo(type)));
   16     }
   17     private static RespondToAttribute GetResponderInfo(Type maybeResponderType)
   18     {
   19         return Attribute.GetCustomAttribute(maybeResponderType,
   20             typeof(RespondToAttribute)) as RespondToAttribute;
   21     }
   22     private void AddDispatchIfResponder(Type type, RespondToAttribute responderInfo)
   23     {
   24         if (responderInfo != null)
   25             _dispatchTable.Add(
   26                 responderInfo.Key,
   27                 () => Activator.CreateInstance(type) as Responder);
   28     }
   29 
   30     public Responder GetResponder(string responderKey)
   31     {
   32         if (!_dispatchTable.ContainsKey(responderKey))
   33             return new UnknownCommandResponder(responderKey);
   34         return _dispatchTable[responderKey].Invoke();
   35     }
   36 }

Her forutsettes det at alle respondere (med RespondTo-attributt) har en default, parameter-løs konstruktør, slik at den kan opprettes i lambda-uttrykket i linje 27. Du bør opprette en enhetstest for å validere dette også, slik at ingen lager en responder med konstruktør-parametre i fremtiden og dermed introduserer en bug (ikke at de ikke ville ha oppdaget det, men rask tilbakemelding er alltid kjekt).

Om du nå har skjønt hvordan disse klassene henger sammen gjenstår det bare å opprette og starte en SimpleHttpServer for at dette skal fungere. Her kjører jeg serveren i et konsollprogram, men i et mer realistisk senario vil du typisk kjøre den i en enkel Windows service.

    7 static void Main(string[] args)
    8 {
    9     new SimpleHttpServer
   10         (“*”, 8081, new ReflectiveResponderFactory())
   11         .Start();
   12 }

Og nå kan vi endelig få vite hvor mye 10 + 20 + 30 er…

For å utvide serveren med mer funksjonalitet er det nå bare til å opprette flere klasser som arver fra Responder-interfacet, og legge til et RespondToAttribute. ReflectiveResponderFactory vil finne og registrere den nye klassen under oppstart, og delegere til en ny instans av responderen om nøkkelen kommer i en forespørsel.

Jeg håper noen klarte å henge med óg få noe fornuftig ut av dette. Mer info om HttpListener finner du her, og info om .net attributes finner du via google. I neste blogpost vil du få se hvordan jeg implementerer nøyaktig samme funksjonalitet ved hjelp av Ruby.

Knagger: SOAP, Strategy, WCF

PSWinCom drar til Qcon London 2010

Torbjørn — Fri, 05 Feb 2010 12:47:16 +0000

I mars pakker fire utviklere fra PSWinCom kofferten og drar på utviklerkonferanse: QCon London 2010. QCon er en årlig konferanse som sier de retter seg mot arkitekter, teamledere og prosjektledere, men alle som brenner for systemutvikling vil garantert finne mye av interesse.

Konferansen har ikke noe leverandør-fokus, og dekker arkitektur og design i en nøytral kontekst. QCon 2010 har hele 15 spor, og strekker seg over tre dager. Sentrale tema er ting som utvikling innen programmeringsspråk, craftsmanship, smidige metoder og test-dreven utvikling, nettskyen, browseren som plattform, og SOA. Java og .NET, som de to viktigste utviklingsmiljøene for enterprise, har også hvert sitt spor.

QCon er en konferanse som trekker the best of the best i bransjen. Denne gangen har arrangørene samlet 100 forelesere(!!!), og keynotes holdes av Dan Ingalls (Smalltalk-gud) og Uncle Bob “I want to code till I die” Martin. Her er 15 glimrende grunner til at vi drar i år:

Jeg er spesielt interessert i foredragene som fokuserer på concurrency og skalering, og tror vi kan plukke opp mye bra her som kan gjøre PSWinCom’s produkter og leveranse enda bedre. Allerede nå har jeg bestemt meg for å følge sporene Software Craftsmanship og The Concurrency Challange nøye - sistnevnte med sterkt fokus på funksjonsbaserte språk som Erlang og Haskell. Bortsett fra dette blir det som vanlig en ganske stor utfordring å besteme seg for hvilke av de parallelle sesjonene man skal gå på – f.eks. høres både Pragmatic Cloud Computing og Irresposible Architectures and Unusual Architects ut som veldig spennende spor, og kolliderer ganske kraftig.

NNUG har forresten fått til en deal med QCon, hvor alle medlemmer får £297 av på fullpris om de registrerer seg før 22. februar (med koden “NNUG”). Vi er en liten gjeng fra Bergen som drar over sjøen, og forhåpentligvis kommer det noen fra andre steder av landet også. NNUG kommer til å arrangere en sosial samling i løpet av konferansen på et egnet sted (hørte jeg pub? Selvsagt hørte jeg pub!). Hvis du som leser dette også skal på QCon så hadde det vært hyggelig om du la igjen en kommentar så vi vet om deg!

Hva med NDC 2010 da? I fjor var jeg veldig gira på å dra på NDC, og det ble en flott konferanse med mange, spennende sesjoner. Det ser ut til å bli minst like bra i år, og det vil nok føles litt rart når norges utvikler-community samles i Oslo uten oss i sommer - men for vår del hadde vi lyst til å gjøre noe nytt, så da ble det QCon denne gangen.