This is as untrue as anything I've ever said or written, moreso because it undergirded two years of feverish research. Logic is a formal, mechanically limited contraction of reason. Mechanics and logic exist in what the geometer Bernhardt Riemann would call a limited, finite "manifold" of possible action.

I've been reading a good amount of Kurt Gödel, particularly his essay in the Schilpp anthology for Einstein, his contributions to Robinson's "Non-Standard Analysis", and his earlier works on incompleteness theorem.

Gödel successfully showed in his youth that no logical system could ever prove all of its own axioms, and thus all were incomplete if consistent. This incompleteness is especially true and evident in the discrete mechanical devices with which we compute. It becomes specifically poignant in the context of rule engine design.

Reason, by contrast, is based on a geometry of a higher order. Put succinctly, if reason were a sphere, logic would be the shadow of that sphere on your desk. Rather than logic, reason brought to bear on the exploration of ignorance is the foundation of all philosophy. Logic is a fossil by comparison, as the water in my breath is a fossil.

This research has set my feet in the last six months onto an unexpected course in mathematics and philosophy, after a brief (and fascinating) foray into rule engine design. Bearing in mind the inscription above the entrance of Plato's academy, "No one should enter who knows not geometry", I've thrown myself at the task of learning how to think in terms of actions taking place on n-dimensional surfaces. Anyone who wishes to understand what I mean by "mechanically limited contraction of reason" should read Gödel and probably Riemann as well. Of course there are others worthy of attention who lived and worked in this vein, all prior to 1900, but they're in the margins.

These two should get you started. Don't ever rely on books about Gödel and Riemann, or web sites about them. To hell with contemporary analysis, stick to primary source materials. Just read them, and read what they read.

As for me, I'm stepping back from logic and mechanics for a while, in order to work on something infinitely more important. I've reenrolled in a University, and have a new curriculum before me. Java was fun and I'll cross its path again eventually, but next time it'll be as a man to a chisel, not as a child to a sword. My rule engine work is concluded as well for the forseeable future.

And so I sign off, and leave the following question for you to consider. Which generates more energy when destroyed? An atom, or an axiom?

--
Alex

* Tomcat 5 (what sane person would pay for tomcat 4?)
* Dedicated JVM
* MySQL Database
* 200 - 500 MB disk space
* At least 2048 MB of bandwidth per month, though I doubt I'll need it.
* SSL Certs available
* At least 1 primary domain
* n Subdomains (not rocket science, here)
* Raw log access
* SSH / SCP / SFTP access for posting files.

At the price that some hosting providers charge for the above, I'd be better off to relax a little on uptime expectations, buy one of those sweet Mac Minis for a web server, load a basic environment into it and throw some money at a friend for a static IP and tell him to use the machine as a bookend. Does this sound familiar to the rest of you? Why is Java web hosting so poorly represented, or did I miss some brilliant dev mecca?

Please feel free to post suggestions, comments and flames below.

This May, after a winter-long recovery from post-mercenarial burnout, I began reapproaching the problem of Domain Specific Languages in Drools. I began working with the Drools semantic module framework (drools-smf), trying to figure out how to write DSLs. There's no real documentation on the subject, and I committed myself to writing those docs, just as soon as I could figure out how it all worked. I decided to write a simple example DSL called "Expresso" (sic), to illustrate the concerns of a very specific problem domain--the sacred and immortal rules that guide the behavior of coffee shop patrons. The name of the language was intended to underscore the hilarity of the problem domain. Armed with this irony, I set about coding.

My work came to a head last week when I finished implementing an inversion of my original idea for Shocks. Instead of embedding Drools and a custom Domain Specific Language inside of an action sequencer, I implemented the action sequencer as a domain specific rule language in Drools. Ultimately, I found myself standing on the other side of a mirror I first looked through about two years ago. Only this way actually kills several other birds as well, such as the problem of building extensible and natural sounding rule languages that business analysts can understand.

I love a good surprise.

What I learned over the course of the last month of feverish programming, was that the drools-smf library is so expansive in what it permits, that anyone with solid knowledge of XML and Java (i.e., has written their own XSDs and parsers, eats DTDs for breakfast, etc.) should be able to create just about anything they can imagine in the way of XML-based rule languages.

However, the price of this permissiveness is complexity--Drools' semantic module framework requires that language designers learn about the way the underlying rule engine works. They'll find themselves working with tuples, the working memory, fact handles, declarations and underlying logic closer to the RETE-OO core of Drools than they might care to travel. The more I worked with it, the more I felt it encroaching on what I was trying to do. I became convinced that über-natural sounding language (with proper gammer and fine grained language particles) wasn't really necessary if you could just nail an expression to an XML element name.

Consider the following, for example:

    <rule name="When thirsty and has money, buy coffee">

        <if>

            <customerIsTired/>

            <customerIsThirsty/>

            <customerHasMoney/>

        </if>

        <then>

            <buyCoffee/>

            <modifyCustomer/>

        </then>

    </rule>

All I really want to do is write a quick IoC-style component to represent either a part of a condition or a part of a consequence, and map the name of an XML element (buyCoffee, chow-down-on-a-bagel, etc.,) with a corresponding Java class (CustomerBuysCoffee.java, CustomerEatsBagel.java). Maybe list the bean dependencies as well, so I get simple XML bindings that look like this:

<bindings>

    . . .

    <action name="buyCoffee"

            class="org.eremite.expresso.actions.BuyCoffeeAction"

            requires="customer, coffeeHaus"/>


    <bean name="customer"

          class="org.eremite.expresso.beans.Customer"/>

    <bean name="coffeeHaus"

          class="org.eremite.expresso.beans.CoffeeHaus"/>

</bindings>

Another problem this solves is the reuse of logic inside the conditions and consequences themselves. Who wants to rewrite consequence blocks with a single line difference in 100 different rules? I found patterns inside my components and with the help of Bob McWhirter was able to decompose conditions and consequences into more fine-grained components that can be mixed and matched to form rules the way that amino acids combine to form protein chains.

I assured myself that a single 5k jar with two interfaces and a pojo to abstract the rule engine's working memory would constitute a sufficiently minimal compile-time API for most component developers. This spares them the trouble of importing the drools-core, drools-spi, drools-io, drools-smf, drools-base, expresso-core and picocontainer dependencies into their editing environment (and their code!) More importantly, it prevents developers from relying on the underlying implementations and complexity of the rule engine.

The results? I have a small (25k) DSL that specifically addresses the concerns I laid out above. It allows me to model complex behaviors using rule engine technology, with reasonably natural (if course grained) language elements and easily testable elemental components, bare minimum framework dependencies and easy extensibility (I'm working on some stuff to autogenerate the necessary XSD files for beta-02).

"Wow." I thought. "This is exactly what I was going to do with Shocks. Scratch that idea off my list."

All in all, the experiment was a complete success, and I'm happy to release the first snapshot of the Expresso codebase (including some unit tests, an example vocabulary, and no documentation whatsoever--be forwarned!) under the Academic Free License. Also, now that I understand how all the pieces fit together, I'm turning my attention to documenting everything people could possibly need to know about writing Domain Specific Languages using Drools'low-level APIs and my neat new tool.

And, for the record, thank you Bob and Mark for your patience and head-kicks while I worked on this. You guys uh, well, you rule ;-)

Maybe they're not doing it on purpose, but that's the first thing that popped into my mind. The softpedia article proposes that ISO 18629 "Makes the first step towards AI." The title alone is ridiculous. When I read the article, (you should, if you want to understand what follows), I came to my la-la lane conclusion.

The article begins "Mankind is making the first steps towards artificial intelligence, or AI if you like." and then proceeds to explain why, apparently oblivious to the steps folks have been making in so-called "AI" for quite awhile.

The proof cited in the article?

If a person who hears the commands “paint it, before shipping it” and “turn on the coolant, before milling” understands that the word "before" has slightly different meanings in these two different contexts. In the first command, it is understood that painting and drying must be completed prior to the next action, shipping. In the second command, however, the first action, turning on the coolant, continues after the milling starts. ISO 18629 supports computer systems with this type of rudimentary understanding of context-specific language.

I don't think this has anything to do with AI. It certainly isn't something that "enables" AI, and I'll paint my face blue if it "makes the first step towards AI", as the title of the article claims. On the other hand, it does strike upon a subject I find VERY interesting, because of my recent research in language design: Polysemous Prepositions.

