I don’t have much server background, and probably its a lot easier to set up your servers with amazon EC2 than setting them up yourself or at other hosting solutions. I don’t care, it really annoys me that everybody claims how easy it is, showing you how to launch an instance in a minute. Yes, thats really easy, but you quit too abruptly. Nobody wants to set up an instance, then terminate it and lose everything you did on that instance. I say, never press terminate, you will lose every change from the last ami save. You are warned, be prepared or waste a lot of time.

Read on for links an tips for the whole cycle of launching, changing, saving and registering AMI. Everybody deploying to EC2 really have to do all this as a part of setting everything up, being prepared to launch more instances of the same kind.

If you launch an instance without knowing how to save and register AMIs, save yourself a lot of time (and a few pennies), by not doing a lot of work you might lose. If you do a lot of work, don’t press terminate, it’s not the same as a shutdown of your computer. You have to look at it as an ISO image of files, if you read it, work with the content, you’ll have to create a new ISO image to burn on your CD to keep the changes. At page 26 in the ElasticFox it says “Bundling a Linux/UNIX instance requires the use of the AMI tools”. OK, as you probably understand, I’m burn.

I am now successfully using both ec2-api-command-line-tools, elasticfox and amazons web console.

Ok, so what is the minimum need to get a small server running ubuntu and a mysql database?

• EC2 for your server and database
• S3 for storing your AMIs and register them
• EBS is optional, but you should set one up as a safety-net, replicating your data.
• both the ec2 and ami command line tools.

My links, tips and references.

The ec2 api command line tool:

• http://paulstamatiou.com/how-to-getting-started-with-amazon-ec2 EU? Important addition, put this in you bashrc or bash_profile too

export EC2_URL='https://eu-west-1.ec2.amazonaws.com/'

• AWSEC2 Command Line Reference

ElasticFox

• Amazon ElasticFox pdf tutorial
• If you’re using the alestic ubuntu images below, remember to change “SSH user” to ‘ubuntu’, from the Tools menu in ElasticFox (icon top-right)

EBS to replicate your data

• MySQL database server, including snapshot backup and restore.

Finding ubuntu EC2 AMIs:

• http://alestic.com/

SAVING AMIs

First, make sure you have a bucket in S3 for storing the your new ami. I use S3 Firefox Organizer

• I suppose you have launched an instance
• then partly follow this http://robrohan.com/2009/01/30/saving-a-customised-linux-amazon-instance-ec2-and-s3/
• with the exception if your using alestic ubuntu AMIs (they don’t use root, but user=ubuntu). Run this on your EC2 instance:

mirror=http://us.ec2.archive.ubuntu.com/ubuntu/
printf "%s\n%s\n" "deb ${mirror} karmic multiverse" \
"deb-src ${mirror} karmic main" |
sudo tee /etc/apt/sources.list.d/multiverse.list
sudo apt-get update && sudo apt-get install ec2-ami-tools

I struggled a lot with sudo, but found the solution mentioned above, at here at google groups

Now you should be all set to launch a new instance based on that new AMI of yours! Break a leg!

I’d like to share my workflow, as it has proven efficient for me. I’m running two ’servers’ locally (!). Hang on, I said it was efficient, even though it surely doesn’t sound like it. The workflow should gain teams of any sizes, in my opinion.

I am developing an app it in rails and it also exposes some RESTful web services,  with_feed :through => :third_party. The third parties aren’t necessarily third parties, as we develop these too, but they are external apps collecting and sending data to my app. Part 2 will cover the creation of dummy clients that send randomish data to the core app.

OK, I will share the script and procedure I did to have a running server locally alongside developing my app. I wanted to have the server running locally, being able to receive request to the web server, testing the app manually, fast. To distinguish this local server (say localhost:3001) from your development server (sat localhost:3000), I decided to name it experimental, for simplicity. This is my workflow cycle

1. developing, creating migrations and so on, running mongrel at localhost:3000
2. git commit -am “I commit small changes, often!”
3. back_to step 2 if more_should_be_done
4. relaunch experimental server at localhost:3001, continuously receiving WS requests.

