October 29, 2012
February 1, 2012
Here’s a burndown chart for the ages: my January. The blue line is new issues created, the green line is issues completed.
During the slow early part I was actually going through the 218 page spec line-by-line, creating new issues for myself, which as you can see I entered all at once (the spike). Then over the next five days, that 48 number dropped to three.
Nothing like a good, old-fashioned, unmaintainable coding binge.
January 25, 2012
using launchd and growl to show a daily message on Mac OS X
Just spent too much time figuring out how to show a Growl message at a particular time in Mac OS X. Seems like “cron” has been abandoned in place of launchd, so I had to write my first .plist file, which was simpler than expected.
Here are the steps:
1. First install Growl and growlnotify if you need to. (download here). Note for pre-Lion, growlnotify is in Extras in the Growl download.
2. make a script that shows your reminder, such as my schoolClock.sh:
/usr/local/bin/growlnotify -s -m "Time to pick up Isabel!" --appIcon "/Applications/iCal.app"
3. open up “Property List Editor” (which is included in XCode dev tools) and make a plist file in ~/Library/LaunchAgents
I called mine “com.immuexa.schoolClock.plist” and it looks like this:
(click image to see it, note the location and name of the script)
4. run this command in Terminal:
launchctl load -w ~/Library/LaunchAgents/com.immuexa.schoolClock.plist
Do this and you’ll get a message saying “Time to pick up Isabel at 3pm each day”.
For those that don’t have Property List Editor handy, you can use any text editor to create:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.immuexa.schoolClock</string> <key>ProgramArguments</key> <array> <string>/Users/immuexa/cmd/schoolClock.sh</string> </array> <key>StartCalendarInterval</key> <dict> <key>Hour</key> <integer>15</integer> <key>Minute</key> <integer>0</integer> </dict> </dict> </plist>
October 3, 2011
priming the pump
Running your own business means you’re always looking for work. I sometimes get a reprieve from constant sales when I’m in the middle of a months long project, such as the current one for the genetics testing laboratory. As the end of that project is now in sight, it’s time to prime the sales pump again.
I need a retainer for my next project by December 1st. In the 13+ years I’ve been doing this, there’s been a few immutable laws. One of them is that it takes two months to find, sell, and start a new software project, which means I have just enough time to do this. I’ve got October and November.
At the start of a sales cycle, pretty much anything is possible. The beauty of software is that I can pretty much target an industry of choice, using the tools of my choice, aiming for that most desirable of states: gig bliss.
I’ve been really enjoying Java EE 6 during the genetics testing gig, so I most definitely want a project using JSF/JPA/EJB and friends again. Luckily, these tools are very much in demand these days, by companies in all industries. Given my past experience on three large-scale medical projects, it’s likely I’ll be targeting this industry again, simply to ease with sales. It also helps that medical companies typically have ample budgets and ample need. I’m also very interested in combining my non-profit educational aspirations with a for-profit software gig, so I’ll be targeting the education industry as well.
Beyond Java EE6, I’m very much interested in returning to semantic web technologies, since all signs point to Web 3.0 being about ready to really take off. It’s been 8 years since I first started working with those tools, and roughly 4 years since I stopped using them, so there will be a lot of catching up to do.
I’ll also be looking for a project of sufficient size that I can work with two or three other developers. My solo work on my current project was fun for a while, but it really does get a little old without chaps to chat with in IRC throughout the day. Ultimately I make less money this way, but everything else scales much more nicely.
So, where to start? First thing is to finish my company website revamp I started a few months ago, since the thing looks about ten years old, which it is. Updating the showcase with information on more recent projects, updating the people page, the tools page, etc, will help greatly with first impressions.
After this I need to make a new sales brochure, both print and PDF, to convey the benefits we’ll bring to a project and what we’ve done. Often working on a brochure helps galvanize the new sales rap.
While doing both, I’ll be doing recon on prospective companies, entering their information into my leads database, which is part of Storymill. When I’ve finished feathering my nest (the website and brochure), it’s time to start sending emails and making calls. With an hour each day for two months, I’m bound to find not just another gig by December, but a fun, profitable, and meaningful one.
August 26, 2011
name of the bot
Our next task is to pick a name for our first StoryBot agent, which might seem an unimportant choice, though in practice it matters quite a lot, at least to me. StoryBot is the marketing name for the overall system. The individual agents created with StoryBot have their own names.
Our long-time bot in Immuexa’s IRC channel is named Waverly, which has served us well for half a decade. While the name “Waverly” would be very appropriate for an education bot, given its similarity to our education nonprofit, Waveplace, I’m ready for a fresh start, so Waverly is history.
Another bot name I’ve used briefly is Smilla, named after the lead character in a great novel, but mostly for its similarity to Storymill. Though I did use that name for the initial example, I’m just not feeling it today. I want another name.
Just now I was scouting around and briefly considered Zeno, given the symbolic connection to the Greek philosopher (not the acne treatment). While naming it after the father of dialectic would certainly be appropriate, and while the connection to Hofstadter dialogues is also nice, as I type this I’m thinking that Zeno feels like I’m trying to hard. Perhaps Zeno will be another bot, but not the first one.
Instead I’m thinking of another old favorite, this one the name of an illustration we made back in 2005:
Sibley is a friendly name, with a clear phonetic connection to StoryBot. As a character, Sibley the great blue heron has a personal connection for me to southwest Florida, the site of so many Gravity ideas from the early nineties. Also, as we are now entering the fall migration season, choosing a bird feels right, particularly since we’re working again with Hawk Mountain Sanctuary (though I don’t think they’ve seen many herons up there). And lastly, we’ve already got an illustration for the bot!
So Sibley it is. Now to get her to talk.
August 25, 2011
A long-standing tradition among software developers while learning a new programming system is to first display the message “hello, world.” While something so simple might seem pointless, there’s actually a lot that must go on before that, usually wiring up a development environment, creating the project, and writing the minimum amount of code. Hello world programs are about getting the plumbing right. Often programmers use a variation of “hello, world” such as the OLPC/Sugar team, which displayed, “Hello, (children of the) world,” which I quite like. I’ve already decided on my “hello, world” phrase, something that has personal significance to me.
The next decision is what programming language and core tools to use. Many developers are religious in their advocacy of a particular language or tool. I’m more pragmatic. My chief concerns are: 1) are there lots of people using it, so I can find help; 2) are there lots of specialized tools I can use with it; and 3) can I get up to speed quickly without wasting time learning to walk again.
Given these three criteria, there’s only one choice for me. Java has been the most popular programming environment for decades, with nearly all colleges teaching it as their primary language, which means lots of specialized Java tools are available, many more than other systems. I’ve also been using Java for 14+ years, so I can jump right in and get results.
Would I like to use Python or Ruby or Squeak? Sure. Programmers like learning new languages, and I’m no different. But when making these sorts of decisions, I’m much more conscious of avoiding gotchas and sinkholes which inevitably come from switching systems. My goal is to stay productive, which is even easier with all the changes to the Java platform in recent years.
So with that choice behind me, it’s time to fire up my favorite development tool (IntelliJ IDEA), create a new project, set up the version control (Subversion), and write some code. For the record, I’m using a MacBook Pro that’s more than three years old, which is ample.
Off I go …
(two hours later)
A very good start. I’ve created Java interfaces and base classes for agents, channels, prisms, and messages, along with an application wrapper that starts an agent and gets it running. The mechanisms for im/mu/ex processing and prism/channel maintenance are all finished. My code is in Subversion and I’ve got a Maven project all set-up. In other words, I’ve done pretty much all the plumbing-only stuff.
Now to try it. I open the Mac terminal and type “storybot” …
teefal$ storybot You may begin.
August 24, 2011
blank page design
When hearing a new idea presented, most people compare it to what they know and ask things like, “Have you used Wolfram|Alpha, or Cyc, or chatterbots?” Most would start by researching such projects, comparing features and approaches, getting inspiration. Personally, I prefer “blank page design”, trying to empty my mind of all influences, including my own past designs, so I can get to the core of things and limit my assumptions.
So let’s start. We know from the previous two posts that I’m creating StoryBot, a cognitive agent, with three essential capabilities: im, mu, and ex. Two of these operations, im and ex, involve communicating outside the agent, so we’ll need some conduit, some method for getting input and sending output. Rather than talk of websites and IM clients, I’ll ignore such real world concerns and simply talk of channels (which has nothing to do with the fact that I’m now watching the original Star Trek series).
An agent communicates with the outside world through channels. It’s a bit like an author trapped in a small room with only a mail slot in one wall. Ever so often, a piece of paper gets slipped through the slot. The author reads the paper, writes a response, and slips it back through the slot. The author has no idea what or who is getting the response. For all she knows, her response could be displayed on the Time Square billboard or read aloud to a kindergarten class. Her response could be used to make a movie or build an electric car. Such is the life of an agent . . . it knows only mail slots, or channels.
Using such a simple abstraction allows us to make all sorts of channels that work equally well with each agent. We’ll have an IRC channel, a web application channel, a Skype channel, a Facebook channel, etc. By using this abstraction, we can isolate such particulars from our core design.
Now that I’ve got a useful abstraction for im and ex, I’ll focus on mu. The defining attribute of mu is “change” … information comes in, gets changed somehow, and then goes back out. Reminds me of a favorite quote by Gregory Bateson: “Information is any difference that makes a difference.” It also reminds me of prisms, since they receive, change, and send light in pretty cool and clear ways.
So our central mu abstraction will be the prism, which you can think of as a kind of sub-agent that changes information on behalf of its agent. To return to the mail slot room example, imagine that prisms are other people in the room that help the author. So when a letter comes through the slot, the author (agent) gives it to the helper (prism), who then makes their own response and hands it back to the author.
Already I’m second guessing things, wondering if there’s any useful distinction between agent and prism, or between agent and channel for that matter. This likely has to do with my old designs creeping back, affecting my blank page brain. For now, agent, channel, and prism are useful as starting points.
Time to write some code.
August 23, 2011
So let’s start our StoryBot talk by defining some terms. First off, what is a “cognitive agent”? What makes it different from other programs?
For our purposes, an “agent” is an autonomous self-contained software system that receives input in some manner (IM), processes this input by consulting its internal context (MU), and creates a response (EX). The name of my 13 year old software company comes from this 24 year old abstraction (and word):
IM – impression, perception, things going in
Immuexa is the process of perceiving, creating, and expressing. During my years working on Gravity, these three short words represented the fundamental components of the architecture. Now, you might say, “Well that describes all computer programs and people!” and you’d be right. The usefulness of im/mu/ex lies not with the external view, but how this pattern replicates itself “all the way down” in a many similar to a fractal.
But I’m getting ahead of myself. For now, just know that an agent is something that im’s, mu’s, and ex’s. By “self-contained,” I mean that each agent is a black-box to the person or system interacting with it. There’s no telling what happens between im & ex. The word “autonomous” means that each agent works independently of any system that contains it. The same agent can be wired to a website, iPhone, IRC channel, or group of other agents.
So what about “cognitive”? How do cognitive agents differ from simpler software agents, such as mailer daemons? Well, this is a much bigger question, so I’ll simply give a quick example here.
The simplest non-cognitive agent:
<nosmo> What is your name?
A complex cognitive agent:
<smilla> How can I help?
Smilla is “more cognitive” than Nosmo. And more useful.
August 22, 2011
next bold move
Between 1987 and 1994, I designed and built Gravity and Colony, greatly anticipating the World Wide Web (Web 1.0), though my designs went much further, which is why they never took off. They weren’t as simple, as infectious, as the Web, so I sat things out while watching the dot-com gold-rush from the sidelines.
Between 2003 and 2005, we continued my old designs and built Tidepool and Storymill, anticipating what would become Flickr and Facebook (Web 2.0). Again, if we had focused simply on the web-side of things, if we had stayed simple, we could have ridden that great second wave of the Web, though didn’t.
In all these years, there’s been one major piece of my Gravity dreams that still hasn’t caught on, that’s still waiting to make someone a lot of money. For twenty-four years, I’ve called it the “cognitive revolution,” the one that will make Web 1.0 and 2.0 look like a mere prequel to the main event. At it’s core, Gravity was about cognitive agents, little interconnected benevolent leprechauns that did your bidding in surprisingly useful ways.
Starting today, I’m stepping back into the ring to help make Web 3.0, this time building StoryBot™, a general purpose cognitive agent that can be bundled into any desktop or web app. I’ll start by teaching StoryBot about educational resources, which given my Waveplace and Squeakland experiences in the last four years, will hopefully yield some genuine interest and funding. My hope is to help solve the trickiest of problems: flexible, context-driven, educational resource selection and assessment that avoids rubber-stamping our children towards Stepford futures.
I’ve spent years talking about the problem. I’ve spent years thinking about the solution. Now to build it.
May 9, 2011
I’m minutes away from starting a new software project for a genetics testing laboratory called CTGT. We signed the contracts last Friday, thus ending two months of mid-project limbo wherein three very different companies were vying for my summer. I went with CTGT for three reasons: 1) it’s local, which means I can stop by whenever needed, 2) the spec was very detailed, which means I can jump right in and start building, and 3) it’s scoped to let me continue picking my daughter up from school, rather than the usual pacing on the phone till after five.
Another big difference is that I’m doing this one solo rather than bring in contractors to help. After all the talk-talk-talk of recent years, it’ll be wonderful to slip on my work gloves and simply code for a solid long time. I’ll be using JEE 6, switching between Glassfish and JBoss, which means I can use some best practice technology, particularly JPA and JSF.
Anyway, it’s time to start. I’ve blocked out 7am to 11am each morning till August. Can’t wait