code prole


coding for the proletariat since 1977

Electronic Text Books

My employer has a Safari Books online account, and I am using that to access Cocoa Programming for Mac OS X, Third Edition, to jump start my understanding of Mac programming in general and Cocoa in particular.

I have a love/hate relationship with online books. For reading novels the format is great. I have several hundred fiction titles in my electronic collection and make good use of an aging Palm m515 to read them. Reading non-fiction, particularly text books is a less enjoyable experience. With the book open (either in a PDF reader or the browser or eBook reader)  you have to continually “flip” back and forth between the text and your working example in the IDE of your choice. Often times you’ll find yourself positioning the text as far to one side of the screen so that you can position the editor as far as possible to the other side of the screen so you can transcribe the example code.

The ideal situation is multiple monitors, which I have at work. Put the IDE on one screen and the tutorial or book on another screen and have a ball. My personal machine is a laptop and I don’t have an external monitor, so no multiple screen goodness to the rescue. However, I have more than one laptop, so I have on occasion emulated multiple monitors with multiple computers.

Safari Book Shelf is nice enough, especially since I’m not paying for it. I think, at least for books, I prefer buying the actual hardcopy and having it as a reference. Pragmatic Programmers publish most (if not all) of their titles as either PDF or paper book. I usually buy both; that way I have the book for reference and a PDF copy on my machine for times when the book is where I’m not.


Filed under: eBooks, Pragmatic Bookshelf, Safari Books

Old Dog, New Tricks

In an effort to dust of my long languishing programming skills I’ve decided to learn Cocoa programming on the Mac. Sure, my job uses Java primarily but I mostly understand it, even if I don’t regularly code Java. Ultimately I’d like to contribute to an open source project, Adium for example. Contributing to a widely used open source project would be acceptance on a grand scale.

The Adium project uses Mercurial for source control, and I’ve already started learning it. What I really need is an update XCode / Cocoa tutorial or book. I’ve got a copy of Vermont Recipes, but it was written for the inital XCode release and too many of the underlying tools have dramatically changed for it to be an effective resource. Fortunately my employer has a Safari account and I can access several Cocoa programming resources there.

In addition to learning Mercurial and XCode / Cocoa, I’ll need to reintroduce myself to programming. It’s a discipline I’ve always enjoyed but one I’ve lost. The concepts are still here, I just need to brush them off and reapply them.

Ideally I’ll track my progress here. Hopefully this posting won’t be the only one on this subject.

Filed under: Cocoa, Mac OS X, Source Control

On Not Getting Run Over

My current employer has, in the last three years, been graced with a sudden influx of new business.  Revenue from what was originally considered by many within the corporation to be merely an adjunct line of revenue, has now become the mainstay of the company.  Suddenly we are the leader in this field.  Internally the group overseeing this cash cow is still small, 40 or so people out of nearly 1000 employees.  Through luck, and sheer force of will, our director has managed to carve out relationships with the considerably larger IT, Client Services, and Product groups, necessary to our survival.

Only those considerably larger groups are now starting to catch on that we, the tiny 40-person department, are the keepers of the gold egg laying goose.  Like many corporations this one isn’t nimble; changes in direction come slowly, if at all.  Usually the company has to run smack into a wall before realizing that the former direction was a bad one.

My fear is that our little group is about to get trampled by the big boys.  The IT department is roughly 10 times our size, as is Product Planning.  Once they get themselves turned around and pointed our way we had better be prepared to lead the charge, or we’ll get trampled in the ensuing rush.

Naturally we are just winging it in our group.  Processes exist only in people’s heads.  Nothing is repeatable, and when we do repeat stuff it is never done the same way twice.  We aren’t any more agile than our larger siblings, and we are no better prepared for an abrupt change of direction either.  Our only hope for survival is to document the hell out of what we do, to cement the ad-hoc relationships with the groups we depend upon daily/weekly/monthly, to be ready to hand over the reins of a smoothly running, highly organized process to those that want it.  Only by doing that will we be afforded the opportunity to create new processes and continue to lead.  Without documentation and without clear, well-defined procedures, we’ll be left to clean up the mess, while the bigger departments take over the new work.

