Older blog entries for garym (starting at number 76)

black arts of estimation

I hate estimating projects. Face it, unless you've done the same job a statistically significant number of times before, there isn't an estimate on the planet worth the bits in it.

They tell me there are two basic philosophies of estimation. There is the American way of over-estimating and then joyously coming in under budget. And then there's the way I'm told is currently in vogue among the off-shores where the initial estimate is absurdly low, and creeps up and up and up and up as the client is drawn more and more into their commitment to the investment.

I prefer the former :) The rule I like to use is almost universally both right on the mark and initially completely, categorically and flatly rejected, the Fahrenheit-to-Celsius rule:

Take my best estimate (say $24k, double it and add 10% ($52.8k) and take away 32 comparable-sized units, usually of the next lower order of magnitude ($52.8k - 3.2k = $49.6k).

That said, I wouldn't want to ask for $50k up front; I'd instead prefer maybe 20% up front to get us rolling, prime the dev environment and then involve them in all facets of the progress as soon as we have even a few pages to show, and keep the discussions in the open, making sure everyone knows where we are at all times so we can manage the burn rate to hopefully get to the destination state way under that price.

It's like the game we used to play with art installation funding with the Canada Council: They offered some cash sum for some certain kind of event, we'd target that sum in our proposal, then pay our musicians, technicians, suppliers and artists out of that account, and everything left over by the end was a bonus (usually paid for opening night pizza).

But, really, realistically -- asking us for our estimate is all backwards. A client should be preparing to wager some fraction of their ROI, some sum that says unspoken, "If it's headed higher than this, we need to bail." Their return on this wager/investment is the only true bottom line -- if the return is $1M/year, then it's worth half that to build a truly stunningly brilliant design; if the return is only $10k/year, then it makes more sense to cobble it on the dirt-cheap from spare parts and student volunteers.

'Course, you can I both know that no one wants to face this reality, and without that basic bit of realism, we're all still stuck with that old smoke and mirrors cat-and-mouse game of "how much does it cost?" vs "how much are you willing to pay?" :)

XRML - Extensible Rule Markup Language

Graeme Burnette tips us to a new technology for building rule-based information systems: Extensible Rule Markup Language (XRML) can support the automatic processing of implicit rules embedded in the hypertexts and help human browse them for their comprehension ... XRML aims to convert itself to XML for browsing, and assist the generation and maintenance of consistent explicit rule structure.

This is the initial run proof of concept from "Extensible Rule Markup Language - Toward the Intelligent Web Platform" by Jae Kyu Lee and Mye M. Sohn, to be published in the Communications of the ACM.

18 Jul 2003 (updated 26 Jul 2003 at 04:04 UTC) »

decisions, decisions

A completely hypothetical IT jobhunters' quiz, an IT Friday Five you might call Prisoner's Dilemma: a list of options, and, like, one day to select...

  • One offers 12% voting shares in a company and no pay. The 51% owner isn't a big compromiser and promises the moon for a song to Big Name prospects (who traditionally will try hard to leverage fame for price) rather than sell proven product to regular joes. He wants someone to architect 'next generation' services on a promise of 'dividends' while the coder who builds it (boss's buddy) gets a cash reimbursement from the corporate sales.

  • One offers 80% market rate and the promise of "equity" on a noble idea on questionable foundations. The technology plan uses a hastily re-invented P2P by anonymous programmers -- the design shows hard evidence of already making the same naiive mistakes Onion Networks had made nearly 3 years ago, mistakes which caused Justin to greatly modify his fundamental approach -- and they are running an expensive and unstable proprietary platform (with no in-house expertise) with non-MVC webtools. The business plan bravely and nobly sells advertising on independent obscure artist content.

  • Plan three offers 80% market rate, no shares, no equity, not even rights to intellectual property, with a requirement to "provide advice, specs, design <u>and</u> implementation" on a massive distributed information server. Although the marketplace has numerous high-profile and very robust, proven and mature productized alternatives, this must be a competitive clean-room re-implementation, done by one person inside of 300 hours. Your predecessor skipped, or fled, leaving no shred of docs behind, and what docs do exist for requirements are scant and ambiguous.

  • Four has the best of intentions, a long time trusty friend with inexhaustable good-will and great humanitarian ideas. What little cash is personal savings, but he's ready and willing share and share alike and sing your praises everywhere. He just needs some dedicated assistance to get this baby off the ground. The recompense is the promise of a fair percent of whatever the two of you can get.

  • A subsidiary of a massive manufacturer will pay fair market rates sub-contracting on a very large B2B catalog server. No equity, no intellectual property, straight-up work-for-hire on an implementation in open source for the price you ask, paid on time, no cheques bounce, and prospects for future contracts.

The people and situations described in the above scenarios are fictional. Any similarity to persons living or dead is completely co-incidental.

Ok, kids, it's 11th-hour time ...

Which do you choose?

Turns out, fate chose.

Steve Mallet reports on how Ruby stole the show at OSCON

Matz, the founder and developer of Ruby, had said in his session that a good name for a project will take care of 80% of your design work for that project. Afterward we mused that a good leader will take care of building a community around a project and that it was equally if not more important than the project itself. Those in the session felt that Ruby had these thing going for it. Aside from being based on what I see as the best aspects of perl and python, and it being a great thing, we see that while Ruby has a great start, it has a great future.

Get no quarrel from me there ... but before I truly switch over, Ruby has to sort out the package management and from there build itself a real competitor to CPAN -- they do that, and man, I'll flee from the camels!

For a company so vehemently outspoken against the anti-democratic scourge and pestilence of Linux, there sure is a heavy concentration of busy penguins down at the Microsoft London Internet Data Center ...

First light

Ok, turns out the magic trick to getting the Lucent FW323 Firewire card to work is to load the raw1394 modules before the ohci1394; then all of a sudden the gscanbus goes nuts dumping data and dvgrab gleefully grabs frames.

Now I have a different problem: Is there no software that will read the output from dvgrab? the README says how to capture a movie file, but then says "go get windows media player"???? Ok, I expect there is a deep reason for that, but since that's not an option around here, it's back to google to see what my alternatives might be.

Light my firewire

Been putting it off for far too long, today was the day to bring the machine down, take out the modem obsolesced by the wireless highspeed, and install the ilink/firewire card. This is the story of that adventure:

First off, plug in the card, restart the machine, no smoke. Good sign, so I plug in the camera, a Sony Digital8 700x SteadyShot. Ok, on the Mandrake menu is bcast2000, so for fun, I hit it, and for the record, nothing happens. Two instances of bcast2000 in the process table, but nothing opens. So I kill it. Plan B: Google the blighter.

Google on "linux digital video" sends me to Kino. Kino wants libdv and apparently didn't like Mandrake's libdv2, so I download and install libdv from the sf site, but Kino's config still won't accept the libdv/dv.h that is clearly there in /usr/include. There's another ominous google hit, a mailing list post of someone who had gone this way before, but ran into dead silence when they asked if there were any drivers for Sony handicams ... and sure enough, following his process, a modprobe of the ohci1394 shows

/etc/hotplug/ieee1394.agent: ... no drivers for IEEE1394 product 0x080046/0x00a02d/0x010001

Y'know that sinking feeling you get when you've spent a lot of money on a "standards based" device and then discover you're locked out of it because you won't play the Redmond game? That's the feeling. I wrote to the author, since his post was 6 months ago, and trod on ...

kino's sister prog, dvgrab, wants raw1394 installed, and on this one, for the first time, there's a urpmi match: libraw1394_5-0.9.0-1mdk.i586 -- I install it with the devel RPM as well; config now wants libquicktime (not found in urpmi) and once again, it doesn't find the /usr/include/libdv/dv.h include file (locate finds it no problem), but dvgrab doesn't bomb on that, it just says the AVI's would be better if it had it. Right now, I'd be happy with a first light so I trod on and hit make.