git pull and git push is performed frequently as well, but not as frequent as the above.

So, why would you I want that last step?

• It’s a great way of proving your migration scripts work. That server is supposed to be running all the time, containing more data, and old data.
• proving that your code works (which you of course also have extensive unit and integration tests for)
• prove that the clients still submit data through the web services as expected. (more of this in Part 2)
• better break experimental than staging?

What? isn’t this just the same as Cap and a staging server?

Well, not exactly, but yes, very similar. Experimental is something in between of staging(pretty stable) and the development server(unstable). If stableish was a word, then that’s what it is;) Differences better explained:

• The staging server is shared, experimental is not.
• The round trip is shorter. ‘git commit’ is sufficient. For staging I bet you have agreements to perform ‘git push’  to share code before deploying to the server (or ‘cap uses git pull’)
• Local development server is too unstable to have other apps sending data to it every hour. So you wouldn’t normally do that, you’d set it up for staging.
• Breaking staging messes up for more people than yourself. Also, you checked the code in with git push, probably.
• With the local experimental server you may mess around as you see fit, without becoming an impediment in your team.

Script deploy_to_local

To do this locally, you can’t use Capistrano (if you can, please educate me), so I created my own super-simple script to automate it. Say I have this file structure :

dev/myrailsapp/ (with .git, app/, etc.)
dev/temp/myrailsapptest/ (.git, app/, etc.)

where myrailsapptest is a duplicate of myrailsapp, except of the standard configuration files, like database.yml and such. These must be ignored by git, in .gitignore, or they will be overwritten.

#script deploy_to_local
rm -rf ~/dev/temp/myrailsapptest/.git
cp -rf .git ~/dev/temp/myrailsapptest/
pushd ~/dev/temp/myrailsapptest/
echo "git checkout ."
git checkout .
echo "rake db:migrate"
rake db:migrate
echo "Note: remember that the server must have been started with 'mongrel_rails start -d --port 3001' (daemon mode)"
mongrel_rails restart
echo "Restarting backgroundrb workers"
script/backgroundrb restart -e development
popd

Pretty simple, right? You can’t do this with svn, though, as it infects every directory you’ve got. Git stores everything in .git/ and a ‘git checkout .’ will automatically replace, add or delete everything as long as they’re not listed in .gitignore.

I’m using backgroundrb for scheduled tasks, if you’re not, remove backgroundrb restart from the script.

Notice that ‘git commit’ must be done first. This is why I consider the experimental server more stable than the development server. You may argue that it could be done without performing git commit first, but I guess nobody will. To me, committing is a small, important task that should be done often.

First step

Backtracking a little, the first thing you have to do, a one-time effort, is

• copy your whole rails app project directory to ../temp/railsapptest so that you also get the ignored files.
• Or, copy the .git and fix the ignored files manually. Whatever suits you.

Note (as in the script): to be able to perform a mongrel restart, you have to start it in daemon mode.

mongrel_rails start -d --port 3001

I’m saying this, because it’s poorly explained and I struggled for hours with it stating “PID file log/mongrel.pid does not exist.” when trying restart after a standard server start (script/server).

Last note. Exposing the local experimental app over the internet.

You don’t need any other server than your own mac/linux/win to show off your app to other people through the internet. Why deploy to staging before showing off your changes?

I did this at home, logged into my router, set up port forwarding of port 3001 to my computer (I’ve set up my router to recognize my mac and always  give it the same local ip address)

Then, given the IP address of the router is abc.def.ghi.jkl I would call or email whomever and say, check out the app at abc.def.ghi.jkl:3000 and tell me what you think! This guy would see exactly the same as I would on localhost:3001, which is cool. I’m sorry if you’re a corporate guy with routines, rules or other a bureaucrazy environments, hehe. Well, of course you can’t go port forwarding to thousands of people, this one is just a snack for those of us wanting to show of stuff we make at home in our spare time;)

Hope somebody find this useful! In the next post I will talk about the dummy client apps I wrote to feed my app, using RESTful web services. Maybe something about the backgroundrb jobs I’m using, if I feel like it. Should I?

I’ve been working with ruby on rails for the last few months and it’s been lots of ups and downs to me. It’s a learning curve and you just have to stand tall through the first frustrating weeks cursing the magic behind that you don’t understand. At least for a hard core java, spring, hibernate developer like myself, spoiled with great IDE support, which ruby lacks (It’s improving, with RubyMine, which I’m using,  a “clone” of IntelliJ IDEA). But then it becomes better, a lot better!

Templates

Kind of what AppFuse was supposed to provide the java maven community (what’s happening with this? I like the initiative!), the template runner of rails (version 2.3+) is supposed to help you set up your project with useful libraries, as authentication, test frameworks etc. No need to talk to much about it, I’ve created one that you can see for yourself, http://github.com/oma/rails-templates !

It’s tailored to my own need, and I don’t even know what I want, so you’d probably want to clone or download it yourself, to customize. It has a list of gems, as Shoulda, Mocha, factory-girl, authentication, openid, mail and more. Play with it! Run

rails mynewapp -m http://github.com/oma/rails-templates/raw/master/oma_rails_template.rb

check that rake test works, then navigate to mynewapp and run script/server. in http://localhost:3000 you’ll see a nice welcome page with login and logout functionality.

Resources

God, I love this Ryan guy creating the screencasts at http://railscasts.com/. He targets the intermediate rails developer, but this is excellent stuff for noobs as well. He taught me rails template runner in episode #148

More templates at http://github.com/jeremymcanally/rails-templates

I’m proud to say that there have been over 400 downloads of the burndown and burnup graph excel sheet I published about a year ago. I didn’t clean up nor explain much, just threw it out there. Download the (unmodified) excel sheet here: http://blog.omaconsulting.no/BurnDown/burndown.xls

Here is the post I publish about a year ago 18th June 2008 http://olemortenamundsen.wordpress.com/2008/06/18/sharing-my-burndown-and-burnup-excel-sheet/

What disappoints me, is that I have received no feedback. NO FEEDBACK!? Why not?

It contained a lot of experimental numbers and formulas, I would guess somebody thought they were strange. I’m sure many of you improved it and tried out. Maybe it’s been mostly managers downloading it, I have feeling this group tend to like being shared stuff, than sharing themselves. Too presumptuous? OK, I’ll watch my step :) I’d like feedback, though. I wish to learn from your experiences, good and bad.

The short story: Struggling to find any nice and simple burndown graphs to help me in a project, I created one myself (late 2007). I started out simple, with a burndown graph on A3 paper, then a simple excel sheet. Then it grew in a on-demand manner, truly agile. A friend liked burnup graphs and I discovered that these were really good at presenting the daily delivery speed, while the burndown was better at illustrating remaining work, scope creep up and chance of success (hitting zero at sprint end).  Of course, I started using both! Further combining a story point burnup in the (task-) burndown graph proved to be most valuable the times we scoped out user stories during the sprint. The scope down was greatly illustrating that fact that we thus delivered less business value (story points).

Along the way, I experimented a lot with numbers and formulas, mostly related to the burndown factor. The objective was to be able to deliver consistently, always committing to the most we could and always delivering what we committed ourselves to. Predictability is valuable to analyse the progress and the likelihood of reaching your deadline half a year, or a year, away. Do you have to modify your triangle? Scope, Resources, Time?

Good luck and thank you for sharing!

What I have

• Maven2
• Eclipse/IntelliJ IDEA
• Fast tests (unit tests)
• Slow tests (integration tests)
• Test coverage maven plugin (Cobertura)

I wish to

• run my fast tests (unit tests) from my IDE
• run my slow test (integration tests) from my IDE and maven
• run them all before committing code.
• create test coverage reports combining unit and integration tests
• create test coverage reports from unit tests only

