Videos from demodag 8.

30 11 2010

The videos from demodag 8. is now released on video.demodag.org a big thanks to Claus Dahl for one more inspiring demodag.

Marbleart twitter and facebook  enabled artwork www.marbleart.tv
Me and Marcus hold a short demo of www.marbleart.tv
Since I  have made a promise to Staffan Nöteberg to put the video here on my blogg, here it is, even if I hate to see and hear my self on video.
I  guess its a good thing to go beyond my comfort zone :-)

http://video.demodag.org/video/909050/marble-art

Don`t forget to visit demodag.org for more videos of inspiring demos.





Give Away Candy

9 05 2010

My goal to make it possible for everyone in the world (at least internet world) to give me candy is almost fulfilled.

setup of slickstreamer

As long as you have a twitter account you can, by writing “give @sidpiraya candy” on twitter. You can of curse see the candy be delivered on a live stream at the site  www.giveawaycandy.com.

We (me and Marcus) has also build one more machine to be used in other project/events. for more info follow www.slickstreamer.info

More creative projects are one the way:-)





Thinking Regular Expressions

5 08 2009

Thinking
Early this year I hold a presentation at work called Thinking Regular Expressions.
My point is that I think many developers see it as hard/complex to understand and use regular expressions, but by getting the basic thinking right I believe it is really easy to getting started to use this powerful tool. The presentations was supposed to be a kick start.

I publish the slides even if its not made to say something by itself without my talk. But you might get something out of it.
http://www.slideshare.net/sidpiraya/thinking-regular-epressions





SlickStreamer part 1

11 05 2009

History

Once upon a time I was having one of many creative brainstorm/discussion with my old colleague Ricki Pedersen (@shim). This time we where running away in our minds thinking about how great it would be to just have a candy machine automatically giving us candy every time we had “earned” it. (And of course we earn it a lot :-)).

I kept on thinking how great it would be to use it as rewarding system in a dev team. Direct connected with systems like CC.Net, SVN, CVS, and TFS etc.

After presented it with another old college Marcus Olsson (@_macke_), it was getting some meat to it since he is the kind of guy that build robots on his spare time he have all the knowledge I didn’t have about the servo part.

We (Markus and I) started the project by buying a candy machine, servo controller and a servo. Now there was some energy and soon we had it ready to be controlled by our computer. Here are some pictures.

D’Oh! Now it was late 2006 and we had crazy load of work at the company and we hade no extra energy for project like this. It was stalled. We did try to energize the project again by adding it to source forge and invited more colleague to help us. But again I guess all our energy went to other projects.

I still like to finish the “reward” project but right now its on hold since I have kidnapped the machine for my twitter project.

Ok so what am I doing with a candy machine on twitter?

I want to give anyone in the world the possibility to give me a candy.
That’s it.

I will go in to more details about the setup in the next post, in the main time follow me on twitter will give you the possibility to be a part of the beta tests and have all the latest news about the project. This is a hobby project that I run in my spare time, so please be patient if the progress is a bit slow.

Get ready to Give @sidpiraya candy





My first Ruby experience

4 05 2009

Here is my story about my first ruby script ever, actually it was the first time I writing coded in 2 years time.  So please be gentle to my awful code :-)

Purpose was to help PO to get a complete “read me” file over every patch the “Team” created.
So why not try something new while solving the problem? I started out by “just do it” with some help of  guessing and google, Here is my first version of the code:

Round 1

def createAndWriteToFile(file, text)
 myFile =  File.new(file, "w")
 myFile.write(text)
end

def getPatchID(path)
 myRes = path.scan(/.*Patch_(.*)\//i)
 return myRes.to_s
end

def getOutputHeader(x)
 outString = "\n ----------------------------------------------------------\n"
 outString += "Patch: " + getPatchID(x) + "\n"
 outString += "\n ----------------------------------------------------------\n"
 return outString
end

def getFileContent(x)
 fileContent = ""
 file = File.new(x, "r")
 while (line = file.gets)
    fileContent+= line
 end
 file.close
 return fileContent
end

def buildFileOutput(x)
 fileContent = getOutputHeader(x)
 fileContent += getFileContent(x)
 return fileContent
end

def getAllFilesOutput(files)
 filesContent = ""
 files.each {|x|
    filesContent += buildFileOutput(x)
 }
 return filesContent
end

#Run
createAndWriteToFile("AllReadme.txt",getAllFilesOutput(Dir["./*/README.txt"]))

Round 2

After asking Niclas Nilsson to review my code (on paper) I learned some new  things.

  • “returns” are optional.
  • “()” after method name is optional.
  • In Ruby “we” don’t use camel case
  • There is easier way to open and write to a file.
  • And last but not the smallest lesson the power of “.map”

So here is my new version of the code.

def create_and_write_to_file file, text
 File.new(file, "w").write(text)
end

def get_patch_id path
 path.scan(/.*Patch_(.*)\//i).to_s
end

def get_output_header x
 out_string  = "\n ----------------------------------------------------------\n"
 out_string += "Patch: " + get_patch_id(x) + "\n"
 out_string += "\n ----------------------------------------------------------\n"
end

def build_file_output x
 get_output_header(x) + File.read(x)
end

def get_all_files_output files
 files.map{ |file|build_file_output(file) }
end

create_and_write_to_file("AllReadme.txt",get_all_files_output(Dir["./*/README.txt"]))

Round 3

Okay hang on now it was Anders Janmyr turn to take a look at it.
This is how he would like to do the code.

def get_patch_id path
 path.scan(/.*Patch_(.*)\//i).to_s
end

def get_output_header path
 out_string  = "\n ----------------------------------------------------------\n"
 out_string += "Patch: " + get_patch_id(path) + "\n"
 out_string += "\n ----------------------------------------------------------\n"
end

File.open("AllReadme.txt", "w") do |output_file|
 readme_paths = Dir["./*/README.txt"]
 readme_paths.each do |readme_path|
    output_file.write get_output_header(readme_path)
    output_file.write File.read(readme_path)
 end
end

Round 4

Okay I get it, in ruby we don’t write too many lines or what?
Here is my final version.

def get_output_header path
 out_string  = "\n ----------------------------------------------------------\n"
 out_string += "Patch: " + path.scan(/.*Patch_(.*)\//i).to_s + "\n"
 out_string += "\n ----------------------------------------------------------\n"
end

File.open("AllReadme.txt", "w") do |output_file|
 readme_paths = Dir["./*/README.txt"]
 readme_paths.each do |readme_path|
    output_file.write get_output_header(readme_path) + File.read(readme_path)
 end
end

Round 5

Now its your turn to give me feedback. Which version would you prefer  and why? Would you write the code differently?
Please feel free to comment.

Thanks to Niclas Nilsson and Anders Janmyr for taking the time to help me in my learning process.

My next project in ruby is ongoing and will be a experiment with twitter and the home made candy machine called “SlickStreamer” developed by me and Marcus Olsson . I will soon post more information about this project.





Agile Retrospectives, Making Good Teams Great

28 04 2009

Agile Retrospectives, Making Good Teams Great by Esther Derby and Diana Larsen

agileretrospecives

Found myself writing a recommendation internally on our intranet, so I thought I better share it with some more people.

If you serious about agile you should doing good retrospectives, this is a really simple and concrete book for you to take retrospectives to a high level. I have also had the pleasure to attend in a 1 day workshop with Diana Larsen, if you have the possibility I warmly recommend you to do the same.

In my experience retrospectives not only help the process and the team to “inspect and adapt”.
It’s also a great way to build strong teams, mainly since it helps the communication and build trusts in the team. Start doing retrospectives seriously and you will grow really strong teams out of it.

I will try to going in more deeply in my experience of how retrospectives can help you building team in a later post.

The book at Amazon

Esther derby

Diana Larsen





Just Say Thanks, a Hometown Story

14 04 2009

I have earlier recommended the book Fearless Change. Here is one of my  [HomeTown Story]* about [Just Say Thanks]**.

In one of the companies I worked in there were an “internal Service desk”. There was a huge amount of frustrations about this function probably because they didn’t have time enough to solve the huge amount of problems reported. Most work was done to the one screaming highest or with most managers on CC on the reported issue.

It was normal with weeks of waiting time and a really poor service where most of the time nobody told you when the finally actually did resolve the issue.

Then suddenly of some reasons I don’t know about, I one day got a response about my issue in a reasonably time after sent it in, they told me they worked on it, and a hour or so later I got the message that my issue was solved.

I was sincerely appreciating this fast handling and rich communication around the issue, and I did send a mail to thank them, and I did put on there boss on the CC.

Magic, absolute magic from now on every time I send in a request I got a quick answer and help to solve my problems. And every time I send them a “thank you” for the help and the quick handling even if they just did what the supposed to do.

This went so long that it ended up with my colleague in my department asking me for help when they needed help from the internal service desk.

“Why do you always get help?”

“Please Michael can you send a mail to service desk so I can get some help on my issue”

I do now have the insight on why the story ended up this way.

*[ HomeTown Story] To help people see the usefulness of the new idea, encourage those who have had success with it to share their stories.

**[Just Say Thanks] To make people feel appreciated, say “thanks” in the most sincere way you can to everyone who helps you.








Follow

Get every new post delivered to your Inbox.