Here's how it breaks down. In natural languages, there is a common occurance called "polysemy". Polysemy happens when one word can mean a number of things, dependent on context. One of the areas most notably affected by polysemy in English is prepositions.

The Metaphor Research Group at Georgetown University has been conducting discussions and research into the question of whether polysemy in English prepositions follows a logical pattern, or whether its arbitrary and idiomatic. This work has recently culminated in a fascinating publication on the subject, titled "The Semantics of English Prepositions: Spatial Scenes, Embodied Meaning and Cognition" by Andrea Tyler and Vyvyan Evans. (ISBN: 0 521 81430 8 hardback)

The problem with polysemous prepositions in language, which is familiar to any language geek who has ever done any work trying to approximate natural language in a logical semantic system, can be illustrated by part of a simple quote at the beginning of this book:

"We won't come back 'til it's over, over there."

The word "over" has two radically different meanings in this sentence. Same word, but how do you know which version of "over" is meant? "Over" as in "finished", or "over" as in "on the other side of a certain amount of space"? The book goes into other meanings for "over": in motion above, as in "flying over the ocean", resting above, as in "over an open fire", more than, as in "over 90 percent", the list goes on.

To resolve this question of polysemy, the human listener has a number of potential options: one is to construct the meaning "on the fly", at "runtime", so to speak. This implies that the reader is generating hypotheses about the meaning of the language as they are reading. Another option is for idiomatic or "rote" memorization, where you learn to map spatial and temporal concepts with certain instances of usage in your mind. This is really just pre-processed language.

Now, it is undeniable that, over time, people develop idiomatic concepts to help them process polysemous expressions. That part of their language usage is already precompiled and in memory. But when learning a new language, such as a foreign language, must people memorize what the proper prepositions are for certain expressions, or is there a hidden, underlying system that actually makes rational sense?

Tyler and Evans argue the latter point, and do so with a candor that is charming and unexpected in such a dry-sounding topic as polysemous prepositions.

The questions their book raised in my mind, were along the following tracks: If prepositions deal primarily with mapping conceptions of space and time to language, what changes need be made to language and its study when Gaussian and Riemannian concepts of space and time are taken into consideration? Specifically, what's the plan to overhaul our notions of location and time? We know with absolute certainty that old Cartesian and Euclidean concepts of space, time and other manifolds are simplistic and rife with paradox, and that Gauss' cyclonic functions and complex domain, taken alongside Riemann's notions of multiply-connected manifolds lend radically new and elegant ways of resolving colocation (a type of polysemy) and other spatial paradoxes into simple and rational forms.

But, because Gaussian and Riemannian spatial concepts ("space" is such a limiting concept, really) have not penetrated our education systems (yet), neither our usage nor our understanding of language and the ideas that underlie it have changed noticibly since these discoveries. Structuralism and post-structuralism actually took us further from these discoveries, first toward the realm of discrete mechanical breakdown of language, a throwback to the scholastics (which we see here in ISO 18629), and later toward the post-formal absurdities of post-structuralism, another throwback, only this time to nihilism. Neither showed the foggiest recognition of these 19th century advances in mathematics and geometry, or of the immense philosophical implications of these advancements. Nowadays the works of Gauss are becoming available in English, but Reimann's still hard to find in English.

Don't be fooled. ISO 18629 is a library for mapping "process information related to discrete manufacturing." It uses AI, it doesn't enable AI. It's no breakthrough in AI, and it won't lead to rational machines. For my dime, it's just another domain specific language (I'm sure it's excellent at what it does, and that its designers should be proud--my complaint was with the slipshod reporting at news.softpedia.com)

To keep people thinking, I'd like to put forward the following assertions, which I'll be happy to elaborate on at a later time:
1. Logic is not Reason.
2. Now, I'm biased, but I think if people seriously want to make real breakthroughs in AI (break-outs, that is--I hold AI and cybernetics to be totally absurd, but that's for another day), they should be studying geometry (and its many cousin languages), not drooling over a specification for a discrete manufacturing syntax.

Overcoming JPox integration hurdles was slightly challenging for me--and I consider myself very competent in this sort of thing. I can imagine it being very frustrating for a new user, so here are some notes and tips.