If you’re like me, you wish to run all your fast unit tests often! And the process shouldn’t take more than 15 sec in total. In Eclipse or IDEA, you simply right click the project or the src/test/java and run tests. But how do you exclude your integration tests? Move them?
In maven2, you may create include and exclude statements, like **IntegrationTest.java. This is all fine, but in my frustrated this doesn’t help you in Eclipse or IntelliJ.

I’ve googled a lot, stating that there’s gotta exist a simple solution to this!? I found some unsatisfactory suggestions here
http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing
They might be good, but they don’t meet my needs of combining IDE test run and combined code coverage! Below is a list of the various suggestion, with the one I ended up with at the end.

1. Separate Integration Tests Module. Works for both maven and Eclipse. But what about code coverage? You will not get the combined code coverage of fast and slow test. You may say this is a cobertura (clover as well I guess) issue, that it doesn’t instrument packaged jars.
2. Test Suites. Create a test suite for integration tests and one for unit tests. With hundreds of tests it can get quite tedious. I guess you may code it more intelligently to find the tests, but I have not seen a good solution yet.
3. src/test/java and src/it/java. Would solve everything elegantly, but we’ll have to wait until maven supports it. (Update 29. sep 09: Bertrand commented that the mojo build-helper-maven-plugin might help. Report back to me if it does!)
4. my.package.tests.a.b.c and my.package.it.a.b.c. Looks lik 3 but is very different! The tests should be in the same package as the class it’s testing. Else you would suddenly find yourself having to open up the domain object, as it were a simple bean! Protect your domain objects, make package protected constructors or method if needed for the tests.
5. Run the tests in maven only. Yes, many chooses this… But it’s plain ineffective if it takes 10 sec to run them in Eclipse and 1 minute (often 2) with “maven test”. Besides you often need to include “clean”, maven clean test.
6. TestNG. I got this to work for all, maven, IntelliJ IDEA and cobertura. But there are things about TestNG I don’t like. Solution and elaboration follows below.

TestNG supports
@Test (groups ={“unit-tests”}) and
@Test (groups = {“integration-tests”})
which are easy to use in IDEA. The Maven Surefire Plugin also understands it and the Cobertura instrumentation works fine when you select to run them all together. Yeah!

But what I hate about TestNG is that it doesn’t provide the execution time per test nor the test results for each test class, only a summary at the end “Tests run: 272 failed:1 … duration:5 minutes” or something like that. Goggling this all I find is arrogant answers to the this question, stating that “That’s the way testNG is supposed to work” or “Why are you using it if you don’t utilize it’s parallel test execution potential”. Bullocks ;)

Wishlist:

• maven supporting the directory src/it
• Junit supporting grouping as testNG does

Oh, you know a better way? Great news! Tell me:)

EDIT 23.jul-09 : I added some stuff from my pom file. Will not work out of the box, but should be helpful anyhow.

<profiles>
 <!-- Profile for running both TestNG integration tests and Junit/TestNG unit
      tests. Example of usage: mvn clean install -Pintegration-tests -->
 <profile>
  <id>integration-tests</id>
   <build>
    <plugins>
     <plugin>
      <artifactId>maven-surefire-plugin</artifactId>
      <configuration>
       <forkMode>once</forkMode>
       <argLine>-XX:MaxPermSize=256m -Xmx512m</argLine>
       <includes>
        <include>**/*Tests.java</include>
        <include>**/*Test.java</include>
       </includes>
      <excludes>
       <exclude>**/Abstract*.java</exclude>
      </excludes>
      <groups>unit-tests,integration-tests</groups>
     </configuration>
    </plugin>
   </plugins>
  </build>
 </profile>

If you’re using Hudson, include this to display it in the build results and look at test coverage history.

<!-- If we are running in hudson use cobertura.   -->
 <profile>
  <id>hudson</id>
  <activation>
   <property>
    <name>BUILD_NUMBER</name>
   </property>
  </activation>
  <build>
   <plugins>
    <plugin>
     <groupId>org.codehaus.mojo</groupId>
     <artifactId>cobertura-maven-plugin</artifactId>
    </plugin>
   </plugins>
  </build>
 </profile>

I’m giving a lightning talk Wednesday, 11.feb, on SW2009, Oslo. It’s on a day-track called “Future development processes in a post-agile world (Effective software development)”. What’s your thoughts about that title? Clever? Needed? Provoking? Sad? Happy?

My thought? – Are we even agile yet? I think we’re far away from post-agile, but it’s probably good for us to discuss the subject.

Anyways, my lightning talk title is “You have yet to have success with an agile project” (Du har til gode å ha suksess med gjennomføringen av et smidig prosjekt). Switch You with I and it’s partly true as well, because how do we measure success? Well, that’s a whole other discussion, all I know is that I felt we had a potential to do much better, given the resources and information available at the time.

The objective of my lightning talk is to affect the attitude I feel many people have towards agile. So, is agile easy or hard, simple or complicated?

Most agilists would claim “Agile is simple!”. Maybe they’re right, but herein lies the problem, I think. When we sell simple to the customer (and the developers for that sake!), we risk that he’ll take too lightly on the process. Perhaps key elements are forgotten or simply ignored? The customer plays a big part in both waterfall and agile, but in agile his role is very different. We need the customer (product owner) on-site, continuously providing feedback and steer the project in the desired direction according to the newer information obtained. Sounds feasible, and easy, but this person needs both domain knowledge and the executive rights to guide the projects. Who can spare such a vital person to a development project? It would certainly be an easier decision if the customer new the project would fail dramatically if not.

So, from now on, sell “Agile is hard, but you get the better product”. Then, maybe, agile will become easy ;)

edit: so kill them fast :)

Smidig2008 was a conference about agile methodolog, as was Smidig2007. I participated in organizing them both and we repeated our success from last year, expanding from 300 to 450 participants. I’ll continue this in norwegian as this is the language spoken at the conference.

Smidig2008 gikk av stabelen 9. og 10. oktober i Oslo Kongresshus. Vi hadde lært masse fra fjoråret, og bytte av lokale samt bedre registreringsprosedyrer bidro til en smertefri gjennomføring. Foilene ligger nå ute! Senere kommer også videoene. Jeg skriver her litt om konferansen generelt og mine opplevelser.

Alle lynforedragene ble filmet av amerikanske Confreaks og i år, som i fjor, kom ikke utstyret over atlanteren tidsnok. Flaks at det er en smidigkonferanse! Vi omfavner endringer… Når det er sagt, så skal man lære av sine feil, så det ble gjort grep. I fjor rotet flyselskapet bort bagasje med utstyr, så i år byttet de til FedEx. Men så rotet det seg til allikevel! Uten norske Howard Brodwall hadde vi slitt kraftig, man kan vel si at han reddet oss i år, også. De sto på hele natta, ringte rundt etter utstyr, kuttet kabler etc. Dermed blir det video av alle foredragene på nett! Når det er klart, vil det sendes ut mail til deltakerne.

Årets provokatør

Gud som jeg gleder meg til å se Tom Gilb sitt lynforedrag på video. Han er den ubestridte provokatør i Smidig2008-konferansen! Kanskje ikke grunnet innhold, heller ikke det han sa, men kanskje det han ikke sa ;)

Mye ansvar

Selv fikk jeg mye mer ansvar disse to dagene konferansen pågikk, enn det jeg hadde forventet. I utgangspunktet skulle jeg holde introkurset om retrospective, men holdt også velkomsttale og deltakernes retrospektiv. Velkomsttalen fikk jeg vite at jeg skulle holde først klokken 23 kvelden før, under rigging av konferansen. Det, samt generelt mye tid til forberedelser til konferansegjennomføring, ønsker jeg å bruke som unnskyldning for at jeg ikke var godt nok forberedt til min Intro:Retrospective. Men det får jeg ta i min egen retrospektiv og konkludere med at det kunne jeg gjort mye bedre. Mitt tips: Gå alltid gjennom hele foredraget muntlig, snakk til en venn eller kjæreste. Det er alltid så mye du ikke har tenkt på, eller som du legger merke til at kommer dårlig ut muntlig.

