lauantai 30. lokakuuta 2010

Puppet on Centos 5.5

I've been fooling around with cobbler and puppet, and I had a lot of problems when trying to get puppet running on Centos 5.5

In short, puppet supports version 1.8.6 of Ruby and ActiveRecord 2.1

Use version 1.8.6. I tried following versions without luck.
- 1.8.5 didn't support activerecord, or so I thought. Should have tried to install older version of activerecord
- 1.9.1, 1.8.7 from sources, puppet doesn't support and they don't tell you clearly what version of ruby is supported
- 1.8.6 worked, but newest activerecord doesn't support -> use active record 2.1 (gem install activerecord -v 2.1 after you've installed rubygems)

The dependency to version 1.8.6 seems to be because "exec" -function in somewhere in Ruby or in its default libraries has changed in x.z.1 release..

Dependencies for compiling ruby:
-openssl, openssl-devel
-zlib-devel, comes with openssl-devel
Just yum install openssl openssl-devel

Compiling ruby
-get sources from ftp://ftp.ruby-lang.org//pub/ruby/1.8/ruby-1.8.6.tar.gz
- ./configure && make
- make install
Install rubygems
-Just get sources from http://rubygems.org/pages/download, untar and run "ruby setup.rb"

Get puppet and facter as gems from http://puppetlabs.com/downloads/gems/
- gem install facter-x.y.z.gem
- gem install puppet-x.y.z.gem

Create user "puppet" and group "puppet"
- For me, puppetmasterd --mkusers failed when doing this, but it was because I had ruby 1.8.7 installed.
Run puppetmasterd --no-daemonize --verbose

Running puppetmasterd should create necessary configuration directories.

Using ssh to contact guest operating system in VirtualBox

From manual, page 82 '6.3.1 Configuring port forwarding with NAT'
VBoxManage modifyvm "VM name" --natpf1 "guestssh,tcp,,2222,,22"
--natpf1 is the number of interface used for NAT'ing between host and guest operating system. After this you can just 'ssh -l username_on_guest -p 2222 hostsystem'

torstai 28. lokakuuta 2010

Why Scrum sucks

Most backlogs contains a lot of waste as a inventory and in waiting. There's a lot of stories, some of which will never be implemented.

Fixed length of sprints. implementation of features isn't prioritized just for their value, but also for their size (it fits into the sprint). Fixed length sprints can also force into splitting of features which doesn't actually add any value.

Implementation of Scrum usually begins with a training session and then with "by-the-book" -implementation. This is usually a extreme change to previous work processes. Better way might be use value stream mapping and actually find out what the process is currently, and then decide what is the smallest step we can take to make it better.

So called continuous improvement, which actually is just phased improvement. It happens every two weeks, not continuously.

The value stream map for worst case if implementation goes right shows pretty well how much waste and waiting is involved in Scrum:

Idea
 |
 |
Backlog
 |
 |
Planning session (First prioritization)
 |
 |
Sprint (Idea sits in backlog)
 |
 |
Planning session (not important enough)
 |
 |
Sprint (Idea sits in backlog)
 |
 |
Planning session(made to be more important)
 |
 |
Sprint (Story sits in backlog)
 |
 |
Planning session (Didn't fit into sprint, splitted and designed)
 |
 |
Sprint (Do first half of splitted feature)
 |
 |
Planning session (do the rest)
 |
 |
Sprint

What phases did actually add value? How long did it take to from idea to release?

There's a lot good in Scrum, I wont deny it. It gives a clear structure for development and you don't have to think what you do in the beginning, you just try to implement the process. You'll probably fail, but that's life.

lauantai 9. lokakuuta 2010

Process models, methodologies and majority

When things are written down, they become laws. I've been in situations where I've been told that "you're not following the documented procedure." Reason for this was sometimes that I forgot, and sometimes it was because I thought that the documented procedure was not valid. Only thing is that in some of those situations I wrote that documented procedure. Of course, I've should've updated the documentation. But this shows how written word becomes the truth, something you cannot change.

This is one of the reasons why many software process implementations fail. They are following standardized process model, which they will follow blindly, even if they do not work on their situation.

When new process model or methodology emerges, innovators and Early Adopters usually understand the meaning and possibilities of new methodologies. They understand that the new thing might not work for them, and they are willing to try and able to modify it. Majority will check what innovators and early adopters have done, and then implement it like it's business as usual. And in this point, things will start to go downhill. Most of the majority will fail in implementation, because they wont adapt the methodology and process model.

While I was writing this post, I happened to read a blog post which was titled "How Good Becomes the Enemy of Great". It manages to say a lot more clearly what I'm trying to say here. There are no silver bullets, you must keep your eyes open and adapt to your own situation.