Blog

Is Spotlight becoming a command-line tool?

 

I was just working through my podcast backlog and hit Apple Tip #44 which demonstrates using Spotlight for doing simple calculations and defining terms. Google’s been sneaking similar features into their basic and advanced search for years. Maybe it’s just me, but it feels like command-line tools are making a slow, under-the-radar comeback.

As much as I love the Mac’s GUI, I’m a UNIX guy and just need a command line from time to time. GUIs are great for arbitrary selection, but command lines provide better related-set definition and complex processing via wildcards, regular expressions, and pipes. That was my initial attraction to Mac OS X–best of both worlds with a new GUI on top and BSD underneath.

I have to admit I don’t open terminals much lately: Bluehost‘s control panel and Coda let me handle routine web hosting activities, and I’m more likely to open Python than use bc to do simple math. There’s also Quicksilver, an interesting hybrid of keyboard control and graphical display worth investigating. Parsing a raw dump of my currently-subscribed podcasts still benefits from some sed/awk magic, but I’m getting comfortable enough with AppleScript to try that approach next time.

Neither GUIs nor command-line interfaces are silver bullets. Improvements in Spotlight and Automator are giving GUI users some of the capabilities that previously were only available to the UNIX-savvy. I can’t wait to see how these new hybrid tools evolve to give me new ways to look at and work with my computer. Must be my Perl heritage, that need for more than one way to do it.

Another Conference I Won’t Attend

EMC World is in Las Vegas this year, and once again I won’t be going.  When will this conference come to the Northeast?  I’ve been on a plane three times in the last eight years, and I’d be perfectly happy if I never got on a plane–or set shoeless foot in an airport–again.  The whole process is wasteful, annoying, and unhealthy.

Speaking of conferences, I haven’t seen any email about FCG’s annual event.  If anything, it was a great way to reconnect with other old-timers.  I’ll have to poke F. and see what’s going on.  (Assuming he reads the blog, he should consider himself officially poked.)

Speaking of poking, this month is the 14th anniversary of my first job with Documentum.  Time to send out an email and see if the old team is available for a commemorative lunch, especially since I may be out of the Philly area for a while.

I have mixed feelings about leaving home because I’ve really gotten reconnected in my downtime, but the area’s depressed and the opportunity has benefits to compensate for the location.   Details to follow after we put ink to paper.  Last chance for any Center City Philadelphia company to snap me up.  Too bad nobody down here actually uses Documentum.

Science and America’s Future

I’m working through my podcast backlog between films and finally got to the Science Talk episode Science and America’s Future. Robert Posner, the director of Argonne National Laboratory, talks about the value of basic research and the negative impact of the three-years-running cuts in Federal funding to basic science. This is a must listen (or read).

He talks about how our increasingly short-sighted society is bankrupting our scientific future because they don’t get that it takes decades for basic research to mature into game-changing technologies. Companies only worried about their next quarter aren’t going to spend money on ideas that seem like science fiction now but will dominate the economy of the next generation. The Long Now Society has been sounding that alarm for a decade. Is anybody listening yet?

That’s why government funding of basic science is even more important now. But suppose our current (rapidly declining) economic and scientific world dominance rests on the laurels of research started in the sixties and seventies. The “Reagan Revolution” of the 1980s kicked off America’s anti-science attitude. Republicans pandering to their religious fundamentalist base curtailed new vistas in science like stem cell research, but Bush’s broader defunding of basic science may relegate the country to scientific irrelevance in 20-30 years. Given how science begets economy begets political power in the post-WWII world, it’s not just scientific irrelevance we need to worry about.

Further Reading:

The Clock of the Long Now (book)

Job Hunting

Kermit the FrogMy first month of job hunting hasn’t flushed out anything great. I’m trying to stay local, but the market in Philly is a little stranger than usual. Philly itself isn’t a hotbed of high tech, and some of my former clients in the burbs are downsizing. I have some leads out of state, but they’d have to blow my socks off in every other way to make up for the location.

Two weeks down with the flu hasn’t helped much either. The last three years seemed particularly bad for me and the general population. Are we dealing with nastier bugs, more opportunity for transmission, or declining health across the entire population? In any event, I hope I don’t sound like I swallowed Kermit the Frog on my phone interview later today.

One good thing about a slow market is that I’ve decided to reserve time off for the Philadelphia International Film Festival. I always take off for the gay film festival in July but usually just stick to weekends and late showing for the April festival. This may be K.’s last festival as a U.S. resident, so a few extra weeks off isn’t a bad thing.

Regulate Investment Banks?

Hell yes!Bladerunner

After four years consulting for a financial services company, I say regulation can’t come fast enough to investment banks, hedge funds, and private equity funds. They weren’t doing anything technically illegal, but they certainly were being too clever, too greedy, and too secretive. Now we’ve got some nose-on-your-face evidence with the mortgage meltdown and collapse of Bear Stearns that they need oversight. I invoke the Blade Runner Test:

Rachael: It seems you feel our work is not a benefit to the public.
Deckard: Replicants are like any other machine: they’re either a benefit or a hazard. If they’re a benefit, it’s not my problem.

The same is true of the byzantine instruments and predatory fee structures running rampant through the alternative investments space. The hazard comes in two forms:

(1) Institutional investors like pension funds are exposing their members to unacceptable risk. These individuals can’t invest directly in things like hedge funds because they aren’t qualified investors, a fancy way of saying “rich enough to lose a million dollars and not feel it”, but now they’re exposed indirectly with their very futures at stake.

(2) The financial system is a house of cards with players so heavily indebted to each other that one falling could topple the whole system. I don’t like what the Fed did, but they were dead-on about preventing a complete seizing-up of the financial industry–a substantial, growing part of our GNP as we forget how to produce real goods, services, and new ideas. The country as a whole would bear the brunt of the suffering–either via bailouts or a 21st century worldwide depression that might make the 20th century one seem mild.

What boggles my mind is how predictable this all was. The reasons why things are falling apart now are the same reasons we regulated banks and securities after the Great Depression. Besides regulating the existing instruments, I hope governments learn that they must regulate all new instruments at some minimal level to make sure Wall Street isn’t being too clever or cavalier. They also need to ratchet up the regulation whenever individuals are unaware they’re being exposed to risk via institutional investors like pension funds.

DMCL: Language-Neutral API

One thing that first impressed me about Documentum was its language-neutral API. You could add the full Documentum API to any programming language by adding a few C functions and the DMCL. Unfortunately EMC no longer sees this as a strength and is trying to replace it with a pure language-specific (Java) solution.

First, thanks to ukdavo for his comments on my post about Aspects in D6 and Ruby on Rails. Both comments added interesting new technology to my list of things to investigate, like Groovy and Grails. Java without the bitters and jitters perhaps? Groovy wins quick points with me by having a python-like interactive mode; scripters and Agile fanatics living in a Java world might want to check it out. He calls on EMC to support using the Documentum APIs from more places and retire DocBasic. I completely agree and hope that EMC will consider returning to one of the basics that made Documentum great for developers.

The Documentum Client Library (DMCL) is the core C/C++ code that unifies a docbase’s underlying components into a single cohesive layer. There are also some proprietary crypto libraries in later versions, something I banged up against when compiling the first Linux version of dmperl at M. It also included a custom version of libC.a on Solaris that made using Sun’s professional C++ compiler difficult: That’s why my first major Documentum project was done in C rather than C++. I never did find out what they hacked in libC.a. Anybody know? Please post a comment.

The DMCL gets distributed as DLLs or shared objects depending on the platform. It’s a huge and complicated hairball of code with more rings than a hundred-year-old Redwood tree, but Documentum came up with an incredibly simple five-function interface for anything wanting to include the libraries. Two of those functions were basically housekeeping: dmAPIInit() and dmAPIDeinit() did things like allocating memory for the sessions, caching, and garbage collection. Even relative newbies to Documentum have seen the three workhorses via DocBasic: dmAPIGet(), dmAPIExec(), and dmAPISet(). That’s it. Five functions gives you access to the entire DMCL.

The workhorse functions take a string argument that’s basically a message to a DMCL session. Here’s where brilliance missed a step by trying to be helpful: Instead of the more proper message format of “<session>,<method>,<arguments>”, Documentum decided on “<method>,<session>,<arguments>”. It seems like such a small thing, but it’s always a a bother choosing between consistency with the API or doing the right thing in the inevitable wrappers people write around them. I’ve written a dozen versions for a half-dozen languages and never completely resolved the argument. At least I got to take J. to task for this “helpful idea” when he was doing the Alfresco dog-and-pony show for M. If I could go back in time, I’d have rewritten those three functions to take separate string arguments for session, method, and arguments. Ah well.

Documentum provides a version of gawk with the DMCL included, and I’ve evangelized dmperl for over ten years now. It was incredibly easy to dm-ify any programming language, especially an open source project. That meant you could choose the right tool for the job. I loved dmperl because most DMCL work is string handling: building method strings and parsing results. Nobody does strings better than perl. I bet some Emacs fanatic even compiled in the DMCL or made a dmLisp. For the record, that counts as unleashing an unspeakable evil on the world.

Next time we’ll take a look at Documentum’s move to a language-specific implementation and how it differs from the original approach.

Getters and Setters

I’m running through Head First Java as a refresher, and they just introduced getters and setters. Oh, how I hate them.

The reason for getters and setters makes perfects sense: Sometimes you need to enforce value constraints, map internal values, log activities, etc. when exposing an object’s state. They can be valuable–even necessary sometimes.

It’s the needless repetition when you don’t need them that irks me. My inner minimalist screams in agony when I need to write a bunch of getters and setters with single-line bodies like instanceVariable = aValue; or return instanceVariable;. Even if the IDE manages some of the work around getters and setters, having valueless cruft cluttering my code drives me crazy: Less is always more when trying to understand or maintain code. I’m just plain happier using the simpler notation of instance.variable; every modern-day compiler or interpreter is smart enough to figure out if I’m getting or setting for itself.

It would make much more sense to declare handlers and associate them with instance variables. If you really don’t care about what comes in or goes out, no problem! If several instance variables need the same constraint checking, write the method once and associate it as many times as you like. What about something like this?

String instanceVariable = "default"
    onSet mySetHandler()
    onGet myGetHandler();

Anybody using languages that handle getters and setters like this? I’d be so envious.