Smidig konferanse – programmet ble til underveis

Enda et bevis på at konferansen gjennomføres smidig, med eierskap og ansvar er deltakernes retrospektiv. Under konferansemiddagen, torsdag kveld, kom vi til å tenke på at vi ikke hadde et opplegg for årets retrospektiv. Under standup klokken 2030, lettere bedugget, tok vi den vanlige runden. Vi avtalte fremmøte og fremdrift for neste dag og skålte for en særdeles vellyket første dag. Under lunsjen dagen derpå satte Jerome Lacoste og meg ned ved et bord og brainstormet. De andre ved bordet tenkte nok sine tanker om oss… Vi kom til at følgende kriterier var viktige

• Involvering av hver enkelt deltaker (positivt fra ifjor)
• Drive, fremdrift (ikke så bra ifjor)
• Enkelt og tydelig
• Forbedringsmål for Smidig2009
• God stemning

Deltakernes retrospektiv

Jerome hadde også et forslag om å kjøre 3 retrospektiver i 3 forskjellige rom, for å kunne prøve ut 3 forskjellige metoder. Kjappere læring. Det er en genial idé, som jeg ønsker å få prøvd en gang.

Men vi valgte en safere løsning, da vi er klar over at deltakerne på det tidspunktet er altfor klare til å avslutte, med nesen vendt halvt hjemover. Så vi gikk for å samle alle i storsalen. Vi laget en tidslinje for et opplegg som skulle vare 20-25 min og involvere 200 mennesker (stort frafall mot slutten av konferansen). Deretter fant vi noen sjeler som ikke så for opptatt ut i en open space og ba dem delta på en generalprøve. Takk skal dere ha, der lærte vi mye! Det kom frem at det var viktig å informere deltakerne om å skrive tydelig på post-it-notene, gjerne blokkbokstaver, samt annotere dem med en tydelig + eller – øverst. Dessverre rakk vi ikke fullføre før vi ble jaget ut på scenen. Selvfølgelig fikk vi da problemer med den biten vi ikke hadde gjennomført generalprøve på!

Deltakernes retrospektiv gjennomførte vi slik:

1. Samle alle i Sal A mens vi deltakerne rydde alle stoler vekk, for en stående retrospektiv.
2. Be deltakerne samle seg i grupper på 8 med 1 stor (A3) post-it blokk, 1 stor tusj, post-it notes og penn til hver deltaker
3. Demonstrere på scenen, samtidig som deltakerne utfører oppgaven. Det sikret lik hastighet og ga tydelig eksempel. Vi delte post-it blokken i 4 kategorier slik:
4. Hver deltaker måtte skrive minst én positiv og én negativ lapp, i hver av de fire kategoriene.
   • først 5 min uten å si noen ting
   • så 3-5 minutter med lov til å prate
5. Deretter fikk hver gruppe utdelt en lapp som fortalte hvilken kategori de skulle fokusere på. De skulle stemme frem et forbedringsmål (negativ) og en ting vi må fortsette med (positiv). Dette rakk vi ikke i generalprøven og når jeg hørte Aslak i arrangørgruppen rundt sin post-it flipover si “Jeg skjønner ikke hva vi skal nå” tenkte jeg det skulle gå åt skogen. Men det gikk…
6. Deretter ble alle disse viktigste lest opp på scenen. Kort fortalt gikk mye på støy i open space og i liten mulighet til å bevege seg mellom lyntaler.

Registrering

Registrering var et herk i fjor. Det var også logistikken rundt mat, som var tusen ganger bedre i år. Men DogA liker ikke oss, og vi liker ikke … Registreringsløsningen til Daniel Holmen, med strekkoder var helt fantastisk. Ole Christian Rynning bidro også her med fiffige rubyløsninger for å få det til å fungere. Det var rett og slett helt fantastisk.

Før konferansen

Folk bidro i veldig varierende grad til årets konferanse. Det ble gjort en del gjennom smidig.no forumet på nyåret, hovedsakelig anført av Johannes og Aslak. Senere skjedde det lite og spesielt på utviklingen av Smidig2008.no lå vi etter. Teknologivalg med Git, Radiant (CMS), cucumber, ruby, rails, mysql og en egen extension av radiant kalt ba som gjorde git litt vanskeligere å bruke. Det var summen av teknologiene som gjorde det hele vanskelig å bidra. De fleste av teknologiene er kule (det vil si bra) hver for seg, unntatt radiant, som det er rimelig konsensus om. Man må også huske at vi bruker fritiden på dette og da har man en ganske mye lavere smerteterskel for å “ikke skjønne noe”. Mangelen på kildekodekontroll er hovedankepunktet mot radiant, samt at det var masse egne tags (kun et problem fordi jeg hater radiant generelt) og slikt å lære seg. Jeg bidro svært lite for å fikse applikasjonen og følte jeg var mer til bry enn til hjelp. Allikevel har jeg brukt et høyt tosifret antall timer på det (kall meg treig). Hadde ikke Aslak satt inn både ett og to gir ekstra, hadde vi nok ikke kommet i havn med applikasjonen. Snakker om trikkefaktor ;) Sarah Brodwall fungerte som vår grafiker og grensesnittsprogrammerer, en uverdelig person i et team med hovedsakelig utviklernerder. Veldig serviceinnstilt og konstruktiv, det kan du sette på CVen Sarah.

Etter konferansen

Etter konferansen, i femtiden fredag, hadde vi en skikkelig retrospektiv, med ærlige og åpen atmosfære, og øl! Vi følte vi hadde mistet noe av futten etter Smidig2007, at vi la oss på plankekjøringsmoduset. Mange av oss må ta selvkritikk for at vi ikke tok nok ansvar eller involverte oss oftere og tidligere. Selv meldte jeg meg ut en veldig lang periode og bidro ikke i den grad det var forventet av meg.

Men kommentaren fra garderobedamen på kongresshuset gjør oss alle motivert og får oss alle til å smile fra øre til øre: “Det er så mye energi i dere. Folk diskuterer og er ivrige. Det er jo helt annerledes enn det pleier å være”. Det er en utrolig bra tilbakemelding til våre deltakere og til opplegget de bidrar til å gjøre så effektivt.

Smidig2009

Det er en fare for at det blir en smidigkonferanse neste år. Vi skal ta erfaringene fra Smidig2007 og Smidig2008, trekke ut det som er bra og forbedre det vi kan. Fra Smidig2007 glemte vi “brannfaklene” og er en av hovedtingene vi må få med neste år. Vi er også usikre på antallet, noen vil ned til 300 virkelig interesserte, andre nå ut til et større publikum. Jeg føler uansett at folk var ganske mye feigere i år enn i fjor. Vi gjør forskjellige ting, feiler på helt nye måter. Vi må provosere smidigmisjonærende enda mer!

Jeg beklager overfor dem i smidiggruppa som ikke er nevnt eksplisitt her, jeg føler jeg allerede har skrevet nok tekst. OK, jeg må så absolutt nevne og rose dere også! Simen, Trond P, Trond W, Thommy, Lars Arne, Christian og Øystein, gratulerer med nok en vellykket gjennomføring av en smidig konferanse. Ser allerede frem til neste.

Code is included in this post! I’ve written a small ruby script for polling a bamboo server for (multiple) build results, playing sounds for success and failure. It even controls lava lamps connected to a AM12 power outlet through a CM11 controller using the X10 protocol. You may get these at framtidshuset. To send the signals through your serial port(yeah, I know! serial port) to your CM11 controller, you need a program that takes arguments like this ‘command A1 on’, where A1 is the lamp/AM12 code and ‘on’ is the opposite of ‘off’ :) I use windows and ActiveHome’s (HomeControl) x10com32.exe (ships with the CM11 if bought from Framtidshuset), and on Linux you would use the free ‘heyu’ program. I’ve used heyu before and promise you it works.