I rushed straight to their latest 1.1 beta 3 release, knowing full well the pitfalls of working with betas (Drools, anyone?). After an hour or so digging through their site, I'm not certain the documentation on is up-to-date with regards to the maven plugin. But I'm alright with that.

The first thing I'd like to note for newcomers to JPox, especially those working with the new 1.1 betas, is that the instructions currently (06/02/05) up on the JPox maven plugin page (http://www.jpox.org/docs/1_1/tutorials/maven.html) make the maven build sound a lot easier than it actually is.

First off, you'll need to manually install the jpox-maven-plugin
Get the version that corresponds with the latest release of the code you're using. I'm using 1.1.0-beta-3. After you download the plugin, add it to your maven plugins directory.

You'll also need to download the jdo-2.0-beta.jar, and throw it either in your local maven repository, or put it up online somewhere. I keep two or three maven repositories squirreled away online, for my own personal use. Be sure to follow Sun's license guidelines when you do this, though.

Now, even though I've satisfied all my dependencies, I run "maven jpox:enhance" and I still get a NoClassDefFoundError for org/jpos/metadata/ClassMetaData. This is slightly disturbing, because it means I'll probably have to walk through the JPox jars in my repository, to see if the class is actually there, or if I missed something (which is likely).

So, I open up the jpox-1.1.0-beta-3.jar in WinRAR, or rather, try to. It seems the file is corrupted. This explains the strange error. I nuke the file and rebuild in Maven.

BUILD SUCCESSFUL
Total time: 20 seconds
Finished at: Thu Jun 02 10:53:06 CDT 2005

Woot.

In conclusion, when you're working with JPox in Maven, be sure to download the jdo-2.0-beta.jar and to install the JPox plugin from JPox's sourceforge download page. All the hyperlinks should be listed above.

Now, what I really want to know, is when will JPox support object arrays?

The first-of-its-kind event, Interop City brings software technology user groups together for a day of presentations, demonstrations, and dialog on .NET and J2EE interoperability. Interop City is a unique event based on a grass roots initiative. Bringing together User Groups, Corporate IT, Vendors and today's Thought Leaders, members of the Java, .NET, and XML user groups, along with chapters of IASA and the IEEE, and the Software Process Improvement Network will congregate under one roof to discuss one of today's hottest topics.

For more information, please go to the all new IASA home web site: www.iasahome.org/events

Hope to see you all there!

Krzysztof Karski
Twin Cities Chapter President
International Association of Software Architects
[e-mail removed]

* * * * *

If you'd like to pass a message on to Krzysztof, you can drop me an e-mail, and I'll forward it on to him. -- n (at) alexrupp (dot) com

C:/Windows/Prefetch
C:/Windows/Temp
C:/Documents and Settings/<username>/Local Settings/Temp
C:/Documents and Settings/<username>/Local Settings/Temporary Internet Files

I ran a couple of tests, tried out the script, and it worked as intended. Just to satisfy my curiosity, I rebooted the machine, and then navigated to C:/Documents and Settings/<username>/Local Settings/ Temporary Internet Files. What's this? The directory was full of cruft again.

Paradox:

I deleted the files, but here they are.

Hypothesis:

Maybe there's something wrong with how maven deletes files. I'll try manually removing them.

I deleted the files manually, then rebooted the machine again, navigated to the TIF directory, and the files had returned.

Paradox:

I deleted these files, but they still show up in the folder. Unreal.

Hypothesis:

Maybe these aren't really files.

I punched F3 and ran a file search for one of the files in the directory, but could not find it on the filesystem. I searched around some more, and found the Content.IE5 directory, navigated into it, and discovered the index.dat file. I opened it up in a text editor. Voila. "This must be the source of my trouble," I think. It contained everything which was appearing in my TIF folder.

Hypothesis:

Maybe the folder really is empty, but it appears otherwise.

I punched F3 again and ran a search for "Temporary Internet Files". I created a shortcut on my desktop to my TIF folder, and opened it.

Paradox:

I have two windows open, each with the same address, which is C:/Documents and Settings/<username>/Local Settings/Temporary Internet Files. One is empty, the other is full of files. Same directory, same address. Different contents.

