Put the knife down and take a green herb, dude. (c) Ruffin Bailey 2001-2021

I've enjoyed a couple of Elliotte Rusty Harold's books teaching Java that have been published by O'Reilly, and though I'm certainly not an XML fan (exhibit A & exhibit B), thought his online book, Processing XML with Java, would be worth a look. Even if I'm not the biggest fan of XML's due to its overuse (or at least its proponents attempts to have it overused), I do think it's great for the one purpose I've mentioned before (see exhibit A again), namely preparing your app to interface with anonymous applications.

At any rate, much of the first chapter deals with why you'd want to use XML in your Java apps. Here's his goal:

Would you rather write the code to send and receive orders that are formatted as nice, simple linefeed delimited files as shown in Example 1.1 or as complex, marked up XML documents such as Example 1.2? Both documents contain the same information. Most uninitiated developers prefer the first, simpler form. After all each piece of information is presented on a line by itself with no extraneous markup characters getting in the way. It's my goal to convince you that contrary to most developers' first intuition the second form is more robust, more extensible, and much easier to work with.

Well, there's no doubt XML is more robust that "rolling your own text files", though I'd tend to disagree with an arguement that it's more robust and extensible than a good rdbms system -- or even an underpowered one like Access or hsqldb. It's always interesting to read these comparisions that prop up the straw man of a text file and then knock it down with XML when rdbms's run rings around both in these "middle cases" where the users of the data-store aren't anonymous, and chances are they never will be.

And when it comes to small-time apps with little data, I'll stick to my guns and say a home-rolled text file, well wrapped in good object-oriented code, will do you one better than XML every time. Harold admits it himself, I'm afraid, making the case a shut one in my mind with this quote:

One of the original ten goals for XML was that "It shall be easy to write programs which process XML documents." Originally, this was interpreted as meaning that a "Desperate Perl Hacker" could write an XML parser in a weekend. Later it became clear that XML was simply too complex, even in its simplest form, for this goal to be met. However, the understanding of this requirement changed to mean that a typical programmer could use any of a number of free tools and libraries to process XML. Given this interpretation, the goal has most certainly been met. [bold was mine, of course]

I'll spare you the point by point refutation of the first chapter for now, but thought I'd at least blog this much. The advantage of XML is twofold, neither of which wins it for me. One, it's extensible and quite easy to change its design after the fact. This has kept me coming back to XML now and again, hoping it was more elegant than I last remembered (so far, no). Second, XML is human readable and machine readable, which Harold talks about at length. But if it's machine written, its just as likely to be mis-written as the plain text file, and being human readable only matters if it's a mistake that's easily caught/eyeballed and if the data is routinuely spotchecked (which implies a big system, indeed!). Otherwise you've just added a maintenance nightmare waiting to happen with overhead you simply don't need to include inside your application.

That said, I hope to inch my way through the online book. ;^)

I think I finally figured out one of my main aversions to XML parsers in every freakin' Java program out there. To use the software, you used to have another technology you'd have to download and familiarize yourself with before using. To maintain the code, you have to not only figure out how a parser works -- and sometimes make sure you grabbed the right one -- but you also had to learn XML, XSL, XPath, SAXm and all sorts of other technologies in order to read from a stinkin' text file. As I've said before, XML is great only if anonymous developers are going to be interfacing with your product.

The theory here, of course, is awful similar to Joel Spolsky's idea of barriers to entry article. Here's a rather lengthy quote.

Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won't be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles. With 8 or 9 barriers, everybody will have one non-negotiable deal killer.

This calculus [calculus? -R] means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market, because eliminating just one barrier will likely double your sales.

And we quickly see that we have several barriers when using XML. When creating code that depends on XML, first your developers have to understand the alphabet soup of XML. Then they need to understand need to understand parsers (luckily you no longer have to search for one; Sun's already made the decision for you and packs one with recent JVMs. Of course if you're releasing for Mac Classic or Microsoft's JVM, both 1.1.x, you're in trouble).

Even if these issues seem trivial, I'd extend the idea of barriers to entry to say that your code will be twice as difficult and resource intensive to maintain with each barrier you add.

