Kallokain

I had some good news a couple of days ago, and I just can't resist toting my own horn a little. A couple of years ago I was subcontracted to write a web based print formatting system. The system could automatically produce brochures, and used FrameMaker as a formatting engine. I haven't counted this system as one of the great successes of my career. FrameMaker and Internet Information server did not play well together. (Neither did Apache and FrameMaker.) In the end, I solved the problem by writing a small web server of my own. Though the solution worked, my client was not happy with the design. He insisted he wanted the application to run under IIS, even though it was not technically possible. Fortunately my client's client did accept the solution. Still, my client wasn't happy, so I wasn't happy. Earlier this week a friend of mine told me what became of my 'failed' system. The system has worked very well for more than five years now. The customer estimates

A friend and I spent an enjoyable afternoon debugging a Rails application yesterday. "Enjoyable" and "debugging" usually don't go together, but in this case they did. My friend, who happens to be a much better programmer than I am, was stuck on a bug. His application had a form that worked correctly the first time it was used. The second time around, values filled in the first time reappeared in the form. In the end it turned out that an automatically generated find_xxx_by_id method returned the wrong data the second time it was called. (My friend is filing a bug report.) Our excursion into bug country was enjoyable because we solved the problem as a team. It made it easier to keep focused. There was communication. We could bounce ideas off each other. I learned a few new things about ActiveRecord. We solved the problem, and the bug report may save other people some trouble in the future. It was a good half days work.

The connection to www.henrikmartensson.org is incredibly slow at the moment. Don't know why. My site host and I will look into it.

Avoid method name collisions by mixing in modules to an instance of an inner class. class Outer class Inner end def initialize(mixin) @inner = Inner.new() @inner.extend(mixin) end ... end When extending objects with mixin modules, there is a risk of method name collisions. Given the example in the Module Injection post , the execute_before and execute_after methods in the Strategy object might collide with method names in a rule module. Suppose the rule module looks like this: module TransformationRules def functiondef_before(element) ... end def functiondef_after(element) ... end def execute_before(element) ... end def execute_after(element) ... end end When the dispatch mechanism in the Strategy object finds an execute element, it will dispatch the element to the wrong execute method. It will call the execute_before method defined in Strategy, not the one defined in the TransformationRules module. Pollution Control reduces the

Signal that objects of a class is designed to be extended via mixins by passing the mixin module via the constructor. class ExtensibleClass def initialize(mixin) extend(mixin) end ... end Ruby allows objects to be extended with new functionality at runtime. Any object can be extended in this manner by a call to the extend method. Some classes are designed to have their objects extended with new functionality. Example Consider a Strategy object that encapsulates a set of transformation rules for XML documents. The document is used by a treewalker. The treewalker walks the node tree representing the XML document. The Strategy class uses Module Injection: strategy = Strategy.new(io, TransformationRules) treewalker = TreeWalker.new(strategy) treewalker.walk(xml_document) The strategy object contains dispatch code that chooses which transformation rules to call depending on such things as node type (element, processing instruction, text, etc.) and node name. The Strategy object

My publisher (Apress) is looking for an author interested in writing an advanced book on Rails. They work with new authors all of the time, so prior writing experience isn't necessary. If you're interested send myeditor (Jason Gilmore) and email at jason@apress.com .

I attended a talk by Lars Taxén about Integration Driven Development and Anatomies today. IDDA is a development methodology for large projects. "Large" means 1,000+ people. IDDA was developed at Ericsson for use in telecommunications projects. One of the things I found interesting was that the anatomies part, a method for modelling complex systems, is quite similar to Domain Modelling. That is, both methods aim to create models that mirror real world objects or processes. Anatomies, like Domain Models, make use of bounded contexts to separate different parts of the system. Some things were very different from what I am used to. For example, IDDA subsystems are implemented in the order they are activated when the system is used. That is very different from the Agile practice of implementing the most valuable functionality first. For example, consider a document production system consisting of three subsystems: an XML authoring system, a Document Management System (DMS), and a