I have designed and implemented over 50 different applications in my 20 years of writing software. Most of us that have been doing this since the '80s have.
Few apps are ever rip roaring successes, most of mine were either prototypes or software for the use of small work groups. The basic process of designing and implementing is the same, refinement is usually more of a budgetary and market size issue.
My approach to application design tends to be more customer centric an iterative than anything else. Experience has shown that few people can ever hit better than 10% or 20% on anticipating requirements, so rather than expecting customers to do something that seems unlikely, I attempt to be flexible and move quickly through many iterations.
This is also another huge advantage for an approach using code generation. By doing as much of the database table IO through code generation as I can, this frees up 80% of the time to do the changes that keep a customer on target.
Artificial Intelligence, also sometimes called by the discipline of Business Rules, has been a focus of my weekend and evening studies for years, ever since I met James [] and learned about how much higher his billing rate was than mine.
This aggravation only increased after an epiphany in one of James's Saturday sessions when I suddenly realized that, in essence, Artificial Intelligence is little more than syntactical sugar for abastracting out "if-then" logic statements.
So to summarize, I understand the basics of RETE and rules engines in general, and would know which tools to use to pursue this type of project. I cannot claim any direct experience though, other than my many sessions with James and others like me, trying to learn.
As a side issue, I have built some of my own "rules based" processing engines, though it is not Business Rules-ish in the sense that the rules are not always stored in a different medium or syntax. I also can't remember what they are.
Autonomic computing, also described as self healing systems, are a new fad in computing amongst the biggies (IBM, HP, etc). The two primary features are diagnostics and corrective routines.
Almost in passing, I have incorporated automated background launching of any named subroutines (prescribed in xml files). I haven't written the diagnostics of healing pieces, but these are pieces common to systems over past decades, hardly difficult.
So I can't say that I have done autonomic computing yet, but it looks like doing so is going to be pretty easy to get a start, once I get a customer interested in the end result.
Like any good developer, I am never enthusiastic when forced to take time out to document my work.
Despite these impulses, however, I have done some excellent documentation, as well as pioneered some nice documentation technologies in the shops I have worked in.
I can't claim to have singlehandedly started the Wiki craze in Dallas, but I did introduce, install, pollinate, and utilize the Wiki technology in many shops and user groups in town and in the open source scene.
I am also one of the strongest users of documentation using massive quantities of screen shots, a very easy kind of documentation to follow, on the web.
Lately I have (appparently) been a pioneer in the next thing up from a Wiki, which is a CMS. This has been a very helpful documentation technology because of its controlled access and better menuing and searching. I must credit my mentor Chris Rauschuber for turning me on to this one though.
In 2003-2004 during my time at Lockheed, I was allowed to convert several of my command line based programs to Eclipse plugins, where everyone on the team could run them from within Eclipse.
We were also allowed to customize another open source plugin for testing to add additional testing functionalities. This too was very successful and well received.
In subsequent months I also created a couple Eclipse plugins for modifying Ant properties files for Keel builds.
I have written many different file parsers, mostly for delimited and fixed length files, but also for more complex files. This is a frequent requirement of automated code generators and also of data conversion routines.
It typically takes longer to figure out WHAT to do with the information to be parsed from a file, than it does to write the parser that does it.
If you are a component based programming enthusiast such as a user of Spring, Pico etc, you probably use the term IOC or Inversion of Control to define the basic building blocks that make up this approach.
If not, the high level idea is that Objects are not enough, because they allow for too much wide open interdependency. Component Oriented programming is more like your old component based stereo, everything is separate black boxes. IOC is the wires that connect them all together. Maybe that's a crappy analogy but it's a start.
As a founding contributor of Keel Framework (see Keel Framework) I have been following this programming fad actively since 2000, well before it became a rage in recent years. We use Apache's Avalon as our IOC container, and I am still not brilliant in its use, but I have used it for enough years to at least be able to get the job done.
In 2004 I got some experience with some of the more arcane capabilities in java, the handling an moving of very large media files using the java.nio libraries.
It is very strange handling 5 and 10 gig files, but it does seem to work fine.
I have run the gauntlet of learning and applying regular expression syntax many times for many different purposes. I never seem to retain it, so I have to relearn it every time.
It is never a pleasant task, but one that always leaves me smiling just because I am always so glad when it's over. It is so incredibly powerful; it's hard not to appreciate.
I have used several different regular expression parsers, most commonly the one in the standard java library, lately.
Fall 2005 I worked for several weeks as designer and architect of a sophisticated scheduling module and its companion management module.
Using a combination of CRON like or time based [] library, and sequential or list based processing, the primary features of the system were to provide a minimal interface to allow complex combinations of various broadcast and media file movement tasks.
The first software I wrote in 1985 was job cost accounting, the second a job estimating program. That was not for someone else, I have been estimating, budgeting and building since 1980, and doing so without computers to handle the minutiae is a pain.
It is interesting how little things changed when I migrated to building software, from building buildings. From a budgetary standpoint, the differences are not so great. The processes are so similar you can almost use the same software, only the categories and cost ratios seem to be very different.
See also project management and bottom line, I am accustomed to running from a budget, meeting a schedule, etc. It is sometimes harder in software than in the building business, but only because the practice of establishing requirements is so relaxed, er uh, I mean unrefined.
I was at one time a proficient struts user (2001-2003) and could be again, with a little effort.
See also JSF.
See also J2EE, I have built many web applications of many types, having done little but that for several years.
This includes working on two large teams (one very large) and many smaller or solo efforts.