That's why I like using plain text (most Java programmers understand I/O) or an RDBMS (it's relatively easy to learn SQL even if you don't know it already). More importantly, that's why I like abstracting data read/writes into objects that aren't dependent on the underlying tech at all, so that your programmers only have to know one tool -- object oriented programming. Then you can have one feller who knows the appropriate read/write tech -- be it file I/O, SQL/RDBMS admin, or XML -- and Java who maintains that layer. And your app's goals will decide which you use.

This is also, of course, why managers, whether they know it or not, prefer simple, one tech solutions. This is also why managers love Microsoft. You want to make this in php and mySQL on Linux? What if the next open-source weenie knows mySQL and JSP? Or Postgresql and Python? Or Postgresql and Perl? What's the standard open-source solution? (Of course each of those require another tech to talk between the dbms and the web page.) Developers with "pet techs" make maintenance nightmares.

With Microsoft, it's easy. You use ASP, vbscript, ADO, and either MS-SQL Server or Access, depending on size. You install on Win2k. Done. If you want to be "forward thinking", you just onto the blee/lea/ding edge and use ASP.NET, VB.NET or C#, ADO.NET and Windows Server 2k3. There's one set of technologies. There are tons of people that know these technologies. They all know the same set of technologies. Over the long haul, it's cheaper to pay the piper for licensing to buy into the easy to maintain, all-choices-made-for-you environment.

title: Put the knife down and take a green herb, dude.	descrip: One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!! Back-up your data and, when you bike, always wear white. As an Amazon Associate, I earn from qualifying purchases. Affiliate links in green.
x MarkUpDown is the best Markdown editor for professionals on Windows 10. It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support. Features you won't find anywhere else include... MarkUpDown Multiline Table & Bootstrap Grid support. Beautiful Easy Actions that keep the Markdown flowing. HTML paste to paste HTML source into your documents. You've wasted more than $15 of your time looking for a great Markdown editor. Stop looking. MarkUpDown is the app you're looking for. Learn more or head over to the 'Store now!

Saturday, May 31, 2003
Would you rather hire someone who comes with five fish or hire someone that's able to learn how to fish? posted by ruffin at 5/31/2003 02:05:00 PM

Hide apps in the Dock that are hidden on the screen. Also shows how to make every OS X control keyboard transversable, not just lists and textboxes. THANK HEAVENS!!! posted by ruffin at 5/31/2003 12:43:00 PM

Welp, I've finally figured out what kind of programmer I am: a perfectionist. Okay, not technically a perfectionist, but I do prefer for code to anticipate itself becoming perfect rather than to be shooting for anything less. If, at some point along the way to becoming perfect, the code is in a testable, usable state, ship it! But if it's going to take the same or less time -- heck, if you're going to pour anything resembling half the time into a short-term, non-permanent fix -- to solve the issue you're introducing with a shortcut to get back onto the road to perfect, I'd prefer to make that change now. Now I'm not freakish about it. I understand goals change and you have to back up and say, "We were headed towards point A, but now we've decided, for good reasons 1,2,3, to swap our direction to point B." That's fine. But I can't stand huge detours to point C where you still outwardly claim you're headed towards your original goal. And if you swap goals too often, well, I hate that too. ;^) Factoring code might seem "as much art as science", but it's all logic. And, as a coworker once said, "I can hit a moving target, but I can't hit a moving target in the dark." Change goals, but warn me and tell me what's out there so that the code's ready to achieve 'em from day 1. Nothing worse than ripping up work due to poor planning. Which brings me to the second part of being a perfectionist: I don't like shipping crappy, hard to maintain code, even if it does exactly what it's supposed to. Short-term-goaled managers hate me. Long-term-goaled managers love me. Realistically-goaled managers aren't real sure, but at least know where I stand. You must QA your code, and I mean the innards as well as the outards. If you're taking a shortcut when coding, comment why. If it's going to take longer to comment and explain to the next guy than it would take to Do Things Right, well, Do Things Right, dangit! Perhaps that makes me more an idealist than a perfectionist. Anyhow, rant over for today. posted by ruffin at 5/31/2003 12:16:00 PM

