Kallokain

Culture is not a product of what management says, it is the result of what management does. - Bill Waddel in the Evolving Excellence blog, 24th of January 2006

If you are bored with all the new fangled Agile stuff, why not try a more traditional approach to software development?

I think I might have a previously uncatalogued refactoring here. This is an alpha version. If at least a few people find it useful, I'll do a proper writeup. Here goes: You have two classes or mixins with similar features. Create a mixin module, and move the common features to the mixin. This refactoring is applicable with languages that support mixins, like Ruby. Motivation The primary purpose of Extract Mixin is to eliminate code duplication. In this respect, this refactoring is very similar to Extract Superclass . There are some noteworthy differences: Mixins are not a part of the inheritance hierarchy. Thus, it is possible to mix any number of mixins into a class, or into other mixins. Consequently, mixins are more flexible than class hierarchies. Mixins can create instance variables, but this introduces the risk of naming conflicts. Therefore, this refactoring is safest with methods that get all their variables as parameters to the method call. Extract Mixin

I think I accidentally discovered two new refactorings today, Extract Mixin and Replace Mixin With Class . (I'll make detailed writeups in a day or two.) This morning I found myself in central Gothenburg with nothing to do for an hour before a meeting, so I ducked into a cafe, had a cup of tea, and began refactoring Test::Unit::XML. If you have had a look at the code in the assertions mixin, xml_assertions.rb , in version 0.1.4, you'll notice that it is fairly heavyweight, weighing in at more than 220 lines of code. This is a fairly large chunk of code, and all of it is for a single assertion, assert_xml_equal . A big part of that code is for comparing different types of REXML nodes, REXML::Element, REXML::Text, and so on. The node comparison code was split into fairly small methods, so it wasn't too shabby, it was just that it was located in the wrong place. It made sense to move that code to a class of its own. I did consider moving it to a mixin module, but in the end I

I just checked some Test::Unit::XML download statistics over at RubyForge . Looks like 15 people have downloaded the package so far. (The chart says 18, but I have made three test downloads myself, so they don't count.) Due to the smashing success, I am going to treat myself to a bit more Ruby programming tomorrow.

Time for a development diary entry. I've just released Test::Unit::XML version 0.1.4, an XML test framework for the Ruby programming language. This release adds doctype comparisons to the assert_xml_equal assertion. There are also improvements to the documentation , and minor updates to the tutorial . Barring bugs, assert_xml_equal is now finished. The next release will feature at one more assertion. I'm keeping the releases really small in order to provide new features as frequently as possible.) Internally, the structure of the framework will change substantially. In version 0.1.4, the bulk of the functionality is in the xml_assertions.rb file. This includes a truck load of methods for comparing various elements. These will be factored out into a separate class. From release 0.1.5 onwards, xml_assertions.rb will delegate as much work as possible. Version 0.1.4 has 17 tests, with a total of 67 assertions. That's a lot of tests for testing a single assertion. Still, I

I had a thought while doing a bit of editing on my previous blog entry . One thing that could be useful to software development projects is a set of patterns for project managers, like design patterns for programmers, or system archetypes for line managers. Most development methodologies have plenty of artifacts, but no management patterns. It may be that the systems archetype pattern language from Systems Thinking is a good fit for this. I need to cogitate a bit on this, and try a few things out, but I will return to the topic.

I visited the easyFair convention at the Swedish Exhibition Centre in Gothenburg today. I found three different vendors who sold project management software. All three products had functions for tracking the cost of a project. This isn't surprising of course. What I found interesting is that all three products used the same economic model to do it, and that model is wrong. Huh? How can that be possible? It is not as strange as it sounds. All three products had functions for tracking the hours worked by each project member, multiply it with the hourly cost, and sum the costs for all project members, like this: project cost = Σ(cost/hour * hours) A simple formula, but there is something missing. Try this one instead: project cost = Σ(cost/hour * hours) - profit The profit here is what the customer earns from getting frequent partial deliveries during the course of the project . (It's not the total profit from the project. Oh, how I wish for MathML support in more browsers.) In

I just added a link to Poppendieck.LLC . This is the web site of the famous management experts Tom and Mary Poppendieck. Their book Lean Software Development is a must for anyone, customer, manager or developer, seriously interested in software development. There is a sample chapter here .

I had a look at the Standish Group's CHAOS report of 2001 . The report contains an analysis of the factors that contribute most to project success. In order of importance, the factors are: Executive Support User Involvement Experienced Project Manager Clear Business Objectives Minimized Scope Standard Software Infrastructure Firm Basic Requirements Formal Methodology Reliable Estimates Other According to the report, the top item, Executive Support, is about 3 times as important as the number eigth item, Formal Methodology. When I hold talks about software development, which I do a bit sporadically these days, I am most interested in talking about the top five items on the list. Not because of the report, BTW, but because my own experiences, and those of others, have led me to believe that these factors are important. I also like to talk a bit about number eight, Formal Methodologies. This is because of a personal belief that methodology matters a bi

Stephen Chu (whom I don't know) has some interesting tips on writing Stories for agile software development . I found his posting on ThoughtBlogs , and it prompted me to have a look at Chu's blog . Interesting stuff on .NET, Ruby, and development in general.

The Declan home page is up and running. I have also uploaded some prototype code to the SVN repository at RubyForge . This is just the beginning though. A release is a long way off.

My friend Ari Nordström mentioned Kallokain and me in a recent blog posting. I thought I'd return the favor. Ari's Blog has a much wider range of topics than Kallokain. Ari's recent posts span a range of topics, including XML (he is a very skilled information analyst and XML designer), Linux, authism, writing, chess, and how to counter pfishing and similar confidence scams. Why not pop over and have a look? You might like it.

One of the things I like about Extreme Programming is the spike solution . A spike solution is a small, focused effort to explore a possibility, or solve a problem, by writing code. I worked a bit on Declan today. Declan is the declarative XML transformation system I wrote about in a previous post. I have a very simple Declan prototype up and running, but it has one little snag: declarative Declan statements must be part of the body of a class declaration, or they won't work. I want to be able to write a file with rules, and then load those rules with a load or require statement. This would be easy to do, but for one thing: as the rules file is loaded, Ruby will execute the statements. This is not a problem per se, but the Declan statements will change the state of the application. I need to store that state, without having an object handy to store it in. Being something of a Ruby tenderfoot, I'd like to explore the solution I have in mind before committing serious effort to

If you are working with XML and Ruby, you might want to have a look at Test::Unit::XML, a unit test framework for XML documents and document fragments. The following is a short tutorial to help you get started. This version of the tutorial is for Test::Unit::XML version 0.1.4. Downloading and Installing The easiest way to download and install Test::Unit::XML is to use gem, the Ruby package manager. All you need to do is this: gem install testunitxml You can also download Test::Unit::XML from the download page, and install manually. If you install from the tarball or Zip archives, you need to: Unpack the archive file Run the script setup.rb from a console window. Testing XML Documents Let's try something easy, just to see how Test::Unit::XML works. Assume that you have two XML files that you wish to compare. Lets call them expected.xml and actual.xml. If you wish, you can pretend that actual.xml has been created by some software that you want to test. Fire up a text editor and crea

A couple of months ago I wrote some XSLT stylesheets to extract information from W3 Schemas, and generate documentation from them in HTML format. I can't say I didn't have fun, because I did (I'm easy to amuse sometimes), but as always when I am working with XSLT, I wished I had a better way to do XML transformations. XSLT is a powerful transformation language, but it is also very verbose, and the XML compliant syntax is definitely not designed for editing with a text editor. Also, you often need to write an application in some other language to get a complete application. Transformations are usually only a part of the job. I had just become interested in Ruby, and also came into contact with Rake, a make-like (Ant-like, for Java programmers) build utility. Rake is written entirely in ruby, and has a very nice declarative syntax. While I was immersed in Ruby/Rake, some of my XML neurons suddenly fired up. If Ruby is good for writing a declarative build language, maybe it is

It's done! I have a blog.