It’s going to be a wild ride.

Filed under: Miscellaneous, ,

Learning Curves

Recently my career has taken a few curves, learning curves to be exact.  After several years of little or no professional programming, I am re-entering the development side of the house.  Lately I’ve been immersed in Java, Eclipse, WebSphere, JDBC, ODBC, Maven, and CVS.

Each of these technologies individually wold make for a decent learning curve, taking them all on at once, in the midst of a major re-engineering effort, has made for some frustrating days.  The organization is in flux, the development standards are changing (we’re switching from CVS to Subversion as I type), new managers and new employees are altering the status quo at every turn.  It is exciting and terrifying all at the same time.


Filed under: Software,

Portable Apps

Off and on I have been using portable apps, run from a USB-key as a part of my daily work experience. In my former life as a consultant I was bared from running some software on the client-provided workstation, and in some instances didn’t have administrator access to install software I wanted. Being able to run Firefox or GAIM from my thumb-drive was a life saver.

In a couple of months I am taking a vacation to Europe and I am strongly considering not taking a laptop with me. Instead I’ll rely on my portable Firefox, Thunderbird, and GAIM to provide me the connectivity I want. I’ll be taking a portable 40 GB hard drive with its choice of Firewire or USB connection too, to hold pictures captured from my camera. The only piece missing from this portable collection (other than the laptop) is some kind of protection against key loggers on public Internet cafe machines. Once I locate something that I can run from the key itself to ensure that no one is snooping on my activity, I’ll be laptop free but still connected.

PortableApps. Check it out.

Filed under: portable

Network Latency

Yesterday morning I started the IBM Installation Manager so I could update my version of RSA from 7.0 to  Twenty-three hours later the process was still running having completed only 53% of the estimated work.  Obviously something wasn’t kosher.  When I discovered the process was still running this morning my first thought was that the anti-virus software was inspecting the download and causing it to run so slowly.  However, a quick peak at the active processes revealed no virus scanning activity.  After describing the situation to a fellow denizen of the local cube-farm I tried disconnecting all the network drives attached to my workstation.  In the next twenty minutes the process finished the final 47%.

It would seem that here at Widgets-R-Us network latency is a problem.

Filed under: Miscellaneous, RSA

Not Making a Splash

I’ve been using Eclipse, or Eclipse-based tools for many years now, and in all that time I’ve never had need to turn off the splash screen that is displayed when the tooling first starts. However, the latest and greatest Rational Software Architect from IBM (basically a huge plug-in to Eclipse) manages to hide the workspace chooser behind the splash upon startup. Since RSA can be a bit slow getting loaded and running it is easy to assume the worst and wait for the workspace chooser.

And wait.

And wait.

So I’ve added the -nosplash switch to my RSA shortcut thus eliminating the splash and making the workspace chooser visible as soon as it pops up.

Filed under: Eclipse, RSA

Used Car Recruiting

Recently I updated my resume on the major technical job search sites, something I do once a year of so, if for no other reason than to test the tech market waters. As is always the case following a resume refresh, the amount of job related email and phone messages increases. I am afraid to say this, but, looking for a job in the technical market space is ever so slowly inching towards the “buying a used car” end of the user experience spectrum.

A few points for the recruiters among you to consider:

A. My profile very clearly states that I am NOT interested in relocation or travel beyond a bare minimum amount. More than half of the inquiries I get or for positions hundreds if not thousands of miles away, and/or engagements that would have me living out of a suitcase at the local “suite” motel. Why are you wasting my time and yours?

B. Just because I use the words “configuration management” in my resume does not mean that I am a Configuration Manager. Relying solely on keyword matching to blindly send out emails or make cold calls displays a shocking lack of involvement in me and my future. If you can’t be bothered to eye-ball my resume to see if I am at least a cursory fit before calling me, why am I to believe that you will be there for me when the chips are on the table and I need back up during the assignment?

C. Calls or emails which can be paraphrased as “Do you know anyone with these qualifications?” will be deleted immediately. Why should I do your leg work for you?

D. Proofread, proofread, proofread. Surely there is someone in your organization for whom ESL is not an excuse.