Hypothesis:

The folders need to be refreshed.

I refreshed each folder, the results did not change.

Hypothesis:

Windows will lie to the user, and present a list of references to cached files in the TIF folder, if they navigate to the folder using the file system, and not a desktop shortcut or a command line. The erroneous representation is governed by the contents of an index.dat file.

Further research on the internet uncovered thousands of pages on the infamous index.dat file. I was completely revulsed. These files are bulletproof. Several hours of searching only uncovered one program, called "Complete Internet Cleanup" that would actually remove the contents of the file. But, it is not Open Source, so there's no chance of embedding it the desktop cleanup tool I'm working on. I checked SF.Net, googled for references to a Java tool that would wipe out index.dat files, all to no avail. I tried killing system processes, using the "Handle" tool from SysInternals to figure out which processes use the file, all to no avail. I know these files can be wiped clean, but I don't know that anyone's ever devised a way to do it in Java. If they have, please send them my way.

All I really need to do is wipe out the Temp directories and empty the Recycle Bin. Maven can do the first, but these damn index.bat files give the impression that all the files are still there, which is certain to infuriate users.

More notes on this as the process continues.

Barnacles, Spyruses, we have many names for them here. But they are the enemy. We've built zoo machines and read-only arks of all the worst nasties to cross our nets in the last six months. Blaster. Welchia. Netsky. Gaobot, and all its cunning variants. Internet optimizer, CoolWebSearch, you name it. We have 5,000 resident users in one great big network corral, with almost unrestricted access to the external net. They function like fishing nets, bringing us all the worst computer infections the world has to offer. Their job is to play, and learn. Our job is to protect them from each other, and the world from them.

We fight the bots, and we win. Time and again. I've been training a team of about 25 people, to be able to sit down with any Windows XP machine, and disinfect it--completely--in an hour, when a compromised or clueless Symantec would still be wandering blind through the System32 directory, and Ad-Aware would still be on-deck.

The best part, in my mind, about my place here, is that the people on my team aren't former virus writers or cybercriminals. They're honest, bright students who take more satisfaction in reinforcing windows than in breaking them.

We expect to tag a 2.0-final release sometime in the next month or two. Special thanks to Andy Barnett and Mark Proctor for their commitment to the project! I feel very comfortable using Drools in production systems, and the future of the project is looking very bright indeed.

Intertech Training (David Blevins of OpenEJB used to teach classes here) has sponsored the Twin Cities IASA chapter! They'll be providing us with a venue for our software architecture meetings.

I've put up some more information on the August meeting at the TC IASA home page. If you want to come to the meeting, please drop me an email and let me know. Software architects of all stripes are most welcome, as are those interested in learning more about software architecture.

Also, it's not a done-deal yet, but I'm talking with Gregg Kloke, former CTO of SimonDelivers.com (online grocery delivery service for those of you in cities without one!) about speaking in September. I'll let you know when I find out more about that.

I've recently begun a Twin Cities chapter of the International Association of software architects. IASA is a not-for-profit company devoted to advancing the science of software architecture. The Twin Cities chapter will give residents of the Minneapolis and St. Paul area a language-neutral forum for discussing architectural concepts. We're having our first meeing in August, on the 16th. I'm still looking for a flexible and affordable venue, but we've got our speaker lined up and it's sure to be good. I'm just extremely thankful to have a group like IASA, which can offer me a national superstructure for hosting architectural meetings. I've really longed for high-level architectural discussion in the course of the last year, and found a rather sparse community.

Believe it or not, the best friend the architecture community has right now is probably Microsoft corporation--they've been a tireless advocate of advancing architecture as a science and as an art form, and they've been more eager than I would originally have thought to assist my fellow IASA chapters (all of whom to my knowledge have been founded, organized and run by Java User Group leaders). They're actively encouraging me to seek out sponsorship for my local chapter from the J2EE industry, because they know that architecture is a language and platform neutral science (it's been around far longer than .NET or J2EE/J5EE/whatever version Sun's PR goons want to call it. The willingness of Redmond to assist without control and encourage cooperation with Sun, IBM, BEA, SAP, Borland, etc is an advanced indicator to me that Interop and SOA is truly the way of the future. And that means that software architecture as an explicit and well-developed science is also the way of the future.

