Welcome to my personal site. At some point I intend to set up some sort of site management program but for now it's strictly plain old HTML.
I am currently a self-employed software developer working primarily on Apple's Mac OS X platform. My current work involves the wxCocoa port of the wxWidgets toolkit.
I've had the opportunity to work in many programming environments over the years. These have included C, C++, Java, Python, and various command scripting languages such as bash. In addition to that I have an interest in assembler (specifically PPC and x86) at least enough to be able to understand the code that a C compiler generates. I don't usually write in PERL or Ruby but I do occasionally do simple mods to programs written in those languages as well as programs written in a number of other languages.
While I worked at STC I wrote a comprehensive contract management system known as ETOMS. The first major version of that project supports STC's EFS contract with NASA LaRC. The second major version of the project supports STC's DDST contract with the Army's Dugway Proving Ground.
The ETOMS application is absolutely critical to STC's ability to manage the DPG contract. It is a wonerful example of how well-designed software can make a huge difference in business efficiency. It is also a wonderful example of how software can be developed quickly to meet the needs of the business. The project grew from a simplistic task management system to a comprehensive system supported by its own class library able to provide the data for several different kinds of reports.
It could not have been done without using Apple's WebObjects frameworks. WebObjects is an amazing piece of software supported by its own Enterprise Objects Framework. EOF is not a data serializer like most of its so-called competition but rather a comprehensive entity-relational framework. With OS X Tiger, Apple brought some of the ideas behind EOF back to Objective-C in the form of Core Data. Unlike WebObjects, Core Data is limited to local databases like flat files and SQLite.
After taking a brief hiatus from WebObjects development I decided to try to go back to it. I even have some plans to manage parts of this site with it. Well, that proved to be somewhat problematic because the legacy developer tools (EOModeler and WebObjects Builder) refuse to run on Leopard. After wasting a bunch of time trying to get used to the new tools I gave up for a while. I then decided to use a Tiger system to do some development but that's a pain since it's on an old desktop Mac, not my MacBook Pro.
Still, it was enough to realize that I really did want to use the legacy tools badly enough to invest some time to make them work on Leopard. Thus I came up with my WOCompatibility hack. I figured, why not.
One of the first things I did at STC was to write a GUI wrapper around a very impressive image enhancement algorithm known as Retinex for the TruView subsidiary of STC. The project was sort of a skunk-works thing intended to replace the absolute mess that was version 1 with a working program capable of being ported to the Mac.
After some research, I setled on the wxWidgets toolkit. After completing version 2 for Windows I moved on to porting it to the Mac.
My introduction to the Mac began with OS X version 10.1. While I was completing the initial version of PhotoFlair 2 for Windows I dedicated a bit of time each day to learning about the Mac. When it came time to do the Mac port I had no choice but to use the Mac. Looking back it's almost amazing at how far OS X has come since the 10.1 days but it's also amazing how much Apple got right from the beginning.
Since I had been using Linux to write PhotoFlair I simply stuck with the environment I knew and continued using VIM to edit and configure/make to build. Being familiar with Linux allowed me to move right in to OS X development. But it certainly didn't prepare me for the foreign world of Carbon.
Back then, Carbon was a slightly modified Mac toolbox. Having no prior Mac experience it seemed rather odd how this toolkit could possibly form the basis of OS X. After more research I realized that it didn't and that the real gem in OS X was the Cocoa frameworks and the Objective-C language. Being a C++ programmer, the Objective-C language was at first a little odd. When I finally learned enough that I felt I could start writing a new wxWidgets port, I did. That is how wxCocoa got started.
wxCocoa is, as the name implies, a port of the wxWidgets toolkit running on top of the Cocoa toolkit provided with Mac OS X. The wxWidgets toolkit is rather unique among cross-platform toolkits in that it does not attempt to implement a cross-platform set of controls but instead strives to use the platform's provided controls.
That means that on Windows a wxWindow has a corresponding HWND, on Mac an HIView (or one of the older carbon window classes), and on Cocoa an NSView. More importantly is the fact that a wxButton is actually a real NSButton in cocoa, not some thing that looks like a Cocoa button but is really a generic control and just an NSView.
The initial code in wxCocoa progressed rapidly but eventually I wound up working on too much unrelated real work. That left little time for hobbies (a pity, really) so wxCocoa stagnated for a couple of years.
Recently, I've had an opportunity to continue working on wxCocoa. Stefan is also doing a lot of work on his own bringing some Cocoa functionality to wxMac and eventually we plan to mostly merge the ports.
If you are interested in wxCocoa I suggest you join the wx-dev mailing list. The project could use some developers, particularly those who want to use wxCocoa and don't mind implementing a class here and there.
Almost since I started using OS X I have been fascinated by the idea of running the open source portions of it on a normal x86 PC. Even without all of the additional frameworks and applications that make OS X the wonderful system that it is, Darwin is a good system in its own right. Consider the IOKit, or launchd, or the mDNSResponder.
Have a look at my Darwin/x86 page for more information.