dru@druware

Someone asked about some of the background of Druware and myself, and I realized that it's not something that I've ever really talked about, so I thought I'd share.

I've actually been working with computers since I was about 8.  My father had been an IBM technical salesperson, and was one of the very first to leave and start what we now call an ISV (Independant Software Vendor).  In those days, software was created by the machine vendors, and as such the concept of the ISV really didn't exist.  Because of that, I came home from school one day to find a refrigerator sized box in the garage with a cable the size of my arm going up through the ceiling and into dad's 'office'.  Upstairs in dad's office was the table thing with a keyboard and green screen.  This was my first exposure to a computer.  It was an IBM System/32. 

I was pretty much hooked from then on.  During those early years, we had one of the original IBM PC's, in addition to various IBM midrange computers, 34.36, AS/400,  and my own experience and evolution followed.  By the time I was in college, I was working at a restaurant because I was kinda directionless.  While I was working there, I continued to play with computers, tearing apart operating systems to see how they worked and hacking.  I really started trying to make a living in computers while I was still cooking and going to school.  It started with a small consulting business, then added a 'classified' advertising idea called the Web Wide Classifieds in 1995-1996, lacking the funds to make that into something more,  circumstances worked out that I ended up working on a project called DeskXtend, which went on to become the foundation of Stardock's Object Desktop. 

While that was in progress, I was splitting time to help my father get an application up and running for his company, Satori & Associates for Bankruptcy Trustee Case management and accounting.  Somewhere along the way, an opportunity to go work for a startup called CareLinc came along and I took it. It was an interesting ride in the Venture Capital fueled world prior to the dotBomb.  From there, I took a couple of contract gigs, which eventually left me as a Sr. Web App guy for LandAmerica Financial Group, where I stayed for several years. 

I returned to my dad's business shortly after he had some health issues that raised some concerns as to if he could continue to do everything he was.  Today, I'm still there, but I'm also doing this, and as this builds, and we hire additional people over there, Druware is becoming my primary job.

Along the way, I've invested heavily into Open Source through my time, though really only three of my Open Source efforts really matter.  Those OSS efforts are all reflected in the work I'm doing here.  The first, and least referenced is the work I've done with Mono, specifically in the Cocoa# project.  I've done almost no code, but provided guidance, and when needed bug testing, but my primary role has been as a consultant.   That is changing a little, as I'm doing some active changing to that code, but still.  The other two are well documented here, PostgreSQL for Mac and ODBCKit.  

There have been some pretty extensive diversions throughout this list, with  deep foray into Real Estate support, Network Engineering, Manufacturing & Accounting software, but those are the high (and low) lights, of how we got here.

Now we are building the next stage.  Druware is my future, and the products that we are building are what I hope to use to feed myself and my family for years to come.

One of the things about being a small business like this is that while much of the industry shuts down for a week during a holiday week (Thanksgiving here in the US), we look at this as a week of free time for coding.  This is a good thing as we are rapidly approaching the release of our first product as a company, we still have alot of ancillary work to get done.  The customer management database and software is now set up, and once we finish a couple little details in the whole process, the product software will be completed.  

So while we wish everyone a happy Thanksgiving, and hope you have safe travels, we are going to go disappear into the home offices and try to knock out some details in the hopes of getting some product released a little early.

Well after some consternation, the problem with the ODBCKit and Leopard has been identified and fixed.   As a bonus, this should also resolve several issues with MySQL ODBC issues that have plagued the 0.2.5 release.  

Today, 0.2.6 was released and it adds a couple of minor fixes, but also paves the way for some major enhancements in terms of gracefully dealing with driver and ODBC version support issues that linger from the quick 'bring up' of the code without a whole lot of thought into dealing with the various permutations of driver  behavior. 

0.2.8 is targeted for January, and should accompany the release of the upcoming DBAAP package as the new ODBC Automator Actions depend upon functionality found in that code.  For more information, check out the product page for ODBCKit.

Just a note, that this morning we committed the first revision of the PGSQLKit Framework into the PostgreSQLforMac Subversion repository.    This framework is at the very heart of all of our PostgreSQL GUI tools.

For the record, it's hard to get a publish done when you have about no time to deal with it.  

Well, a couple of weeks ago, PostgreSQL 8.2.5 was released to the masses from PostgreSQL.com.  The problem is that this meant getting the Mac version rebuilt, and well, the timing sucked for me personally.  You see, I am generally the only person involved in the actually build & publish process.  Sure the others to some testing and development, but when it comes to the actually build the package, push it over to SF.net and the website, it's all me.  

With everything else that has been going on around here trying to get DBAAP wrapped up and get the work on PGDS ramped up to full speed, well, I've been overwhelmed.  So I tried to get a PostgreSQL for Mac release out the door.  The actually binary installer for the server is fine, but the client tools are an unmitigated disaster :-(.  Apparently, the build system completely hosed the builds and dropped the PPC versions in the first release, then in the second, they completely broke Leopard support, and *some* Tiger machines have issues with them.  

Frustrating doesn't begin to sum up the issues.  

The problem is time.  I should have tested things more thoroughly, but I didn't have the time, so I let things go out without enough testing.  It's my fault, and I have to fix it, but the rub is, that it's a 'for free' effort, which is takes away some of the motivation to invest the proper amount of time into a release.

So, now I'm working on a new build, and a new build system to help mitigate this kinds of issues in the future.

Over the past couple of weeks, we've gotten a couple of questions regarding our work on Automator Actions.  Specifically of the 'Why bother, it is nothing but a fluff tool'.  The problem is that Automator is so much more, and could be even more if more developers understood it's power.  So I want to talk about a couple of examples I use right now, and a couple I have deployed to customers.  

In terms of personal workflow automation, I have one that I use 15-20 times per day.  Like most software developers, I have a 'support desk' system in which each customer support email goes into a customer relations manager and gets a 'ticket' number that the customer has.  As I work a ticket, I like to keep the customer informed as to the progress of the ticket.  So, as I work, I keep notes in the notes section of the ticket in the CRM tool.  When I wrap up my notes for that ticket, I hit an icon on the dock and away goes an Automator workflow that does something that would take me a couple of minutes.  First it grabs the current ticket number from the web browser I was using, then it downloads a PDF version of the ticket to attach to the email, then it creates an email to all of the associated parties (that isn't me), and places the current notes and the resolution if it is resolved, into the email.  It then attaches the PDF, and sends the mail message.  

Let's be stingy and say it saves 2 minutes per message, which is generous, because if I have to open Mail to look send the message, I'll end up reading some message there, and not doing the task as promptly.  If I touch 15 customer tickets in a day, that's 30 minutes saved a day, 2.5 hours a week, so it's over one day per month saved by an automator workflow that took just about 2 hours to create and test.

The rule that gets run by Entourgae when these emails come in actually generates the tickets and sends our the number back to the customer is also an Automator workflow, generating an XML file from the email, posting it via SOAP to the CRM application, returning the ticket and a PDF copy of the ticket to the customer, saving a staff person from manually entering the tickets as they arrive.

Unfortunately, most of the why bother crowd says this is just as easy in AppleScript, and it is, if you already know AppleScript.  Not too many people know AppleScript that well, though.  That doesn't really solve the problem of making workflow automation easy for anyone though.  Automator does make it easier (not easy, you still have to think, and sometimes wiring it all together can be disconcerting, but with  little experience, Automator becomes a VERY powerful tool.  So that is why we are going down this path, to build something for the wider market than those who have learned AppleScript.

I know I've been a little quiet about the actual product work around here, so it's time for an update.  This week we've gotten the first internal test builds of the modified ODBC Query and Dynamic Query actions built and into a testable form.  The PostgreSQL versions are also now built, and will move to testing as soon as the developer finishes his testing.

Next on the agenda are the hard ones, For Each Record Run Workflow, Exit on Criteria, Export Recordset (to XML, CSV, etc), Transform XML via XSLT, and Import Record(s) from XML.   

Originally we had decided to release this as a single package, but we are starting to lean towards also offering the actions 'ala carte'.  We'll know more in the coming weeks.   If you have a thought, let us know in the comments so that everyone can get in on the action.

Alright, after a week of hacking and poking around in areas of the Mac OS that I knew existed, but I hadn't poked around in, the common login panel for the ODBCKit is nearing completion.  This has been an interesting and educational week.  

What you see here, is the new common dialog in the PGSQLKit's PGSQLLogin class.  Using the panel itself is fairly easy.  It requires two pieces.  The first, handle the delegate call from the login panel and then instantiate the PGSQLLogin class and call the beginModalLoginForWindow method passing in your own window.   

In code, the login call itself would look like the following:

When the user exits the login panel, the class will call your loginCompleted implementation allowing you to do whatever you may need.  In the following example, it uses the returned connection to retain the connection for use in the lifespan of the application and logs the state using NSLog();.  

In and of itself, this is not terribly complex, but behind the scenes, there is quite a bit of heavy lifting going.  Creating the connections is just a small part of the work here.  In order to make the panel more powerful and flexible, the panel itself embeds logic to save connections in the powerful and cool Keychain.  

If the user enters an account and a name, the dialog will save that connection complete with password in the Keychain for quick retrieval later.  That information can be edited and viewed in the Keychain Access tool, like this:

Just a heads up.  After a busy couple of weeks, I am headed out to a customer's site.  That means no updates here until next Tuesday at the earliest.  

It also means that your support emails may see a slight delay in response time and I want to apologize in advance.  The ones that are high priority by the support person that will be filtering them while I'm gone will be forwarded and answered from my iPhone, so the grammar may be awful :-).  You have been warned. 

On a lighter note, last weekend saw the upcoming PGSQLKit reach it's first milestone, where it can now do everything that the pgCocoaDB did.  It is also now building on Leopard.  Full commit to SVN is expected in the next couple of weeks.

Now on to a complex subject.  Getting and staying motivated during the startup phase of building a small company of this nature is a very difficult thing to do.  For a long time I assumed it was just me and my slightly scatter brained personality, but apparently I'm not alone.  After a recent discussion on the MacSB mailing list, I not only realized that I'm not alone, but not even in the minority.  There seem to be several approaches to this problem.  Interestingly I find that I already use some of the techniques for efficiency and time management reasons. 

One of the recurring themes in the discussion was that of choosing a first project that was too ambitious and would become boring or overwhelming before anything was released.  I actually feel that Druware did fall into that category initially, and that is largely the reason for the recent changes in the website and focus of the company.  It is excellent advice, pick a small attainable project as your 'getting started project'.

Other advice and suggestions dealt with the usage of tools for time management.  While this is very practical, I know many developers that are incapable of the context shifting required by time-slicing.  I'm not one of them, I find that from an efficiency standpoint, I time-slice my day every day.  Generally assigning specific tasks and project to specific time slots during the week.  Again, I've found this to be good advice, and it helps keep a project manageable without inducing burn out.

But probably the most important advice had to do with releases.   The motto in the Open Source Community has been 'release early and often' for many years.  For the aspiring microISV, this holds true as well.  Rather than use big milestones, choose small milestones, develop them, ship them.  By doing this you gain several advantages.  You have something in the customer hands sooner, and by releasing more often you can raise your mindshare with the marketing that goes along with a release.

Either way, the discussion is valuable, in that is sparks evaluation of your own process.  For Druware, it means evaluating and picking he appropriate projects, and evaluating them every month or so.

So now that we have the plan and products in mind, it's time to rebuild the website.    In the long run, we would like to host on-site and have a fully interactive web presence with all kinds of bells and whistles, but with the mindset of 'Getting Things Done', that just is not a good idea at this point.  As an aside, accepting that  is one of the hardest things to overcome in the 'what I want' category.  Taking a longer view of where we want to take Druware, we have started with a very basic, largely static website.

So what are we using to build the site?  Well, the server is a shared hosting plan, running a version of Linux.  We are using HTML and PHP on the server, and using a mixture of Coda, CSSEdit and Adobe's CS3 Web for all of our development processes.  We'll be reviewing each of these in the not too distant future.  Then for this blog, I have elected to use SandVox rather than one of the server side engines. Primarily, because I prefer client side editing.  If you've read some of my stuff prior to moving here, you'll notice that I have a strong bias towards client side applications over 'Web' applications.  

Building a website is, at best, an iterative process.  This first pass at restructuring is just that a first pass.  We've taken what we learned didn't work in the past and started fresh applying things we've learned along the way, and working a little bit at  a time, we are building what we want.  

The term I find most descriptive actually comes from a former coworker of mine, Emma, who described the process as 'Baby Steps'.  The process boils down to applying the same steps I've used in coding to building a business.  Make a small effort, test it, deploy it, build on it.  In code, that is build a unit, test it, deploy it into the project and move on to the next part that builds up from it.  In business, it means building an aspect of the business, and then build on it from there.  In this instance, it's the website, which is, for all intents and purposes, the modern equivalent of hanging a sign on the door that says, open for business.

This is a question that I have started asking every morning.  It's kind of a status check for me.   Where are we? in regards to the various projects I'm working on.   Side story, before I went back to Satori & Associates, which is a family business that I helped my father start and didn't return to until he had a health scare (that turned out to be not a big deal), I was working in a Fortune 1000, and had learned to be a a very structured, organized and 'time' oriented person.  This was a hard lesson for me because that is not my nature.

When I got back to Satori & Associates, I slipped back into 'chaos' mode.  This is where you work on whatever fire is burning the hottest right now, and switch whenever there is a hotter fire.  The problem with this mode of operation, is that nothing ever gets 'finished'.  Unfortunately, within the confines of Satori & Associates, I can only change my own process, there are others who are too rigid to change.  That means two things for me personally.  First, I have to fix my own working model, and second, I have to focus on restoring order where I can, and that means Druware (and to a lesser degree, Two Wheel Junction).

So, where are we?  The first step is in progress.  For the first time in 4 years, I have returned to my planned and structured days, where my projects are mapped out and I work on them in timeslices, and that is ALL I work on during that slice.  Over the years, I have found that this is the most effective use of my time.  Closing email, closing support and coding on a specific project during it's timeslice.

The second step is just beginning, and will take time to get rolling at full speed. This, the blog and website is just a small part of the process.  Finishing up some of the several 'in progress' projects for publication is the next.

In the next post, we'll address some of those 'in progress' items...

We'll talk again on Friday.