Laurent Bossavit and J. B. Rainsberger are looking for volunteers to help out with the Gordon Pask Award.

For the moment, they seek volunteers to help with work such as:

• advertise and promote our initiatives on weblogs, in discussion groups, in user groups, at conferences, and wherever you can garner attention
• design a physical Gordon Pask Award prize
• interview Brian Marick about the story behind instituting the Gordon Pask Award in 2005
• interview past award winners and write articles about them
• connect the program with public relations or press outlets to help promote the award and raise its profile in the larger software community
• suggest changes to the nomination process
• suggest something special for the fifth year of the award (2009)
• design a logo and color scheme for the Gordon Pask Award

I wanted to give the design logo a try. I have done some graphic work before (creating posters and flyers) but nothing serious. I submitted a proposal last night. It’s very raw and this is my first try at it. Let us know what you think! I am actually pumped up that J.B decided to post it on his website.

My team likes to play little silly games. Ok, I admit, I like to play little silly games at work. Why? I like to work in a fun and engaging atmosphere. It enhances collaboration and communication. It builds trust.

One cool way to do build a team culture is to make up some games. No single game is going to fit every team. First, you have to observe how your team works: what do they find funny? Annoying? Frustrating? Games are a good way to get those things out in the open instead of waiting for the retrospective that is scheduled for next week.

These are the current games that we play in my team: The Happiness Factor, How high are your pants? and Jim’s forecast and Taboo Word.

The happiness factor
It’s easy to make with paper and index cards. Draw a scale from 1 to 10 in the paper and stick the nicely cut index cards with each team member on it.

The game is that anyone can get up and change anyone’s position on the scale at any time. If I am pairing with Jim find that he is cranky for example, I get up and modify Jim’s position on the scale. As soon as I get up and head for the board, Jim starts to smile as he knows he’s being moved to a lower rank and the team joins in throwing a joke or two on Jim’s new position. Jim can choose to explain the reason of his crankiness…or not! That’s up to him; he knows he has the team’s attention to take action if necessary.
If it’s something bigger than a cranky morning (we all have those), we just talk about it. Because we sit together at a big table, it’s easy to get everyone’s attention.

How high are your pants?
One day, one of us was challenging a new practice that we wanted to try out. During that discussion, someone got up and acted like an old man with an old rifle asking the kids to get out of his lawn.

We all laughed at that visual picture and the game was born a few days later.
You need intermediate design skills to make this one with index cards

The higher you are on the scale, the more old-fashioned-not-wanting-to-give-it-a-try you’re going to look like. Anyone’s position can move at any point. This has been proven to reduce tension when deciding on new experiments. And just for fun, I coded a Nintendo DS version of the game.

Jim’s forecast
Jim is the most experienced member on the team. He is our architect lead (he loves to be called an architect). He also carries our forecast. Some people outside of our team know this game and stop by regularly to get today’s forecast. Actually they don’t have to. Jim can broadcast the team’s weather only by the expression on his face. That always makes for funny remarks and good conversation.

Taboo Word
We have different variations on the game. It started with 2 of us talking about a word that everyone uses at our company that are no real meaning outside of it. The “word” has been there for so long that people don’t even notice they are using it. So we started a revolution. One day we decided that we will not use that word anymore. If I happened to say the “word” and my coworker could hear it, I had to give him $1 for each instance of the “word” I used. That quickly removed the habit! The team caught up on the idea and now we have plenty of money saved towards a happy hour. And more importantly we use the correct “word” now.

Yeah….You could say that some of these silly little games are just information radiators, but it’s more than that, these are OUR games! And now get off my lawn, you punks!

When a group of people is selected to work together on a project, they probably don’t know each other. Management puts them in the starting line and off they go toward a goal. With time, they eventually become a team. It can take time, maybe from 6 month to a year. It depends on different factors: collocation, sitting space, pair programming, pair testing, etc…These are factors that can accelerate “the gelling” of a team.

Finally, they create a culture. Something that uniquely identifies them. Teams with culture stand out from the crowd. Other people know about them. For some reason or another, they transmit it outside of the boundary of their workspace.

I worked in some teams that I thought were successful. There is no simple recipe to it. It’s rather hard actually. But it’s worth getting there. I could not come back to a team where people sit in their corner, don’t pair or play silly games like “how high are your pants” (I save this one for another post).

One pattern that I observed is a simple one: When starting to work in a new group, take the time to talk about how you are going to work together. Walk through the life of a requirement coming to the team. Discuss what you do with it, how you get started on it. Who is involved in every step, what is role and expectation of each of the members of the group. Draw a simple diagram with people and events. Talk about the big events and “when are we done?”

Do a couple of iterations (I hope your iterations are no longer than 15 days. 1 week are the best) and take a fun quiz. Let the quiz guide the discussions. Approach it with honesty and an open mind. Listen to the conversations around the questions. Reflect on the results, adapt and become a better team.

I recently started looking for ways to write little fun software on the Nintendo DS and came across Micro Lua DS. I heard about Lua before that and I thought that I should give it a try now.

Micro Lua DS is currently in version 2.0 Beta and can be downloaded and installed on the DS like any other homebrew software.
The download bundles API docs, examples and utilities that let’s you test your lua script on your computer before transferring it to the DS.

Here is Micro Lua DS running on the no$gba emulator:

The syntax is straight forward. Here is the Micro Lua DS Hello World

screen.print(SCREEN_DOWN, 0, 0, "hello world")

In this one liner, you are writing ‘Hello world’ on the top left corner of the bottom screen of your DS screen.

Easy! But when you run it, you won’t notice anything…you’re back to the navigation console. This is because the script is run once on 1 frame and then the program just exits.

The Nintendo DS run about 30 frames per second, so unless you’re pretty fast, your eyes did not catch it.
Let’s add some more code to display Hello world until the user press the “Start” button:

while not Keys.held.Start do
  Controls.read()
  startDrawing()
  screen.print(SCREEN_DOWN, 0, 0, "hello world")
  stopDrawing()
end

Here is what’s happening:

• while not Keys.held.Start do, loops until start is pressed

• Controls.read(), reads any input from the DS (buttons or stylus)

• All your drawing instructions must be between startDrawing() and stopDrawing()

With screen, you can draw lines, rectangles, images, gradients, etc. With a canvas, you have more flexibility to update certain properties like colors and sizes on the fly.

Here is a simple script that let’s you scribble/draw on the screen with the stylus:

canvas = Canvas.new()

function main()
    while not Keys.held.Start do
        Controls.read()
        startDrawing()
        paint()
        stopDrawing()
    end
    cleanup()
end

function paint()
    point = Canvas.newPoint(Stylus.X, Stylus.Y, Color.new(31,31,31))
    Canvas.add(canvas, point)
    Canvas.draw(SCREEN_DOWN, canvas, 0, 0)
end

function cleanup()
    Canvas.destroy(canvas)
    canvas = nil
end

main()

Here is what it looks like on the emulator:

There is also support for creating animations through sprites and scrollable maps.

Sprites are very easy to implement, I got my first sprite to work under 5 minutes. And I never made a sprite before! Quickly, I was able to write a small application that helps the lonely people that can’t pair program to pair with a ninja.
He guarantees to give you his best advice

I recently bought a Nintendo DS. It helps me on those train commutes where I am too lazy to get my laptop out of my bag. A couple of days ago, I got my hands on the Korg DS 10, a synthesizer for the DS. It’s not really game but it’s really addictive. I used to play around with trackers and other music generation software back in the 90s.

So today I decided to save a couple of tunes to my computer and share them because they are short, fun and silly. I am not a musician or pretend to be one but with since everybody deserves 15 mins of fame, here are my already classics tunes: other times were better, washing the dishes and goth and wifi.

Enjoy!