Bamboo must have the Rest API enabled, a property setting you find somewhere in the bamboo settings.

If you make one for say, Hudson, or Continuum or whatever, please let me now and I’ll post a link. Certainly you’d probably want to extend or rewrite the continuous_builder_lamp_controller.rb to better fit your needs, it’s not, you know, perfected ;) It’s agile and on-demand driven development! If you modify it, extend it, improve it, let me in on the details!

You might download the script as a zip bundle here, with sounds and everything. The ruby script itself might also be downloaded here, with a config file example here and here. The x10 program x10com32.exe may be downloaded from here (not responsible for external sites). Below is a picture of a red lava lamp after a broken build. The other one is blue, but should of course be green :) As soon as the build is fixed, the red lamp will switch off, the blue on and cheering will chime to the PC speakers (if you enable sounds).

Broken build. A glowing red lava lamp

Note: The script seem to hang every first time it is executed after a reboot. Kill it, and run again. If you solve it, let me know:)

For many, the source code above is sufficient to get going. For the rest of us, I’ll repeat myself

What do I need to get started?

• Power control system using the x10 protocol. ( Referred above)
  • ActiveHome PC interface CM11G (I’m using the serial cable version, but the usb should work as well)
  • Utstyrsmodul AM12G, one for each lamp (two for each lamp set)
• Lamps or whatever you’d like, using a power cord. As the lava lamps in the picture. Annoying red for critical builds is cool.
• A, preferable dedicated, PC for playing sounds and sending signals to the CM11G module.
• Ruby and it’s required libraries (use the amazing ‘gem install xx’)
• Bamboo build server with REST-requests enabled. (Settings in bamboo)
• The source code (referred to above)

How do I get it running with one lamp set?

First, follow the instructions to connect the CM11G, using the serial or usb cable. Set the AM12G codes, e.g. A1 and A2, and connect the lamps to them. Ensure the lamps are glowing. (Hitting the power switch of the lamps will “override” the switch in the AM12G so that the lamp may always be switched on. This is a “smart” feature of the module). Go to the installation directory of the Lamp control system, having the x10com32.exe and ensure that these commands switches the lamps on/off.

• x10com32.exe A1 off
• x10com32.exe A1 on
• x10com32.exe A2 off
• x10com32.exe A2 on

Now, you’re either having the biggest grin upon your face, or you’re pissed off. Relax, I’ve felt both. If you have problems, check this

• You’re using the correct serial port.
• The CM11G and AM12Gs are on the same power subnet (or something). Recommend using a unit with multiple power outlets on it, while testing. This ensures the signals aren’t disturbed, as the CM11G and AM11g communicates through the power grid(!).
• The AM12Gs have codes A1 or A2 (or whatever you chose)
• The computers power cord is plugged into the CM11G (haven’t tested the necessity of this, though)

Config files

The config files are the only ones you need to edit! They’re fairly self explanatory. The lamp_control success/failure codes are the same as the ones on your AM12G devices (here O1 and O2 instead of A1 and A2)

• For multiple lamp systems, create more config YAML files. We’ll provide the config files as input to the continuous integration lamp control system script.
• Multiple build_names defines that you want the unity of those affect one lamp set.

Check the two example files given (referred to above)!

Edit the config files and execute the script with

ruby continuous_builder_lamp_controller.rb  config.yml config2.yml …

Have fun! May the lamps be green at all times!

My god, eclipse have they’re tests publicly available for you and me to view, and run!

I stumbled across this blog in a hopeless hunt for good articles about FitNesse, test data exhaustion -duplication, -hard-coding and other dreadful things.

Yes, eclipse foundation has executable tests in production. You may view the testflow (and workflow) in the swim framework. Swim impresses me (see eclipse swim pdf). Seems a bit crazy at first, but they’ve got to be doing something right in their testing (and test process) when they can have such automatic tests running in production . See the test result for eclipses election of committers and be stunned!

I’m not the only one curios about this. Repeated, here’s the blog post that I stumbled upon, here

Hope I get to try it, things always tend to look better than they are…