Friday, May 30, 2003
Friend subs apparently let you pass around Types in Visual Basic. What a freakin' mess for something that seems pretty straightforward. I've bumped into this before, and suppose I'll probably forget again. At any rate, it's silly to replace logic that falls into a function that should return three or four values with a subroutine that acts on the parameters you send in. So people are writing subs like... Public Sub returnSomeVals(ByRef strRet1 as String, ByRef strRet2 as String, ByRef lRet3 as Long) ... instead of... Public Function returnSomeVals() as twoStringOneLongType Oh well. This usenet post explains in a little more detail. posted by ruffin at 5/30/2003 09:57:00 AM

Finally met someone with an iPod, and they love it. After a few weeks of hearing about it, naturally I want one. Way too expensive a "Walkman" in my mind, but I mentioned that he'd gotten me interested. Guess what the response was? "Great! I'll bring mine in and we can swap tunes!" That's not great. Naturally paid tunes from the Apple Music Store can't be traded (at least not until they're cracked, and I still wouldn't), but in my mind even mp3s aren't things you should go around trading unless they're from Furthurnet or another legal source. Guess I could play Johnny Furthurseed, but I would like to have my copyrighted tunes on the iPod, and if that means people are going to want to swipe 'em, well, that is bad news. I know, I know, it's obvious that's what people would want to do, even if I wouldn't. Just wanted to point out, for people as naive as myself, a real-world example of why record companies aren't as excited as they could be about digital music. posted by ruffin at 5/30/2003 08:45:00 AM

Thursday, May 29, 2003
Ever wondered what ADO connection string you should be using? You could check here, or you could do this: Create a file called "smack.udl". Right click and choose properties. Set up your connection (connection tab). Now right-click and open smack.udl in a unicode-compatible text editor. Voila. Your string exactly like you want for the datasource of your choice. posted by ruffin at 5/29/2003 12:18:00 PM

Lest anyone think I'm talking about them, I'm not specifically. Instead I'd like to introduce the generic topic of "delivery". By this I mean delivery to clients, delivery to coworkers, delivery to management, any delivery of any content, spoken or coded or written. Don't be Zod. Evilness aside, what's the difference between Zod and Superman? (sorry; have forgotten Superman's Krypton-name. Jor-El or something) Delivery. Superman never asks for people to bow before them and -- guess what? -- they want to! Zod makes Clark do it and guess what? That same blind ego that makes Zod scream things like, "Bow before Zod," has already caused Zod to fall into a trap where he's lost his yellow-sun powers or whatever the heck's going on where he gets to fly and use heat vision. It's a cheesy comparison, but an important one. Ego apparent in your delivery makes you Zod. Think Superman isn't egotistical? Au contraire, mon frere! Heck, he reverses time just to bring back his girlfriend, the selfish punk. It's all in the presentation. (Not that I'm some Zodless saint, but at least I have some measure of perception here. ;^D) posted by ruffin at 5/29/2003 09:57:00 AM

Wednesday, May 28, 2003
This is a bad idea. Never prototype. Make. If you prototype too well, you'll be surprised how often the prototype becomes the application. And then the people who have to maintain the codebase will wonder why so many shortcuts were taken. Why? "It's just a prototype." Or at least it was... Just don't do it. If REALbasic fits your needs, great. Plenty of people have built giant businesses on the back of Visual Basic applications -- heck, I'm working at one now. No reason not to use REAL to do the same -- heck, you'll pick up another 3% of the market for free (more like another 96% of the market for $200; if you're using REAL you're likely on a Mac) using RB! But don't pretend you're making a prototype. Build it for real, and keep your "dream goals" in mind for version 2 or 3. They'll change anyhow. posted by ruffin at 5/28/2003 06:49:00 PM

I love 'em obo errors. posted by ruffin at 5/28/2003 02:41:00 PM

Sunday, May 25, 2003
Netbeans and Eclipse. Why are there two? Seems like open sourcing products that do the same thing -- and are even written in the same language -- would tend to promote convergent coding. Could/Would Netbeans and Eclipse merge? If the sets of parents are any indication (no love lost between those two), I suppose not. posted by ruffin at 5/25/2003 02:42:00 PM

