I have updated the look of the blog as well as the underlying blog software. I have also switched from http://outten.net/weblog to http://blog.outten.net. I had been using a customized version of Typo.

The new blog is running my own combination of Sinatra and CouchDB. I have been using Ruby for a few years now (after starting with Rails). I was curious to see what some of the other Ruby frameworks had to offer. I have tried Camping, Ramaze and Merb. All had some really strong points and I started rewriting my blog in each of these, but did not finish with any of them.

When I first looked at Sinatra, I didn't have a great first impression. I went away and looked at some of the other frameworks mentioned. After dabbling in each, I ran across Sinatra again and really dug it. About the same time I had become interested in CouchDB and really wanted to give it a try. That's when I started playing with a Sinatra and CouchDB combination. They seem to be a nice fit even though I could have written the entire blog in Javascript.

I am planning to release the code in the future in case someone else would like to use it.

Features

• multiple blogs hosted by the single instance
  • each blog uses its own CouchDB database
• plug-in for protecting a blog by requiring users to identify themselves
• admin application separated into a different Rack module

Do you remember in school when you used to have the word problems in math? You had to read a paragraph and then pick it apart for certain key words. You might look for "of*" or "times" to indicate multiplication or "more than" for addition. I remembering doing fairly well at these *word problems (not that I enjoyed them), but I didn't really understand how much these were going to apply to me in the future.

It turns out that in the technical field (and probably others) I am constantly dealing with word problems. There are 2 ways that I see them represented:

1. in general email sent each day (applies to non-technical as well)
2. in specification, requirement or similar documents

Last night, Esther Derby came and talked to the local Agile RTP group. Her talk was called "What's a Manager To Do?". With agile teams being self-organizing, what is the manager's role in this situation? An agile team can start to take on some of the items that a manager used to do. Task assignment and tracking are two items that seemed like good candidates for the team to take over. There are some things that require a manager that aren't going away. HR related issues and budgeting are two examples.
There are several grey areas that could go either way depending on the maturity and organization of the agile team. For instance, conflict/friction issues might need to be handled by a manager, but for the health of the team, might be best addressed at the team or individual level. If someone reports to their manager that someone on the team isn't performing and the manager goes to this individual and says 'I heard you weren't performing (doing or not doing X)', this isn't going to be good for the team. Who can they trust on the team? If the team has been letting an issue fester for a long time (not addressing the issue with the other team member), this can cause even more issues. From Esther's experience, it sounded like 1) openness between the team members is critical and 2) the manager should really fine tune their observation skills so they can catch issues as they come up.

Another grey area is the decision making process. If the team assumes they have the right to make decision X and the manager vetoes this right, that can really discourage the team. It can also work the other way where the team is assuming the manager is going to make a decision, but the manager is expecting that from the team. Esther's suggestion was to layout a decision matrix that helps clarify who is responsible for making decisions. Although it wasn't directly said (or I didn't hear), I suppose this helps with the transparency of the team which is a common theme in the agile space.

An underlying theme, from my perspective, was the reference to teams, in particular team sports, where it truly is a group of players working together (her example was basketball). Many of the agile concepts that appeal to me came from my experiences playing basketball. I am frequently reminded of how my experiences playing on a team were so similar to being on a team at work. Everything from how to interact with others to keeping a goal in mind and staying on target.

Overall, the talk was good and reaffirmed some of the ideas we were already using. Clarifying decision making, dealing with friction and the "team" concept were some of the key points I am taking away from last night.

This (home grown) blog is now running on Ruby 1.9. Since I wrote it using Sinatra and couch-rest, it was pretty easy to get working. The only real trick was adding a fake JSON gem to fulfill a dependency on JSON (which is now part of Ruby 1.9). I found this reference on the IsItRuby19 which came in very handy in determining which gems work on Ruby 1.9.

I really like CouchDB and the flexibility it provides. It is currently under heavy development (the last release was an incubating release) and things are changing frequently. Most of the time, this means improvements or new features, but sometimes this leads to breaking backward compatibility. The other night I tried the latest clone of couchrest with this commit. I looked at the breaking changes page (based on the comment on the commit on github). I found the reference to the moved view URLs which was the problem I was having. After reading the discussion on the mailing list, it sounds like it is a good idea and is worth breaking backward compatibility.

To update to the latest version of CouchDB (basically working from the trunk), here are the steps I took:

1. installed couchdb-python using this script
2. dumped each database using the couchdb-python dump.py described in breaking changes
3. shutdown couchdb and make a backup (for example, I tar'ed my /srv/cocuhdb directory)
4. pull down the latest copy for couch from svn or github
5. build and install CouchDB
6. start the new version of CouchDB
7. go into Futon (for example http://localhost:5984/_utils) and create each database
8. load each database with load.py from couchdb-python again described in breaking changes

After upgrading CouchDB, I then had to update my application to use the latest couchrest.

While playing sports (namely basketball) for a number of years, I played on a number of different teams and had a number of different coaches (2 main coaches in high school and college). Looking back, it was very interesting to see the different styles in coaches and players. I was pretty lucky for the most part, the majority of my experiences were on teams that understood the concept of "team play".

One thing I didn't completely realize was how important the coach's leadership was and the values they instilled. When a player first joined the team, they wouldn't completely fit in or at the very least they would struggle a litte. Having these core values, provided by the coach originally and promoted by upperclassmen, the freshmen (or new transfer) has a base to build from. As they grow as a player and person (going from freshman to sophomore and so on), their playing skills would develop, but they would also continue to 'buy-in' (or gel) to the team values. Of course, this happened at a different pace for everyone depending on the player.

I am starting to see that again in the agile software development. As teams shift and grow, you go through this process over and over. I think it is important to have those underlying values, but the overall appearance of the team will reflect the current players. I am learning there is a delicate balance between emphasizing values, letting the team gel and using the strengths of the new players. If too much emphasis is placed on values, it suppresses the strengths of new players. If the values are shifted too much, you lose the history that has brought you success in the past. I feel like it is somewhere in the middle that allows your team to gel the quickest depending on the number of returning starters you have from the previous season (or project).