chanson

Tonight I uploaded a new page to my web site that describes and has links to all of the bDistributed.com Open Source projects that I released several years ago, before I started at Apple.

A lot of people are still interested in it and still use parts of it — especially BDAlias — and with the bDistributed.com web site down now, I figured (with some friendly prodding from the #macsb crowd on irc.freenode.net) that it would be a good idea to put it back online on my own site.

Share and enjoy! It's all under a BSD license, but it also hasn't been touched for years. Portions are obsoleted by thing that came out in, uh, Panther, so take that for what it's worth...

Update: Wolf Rentzsch has generously put BDAlias in his public Subversion repository, including his own updates to it. Thanks a ton!

I'm going to be presenting at the Northwest of Us Programming SIG (PSIG) tonight about the bDistributed.com BDControl and BDRuleEngine frameworks, and demonstrating a rule-based application. I wrote the frameworks and they're Open Source under a BSD license; I encourage every Cocoa developer to check them out, since they can make your life easier.

I'll also give a quick overview of how Interface Builder palettes work, and a palette I've created that acts as a table data source and lets you wire up an object to a table without writing any code.

The full meeting announcement is here on Jon's weblog: PSIG 68: Thursday, September 4th, 2003

For those who don't know, the Northwest of Us is a Macintosh User Group in the northwest suburbs of Chicago, IL. The PSIG meets at the NWoU office in Palatine, Illinois a couple blocks northwest of the intersection of route 53 and route 14.

Jon reminded me tonight that I needed to post about this somewhere.

I shipped new versions of the Open Source BDControl and BDRuleEngine frameworks and the BDRuleEditor application. They're all targeted developers writing Cocoa applications in Objective-C on Mac OS X 10.2 or later. They'll probably build just fine and be usable on Mac OS X 10.1 as well, but they're built for 10.2 now. They're on the bDistributed.com web site as separate source and binary tar archives, except for the actual BDRuleEditor binary.

There's a major API change in BDRuleEngine 1.1 that isn't backwards-compatible with BDRuleEngine 1.0. It corresponds to a change in the ruleset format. There's a couple new methods that can load old-format rulesets, but all writing uses the new format. The new version of BDRuleEditor understands both formats and will automatically convert a ruleset if you open it and save it.

There's another major change to both frameworks: They're built solely to be embedded in applications. That is, they're built with their internal install path set to @executable_path/../Frameworks rather than /Library/Frameworks. You can put them in /Library/Frameworks or in ~/Library/Frameworks or pretty much wherever you want, and they should work just fine so long as you add a "Copy Files" build phase to any project that uses them to embed them in the resulting package.

Oh, and finally, the new release of BDRuleEngine adds an additional BDAssignment subclass: BDPropertyListAssignment. If you create a BDPropertyListAssignment and specify its value as the string (either old-style or XML) representation of a property list, it will automatically convert the property list to an actual property list object of the appropriate type. This is very handy when you need to return collections of values from fired rules, for instance, the property keys to display for a particular type of object:

R1. inspectedObject.class.name = 'ClassA'
    => displayedPropertyKeys = "(foo, bar, baz)" [100]

R2. (inspectedObject.class.name = 'ClassA') and (inspectorType = 'overview')
    => displayedPropertyKeys = "(foo)" [100]

If the right-hand side of the above rules was a regular BDAssignment then the result of asking for displayedPropertyKeys would just be a string. But with a BDPropertyListAssignment it's an array containing some strings. Keen, huh?

I think that's it for the major changes. For more detail, see the release notes in the documentation.

Ian Wij, Writing Code is Stupid

Get thee to WebObjects and take a look at Direct to Web and Direct to Java Client. Oh, wait, he's a "Microsoft Consultant." Never mind.

It's not clear if that means he's a consultant specializing in Microsoft non-solutions, or if he's actually providing consulting services on behalf of Microsoft. Either way, he loses because he's going to continue to wait for Microsoft to slowly reinvent what some of us have been using for a good long while.

One of these days I might just make good on my threat to develop Direct to Cocoa using BDRuleEngine and GNUstep Renaissance. Or maybe if I talk about it enough, someone else will go ahead and do it for me and I can just use it. (Yeah, that's the ticket.)

I'm giving a short presentation at the next Chicago Cocoa and WebObjects User Group (CAWUG) meeting this coming Tuesday.

Jon Rentzsch is going to give an overview of Direct to Web, the rule-based system for generating web applications automatically from your data model in WebObjects. Following Jon, I'll be discussing BDRuleEngine, my Open Source framework for building rule-based Cocoa appliations.

More details, including the location, time, and where you need to RSVP if you're thinking about attending are in the meeting announcement at StepWise.

(The RSVP thing is important because the meetings are at Apple's office in the Mercantile Exchange Building in the Chicago Loop, which became access-controlled after September 11, 2001.)

Anyone doing Mac OS X development should check out OCUnit from Sen:te and Log4Cocoa by Bob Frank.

OCUnit is a unit testing framework modeled on the Smalltalk unit testing framework written by Kent Beck, father of eXtreme Programming. I've raved about unit testing here before. OCUnit makes it extremely easy to integrate unit testing into the build cycle for your Cocoa applications.

Log4Cocoa is a straight port of Log4J to Objective-C and the Cocoa frameworks. Bob did a lot of good, hard work and now more developers need to pick up the ball and run with it. For the uninitiated, you use Log4Cocoa to add logging to all the various interesting parts of your code. And that logging can be controlled at run time. It can be useful for debugging hard-to-find bugs, like timing-dependent bugs and multithreading bugs.

(Oh, and if you haven't checked them out yet, be sure to look at BDControl and BDRuleEngine.)

I've released BDControl 1.0.4, BDRuleEngine 1.0.1, and BDRuleEditor 1.0.1. The big difference is that the frameworks are built with an "install path" of /Library/Frameworks, and that BDRuleEditor references the frameworks in /Library/Frameworks instead of the frameworks in the build products folder. This means it doesn't expect its frameworks to be in /Users/cmh/Documents/Projects/BDModel/BuildProducts, which 99.999% of users won't have on their systems...

It turns out that even with the Jaguar developer tools Mach-O binaries still store full paths to frameworks they reference. This is because Mach-O is shit. The Preferred Executable Format developed by Apple in the early 1990s for the PowerPC doesn't have this problem; it stores the internal name of any library a code fragment is linked against, instead of a full path to the file containing that library or even the name of the file containing that library. This makes it robust in the face of name changes to the library file, the location of the library file (so long as it's in the library search path), etc.

Then again, PEF and CFM are just generally superior to Mach-O and dyld. Unfortunately, people who I would think would know better - the people that brought the world WebObjects and Cocoa - still just don't get it. (Of course, these same people still haven't brought back EOF for Objective-C despite massive amounts of want from the developer community and a willingness to pay money for it so...)

I just shipped BDRuleEngine 1.0.0, an Open Source framework that provides Cocoa developers with the ability to develop business rule-driven applications. BDRuleEngine requires BDControl 1.0.3 or later, another Open Source framework I released a couple weeks ago.

I also shipped a simple application for editing rule sets, BDRuleEditor. BDRuleEditor requires BDRuleEngine 1.0.0 or later and BDControl 1.0.3 or later.

The rule system works by letting you specify rules, supply some initial data in a context connected to those rules, and then ask that context various questions about that data.

Rules have the form

(condition) => keyPath = value [priority]

where condition is a qualifier object. (See the description of BDQualifier in the BDControl documentation for details; in short, qualifiers are object-oriented predicates.)

For instance, a couple rules for an adventure game might include:

  (torch.burning = false)
    => exitsVisible = () [100]

  (torch.burning = false)
    => description = "Your torch is out.  You can't see a thing." [100]

  ((room.name = 'mainHall') and (torch.burning = true))
    => exitsVisible = ("north", "south", "west") [100]

  ((room.name = 'mainHall') and (exit = 'north'))
    => description = "There is a door to the north." [100]

  ((room.name = 'mainHall') and (exit = 'north') and (exit.open = true))
    => description = "There is an open door to the north." [100]

To start with, you'd create a context linked to the above rules and set whatever data you needed. For instance, you'd set the context's "torch" key to your torch object. Then you ask the context for a value, such as "description". When you ask for that key, the rule system finds the most applicable rule given all of the data in your context that has that key on the right hand side of the =>, and returns the value for that key.

Thus if your torch is initially not burning, asking the context for the value of the exitsVisible key would return an empty array, and asking for the value of the "description" key would return "Your torch is out. You can't see a thing." regardless of what room you're in. When you turn your torch on, asking the context for the value of either key will instead return the appropriate value depending on the name of the room you're currently in.

Priorities are used to differentiate among equally-applicable rules; the rule with the higher priority is the one that's fired.

BDRuleEngine uses Objective-C's introspection features via the key-value coding mechanism to work its magic, so you don't need to do anything special in your own classes to be able to use them with the rule system.