E. Given the choice between two return email addresses, pick the company one. Maybe I’m a snob, but working with a recruiter “in” the tech industry who still uses an AOL account as their primary email just doesn’t inspire a lot of confidence.

F. Don’t insult me by asking, after telling me the title of the position, what my rate expectations are. My rate is based on location, duration, and enhancement to skill set. And there will be a discussion of total compensation value long before I play “guess the number in your head” to move on to the “interview level” of “Let’s Make a Job Deal.”

G. If you send me an email, or leave me a voice mail, stating that I should reply to you with a resume if I am interested and I do not reply, assume I am not interested. Do not hound me with emails and phone calls.

H. Finally, you are not my friend. Nor am I yours. We will have a professional, and hopefully cordial, relationship for as long as it takes you to ink a deal between myself and my next employer. Once you get your 30 pieces of gold you will disappear from my life forever. Don’t pry into my private life and I won’t pry into yours.

Got it?


Filed under: recruiting

Components Scale

Recently at work we’ve been discussing components and how to classify them. It occurrs to me that what is missing in most definitions of components is the context. The context determines the scale of the component.

A Java class is a component, and a simple application utilizes one or more classes as components in completing it’s function or purpose. A larger application may utilize individual classes or call upon a service that choreographs the efforts of several classes or services. From the viewpoint of the application the objects it calls are components. In this example the individual class may no longer be considered a true component – it’s just a building block.

In any given business there will always be a context through which the application is viewed. Having that context is necessary in order to see the components that make up the application. In the context of a small expense tracking program the component scale is small, individual classes, maybe even methods within those classes. If, however, the application is something as large as MIDAS, then there would be layers of components. At the highest enterprise level, the components would be entire applications. Once you move down to that level the components would be business service orchestrator (I’m hesitant to use the work aggregator due to it’s UML implications). Once you drill down to the business service orchestrator the components become functional services and perhaps technical infrastructure supporting objects.

For me at least, having a taxonomy of components that differentiates between business component and technical component, service and embedded, isn’t really useful. What is useful is being able to scale your viewpoint to see the next layer of services or functions from the viewpoint of the current requestor. If it helps people with poor(er) visualization skills to think of enterprise components utilizing business components, which in turn orchestrate functional or technical components, which are comprised of language components, then so be it. But to my way of thinking a component is any self-contained, reusable function or service exposed through a stable and well defined interface.

Just my $0.02.

Filed under: Concepts, Software


I've been a consultant (more or less) since 1997. I've worked at a number of engagements both in the private and public sectors, each with their own flavor. The one overriding concern that always seems to get expressed badly is management of the consultant's time. Some engagements go so far as to require sign-in and sign-out sheets so that the "consultants" can be tracked. My current engagement allows the employees tremendous latitude regarding their work schedules. Some people are at work as early as 5:30 am, and consequently leave by 1:30 or 2:00 in the afternoon.

To a person the consultants I work with on this engagement are professionals. They all work hard, and we are meeting our goals in spite of politics and infighting between the various departments involved in the project. Some of us (myself included) are early risers and are at work by 6:30 or 7:00. Others don't arrive until 9:00 or later. However, the project manager (really an engagement manager) has decided that it doesn't "look good" for us to leave early on Fridays. You see we are contractually enjoined from working more than 40 hours per week. Arriving early and getting a running start on the week's tasks often results in 9 or 10 hours days. By Friday it is typical for me (and others) to only have a handful of billable hours left, and so we leave at 10 or 11 for the day.

Last week the engagement manager, in a fit of pique, sent an email to every consultant under his thumb demanding that we all be at work until 2:00 pm on Fridays from here on out. Reliable sources claim he threatened to set the time as late as 4:00 or 5:00. At first I was pissed that he was going to micromanage my time just so his company could "look" good. The engagement is struggling with large meaty problems like delivery dates, lack or requirements, and an inability of the client's management to keep their own process in check (resulting in a myriad of other problems). So naturally, instead of stepping up and demonstrating true professional mentoring we're going to instead focus on being at work until 2:00 pm on Fridays.


The silver lining in this cloud has been leaving work at 3:00 every day this week to ensure I'd have time for Friday. The extra hour at home every day is nice.

Filed under: Project Management