Make exits ... with a huge string of syntax errors in /usr/include/libdv/*.h -- syntax errors, guint32 used as a type but not defined ... ok, let's shelve that for a moment. I see there's an option to use libavc1934 instead, and it builds and installs without incident, so ...

I install that, kino still fails because of dv.h, so I reinstall that from the sf sources and now dvgrab installs. Cool. Give it a shot ...

raw1394 - couldn't get handle: No such file or directory
This error usually means that the ieee1394 driver is not loaded or that /dev/raw1394 does not exist.

Well, the driver is loaded, but yes, the /dev doesn't. I have video1394, but not the raw, so mknod /dev/raw1394 c 171 0, and it does exist, but dvgrab gives the same error.

I can see this is going to be a long night.

Had a call today from our ISP, in a bit of a panic, seems some script kiddies were causing his website some woes and he wondered if I might be able to spare some time to help out. Now, knowing his machines are Windows 2k of which all I know is that I don't want to know, but I offered to do a security audit.

Simple enough, I fired up Nessus and even produced the fine LaTeX-typeset report into a slick PDF that itemized a long list of naivities, even found a few ports with logins that began "W3lc0m3 t0 th15 D15tr0" (which I highly doubt is the work of those fine folks up in Redmond) and shipped it off with an invoice to follow, but y'know, it's so easy, and I realize this report could save his business thousands of dollars by the time he's followed each individual crack-fix tidbit Nessus appends, but still, it's like taking candy from a baby.

Why is it people don't do these things themselves? Wouldn't you think that part of buying the equipment for an ISP-class set of servers would prompt the vendor to throw in a CD of security tools? Well, yeah, it is Microsoft and where ever it was vended is probably a similar take the money and run, but still, really, why?

Stuff like this is all over the place, it's no wonder we're all prey to spammers and crackers. Our little town is under the kind auspices of at least half a dozen ISPs and I'll bet I could run a report on each one of them and find at least as many backdoors, unpatched holes and the like, and it's really damn hard to sit here and restrain myself from just unleashing a test on them and sending them the report as a "gesture of goodwill" ... 'ceptin' I'm sure I'd probably hear from their legal dept more than their tech support.

3 Jun 2003 (updated 3 Jun 2003 at 21:18 UTC) »
Oh, this is Nice ...

Seriously. I've been searching all my computing life for a decent programming language, and I've been through a lot of them in my travels up since WATFOR and PL/C. Many come close, and those close-fits today form the core of my toolbox; there's been a lot of very nearly almost close-fits and some of them painfully not quite there -- in that latter list I include Ruby -- but because of my annoyingly unavoidable real-world constraints, my toolbox really consists of, in order of decending frequency and increasing power, bash-shell scripts, PHP, Perl, Java and C

Now before the language bigots jump up all indignant like, hear me out. This is, in decreasing order of importantce, what I cannot do without and what disqualifies even wonderful and enlightened programming idioms like Ruby, Haskel and Prolog:

  • free-software 3rd party components -- because I'm just one guy out in the woods and I can't afford to re-invent every low-level protocol or general purpose widget. As much as I would love to author every line of code (just like the good old days of the Z80!) it's just not viable in my market. I have to be re-using components shared by other developers, as much as feasibly possible.

  • Easy, easy package management. Again, I just don't have time to fiddle with manually picking up and tucking into right spots all the little components and dependencies most non-trivial code requires. This drives me bonkers in the Xerces-based XML jar files of Java where the least little version conflict throws the whole thing into a tumble, and CPAN, well CPAN is the single most influential factor in my staying with Perl, the language I love to hate. If Ruby had CPAN, and if Ruby's CPAN had even half the breadth of the Perl archive, I'd be there. As it is, count me with the camel.

  • OOD. Real OOD, not the kinda-sorta joke of OOP in PHP4 or the goddamn the torpedoes let it rip OOPishness of C++ (which has almost zip CPANerisms) but the reasonable sort of mental-scaffolding OOP. And not canned-mediocrity of VBasic either, it has to be seasoned and practical and, well, yes, I'm not the accountant mindset type so it has to have that Eiffel/Pascal notion of "the programmer is not always right" checksumming that saves me from myself. I want to program concepts, not chipsets.

Anyway, back to the point, what should happen today, which is an otherwise yet-another-dismal-no-prospects day of sifting sand in the exhausted stream of the down-the-tubes IT market, and what pops up in the radar but something called Nice. I haven't been there yet, but right off the bat, I can see evidence of those immortal words of Bucky Fuller ...

"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete."

The Nice programming sytem, whether it is or not, claims to be a step in this direction, not trying to usurp my toolbox, just extending it, building on what I have (at least in the Java department) but doing so in a direction that's, well, very probably better ...

Nice is a new object-oriented programming language based on Java. It incorporates features from functional programming, and puts into practice state-of-the-art results from academic research. Among the advanced features: parametric types, anonymous functions, multi-methods, tuples, optional parameters to methods, design by contract, detection of many errors during compilation (in particular, concerning casts and null references). This results in more expressivity, modularity, and type safety.

Nice plays nice with java libraries, so it fits my first two criteria at least as well as Java does (which still ain't no CPAN, but it's no proprietarily padlocked C++ either) while simultaneously extending Java into the directions it should have gone way back what, 5 years ago?

Anyway, I haven't tried it yet, and I'm not sure where I might use it, but if it plays nice with the JVM that's at least an opportunity to test it out, and if it perchance also plays nice with gjc then it may actually win another convert here in Sauble Beach.

And maybe it's a idea worth stealing for Ruby too -- I wonder ... what's the chances of a Ruby-wrapper that would transparently adapt anything you could get in CPAN?

This is funny, just came in over the mail reader:

From: <news@ineedhits.com>
Subject: Yahoo! Has Acquired Inktomi

   Hi Gary Lawrence Murphy, As an ineedhits.com member we strive
   to keep you up to date with the latest Search Engine news, and
   Industry developments. Below is some recent and very exciting
   news about Yahoo! and Inktomi.

 ======================== LATEST NEWS IN THE PRESS ========================

  Yahoo! Has Acquired Inktomi --------------------------
  On the 19th March YAHOO!Inc. announced completion of its
  acquisition for Inktomi. Inktomi is now a Wholly-Owned
March 19th!!!! Oh, yeah, that's latest news alright! I probably heard about this deal within the hour over either Google news or Feedster, and the old "Wait until we're ready to print" ... well, I guess mailing lists just don't cut it anymore.

67 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!