But so very little is commonly known or understood about software architecture. You can't get a degree in it. You can't really even become certified in it. Sun offers an architect certification, but theirs is really a language and platform biased vision of architecture that doesn't hold its own in the world of legacy interop and the emerging web services market.

Paul Preiss, the President and Founder of IASA, has been coaching me on his views of architecture and I've been noticing a distinct bias against including the concerns of developers and development practices in the architects repertoire. This is strikingly familiar to the bias developers hold toward practitioners of interaction design (and also a little reminiscent of the stratospheric nasal tilt many enterprise developers have shown .NET developers in the past five years). In defense of those developers out there looking to learn more about software architecture, and as an early attempt to make architecture more accessible and less "mystic", I'd like to throw out a few of my own ideas about architecture, and some links to other definitions and resources that people might find helpful.

The separation of development and architectural concerns should be undertaken only for practical reasons--when it is more efficient to have specialists focusing on each role than it is to have developer teams juggle traditional programming/construction and architectural/design responsibilities.

The "Model-2" approach to software development kicked off a trend toward greater isolation and abstraction between roles in development teams. In addition to separating the concerns of interaction designers and software engineers, there have been advances for isolating the administrative and executive concerns from the development process. This might be mere conjecture, but based on my own experience, we might have software engineers to thank for most of these architectural advances--it is possible they've been providing automation hooks and tools to remove themselves from the middle seat. I think that perhaps some underground coalition of long-toothed Unix hackers tired of having its shores invaded by milling throngs of well-meaning but tiresome (savage) artists and executives has finally elected to do something about it.

On the other hand, perhaps we are the savages and have the suits to thank for these new advances. Or (most likely), there's a bit of savage and a bit of savant in each of us.

