I’ve consolidated the material that was in ZeeForge back into the Zeetix sites and blog. I may relaunch ZeeForge someday (I still love the concept), but as of January 2013, it is inactive.
I’ve imported the everything, so the dates and headers have remained unchanged.
I’ve refactored and rewritten most of the zeeforge.com site to reflect my focus on building a consulting/contracting revenue stream to sustain ZeeForge in this abysmal investment climate.
The entire site is built using Glooper, the website generator used for the Zeetix family of sites. As part of the relaunch, I added enhanced sidebar capability to Glooper. In addition, I’ve found a set of patterns for css that finally seem to work reliably and well for the sorts of multi-pane compositions that dominate the new ZeeForge look.
The new site also makes widespread use of a new (for me) approach to presenting, structuring, and handling browser forms to make it easier for users and visitors to request additional information. The new form handling capability is built around “Clacks”, a non-intrusive and relatively lightweight ZeeForge project that provides a convenient and object-oriented abstraction for browser/server exchanges. Clacks wraps XmlHttpRequest machinery in code that avoids several usability and reliability problems associated with more naive implementations.
For our new visitors, welcome to the ZeeForge blog. We encourage you to ask questions, leave comments and feedback, and visit often.
I’m in the process of refactoring ZeeForge as my portfolio, so that prospective clients can see how I work.
I’m using http://www.zeeforge.org as a site from which I will host popular open-source services for users and visitors, including prospective clients.
The first service I’m adding is MoveableType, the famous Perl/PHP blog. I’ve been exercising it locally on my WinXP system, and over the next day or so I’ll deploy it onto the zeeforge.org site. I’m using this entry to journal that process.
I found the initial installation on WinXP (using an apache webserver) to be relatively straightforward. I’ve had the usual collection of configuration and pre-requisite snafus, nothing too serious.
I note that the directory structure assumed by MT is a little different from my usual practice. In particular, it expects its resources to be unpacked into my standard “site_root” directory, peered with cgi-bin and public_html. Each new blog, when published, creates a directory in this site_root.
I’ve also had trouble locating a WinXP-compatible form of Image-Magick. I remember this problem from earlier perl thrashing, and I’ll get to it later.
My goal is to create a demo site (and url) where prospective clients who are interested in my ability to support blog services like moveabletype can see my work in-situ.
Problem:
A specific page in a Glooper site needs to be handled specially, with behavior provided by a new descendant.
Contemplated solution:
Add protocol that allows the new behavior to be supplied in a block, supplied by the descendant, that calls back to descendant code when the page is generated.
Approach:
1. Create spike solution to validate that the approach works and settle on the required new method(s).
2. Add tests to GenericGlooperStructureTest to document new behavior.
3. Adjust spike solution as needed.
4. When PageContainer is working with new behavior, add code to the new site that uses it.
I’ve been heads-down with Glooper since February, and it’s way better now.
It has tests (hooray), I’ve refactored it so that it will fit into the Zeetix (Hex?) world, and I’m now using it every day to update the Zeetix sites. I’ve published the first site out of the new Glooper chute — check it out at http://www.zeetix.com.
As soon as I get a chance, I’ll add a post here describing the Glooper product/feature/assembly structure, including its test assemblies.
Glooper began as a website development tool I wrote in Smalltalk and called (for want of a better name) “SiteBuilder”. While SiteBuilder was cool and worked well enough for my needs a few years ago, it had several serious shortcomings that I needed to fix:
I’m sure there were more motivators, but those were the three big ones. I’ll post more entries here describing the changes I made.
More immediately, I’m now in the middle of Glooper’s next real test — an update to a site I built with its old version. I’ll be blogging my experiences here.
The site is for a real paying client (Ambiance Painting), an upscale painting company in Connecticut. The client wants to “spruce up” the site, add a blog, and include archived and current issues of a monthly newsletter distributed using ConstantContact.
Stay tuned!
I’ve discovered (or rediscovered) an exquisite hack — a way to add or (in this case) replace methods of an existing but out-of-scope module, and then put them back again.
Motivation
The minimal ZeeUnit is intended to discover the minimal Zeetix kernel. It therefore should not depend on any clazzes that are outside the Kernel assembly.
In order to reliably restore the underlying database (from which the Kernel clazzes are loaded), it uses code within the existing kernel that (incorrectly) requires clazzes from two non-kernel assemblies — Admin and Command.
I needed a way to use the existing kernel code, while not adding these two big warts to ZeeUnit. I therefore cloned the required clazzes into KernelTest.CoreTest, and made minor edits so that they work.
Unfortunately, two kernel clazzes — ItClazz and ItRecordClazz — contain methods that expect to find these missing clazzes in their original location.
I therefore needed a way to temporarily replace the offending methods so that the new test code works properly.
Solution
I borrowed a paradigm from Smalltalk — Smalltalk-style class extensions. A class extension, in Smalltalk, is a group of methods that can be atomically added or removed from an existing Smalltalk class. This behavior is simulated in Ruby by the Ruby “module” mechanism.
It turns out that a Python class uses a dictionary-style mechanism, similar to Smalltalk, for method dispatch. Python supports adding and removing methods from classes, at run time, by assignment operations on the class. The trickiest part is determining the specific Python class that is associated with a given Zeetix clazz (or Metaclazz).
I used the setUp and tearDown hooks in TestCase to install and then remove the special methods, leaving the Kernel unaffected except while running the test(s) in question.
Result
The result is that the special behavior added by the new test case is available to every existing instance of every Zeetix object, without modification. This proved extraordinarily valuable in this case, because the desired behavior is used across the clazz and metaclazz hierarchy. The resulting code works like a charm.
(more…)
I’ve added a slew of new tests that validate the persistence clazzes (ItRecord descendants).
They exposed an insidious bug, that I’m now repairing: SetRecord and SortedCollectionRecord have never been correctly loaded. Worse, the record_id of their behavior entry is wrong — it is “0”, which should never happen.
This, in turn, means that I now have to adjust the database cleanup and setup routines so that they can be called from regular code, instead of the browser-based admin tools. I suppose I’ll have to be disciplined and write a new test case that confirms THIS change.
The database cleanup and setup routines are invoked from “prepareForDebug”, which is located someplace in the ZeeLife root. I suppose now is as good a time as any to go find and capture it.
In addition, all this means that I’ve started to populate the sql branch of the git tree. I need to move the Kernel.ZeeStore records around. The sql branch is organized like the python and ruby branches; the sql for each assembly/subassembly is located in a correspondingly-named subdirectory of the sql branch.
The new ZeeSuiteTestCase demonstrates the aboutToRun and finishedRun bugs that I found in the original SUnit, and therefore ZeeUnit, test suite.
Interestingly, it demonstrates the utility of clazz instance variables. In this case, a message (aboutToRun and finishedRun) was being sent to all descendants of TestCase instead of just the TestCase descendants whose instances were contained in whatever TestSuite instance was being run.
I created a descendant — CountingTestCase — that contains two clazz instance variables (“ranAboutToRun” and “ranFinishedRun”). It hooks the aboutToRun and finishedRun clazz methods and, within each, sets the corresponding clazz instance variable before delegating to its superclazz (TestCase). It also contains a trivial instance method, “dummy”, that TestSuiteTestCase uses to instantiate test instances. I then created two descendants of CountingTestCase — “ShouldNotRunTestCase” and “ShouldRunTestCase”.
The tests within TestSuiteTestCase (there are currently four of them, two each for aboutToRun and finishedRun) create a new TestSuite and add an instance of ShouldRunTestCase that invokes the “dummy” test method. It then asserts that the ShouldRunTestCase clazz method was run and denies that the ShouldNotRunTestCase clazz method was run.
The initial version of ZeeTest (and SUnit) fails this test.
I then modified the aboutToRun and finishedRun instance methods of TestSuite to fix the problem (see the “Python closures and collections are broken” flame for more).
I then committed and pushed the new code to the git repository.
Now that this ZeeTest bug is fixed, I can resume working on the KernelTest.CLDTTest and KernelTest.AssemblySupportTest subassemblies.
ClazzDevelopmentTest
I’ve defined a new test subassembly, ClazzDevelopmentTest, with three new test cases:
Refactored KernelTest hierarchy
Most of the tests in the KernelTest subassembly hierarchy need to validate Kernel clazzes for correctness. Since every Clazz is built to the same pattern, this validation code is common to all of them. Rather than copy the validation code among each TestCase descendant, I refactored the module hierarchy so that those tests inherit from an abstract “ClazzValidator” (itself a descendant of TestCase) that provides the validation behavior.
I’m aware that this might better be accomplished by applying the strategy pattern, relying on delegation instead of inheritance, but this works for now. It is “the simplest thing that can possibly work.”
This has two immediate benefits:
A “landmine” bug found and fixed
Part of the SystemConfiguration validation test is to verify that the size of the global namespace (“them”) is non-zero. As it turns out, the size reported by SystemDictionary (the clazz of “them”) is always zero. Ouch. The dictionary exists and is the correct size; it is the method that answers the size (“doSize”) for just this Collection descendant (SystemDictionary) that is broken — Set and SortedCollection work just fine.
This, again, is the sort of bug that is pernicious and hellishly difficult to track down. The instance works most of the time. Debuggers report its size correctly. When the bug causes a problem, the symptom is often far removed from the source — in both time and lexical space. The code that needs the size may likely be correct. The code that contains the bug ran a long time ago (at startup, in this case) and in a faraway place (in the Kernel.Core.CLDT subassembly).
I call a bug like this a “landmine” bug (not to be confused with another equally pernicious category, the “timebomb” bug). A landmine bug is a bug that makes a system work nearly all the time, until you step on the landmine. Then — “boom” — the landmine goes off, and the developer is left wondering “what happened?”
This means that the KernelTest.CLDTTest subassembly needs to include a test case that validates that each concrete descendant overrides doSize to answer the correct value (for that descendant, of course).
The more general learning is that we will need a way to specify, as part of an interface, that descendants of a clazz correctly implement the hooks required by that clazz. This, in turn, means that the universe needs a family of interface abstractions and an associated way to test them (see below).
I love unit tests.
KernelTest.CLDTTest subassembly
Validates the existence and correct behavior of the Kernel.CLDT (Common Language Data Types) clazzes. In this case, these are the clazzes that support collections with the Zeetix universe.
to do: Create a test case that validates that doSize is correctly implemented in each concrete Collection descendant.
InterfaceSupportTest and InterfaceSupport
Validates that the InterfaceSupport clazzes exist and operate correctly. When a resource, assembly, or feature claims compatibility with a specific interface, these tests validate that claim. When a resource, assembly, or feature claims to provide a specific existing existing or new interface, these tests validate that claim.
The Ubuntu desktop gets in the way too much. The core functionality is surprisingly good, and the collection of miscellaneous distractions in moving from Windoze (lower screen resolution, missing bookmarks, missing address book, no email history, …) is too much of a distraction right now. There appears to be astonishing new and needed functionality FOR FREE in this world (see
below), and I need to finish the task at hand before I get distracted by
the cool new stuff that beckons.
It was astoundingly easy to migrate yesterday’s work from the Ubuntu platform back to this one. Git/Github is amazing.