Saturday, May 24, 2003
Two quick iTunes thoughts. One, it certianly does make piracy easier. "I just bought a new CD; [I had to burn it for myself, while I'm there] would you like me to burn you a copy?" This isn't the same mindset as, "Want me to burn you a copy of my favorite mix tape?" I can see how that might be a scary proposition for music companies. iTunes becomes not only a but the printing press. Two: If Apple wants iTunes to be as successful as it can be, it needs to open it up similar to a COM-compliant application in the Windows world. Applescript is Apple's answer to vbscript. Either they need to port an Applescript engine to Windows or, much preferable, provide hooks to Java (or at least "ANSI C") in a compatibilty/API layer which makes a crossplatform release quick and easy -- no endian issues, nothing silly making a real port for the interface necessary. At any rate, the hooks need to be the same xplat else iTunes Windows will have more "features" than Mac OS's or, even worse, iTunes won't have been opened at all. posted by ruffin at 5/24/2003 11:51:00 AM

Thursday, May 22, 2003
Talk about impressive. Just threw a lot of Futhurnet tunes into iTunes 4 and what did I wander past? That's right... The Music Store. After a little shopping around, I sure nuff found an album I'd like to get. Took me all of three minutes (Flatt & Scruggs, The Complete Mercury Recordings -- can't wait for the link to say, "People who bought this album also bought... The Sinister Urge by Rob Zombie). I'm about three clicks away from purchasing it thanks to the iTunes/Music Store set-up. But I've already purchased an album this month, and I probably haven't purchased more than an album or two a year the last few years. I'm afraid this easily accessible Music Store could be addictive. Cheaper than the store, and a quick CD-R away from the stereo. I meant to buy Apple stock before the iMac came out and didn't and still regret it. I'm buying Apple stock this time. iTunes for Windows is going to hit big in the long run. posted by ruffin at 5/22/2003 10:00:00 PM

Tuesday, May 20, 2003
After using Outlook 2000 this long, I have to take my "Microsoft client software" blanket off of my "software that's not kludgey" list. This leaves Word and Outlook Express (Mac) as the only two apps I've used that don't feel kludged on some level. I believe my suspicion is quickly becoming at least true throughout my experience, "All software is kludgey. Get over it." posted by ruffin at 5/20/2003 03:05:00 PM

Monday, May 19, 2003
Them thar Access datatypes: BINARY BIT TINYINT MONEY DATETIME(See DOUBLE) UNIQUEIDENTIFIER REAL FLOAT SMALLINT INTEGER DECIMAL TEXT IMAGE CHARACTER (though apparently you're supposed to use CHAR in SQL -RB) Some day I'll commit 'em to memory, but until then, there they are. [Update 7/21] Seems only a few of these "really work". Here's an example SQL statement that I moved from a SQL Server table once it's been Jet-ified. CREATE TABLE StudentInfo ( [StudentInfoId] COUNTER, [lastName] CHAR(50) NULL , [firstName] CHAR(50) NULL , [middleName] CHAR(50) NULL , [preferName] CHAR(50) NULL , [addressIdaddressId] NUMBER null, [hPhone] CHAR(50) NULL , [sex] INTEGER NULL , [dob] date NULL , [pobCity] CHAR(50) NULL , [pobStateId] integer NULL , [religion] CHAR(50) NULL , [parish] CHAR(50) NULL , [fatherAddressIdrelationInfoId] number NULL, [motherAddressIdrelationInfoId] number NULL, [livesWithType] integer NULL , [livesWithOther] CHAR(50) NULL , [bFatherDead] INTEGER NULL , [bMotherDead] INTEGER NULL , [bDivorced] INTEGER NULL , [bFatherCust] INTEGER NULL , [bMotherCust] INTEGER NULL , [bJoinCust] INTEGER NULL , [prevSchool] CHAR(50) NULL , [prevSchoolAddressId] integer NULL , [bRepeatGrade] INTEGER NULL , [txtWhyRepeat] text NULL , [bEval] INTEGER NULL , [txtWhyEvaled] text NULL ); posted by ruffin at 5/19/2003 04:49:00 PM

From: Colin Bell Re: maybe some nice features we can use also in squirrel? 2002-11-28 00:29 Seems everybodys writing an ISQL tool these days... :-( posted by ruffin at 5/19/2003 11:59:00 AM

A little while back I mentioned a hack called QuoteFix that handles plain text quoting in Microsoft's Outlook email client (works fairly well!), and complained that I couldn't believe Microsoft's PD budget couldn't have included this "feature" by default, as so many other mail handlers already handle plain text quoting with line prefixes without any trouble at all. Heck, steal from Mozilla if you have to, Microsoft! Just to rant about another problem I've had with Outlook, if you do quote by prefix, for some reason Outlook says it can't not spellcheck the quoted portion. Now that's just silly. If it's not got "------ Original Message ------" in there somewhere, for some reason Microsoft decided it simply wasn't worth catching. I can't only hope the newest version of Outlook (I'm mandated to use 2k at work) has fixed this crap. In other news, my giant "note to self" which is freakinname is nearly at 6000 hits. Though almost certainly 30% or more of those are my own, many come from people on Google searching for a few topics that this site pretends to cover. Woohoo! And to anybody who actually reads regularly, hope it's better than a strong kick in the face, at least. Also nice to see that Google's gotten the ads for Blogger targetted to the site's content. No HotBabe67 ads here! Just pure rocking geeked-out 0's and 1's-related ads now. It's almost useful. posted by ruffin at 5/19/2003 10:10:00 AM

Saturday, May 17, 2003
http://www.gnu.org/software/classpathx/ nntp Javamail LGPL note to self posted by ruffin at 5/17/2003 03:26:00 PM

Friday, May 16, 2003
Just wanted to say that I've finally, after nearly five years of programming for a living, sold out to versioning control systems for anything more than a quick hack. I've lost enough work from losing or accidently erasing (usually when wiping slick a hard drive) files that it was past time. It's a minor annoyance, but is ultimately much less tedious than copying folders at random intervals and rewriting code. posted by ruffin at 5/16/2003 08:40:00 AM

Thursday, May 15, 2003
Autonumber field using just SQL in Access -- the datatype is COUNTER, as in: `CREATE TABLE contribSumRep ( pkId COUNTER, ... )` Thank heavens again for usenet. posted by ruffin at 5/15/2003 12:45:00 PM

Wednesday, May 14, 2003
Congrats to jEdit for having the most natural key speed-up feature for writing html I think I've ever seen. When you start an end tag, jEdit looks back for the last open tag and closes it. Do you sometimes want to nest tags out of order? TOO BAD!!! The html standard says not to do it, and even though browsers will render it, that's a bad habit. Not to mention it negates jEdit's "smart closing". ;^) Anyway, that's a great feature, and an easy, nearly fool-proof way to subtract keystrokes. posted by ruffin at 5/14/2003 02:04:00 PM

Tuesday, May 13, 2003
Thus spake Zarathustra: Culture, they call it; it distinguisheth them from the goatherds. posted by ruffin at 5/13/2003 05:03:00 PM

Not a bad list of VB resources, even if some are dead links now. posted by ruffin at 5/13/2003 11:06:00 AM

Monday, May 12, 2003
I've enjoyed a couple of Elliotte Rusty Harold's books teaching Java that have been published by O'Reilly, and though I'm certainly not an XML fan (exhibit A & exhibit B), thought his online book, Processing XML with Java, would be worth a look. Even if I'm not the biggest fan of XML's due to its overuse (or at least its proponents attempts to have it overused), I do think it's great for the one purpose I've mentioned before (see exhibit A again), namely preparing your app to interface with anonymous applications. At any rate, much of the first chapter deals with why you'd want to use XML in your Java apps. Here's his goal: Would you rather write the code to send and receive orders that are formatted as nice, simple linefeed delimited files as shown in Example 1.1 or as complex, marked up XML documents such as Example 1.2? Both documents contain the same information. Most uninitiated developers prefer the first, simpler form. After all each piece of information is presented on a line by itself with no extraneous markup characters getting in the way. It's my goal to convince you that contrary to most developers' first intuition the second form is more robust, more extensible, and much easier to work with. Well, there's no doubt XML is more robust that "rolling your own text files", though I'd tend to disagree with an arguement that it's more robust and extensible than a good rdbms system -- or even an underpowered one like Access or hsqldb. It's always interesting to read these comparisions that prop up the straw man of a text file and then knock it down with XML when rdbms's run rings around both in these "middle cases" where the users of the data-store aren't anonymous, and chances are they never will be. And when it comes to small-time apps with little data, I'll stick to my guns and say a home-rolled text file, well wrapped in good object-oriented code, will do you one better than XML every time. Harold admits it himself, I'm afraid, making the case a shut one in my mind with this quote: One of the original ten goals for XML was that "It shall be easy to write programs which process XML documents." Originally, this was interpreted as meaning that a "Desperate Perl Hacker" could write an XML parser in a weekend. Later it became clear that XML was simply too complex, even in its simplest form, for this goal to be met. However, the understanding of this requirement changed to mean that a typical programmer could use any of a number of free tools and libraries to process XML. Given this interpretation, the goal has most certainly been met. [bold was mine, of course] I'll spare you the point by point refutation of the first chapter for now, but thought I'd at least blog this much. The advantage of XML is twofold, neither of which wins it for me. One, it's extensible and quite easy to change its design after the fact. This has kept me coming back to XML now and again, hoping it was more elegant than I last remembered (so far, no). Second, XML is human readable and machine readable, which Harold talks about at length. But if it's machine written, its just as likely to be mis-written as the plain text file, and being human readable only matters if it's a mistake that's easily caught/eyeballed and if the data is routinuely spotchecked (which implies a big system, indeed!). Otherwise you've just added a maintenance nightmare waiting to happen with overhead you simply don't need to include inside your application. That said, I hope to inch my way through the online book. ;^) posted by ruffin at 5/12/2003 09:50:00 PM

I've always hated using folders in Windows. There's no easy way to make a new one. Here are the two choices (discussed in some detail here) in Windows Explorer: Alt-f,n,f Alt-n,cursor right,return. There are also ways to add the function with vbscript, but that's not exactly elegant. Renaming a folder isn't much better. Both of these are easy to do from the keyboard on a Mac, even in OS X. Typically Mac OS's keyboard transversal is horrible compared to Windows, but with folder manipulation and creation, it does right well. posted by ruffin at 5/12/2003 10:00:00 AM

Sunday, May 11, 2003
From the author of jEdit: Subject: Re: [ jEdit-users ] Q: Is there anyone who moved from Emacs to jEdit? Your reasons? A long time ago, I used emacs (among others). I found I could never get emacs configured the way I wanted to; M-x custom is useless, so one usually resorts to copying and pasting Lisp code from other people's .emacs files. Also it bothered me that only a tiny fraction of emacs commands could be accessed from the menu bar. Finally, all the useful features like wheel mouse support, syntax highlighting, saving the buffer list between sessions, etc. are disabled by default. Of course I could spend several years writing an ~/.emacs that would suit me, but why bother? Now that jEdit is mature, I don't have to worry about all this, because I have an editor that (mostly) behaves exactly like I want. Interesting to me on a few counts. First, we've got an obviously fairly good Java programmer (he wrote the vast majority of jEdit, after all) who wants his commands in menus. I like menus as a rule, but to have every VIm -- and presumably emacs (I've only used the former) -- cmd in a menu would be quite a smorgasbord. What this tells me is that the jEdit author prefers having the Windows-way of doing things as a fall-back at the very least, and is not sold-out to the the cmd line/pure keystroke method for his "ultimate editor". To me, that's strange. Let's pretend for the moment that he doesn't use the mouse to get to the menus for daily operation (alt-f-s usually saves most anywhere, for example)... Just the fact that the menus need every command, as I've hinted above, suggests a limited number of functions. I think VIm gets to the point that even its comprehensive manual is, at times, useless b/c of it's bulk, but I'm sure the VIm cmds I use 90% of the time are different from the next user, which are then in turn different from the next guy. Unless we've got smart-menus that learn what to display at certain times, you've got a mess of menu items. It also speaks towards why people write open-source software, which I was wondering about a while back. Seems this fellow just wanted a text editor done the way he thought best for his own personal preferences, and that he's, while doing so, matched his prefs with a number of others. That's what I've done with my trialware app. I subscribe to a ton of email digests, and got tired of wasting three minutes a day wading through all the lists to find the posts I wanted to read. Poof. "The Digest Handler" is written. (Released? No. But written, sure. ;^D I use it almost daily.) The hope is that there are other similar people out there with the same need. I do wonder why jEdit is open-source, however. What's the advantage over trialware smack? Is it b/c it's easier to find web hosting with unlimited downloads on Sourceforge (that alone has tempted me to open-source The Digest Handler)? B/c there are no expectations of support? B/c the author never expected jEdit'd bring in much money even if he did release it (though Ultra-Edit seems to suggest otherwise, at least with text editors)? I'm not sure, and might actually bug the author some day. posted by ruffin at 5/11/2003 11:26:00 AM

Saturday, May 10, 2003
`on open dropped_files tell application "Finder" repeat with a_file in dropped_files set file type of a_file to "TEXT" set creator type of a_file to "CWIE" end repeat end tell display dialog "Done" end open` posted by ruffin at 5/10/2003 08:07:00 PM

Friday, May 09, 2003
Finally used Microsoft's JVM to run an app (a trivial Swing frame) yesterday. That's right, here it is 2003 and I'm finally getting around to using 1998 tech. The upshot is that it worked well and seemed to work (in the five minutes I used it) fairly quickly. Getting a Swing app to work with it was really as simple as `jview /cp .;swingall.jar trivialFrame`. I've seen tons of Java programmers on usenet and mailing lists talk about how they just need Java 1.4, but for the majority of most non-graphic apps you probably don't. Are there places where it's inconvienent to port your code from 1.4 to 1.1.4? Sure. Constructors change, convienence methods have been added, etc. Hashtables and Vectors need to be used in place of lists, etc. But these are generally easy things to change, and even easier to code right the first time if you're designing code to be easily ported from 1.1.4-1.4.1. The upshot is that you can easily deploy a Java app, at least for another few months, on most any Windows box -- and with an extremely small download for your end user, if that's important. The VM's there already, Jack. And if you compartmentalize your app's logic well enough, you can easily provide 1.1.4 level functions to everyone in a tiny download that'll run on 99.44% of the PCs out there, Mac or Windows. And once you're there, that app can help handle their transition to 1.4.1 and the rest of your app's fancy functionality. The MS JVM is a great foot in the door. Java programmers need to learn to use it. Smoke break's over. posted by ruffin at 5/09/2003 08:47:00 AM

Thursday, May 08, 2003
I think I finally figured out one of my main aversions to XML parsers in every freakin' Java program out there. To use the software, you used to have another technology you'd have to download and familiarize yourself with before using. To maintain the code, you have to not only figure out how a parser works -- and sometimes make sure you grabbed the right one -- but you also had to learn XML, XSL, XPath, SAXm and all sorts of other technologies in order to read from a stinkin' text file. As I've said before, XML is great only if anonymous developers are going to be interfacing with your product. The theory here, of course, is awful similar to Joel Spolsky's idea of barriers to entry article. Here's a rather lengthy quote. Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won't be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles. With 8 or 9 barriers, everybody will have one non-negotiable deal killer. This calculus [calculus? -R] means that eliminating barriers to switching is the most important thing you have to do if you want to take over an existing market, because eliminating just one barrier will likely double your sales. And we quickly see that we have several barriers when using XML. When creating code that depends on XML, first your developers have to understand the alphabet soup of XML. Then they need to understand need to understand parsers (luckily you no longer have to search for one; Sun's already made the decision for you and packs one with recent JVMs. Of course if you're releasing for Mac Classic or Microsoft's JVM, both 1.1.x, you're in trouble). Even if these issues seem trivial, I'd extend the idea of barriers to entry to say that your code will be twice as difficult and resource intensive to maintain with each barrier you add. That's why I like using plain text (most Java programmers understand I/O) or an RDBMS (it's relatively easy to learn SQL even if you don't know it already). More importantly, that's why I like abstracting data read/writes into objects that aren't dependent on the underlying tech at all, so that your programmers only have to know one tool -- object oriented programming. Then you can have one feller who knows the appropriate read/write tech -- be it file I/O, SQL/RDBMS admin, or XML -- and Java who maintains that layer. And your app's goals will decide which you use. This is also, of course, why managers, whether they know it or not, prefer simple, one tech solutions. This is also why managers love Microsoft. You want to make this in php and mySQL on Linux? What if the next open-source weenie knows mySQL and JSP? Or Postgresql and Python? Or Postgresql and Perl? What's the standard open-source solution? (Of course each of those require another tech to talk between the dbms and the web page.) Developers with "pet techs" make maintenance nightmares. With Microsoft, it's easy. You use ASP, vbscript, ADO, and either MS-SQL Server or Access, depending on size. You install on Win2k. Done. If you want to be "forward thinking", you just onto the blee/lea/ding edge and use ASP.NET, VB.NET or C#, ADO.NET and Windows Server 2k3. There's one set of technologies. There are tons of people that know these technologies. They all know the same set of technologies. Over the long haul, it's cheaper to pay the piper for licensing to buy into the easy to maintain, all-choices-made-for-you environment. posted by ruffin at 5/08/2003 09:14:00 AM

Any organization that gives an award to FileMaker Pro for "best numeric/database software" needs to have its collective head examined. posted by ruffin at 5/08/2003 07:29:00 AM

Tuesday, May 06, 2003
`9:45PM up 25 days, 9:33, 5 users, load averages: 2.69, 2.05, 1.58` That's from a Mac, and from an iBook to boot. It's a shame I have to shut it down to take in to work tomorrow (guess I don't have to, but easier that way). At any rate, 25 days of uptime -- with daily use -- on a Mac definitely owes a thanks to OS X. posted by ruffin at 5/06/2003 09:49:00 PM

Got an IBM Thinkpad? Understand the humor of not having a Windows key on the keyboard but less amused by the loss of the Window's key functionality? "So was I. But then I found this!" Thank heavens. Worth it for Windows-E alone, but -M, -F, and -R make it a must-install for me. (Though I've already been kidded about my Windows-key addiction at work by people that think ctrl-esc is as worthwhile.) posted by ruffin at 5/06/2003 05:11:00 PM

Something I wish I'd known much earlier -- in VB 6, if you hit "Shift-F2" you'll go to the definition of the variable or method where your cursor is located, no matter where it's defined. Fraid of getting lost? Ctrl-shift-F2 takes you back where you were before. posted by ruffin at 5/06/2003 01:18:00 PM

Monday, May 05, 2003
from here: The down side of Hacker productivity is generally agreed to be in maintainability, documentation, and completion. Very talented hackers may become bored with a project once they have figured out all of the hard parts, and be unwilling to finish off the details. What? No, never! ;^) I tend to comment a bit more than the next guy, so I'm guessing that also brings my hacker quotient down a bit. posted by ruffin at 5/05/2003 05:55:00 PM

Friday, May 02, 2003
Here's a bit of from Apple's job listing for a Windows iTunes programmer: B.S. or better in Electrical Engineering or Computer Science. Required skills include C, C++, UI, MFC, Win32, COM, DirectX, Installshield and application engineering. Exposure to networking and device drivers a plus. Either they only need someone to write low-level drivers or they've really missed the boat! There are two/three better technologies for bringing Apple's music store to Windows machines, and only one reason to use C or C++. If they want to do Sun a favor, Apple should take a cue from their own OS's integrated Java support and create the web services for iTunes (and the app itself) in Java. For music playback, it's still pretty easy to work with Quicktime for Java. The popularity of iTunes is going to be a great way to piggyback both technologies onto Windows machines. Even if you shy away from Java for some reason, then .NET is a great way to get the client-side of the web app going. The only reason I can see using C or C++ is ensuring that you can write to CDs. Even there you're proably better off partnering with someone who can make you a good COM-compliant CD burning object. Apple should be thinking of delivering two iTunes. One needs to get out quickly. Heck, even Visual Basic 6 would be a good way of putting a GUI over a few well-created foundational techs. The second will be Windows iTunes done right. This will take quite a bit longer, but will be a great inroad for Apple on Windows like Office is for Microsoft on Mac OS. I hope Apple doesn't sqaunder this great chance to get some crossplatform foundational techs installed on a good percentage of Windows machines. I wonder if it'll even be given out free... Then you could see apps that depend on QT and/or Java saying, "Prerequisite: iTunes". posted by ruffin at 5/02/2003 05:29:00 PM

Why Microsoft couldn't handle adding this to Outlook, I'll never know. Some schmoe in a few months of spare time adds a feature every plain text mail handler has short of the multi-million dollar in R&D client (guessing, of course, on that amount), Outlook. posted by ruffin at 5/02/2003 09:30:00 AM

Thursday, May 01, 2003
It's interesting to think that, with Apple's new music service and others, that PC consumers will regularly print their pop music at home before their pop fiction. The death of paper was grossly exaggerated. posted by ruffin at 5/01/2003 11:54:00 AM

<< Older \| Newer >>