architecture, in a way, is a way for developers to climb up and see the larger picture. The more you work with different Open Source projects (especially when you're trying to augment, alter or otherwise extend an existing software product), the more you'll gnash your teeth and notice how difficult a poorly thought-out (or even a well planned but strategically dissimilar) architecture can hinder your progress and spoil an otherwise good user experience. For example, the Jakarta Tomcat server has a very specialized architecture that allows it to operate in a standalone environment. This is sort of like an astronaut in a space suit--it's got lifecycle management, onboard dependencies, all the things it needs to operate in the depths of space. But all that luggage might prove a hindrance when trying to embed it in a service-rich environment. For this purpose Jetty is clearly superior--it is well adapted to life in lush surroundings.

This metaphor is working, and metaphor, really, is what software architecture is about, so I'm going to run with it. One could describe an architecture like one describes the evolutionary skeletal adaptations of an animal. The Irish Elk had a very specialized "architecture" in its 13 foot antler crown. Tomcat has a very specialized architecture that allows it to function in the barren environments typically operated by green-skinned n00bs. Both, because of their relative inflexibility (and I'm not by any means trying to cast a shadow on Tomcat--I've warmed to it quite a bit since becoming familiar with OpenEJB) stand to lose out when the environment changes. In the case of the Irish Elk, the weather improved and firebearing bipedals arrived on the scene. In the case of Tomcat, service rich environments and flexible component based architectures could render the "all in one" solution unnecessary. In order to avoid falling into disuse, Tomcat will need to adapt. And development concerns are not what's holding them back. The key lies in architecture.

And this is why developers need to learn about architecture--particularly good developers. There is even cause for them to specialize--the all in one solution might not be well suited to our contemporary technical job markets any more than the Irish Elk was to the woods. The advantage that developers have over self-styled architecture purists is that they know from experience, perhaps on an untrained but intuitive level, how and where the programmatic weaknesses in certain software architectures might lie. But in learning about architecture, they need to abandon the minutiae of flow control and implementations of their software, and begin to concern themselves with the construction of modular but holistic systems, functional organs for a service-oriented world. In this world, executive concerns and Interaction Design play at least as important a role in the delivery of software products as developers.

This morning's ramble is complete for now. I'll continue on this topic (and assemble some links to resources) soon.

I actually majored in writing and poetry in college, and there's an interesting story behind that. I was nearly expelled half-way through my senior year in high school (1997) for hacking past our school's security system (with a Mac, no less) and into the local bank. I had accidentally gained access to the district's payroll system (quite without knowing it, I swear!)

In Saint Croix Falls Wisconsin they don't really know how to deal with that sort of thing. So, for the second half of my senior year in high school I wasn't allowed to use a computer at school unless a teacher was sitting next to me, watching my every move. No lie. It was a tremendously painful experience. I'd already taken almost every class I needed for graduation, and had very few electives to choose from (small school).

So I doubled up on the independent art classes and took FOUR English classes with Mr. Beversdorf (sorry if I mangled your last name, sir--it's been a while), a weight lifting class and study hall. That's right. Full enforced immersion in the humanities for one semester, and I never quite recovered. I didn't have a computer at home (much less the internet), so this was a crippling blow to my hacking career.

I learned during that semester that I wanted to study the liberal arts when I went to college, and not computer science. And that's what I did. I ended up taking a class on first and second order sentential logical languages my first semester, but didn't begin programming in earnest until I got a gig as a web designer at Dain Sundstrom's first company, Arcane Logic. (Here's a bit of trivia--one of Dain's parters at Arcane Logic was Charlie Demerjian, who writes for TheInquirer.net, and who is my roommate. Small world, eh?)

By the time I took my first (and last) computer science class in college, I'd already been studying Frege and Russel's linguistic theory, and had made it and lost it in the boom. I could have been a better computer science student, but language theory itself is what commanded my interest, along with human-computer interface theory and language/literary theory. Also the University of Minnesota's computer science classes have upwards of 400 students in them, and the labs didn't have enough seats for all the students. I was bored stiff during lectures on control flow and when all was said and done I decided not to take up CSCI as a second major.

I stuck with language and literary theory, and I'm still doing it (working with semantic modules in Drools right now). And when I had to choose a major I decided to go with learning how to write the perfect words in the perfect order, which is something that programming and poetry have in common. "Poet" just doesn't look as good on the resume as "M.S. CSCI", though.

So for a while, Open Source has been my only shot at actually writing good software or working with smart developers. I kept at it, hoping it'd pay off in the long run, and decided that if I couldn't get a job as a developer that I'd start my own company and go after small clients. I don't need to tell you, bootstrapping a company on zero budget is no walk in the park.

Very recently, I worried that I'd have to take a "bench" position at one of the giant, soul-crushing consulting firms here in Minneapolis, or give up the ghost (to borrow an expression from Hunter Thompson). And then, one day, while I was coding out loud on Drools at the Dunn Bros coffee shop on University Avenue, I met a guy who, by chance, knew some guys starting an Open Source company. . .

He asked "are you a techie?"

I nodded.

He asked "do you do Open Source?"

I nearly choked, and gave him an affirmative nod.

He didn't waste any time. He asked me for my resume right there, and since I'd just applied for a job at the University I had a copy with me. He referred me to a company called Open Technology Systems (try googling that ; ) and made me promise I'd send an email to the company's VP.

A week later I met with the company's President, Gregg Kloke and the VP, Randy Olson. Gregg's background was with a company called Simon Delivers, an online grocery deliver service here in Minneapolis. Randy had done consulting with Onyx (a bit before my time, I'm afraid) and they are both really into Open Source technology. Their business is based around providing Open Source solutions to small and medium sized businesses. After an hour with these guys, I knew I wanted to join their company. Last week they invited me to their office to sit in on a meeting with a local retailer and talk about Open Source in the context of their business. I thoroughly enjoyed myself and got along really well with the others I met there.

It's been a sleepless weekend, but I got the offer letter last night, and I started this afternoon.

The reasons I'm blogging about this is are pretty straightforward. First of all, I'd like to share the news of my good fortune with some of my friends out there, many of whom have been trying to help me land a regular gig for a while. Second, I'd like to thank Joe, Randy and Gregg (in order of introduction) for giving me a real chance to do what I love.

Finally, it's to remind all the local guys I've met, who've studied computers because they thought there was a future in it, that there is a future in it, and that it's as bright as it ever was. And Open Source is going to play a huge role in it, perhaps bigger than anyone really knows. If you're a young developer (or language geek) and the times have got you down, stick with it anyway. Things will pan out.

Now, lest I jinx my good fortune, I'm going to get some work done.