Man…. When it rains it pours. The automation system upgrade didn’t go according to plan and we had to roll back the changes. Unfortunately, the roll back made things worse, and we discovered that there was a time stamping problem so our automated backups were failing but not reporting that they were failing. As a result the database is being slowly reconstructed and updated by hand (yuk!).
It is now 10:35am and I haven’t gone home yet (got here at 7pm yesterday). At least when I’m done with this my weekend begins.
I thought the title of an ok CD by DJ Dan would be perfect to borrow for this blog post.
I’m here at work for some maintenance to the automation system as well as our Samba server. Unfortunately the Samba server had some unexpected complications but I was eventually able to get it sorted out. Next is to get an additional two machines up and running in the automation system and then upgrade the software system wide.
If Craig & Mike get finished there will be room for the another 3 servers in the rack which are desperately needed.
Published in Uncategorized
.
I had totally forgotten about Cygwin until today when I came across a text editor for windows that can use textmate bundles. In their forum there was a post about e needing Cygwin to do some of its automation.
I used to cygwin years ago, and the idea of having unix tools on windows is extremely appealing. Microsoft is only recently coming on board with the idea of command line automation scripting with their introduction of Powershell. Powershell is definately something I’ll look into. Still, its nice to be able to install tools that are intended for linux or mac use and not have to set up a virtual environment to play with them.
I’m also looking forward to seeing how well e works.
Published in Uncategorized
.
A week or so ago I downloaded the peepcode screencast on Test First Development. It was the first really clear example on Test Driven Development I’d seen and it helped clear up a lot of questions I’d had about it.
I was introduced to the idea of writing code based tests when I started learning about Ruby on Rails. When learning PHP (or any other language for that matter) it was not something mentioned in any of the literature I had encountered. But as Rails takes an “agile” approach to things, writing tests are an expected part of development.
Shortly after beginning my exploration of Rails I was hanging out in the #railsonrails IRC channel and Luke Redpath was talking about Behavior Driven Development (BDD) a variation of Test Driven Development (TDD). I was totally lost but wanted more information. He suggested reading Kent Beck’s book “Test Driven Development By Example” first and get familiar with that before trying to wrap my head around BDD. I promptly added it to my Amazon Wishlist and there it stayed until today. After watching that peepcode episode, I decided that I would finally plunk down for a copy of the book and today it arrived in the mail.
As the title suggests, this is my first book specifically about Agile Methodologies. While the Agile Web Development with Rails book is technically an Agile book it is more about the Rails framework than evangelizing and explaining any specific processes or philosophies. I’m looking forward to exploring the world of writing automated tests for my code prior to doing any sort of development. Hopefully it is as helpful as I expect it to be.
Published in Uncategorized
.
Well in my effort to develop my programming skills I’ve spent a lot of time listening to various software engineering podcasts lately. The most common theme throughout the podcasts has been Agile Development in its various forms. Some dealt strictly with XP and others dealt with Agile in a more general sense.
One person interviewed on two separate podcasts really caught my attention: Alistair Cockburn (pronounced Coe-burn for the non-Scottish). One of the original founders of the Agile movement, and someone who spent several years actively researching software development methodologies, Alistair’s approach was very practical and refreshing.
In an nutshell, he found that anything that made a development team work better together was good and should be kept and anything that inhibited productivity should be tossed out. The humor of this is emphasized in the fact that Alistair is a Ph.D.specializing in methodologies and has developed his own Agile methodology called Crystal Clear.
To be sure, he does identify certain practices that when applied often lead to an increase in productivity. However what separates Alistair from most other Agile methodologists is that he is not rigid in the implementation of his or any other best practices. This was captured in a story he told about how he was brought in to an organization implementing XP and struggling with the weekly meetings. The developers weren’t enjoying them and as a result were not benefiting from them. But since they were a part of XP the meetings kept happening. Once Alistair discovered this, he suggested that they drop the meetings until the next evaluation cycle (3 weeks later) and see if losing the weeklies helped. The solution while simple was revolutionary to the team because it showed them that nothing was set in stone and that they could choose what worked best for them in the situation/project they were working.
When looking at Crystal Clear you get a clear picture of the best practices that Alistair values most:
1. Frequent Delivery
2. Reflective Improvement
3. Osmotic Communication
4. Personal Safety
5. Focus
6. Easy Access to Expert Users
7. A Technical Environment with Automated Tests, Configuration Management, and Frequent Integration
Each of these are relative and flexible in their implementation and need to be defined based on the values of the development team and the requirements of the project but when applied they consistently yield an increase in productivity.
What makes this approach so refreshing is that the ultimate goal of the methodology is to help development teams make better software and enjoy the process. The flexibility on the specific implementation of methods while holding fast to the values that inspired those methods is profound and shows a true grasp of the complexities that each project has the potential to bring to the table. Ultimately it also comes closer to the values espoused by the Agile Manifesto than other methods that are more rigid in their implementation.