Wednesday, September 23, 2009

Being a _____ Programmer

A recruiter called today, asking if I was a PHP programmer. Sure, let's go with that. Truth is, when people ask questions like that, they are asking if that's all I've done for the past several years. But for the past couple of years I've been studying mathematics. So the general answer to most of these questions is no, I'm not a _____ Programmer. I'm just a programmer who has done some work in _____.

And it hasn't been all continuous. I spend weeks here and there working in two or three programming languages at a time, on completely different types of projects. Then I've moved on. "Why," people ask, "don't you stay on one project longer"? Well, when the project is done, you move on. I don't believe in doing projects just for the sake of building IT cruft to circle the customer in, make them pay for junk they don't need. To my way of thinking, people could get away with about 20 percent of the technology they have, and would be better off without the other 80 percent. So I spend some of my time destroying technology. That's as much a description of my past work as anything else.

Take ETL for instance. I've done jobs for Nortel, converting telephone listings for exchange between their directory services products. These were one-of, batch-mode projects, with big buffers, logging, audit trails, and programming to maintain transactional integrity. Completely tested. Stuff you'd use on a 911 system, and we did. The whole point of the system was to be able to say with confidence, that the old system could be turned down, shut off, and eventually discarded. That made the sale possible.

Or PHP. I hate it when people ask me, in not so many words, if I'm a web monkey. No, I have not spent years pretending to do serious Object-Oriented programming with psuedo-object-based template language evolved from a hacked version of Perl. I have coded with PHP in MVC frameworks though, mostly the code in Mambo/Joomla components, modules and templates, but some other stuff as well.

Let's see... the first I ever built was a personalized print-ordering preview component, using a Flash movie to show the look of a client's logo and address on a piece of printed material they could order. I also build a bridge component in PHP/MySQL code to migrate customers from a Bosch Security corporate feed into that system's user table. That interface had to be transactional: we had to update and disable client records as well. So I wrote a differencing algorithm, polling a REST XML URL they provided to source the data twice a day, and applying the transactions in SQL. I really hacked the Mambo core components up for that project, so we could integrate in an existing shopping cart's PHP code. It took a while, but I was able to work the Mambo template to conform very closely to the Bosch Corporate Web site style guide. In the end the transitions back and forth were seamless (we used no disclaimer because the users were restricted dealerships signed in under a special program login).

For the Bosch site we needed to tie back specialized marketing print collateral articles to back-end templates, front-end previews, and a pricing matrix implemented using shopping cart product catalog codes. The way this was done was by introducing semantic tags inside the normal Mambo product articles. The semantic tags carried enough information to do the linking, and were stripped out before they got to the browser. That way we avoided having to fork the stock Mambo com_content table structure. We still needed specialized functions for the previews -- it would be a lot easier with Joomla 1.5's template overrides -- but it worked pretty flexibly.

For production data feeds, instead of using REST I deployed a GIT-like tool as a means of archiving and transferring orders from the front-end site to the production server. This was nice because we could recall the orders for a given time period and rebuild production queues on demand, using the scm's commands, anywhere we wanted.

When I started consulting I contributed a Joomla site to a local Chamber, and built a PHP/XSLT/SQL component for that site. They needed a way to maintain their customers on their Web site. I put together a Joomla Web site, with lots of components specially found to meet their needs for advertising, searching member's profiles, posting special feature articles on the site, and so forth. It was in the bag, DONE. So for icing on the cake I wrote a bridge component to let them dump their QuickBooks Customer Database to the Joomla user's database. Been there, done that, did it differently. This time, I took an XML file and wrote an admin interface to let the file be uploaded, transformed via XSLT into MySQL code, and applied it directly to the database. Batch mode stuff. It wasn't the prettiest, but it worked swell. An advantage here was that the Chamber could have maintained all their membership info within QuickBooks, including categories, and we could robustly populate the Web site with new features in a snap. They had that all, then out of left field asked for an ISV to bid on a new site. The ISV got 6 grand to build a new site, but provided no means of updating the most important advertising content. And the Chamber now has to update the membership list manually. Too bad for them. That's what I get for volunteering. (See my swimming with sharks post elsewhere on the blog).

I've been somewhat conservative with the NC State Mindset Project site. The three most critical issues there were (1) running Joomla in a restricted hosting environment (which was incredibly difficult), (2) making sure the site passed accessibility checks and (3) not introducing unmaintainable code for a research project with limited resources. I did copy and adapted a few Joomla components to meet the unique needs of the project -- a help request submission and tracking component, a personal journal entry component, a simple forums component, and a plug-in to go along. Those adaptations were straightforward and did not impact the core Joomla codebase. What was more of an issue was that certain PHP functions banned in the hosting environment were buried in core code. Some changes to a few components' MVC models and controllers were necessary, and to the Joomla core library, leading to a need to migrate patches forward for every security upgrade. Joomla 1.5's template overrides help here but do not eliminate the issues.

What else, what else... ? I think that's it. I piddled with PHP sometimes at Alcatel, but it was small time stuff. I had more serious Oracle database ETL tasks and 4GL application UI work to concern myself with there. In an enterprise situation often the best strategy is to rely directly only upon the most stable, high-performance systems, and isolate, insulate, and marginalize the rest of the systems through batch-mode or REST-style interfaces. Doing so is akin to normalization with respect to a relational database: you ensure that the solution is structured with the least volatility.

No comments: