From 1985 to 1988, in addition to programming in C, I taught intense week-long courses for Integrated Computing Systems, now The Learning Tree. I was one of their most popular C & UNIX instructors.
C became my primary compiled language as soon as I learned it. Although I learned Objective-C in 1990 and really enjoyed it, I still primarily coded in C--typically daily--through 2004. Today I am more likely to write in Ruby or Objective-C, but I still read and write C fluently.
I wrote much of the code in Executor, a Macintosh emulator. However, some substantial pieces were written by my employees, so ask me if it matters (or assume that they wrote the best parts and I wrote the worst, since that's the worst-case scenario).
I haven't listed C++ as a skill, because I strongly prefer Objective-C. So, I've never written anything non-trivial in C++, although I've read a lot of C++ code over the years.
The language of the iPhone, Mac OS X
Objective-C is primarily used with Apple hardware. It is the language that almost all iPhone apps are written in, but it predates the iPhone by more than twenty years.
I learned Objective-C in 1991 when I ported Executor, to NeXTSTEP. I used Objective-C because I had to; there was no other choice at that time for that platform.
Although I only used Objective-C as interface "glue" in Executor/NeXTSTEP, I liked what I saw. In 1998, I wrote "multibot", the first software to deal multi table poker tournaments on the internet. I chose to implement multibot in Objective-C, even though development and deployment would be under Linux. I have been programming in Objective-C off and on ever since.
Thanks to Popular Electronics, as an electronic hobbyist, I was exposed to CDP-1802 machine language, but I was never paid to write any. I was paid to write a lot of assembly language for PDP-8s. For fun I also wrote assembly for DEC-10s and PDP-11s.
When I wrote Executor, I was fluent in reading and writing 680x0 assembly.
I Understand the Issues, but am not current
When I was knee-deep in assembly, it was easy to get a good bound on how quickly a piece of code would run by counting instructions and memory references. I never became proficient at writing assembly for the x86 and although I've skimmed articles on new CPUs as they've been released, I haven't done any work with the performance counters a modern CPU makes available to a modern assembly programmer. Still, I can come up to speed on modern assembly much faster than someone without years of--admittedly ancient--experience on primitive CPUs.
I learned Ruby in 2005. I needed more than awk and sed, but never warmed to Perl. After examining some of the high level scripting languages, I decided I liked Ruby best. I was already a big fan of Objective-C and Ruby fit the way I like to develop software.
I've been programming in Ruby daily since then. I've made tiny contributions to Ruby open source projects (e.g., tzinfo, RSpec) here and there, but most of my non-Rails Ruby work has been proprietary.
On the first and third Tuesday of every month, I host an informal get together of Ruby enthusiasts in Albuquerque at SWCP from 6-8pm.
Ruby on Rails
I started using Ruby on Rails in 2005. It's a framework that allows me to be very productive. Rails programmers are a subset of Ruby programmers, both communities are friendly and vibrant.
I used Rails for a number of personal projects before co-founding Stolen Bases, a company that used Rails to produce a number of applications, including MailThisOut, a print-on-demand application, WYWH, a post-card from-your-cell phone front end for MailThisOut and Fabrica, an app for unique and small-batch production (used by the Comic Space store).
Post Stolen Bases I've created a few Rails backends for iPhone and iPod apps, created a Rails template and provided over a fifteen hundred hours of Rails consulting to JackRabbit Systems including creating actsasranged.
It's for programming native Mac Apps
I began of programming using the NeXTSTEP API in 1990. NeXTSTEP eventually became Cocoa. I continued to use Objective-C in the 1990s, but I was not using Cocoa.
But it's very similar to iPhone OS
When Apple released the iPhone SDK, and my company decided to create an iPhone application, I took a renewed interest in Cocoa since it is the parent of iPhone OS. The debugging tools for Cocoa were initially more polished in the early days of iPhone programming, so I did a little Cocoa programming to shake the rust off.
I've never shipped a Cocoa app, but I know Objective-C well and can quickly program using the Cocoa Framework.
Developing for the iPhone is fun. It's almost as easy as developing Cocoa applications for the Mac (memory management and debugging is trickier). I'm an active member in the Cocoa Conspiracy a loose collective of iPhone and Cocoa programmers.
I supervised the creation of Postcards, an iPhone app created before Stolen Bases was bought by E-Line Ventures. It uses "ARLite", an implementation of a subset of Active Resource I wrote in Objective-C for the iPhone.
I have written Ruby on Rails backends for iPhone apps, including the aforementioned Postcards and Twittelator Pro.
So, although I personally am more of an infrastructure developer than a GUI coder, I can get iPhone apps built, using my own skills, Marcia's graphic designs and drawing from an extended talent pool in Albuquerque.
In 1986, I began writing ROMlib, subroutines source-compatible with those in the Macintosh ROM. Using ROMlib, programmers with Macintosh source code could make their software elsewhere. In 1990, I created Executor, a Macintosh emulator using ROMlib. In 1993, I hired Mathew Hostetter to write ARDI's synthetic 680x0 CPU. Mat's design was better than mine! I love working with smart people. I wrote the interface between Executor and Syn68K.
At NHR, I wrote a Visual Basic parser (using Bison) and analyzer. Although it was incomplete, it was good enough to parse all the Visual Basic source that I was auditing at NHR.
Emulation liberally defined
Emulation is writing code to specs, frequently very high level and poorly defined specs. ROMlib initially was coded "to the book" (Apple's documentation), but that was insufficient to make everything work (undocumented features, undocumented bugs, misdocumented features and even misdocumented bugs). I couldn't find a spec for Visual Basic, so I wrote my parser using what I could find and then just fed it every piece of code we needed to analyze.
Emulation is fun.
Hand-in-Hand with Emulation
ROMlib and Executor were written using strictly clean-room techniques. Nobody at ARDI ever disassembled any of the code we were emulating. Not a byte of Apple ROM or Apple System File was disassembled. We did, however, disassemble the applications that had trouble running under Executor. Mat Hostetter even made a tricked out version of gdb that could disassemble 680x0 instructions while we were running on x86 machines.
Macintoshes are big-endian. PCs aren't.
Reverse Engineering is challenging, which means it's fun.
In 1993, inspired by Roy Hashimoto's work, I wrote software to evaluate poker hands. Others, notably Keith Miyake, sent me improvements. After Mat Hostetter joined ARDI he made a significant observation that allowed us to write was the fastest in the world at the time. I GPL'd my poker source. It's still available although Michael Maurer and Brian Goetz have since written a superior library.
Stuck at home, handing out treats on Halloween of 1998, I wrote the core of multibot, a server to deal multi-table poker tournaments. Within a couple of weeks of coding in the evening, the denizens of IRC poker were playing multi-table tournaments using my software. I sold multibot in 2001 and continued adding features as a contractor through 2005.
Autotools are a bit arcane. I have been configuring and compiling autotools
(and autotool-like) using packages since around 1994. In 2004 I had
an employee convert Syn68k to use autotools. In 2009, I converted Executor
to use autotools. Executor's
configure.ac file was the least elegant
code I had written in the last five years. Still, I understand the paradigm
and will continue to use autotools when appropriate.
In the summer of 1981, I volunteered to work at the University of New Mexico for free, because they had some UNIX systems and I had heard that UNIX was worthwhile. I liked what I saw and later came back and was hired as a Systems Programmer, where I worked until I pursued my MSCS full time.
After graduating, I became a consultant, writing UNIX device drivers, boot ROMs for UNIX systems, a disk formatting utility, an image processing pipeline library and other system-level UNIX components. I was part of the team that brought UNIX to Salomon Brothers in 1989, and in my own company we used SunOS and later NEXTSTEP.
In 1994, an employee introduced me to Linux (Slackware). I've been using it ever since. A small portion of the HFS support I wrote for Executor made it into the Linux kernel. A trivial patch I made in 1995 is in the Linux kernel (download the source and grep for email@example.com).
Although I haven't done any UNIX/Linux kernel work in a long time, I still have the same eye for detail and understanding of OS internals needed to do it.
Following standards allows us to more efficiently create software that is portable and maintainable. We use tools and compiler settings that check our code and HTML for compliance with standards. By being standards compliant through every phase of development we've been able to find and fix subtle mistakes that might otherwise have resulted in downtime or hours of debugging.
I love to learn and I love to teach. Cleve Moler told me that if you really want to learn Calculus I, you should teach Calculus III. I have taught UNIX and C for the company whose name was originally Integrated Computer Systems, but is now known as The Learning Tree. For several years I taught origami to fifth graders once a month. My wife and I home-school our children.
When it pays as well as consulting, I'm happy to teach a short-course or two. I teach for free occassionally at meetings of RubiABQ, the Albuquerque Ruby User's group.
In 2009 I wrote:
"I have no skill as in graphic arts or layout. I can, however, choose components, put them in place and wire them up. I help non-programmers use Interface Builder, but without their help, what I do myself is bug-free, usable and maintainable, but ugly."
In the intervening six years, I haven't used IB at all, so if I were to use it I'd be rusty, but I still understand the concepts.
RSpec is a Behavior Driven Development framework for Ruby. I use it because it allows me to create solid software quicker than by not using it. I believe that for anything other than trivial apps, I can more quickly write tests, write code, refactor as necessary and deliver final product than I can by just writing code, debugging the code and then delivering the final product.