Posted by Eric Stewart
Sun, 01 Jun 2008 18:26:00 GMT
The first time I wrote a program for a computer was nearly 30 years ago. Of course, I was a kid writing simple programs and learning from the code that I typed in from a magazine or a book, but I was still programming. My father and I would sometimes take turns at the keyboard with one of us typing and the other reading out the code or making a suggestion. Little did I know that I would eventually choose a career that not only involved writing code for computers but also leveraging collaborative practices like the pairing that I experienced with my dad.
Fast forward to the present. I’ve been creating software professionally for 12 years. In that short career, I’ve experienced processes from well-defined lifecycles to ad-hoc and chaotic. One of most interesting experiences has been with processes under the category called Agile. In the upcoming series of articles, I will talk about some of my experiences and challenges with various teams attempting to be Agile.
My initial agile experience was with XP (eXtreme Programming) shortly after I read Kent Beck’s first book on the topic. My experience involved some initial attempts to adopt some of its practices, a very productive year with a small XP focused team, and many years (up to the present) using many of these practices in various ways. That XP focused team tried to go “by the book” and was a success though some definite lessons learned.
More recently my journey has led me to Scrum. It started with the all too common tale of a technology group saying they were practicing Scrum by having daily meetings where all team members reported their status. But with strong interest from the Director of Engineering and some of the team members (plus some outside training thrown into the mix), we have become a team that uses Scrum as a framework for improving how we work and deliver. We are now seeing obvious benefits.
It hasn’t been easy. There have been plenty of challenges along the way. Scrum/XP/Agile are just some of the many ways to deliver software but they offer a basis for teamwork and delivery that I enjoy. I hope to follow up with some of the successes and challenges encountered along this journey.
Posted in Software Development, Agile | 1 comment | no trackbacks
Posted by Eric Stewart
Sun, 16 Mar 2008 03:47:00 GMT
Is Our Happiness Preordained? – Weren’t born with genetic stuff that makes you more likely to be happy? Having trouble achieving it otherwise? If you’re an anxious introvert with high expectations you might benefit from pretending that you are not. That is, if these researchers are right.
Public Service Announcement: Caring for Your Introvert
Posted in Misc. | no comments | no trackbacks
Posted by Eric Stewart
Tue, 29 Aug 2006 03:51:00 GMT
Earlier this year I ventured back from a very enjoyable year building and deploying a project in Ruby on Rails into the familiar territory of Java. Ruby has become cemented as a valuable tool that will certainly remain near the top of my tool box, ready for use.
Right now, however, I’m working on problems that are outside the realm of where Ruby shines (though I’m certain it’ll catch up soon enough). In particular, I recently had the need to research some ideas on creating a solution for a problem that lends itself to distributed computation.
Read more...
Posted in Software Development, Ruby, Java, Technology | Tags computing, distributed, java, ruby | no comments
Posted by Eric Stewart
Sun, 09 Apr 2006 23:08:00 GMT
Can Ruby be useful in the enterprise? Sure! Of course, that depends on what you’re considering it for, how you define Enterprise, and what day it is (the Ruby community is very active on many fronts, and support that was once lacking is rapidly growing in many areas).
I mostly stayed away from the whole James McGovern fracas recently, but since this was one of the blogs he sent a trackback to, I’ll add one little comment that I haven’t seen too many others express. Ruby was never too bothered about its lack of widespread public adoption in the enterprise. It is doing just fine being quite useful in all kinds of environments, meeting needs and providing an increasing number of developers another powerful way to please their customers and themselves. That being said, there are definitely inroads being made.
Consider the public positions of companies that make their living in the enterprise. For example, look at the position posted by MomentumSI. Jeff Schneider has linked to some analysis done by them recently on the applicability of Ruby in the enterprise. I know and have worked with many Momentum consultants over the years and they are very bright people who have a lot of experience in that arena. Of course, ThoughtWorks thinks pretty highly of Ruby too.
Ruby (and Rails) aren’t really striving to become the great enterprise platform. They are trying (and succeeding) to be great tools to help people get things done, be productive, and enjoy their work. I don’t think the community in general cares too much if they aren’t making great strides in the enterprise (even though I think we’ll see much higher adoption there). They are having too much fun using it to do things they are doing now. And as for wondering how Ruby will continue to grow, only time will tell.
Posted in Software Development, Ruby, Ruby On Rails | Tags enterprise, rails, ruby | 1 comment
Posted by Eric Stewart
Sun, 12 Mar 2006 08:03:00 GMT
I never realized the amaroK developers had any affinity toward Ruby.
As a part time user of Linux, usually Kubuntu these days, I occasionally use amaroK for playing music to work by. As Linux music player + library applications go, it’s one of the nicest you can find with some features that you don’t find in many other players.
amaroK, like an increasing amount of modern software, supports scripting to allow users to extend the software’s capabilities. They do this by taking advantage of amaroK’s DCOP interface.
This makes it possible to write scripts in almost any programming language, like Ruby, Python or bash scripting. The recommended programming language is Ruby, which is easy to learn and very well suited for amaroK scripting. The amaroK team will be happy to assist you if you have questions regarding Ruby programming.
Not surprisingly, they even recommend Ruby as a nice way to script the application, though they support other languages.
As development goes on, in fact, they are converting compiled portions of code to scripts that can be customized or replaced. This solution came to light after requests by users to support additional sources of song lyrics and deal with the brittle way they interfaced with such sites.
Sooooo, what to do? Scripts to the rescue! What I did is, ripped the hardcoded Lyrc code out. Ported the C++ code to Ruby. Then added a couple of DCOP calls and script notifications for the communication Script <—> amaroK. Added a slice of XML, and you get your spicy new Scriptable Lyrics Feature, mmh.
There was a bit of reaction in the post referenced above to the dependency on Ruby for the newly converted portion of default functionality. If KDE had a default scripting language (similar to the OS X/Applescript relationship) I’d understand those complaints a little more. But then again, OS X installs Python and Ruby by default along with Applescript and nobody really complains.
Is a dependency on a language runtime very different from a dependency on a given library?
Update: As Cornelius Schumacher points out, other KDE projects beginning to do similar things.
<!- technorati tags start ->
Technorati Tags: kde, linux, scripting, ruby
<!
- technorati tags end ->
Posted in Software Development, Ruby, Technology | Tags extensibility, kde, linux, ruby, scripting | 2 comments
