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

Confessions of a true Mac addict

Welp, Apple's done it again. I'm not sure how, but they've got me wanting to get another one of their computers. In spite of the fact that I'm now 4 of 6 in the Macs enjoyed to Macs purchased ratio, and in spite of the fact that I could get a racin' AMD system for about $400, I think I'm nearly ready to plunk down a few grand for a new PowerMac.

And I don't think times could be any less assuring in the Mac world. Take their new Gigahertz Powerbook. A cool system, certainly, with a slot-loading DVD burner in a laptop. Slick looking, for sure. But then so is a Fiero with a fake Lamborghini body. What impresses me even less than the concentration on slick looks is the slick advertising Apple's pulling recently.

Here are two examples of Apple's less than straightforward adverts:
And it all adds up to wicked-fast performance. In the PC world, you’d be lucky to get this kind of performance in a desktop system. That’s because speed expressed as megahertz alone can be misleading — it’s not an accurate yardstick of overall system performance. Fact is, the PowerBook G4 powers past Pentium 4-based notebooks by up to 44 percent in Adobe Photoshop testing.

Well of course there's a catch to that statement. Here's the footnote:
Test performed on 1GHz system with Adobe Photoshop 7 (November 2002).

So let's translate this one back into English.
"The 1GHz, top of the line, $2800 PowerBook G4 can outperform a 1 GHz Pentium 4 notebook in one application of our choosing, and even then only in certain benchmarks. Nor are we going to tell you if the P4 notebook was plugged in -- it might have been using its 'power-save' mode." That's not so good after all, is it?

Add to that that, just for reference, you can't even find a 1 GHz P4 notebook over at Dell right now (about $1000 for a 1.9 GHz P4 Mobile, fwiw) and we see that Apple's statement, which makes the new G4 Powerbook sound awful fast, really is less than straightforward. Heck, it's downright misleading. There's something "wicked" going on here, and it ain't how fast the G4 is running. The DVD drive does look cool, though.

Move on to the PowerMac. This "benchmark" image is probably my all-time favorite. What does it tell us? The new dual 1.25 GHz G4 PowerMac has 18.3 gigaflops of power versus the old PowerMac's 3.7. Wow! Now that is POWER TO BURN, ain't it?

Closer inspection shows that the old PowerMac was a 500 MHz G4 (why not use an old 604e PowerMac while you're at it?). So we have two 1.25 GHz processors, which means 2.5 GHz "total", which is "equal" to five 500 MHz processors, right? Hrm, 3.7 times 5 is equal to 18.5, which is nearly 18.3. So if we were able to harness every single bit of theorhetical power from the old PowerMac and every single bit of power on the new one, the new one would be five times as fast. Wow! An amazing (or is that wicked?) benchmark!!!

Not only is this math (I'm sorry, I mean "measure of 'peak performance'") no more than a simple truism, it's not even a real world measurement. Many applications don't take advantage of the second processor, meaning that you've lost half of your "peak performance" right there. Even apps that do don't magically become twice as fast as they would be with just one processor. I'm going to wimp out of digging up benchmarks again, but here's one example that I posted to the mac advocacy group. As I start to figure out in the post, even Apple's own iApps don't do as well with multiple processors as you'd like.

So why do I want a PowerMac? A few reasons, I suppose. I've always enjoyed Macs and the "small pond" Mac community. It's easy to get your hands around what's going on, I think. I've also enjoyed the move to OS X, but my 500 MHz G3, 8 meg video chip iBook just can't keep up as well as I'd like. I'm so close to having a great OS; it just needs to run more quickly, just like I hear it does (with Quartz Extreme) on the new PowerMacs. And, admittedly, I enjoy not using Windows, and the Mac is a much nicer alternative than the less user-oriented Linux. There's a reason Linux geeks buy iBooks and Powerbooks now that OS X is out. OS X is the best of both [alternative] worlds.

Performance aside, the iApps are also quite nice. Ultimately, they are what are bringing me to desire yet another impractical Macintosh PC. iTunes is great. I haven't found a good replacement for all iTunes does for Windows yet. Winamp, nice, but buggy in my system when I try to rip tunes after installing the plugin. Quintessential mp3 Player (or whatever) is great, but won't play Shorten format. Neither's interface comes close to being as easy to use as iTunes.

Same with iMovie. I've got a DV camera, and making Quicktime movies to share really is a snap. iMovie is easy to use and I can edit together pretty good amatuer home video in a hour or so, even on the iBook. I've also got a digital still camera, and iPhoto, though horribly wasteful with hard drive space (it copies your originals in a new location, and the copies, even in the same image format, are often larger than what you started with!), is very well done. Planning to try out the linen covered picture-books you can order from iPhoto this month as well. If iDVD is half as good as these, and I'm banking it is, DVD authoring is right around the corner for me with the shortest learning curve you could imagine. The Macintosh as a "solution provider", rather than a "Swiss-army knife" Windows or Linux PC, is a package that's hard to beat. The solutions provided are right up my alley as well.

But knowing Apple, the yet-to-be-released iDVD 4 will require a new G5 processor. And though iDVD 2 will be awfully k3w1, somehow they'll have me wanting to take that last little "inch" to a new computer the same way the iBook has me seeing the proverbial OS X promised land without quite taking me there. And the addiction will continue for years to come as I continue to, against my best judgement, line the coffers of Cupertino. Sheesh.

"Java shareware". Ever seen any? Probably not, and I know why. Unfortunately I even "have known why" and went ahead and wrote my latest app in Java anyhow. The problem is that a Java application is interpreted by a virtual machine. The code is never "really" or "fully" compiled. Rather, it's compiled into the bytecodes used in the Java virtual machine and the VM finishes the job moving it to pure machine langauge. This has the added problem that Java is relatively easy to decompile, as it's not in true native machine langauge. The bytecodes closely resemble the original Java code so that they're easy to move from one platform to the next.

In fact, it's so easy to decompile that it's only one step away from being an interpreted langauge, like the original BASIC. Remember playing some old Commodore 64 games and hitting "break"? Bam, you were right into the code. You could LIST the contents and even change lines to change what happened in the game. Because the BASIC app was never compiled at all, the creators' had to ship the code as the application. Ultimately, as I'll continue to explain, Java applications are quite nearly in the same boat.

Here's a partial example taken from Furthurnet, which is open source so they shouldn't mind us taking a peek. Remember, this is from the "binary", not from the actual [open] source.

public void hyperlinkUpdate(HyperlinkEvent hyperlinkevent) { if(hyperlinkevent.getEventType() == javax.swing.event.nt.EventType.ACTIVATED) { String s = hyperlinkevent.getURL().toString(); String s1 = "http://furthurnet.com/pcplink.html?"; if(s.startsWith(s1)) { s = s.substring(s1.length()); String s2 = URLDecoder.decode(s.substring(0, s.indexOf("&"))); String s3 = URLDecoder.decode(s.substring(s.indexOf("&") + 1)); try { QueryPanel.download(new QueryResultItem((XmlObject)XmlParser.parse(s3).elementAt(0), s2), null); } catch(Exception exception) { } return; } JEditorPane jeditorpane = (JEditorPane)hyperlinkevent.getSource(); ...

Not too bad, eh? Doesn't do a great job of commenting, of course, [because it can't, naturally,] but all in all pretty good source. We'll ignore Furthurnet's horrible exception catching code for the time being.

You can use bytecode obfuscators like Retroguard to make things a little more difficult. Then the names of events and some variables become a little more generic and difficult to read and the like. There are more things like the Strings named s, s1, and s2 above. But the source is still all there. If someone wants to crack your app, they've essentially got the code to work with, which is a dream spot for crackers.

Even when you use something as "trite" as Visual Basic, which I enjoy using, you're going to have a truly compiled application. People can wade into the machine langauge if they know assembler, but this is a much better way of hiding the way you process, say, license keys, which is pretty important to keep private. The level of effort is just too high for your typical dimestore hacker when something is compiled to native bytes.

Of course Java is shooting for crossplatform applicability, and that strikes native bytes almost completely out of the equation. Java programmers' reply to the "open source, like it or not" quandry seems to be, "Anything, even something protected by hardware, is hackable." Well, sure, but it's all about time. As a software vendor, I want to make it difficult enough to deter most dimestore hackers and make it take someone who's really got it in for me long enough to hack the app and distribute it to the pirates that would use it that I can get another version out in the meanwhile.

This is also, I believe, why Java and open source go together so well. The source is already there. It's no wonder most of the Java apps I use daily (Furthurnet and Netbeans for the most part, but there are some other small ones I grab once in a blue moon) are open source. And it's no wonder I've never used, that I recall, a commercial Java app. The only apps that can make it are the extremely expensive ones, like enterprise-level IDEs and server code, where the stakes are high enough and the customers are select enough that nobody's going to fudge.

Is it okay by me that people hack apps? Absolutely not. Is it stupid for me to assume they won't? Absolutely so. To think any other way would be to lose money. And the prospect of accidently creating a successful application has already got me thinking about porting the code to C# for a Windows version -- though I suppose .NET might behave like a VM as well. I wonder how easily it can be decompiled!

Quick update: Yep. It can. Thought so. Wonder what this means for .NET shareware writers and other small software companies. Definitely a vote for web services, like it or not, where you can hide the code on your server. The web services is, unfortunately, what I keep coming back to thinking is the best model for creating applications that can't be cracked [quite so very easily].

More about decompiling .NET here and here.

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, November 23, 2002
Talk about a standard that isn't one. I've always hated seeing, "Please send us your resume in Word format," as if that were a nice, crossplatform, open standard. Luckily most places also accept plain text resumes, but you miss out on formatting and you, via your resume, look bad, relatively speaking. To combat this, I usually hack up my resume in MS Word, then save in Rich Text Format. In theory this is a great compromise. My resume or other document looks just like I wanted when opened in Word, which is what they were going to use to open my document anyhow, and I can rest better knowing that pretty much anyone out there, with Word or not, could open up my doc in a non-Microsoft editor if they needed to. In reality, however, things aren't so rosy. I was busy copying over about 20 gigs of Furthur tunes to my new hard drive yesterday, and my processor was apparently floored by the maneouver. Out comes the iBook for some resume hacking. Long story short, an .rtf file looks quite a bit differently when swapped between Word, AppleWorks, TextEdit, and AbiWord. I already knew that -- I'd always ignored it [naively thinking that I could assume, aka] knowing the end user was going to use Word -- but this time I took it as a challenge to make a truly reader independent rtf resume. I couldn't do it. Sometimes underlines would come out, sometimes they wouldn't, depending on what editor had done the latest save. Sometimes margins would work like I liked, sometimes they wouldn't, again, depending on the editor that was doing the saving and which was doing the viewing. I would hack and slash in each editor, one at a time, hoping this* one would produce the simplest, and most portable, document ,and each time I'd eventually find the editor's archnemesis which would, on one occasion, even duplicate a line of text randomly in a way that no other editor did! I even started from plain text in two editors, and still couldn't get a doc that would appear reasonably the same in all four editors. And mind you, I wasn't putting in colors or fancy margins or the like. I was simply underlining, making some text appear in italics, and occasionally using all-caps (The caps did work well cross-editor, thankfully). What's the answer? Oh, that's easy. People need to start saying html resumes are okay. When a job is web-related, it's hard to believe that's not the case already. If you've ever seen all the extra code Word slaps into a doc spit out as html, you know you've got several kilobytes to work your own magic before you're gotten it as bloated as what Bill's folk do. Html with nice, gracefully degrading CSS and Javasciprt -- now that'd be a resume. But the last thing I'm going to do, though with an rtf I'm awfully close already, is not do as I've been told by the people handing out work. At least I'm pretty sure a user will have rtf's mapped to Word. Sending an html file might be seen as a sign of an inability to follow directions. sigh posted by ruffin at 11/23/2002 10:29:00 AM

Wednesday, November 20, 2002
To be all "cool and down", ya gotta know your slick abbreviations. B2b, b2c, c2c, p2p, and now P3P, case-sensitive, of course. Now P3P, or the Platform for Privacy Preferences Project, is a W3C initiative. I let W3C go when I first heard it, but now with this blatant obfuscation of the nearly truly useful p2p abbreviation, I have to challenge whether these are the people we really want making up standards for computer technologies. If they can't even come up with good, useful, unique acronyms and names, well, can they really be trusted to come up with anything other than New Cokes when they're done? (And I do apologize that "New Coke" is my concept for the week.) posted by ruffin at 11/20/2002 08:16:00 PM

Tuesday, November 19, 2002
Sometimes I think that Joel is writing just to get my proverbial goat. This time he’s suggesting we set up services that charge a cent to send mail. Then spam goes away, b/c it’s going to cost too much to send out tens of thousands (“19 million”) of emails with such a poor “bite-in” (my cheesy term there, not his) from the recipients. Though charging for email is a good way to start controlling spam, the idea bothers me on two counts. First, remember about ten years ago when the whole danged Internet was free? No pop-ups, no ads, no Flash presentations flickering as you try to read the day's news. It’d be a shame that not even email, the most popular of what I'll call the “simple standards” (versus what http has become with plug-ins and javascript galore), can remain true to what originally made the Internet great. Second of all, the charge would hardly stop spam. Embarrassingly simple economics. If the “bite-in” dropped from 0.001% to 0.000%, don’t you think the spammers would start shelling out a cent a message? Somehow, spammers keep paying 17¢ or so plus printing to get their junk delivered to my door. posted by ruffin at 11/19/2002 10:15:00 PM

I think I've mentioned before the time that the resident XML expert at my old place of employment emailed the software development group an article off the web telling how great XML was and how many ways we could use it in our day-to-day projects. Trying to be cute, but at the same time trying to get what I believed across, I did a quick search and replace on the article to insert ASCII for each instance of XML. Easy read and written, a standard for storing and transmitting machine-readable information, etc. Was thinking about how I didn't use XML in my latest app and I don't know that I've much changed my mind yet. Don't get me wrong. XML is great. It imposes a fairly forward-thinking structure to your applications' information, and does a great job bridging the gap between machine-readable information and human readable info. Most important is that "X" in XML, as it's awfully easy to take an XML schema and add a few more bits of information to a certain section/object without ruining backwards compatibility. That's a big deal. At the same time, it's much easier to "inputFile.readline()" than it is to learn the overhead associated with an XML parser. Not to mention all the extra minute rules you have to learn (like the "reserved 'id' attribute must be unique for each element" bit) to be strictly compliant. Of course there's also the fact that you have to learn a brand new pseudo-language, XPath, to extract bits from your XML file though ANSI-SQL with a few extra keywords would have done every bit as well - heck, better. XML has a little of the "New Coke Syndrome" (which I've started explaining in a draft blog entry I've got concerning Java's Swing) that's all too prevalent in computing and standards. In brief, lots of people smarter than us got together in a clean room and put together the best ideas they could about a certain subject and came up with a new way of doing things. Problem is, though everyone might have theoretically preferred the new taste when polled in a similar clean room environment, when it comes to practical action things fall short of the mark. SOAP is another neat idea that, in practice, falls a little short. You shouldn't have to learn so much esoteria to learn and use XML in your apps. And if that's the case, then strict XML's not such a good fit after all. If you're writing the next great business-to-business application, use XML. There's so much there already decided for you that you'll save tons of time and hassle not having to decide what's going to be "your data exchange method" between workgroups in your project. But if you're just hacking a quick website that'll take a few "man-months" to finish or writing a stand-alone app that only four or five people need to support (regardless of how many are going to use it), use the simplest means necessary for simple app preferences or configuration files. Not only will you make the app smaller, you won't be adding months to a new programmer's ramp-up time when they join the team. Only if you find yourself bogged down in the creation of your files' formats should you default to using XML. Be careful you're not headed for overkill. Now at the same time, make sure your application is written in such a way that whatever you use for the backend doesn't make much difference. If you're reading from the same pref file (much less writing) in three different locations in your app, it's time for a refactoring. If you write your code well, switching from ASCII to a RDBMS to XML and back shouldn't be a bigger problem than rewriting one set of I/O routines. I'm not really against XML; don't get me wrong. Ah, forget it. I'm waffling like Clinton. I give up. Sometimes it's good, depending on your coworkers, to force XML just so that you don't have to try and describe how to make code forward compatible and extensionable. It'll save you time in the future by not having to rewrite code by having your team use this standard. I'll just call its applicability situational and leave it at that. Perhaps another day I'll finally figure out what I think about using XML for non-b2b applications, but this apparently ain't it. posted by ruffin at 11/19/2002 05:17:00 PM

Today's news includes finally finding an open source, LGPL spellchecker in Java that looks like it might be useful, even if its name is "Jazzy". I think I've stumbled over this before, but I wasn't real impressed. The demo seems to work okay, however, so I'll have to give it another look soon. In other news, I lost about 73,000 potential customers (tongue in cheek there, a little) for my email list parsing software recently. Not so good. Though the lists and the site in general were pretty hack-n-slash, I did enjoy the lists' content. It'll be a pain to see asplists.com go. I'm a little upset Mr. Carroll has allowed himself to become so upset over the matter that he's cutting his support of MS and ASP & ASP.NET completely like this without even offering alternatives to keep the lists going, but that's certainly his prerogative. And admittedly, I really was hoping putting a link to the app in my sig on those lists might bring me a few bucks. 73,000 is a little high, but maybe five or ten. Oh well. It's hard to sell Java to MS sellouts anyhow. The only other thought for the day is beta testing. I'm not sure if I'm going to expand beta testing much past myself for my application. Trying to rationalize that I'll be johnny on the spot with fixes for the first few customers, and I really don't know that asking for volunteers on the net is the best way to get real testing done. At work, the beta testers were pretty quiet until they were using version 1.0 (or 1.3 or 2.0 or what-have-you) to get their work done. Then suddenly, a month past the close of the testing period, the reports come flooding in from the same people who were supposed to have tested the app in the first place. That might have gotten me a little unfairly wary of beta testers. Testing is an interesting beast. Every programmer knows that no matter how many times and ways they test an app, they only come at its use from one angle. Introduce person #2 and you'll get a completely different way of doing things. I like to close windows with the keyboard, you might with the mouse, etc. Your biases mean missed bugs, as anyone who has finished just one software project already knows. Anyhow, still have a ways to go, so I have some time to think about that one. Update: Looks like Joel's making the same excuses. Sounds like his recent product release has him pretty frazzled. posted by ruffin at 11/19/2002 03:07:00 PM

Wednesday, November 13, 2002
As another update to yesterday's longest blog (that is, the blog that doesn't mention clean underwear), it looks like advertising ain't cheap. Since my new app is written in Java, I can release most anywhere I want. My tentative plan is to release on OS X only at first and hope to scoop up a few schmoes who can help me get the app to be completely consumer ready. No matter how good an app you think you have, a user will always find something wrong -- which is a good thing. At any rate, the "Apple Developer Connection" newsletter recently announced a special advertising rate for OS X software in conjunction with Macworld. Here are the details: Macworld offer: * 1/8 page in the Mac OS X Showcase section for 3 month period Macintosh Products Guide offer: * 1 Product Spotlight ad for 3 month period * 1 Product Description Page ad for 12 month period * U.S. $4,000 for entire program* Sheesh, what a deal! Four grand to have an [admittedly decent sized] advert in Macworld in a section that's easy to gloss over for three months, plus some relatively obscure space on the Apple website. As an advertising idiot, I have no idea if that's a good price or not. The scary bit is that, once you have a decent app, four grand probably really isn't all that much for advertising. Until you have the money for the ante, you can't play at the high-stakes table, I suppose. And as a final unrelated note, Mozilla 1.0.1, though a bit slow, is a great browser on a 240 MHz G3 Mac with 96 megs of RAM and OS 8.6. Jobs may think Mac Classic is dead, but as I've said before, luckily the folk at the Moz project don't yet agree. posted by ruffin at 11/13/2002 11:59:00 AM

As an update to using C# on the Mac sometime down the road, it looks like Microsoft is already started. I didn't think it was any surprise that MS started with FreeBSD as the OS of choice for .NET after Windows -- It's completely "Free" as in "Free to take over as your own" (eg, Apple) and, well, obviously Apple's new OS X uses it. At any rate, you've got ye olde CLI on OS X 10.2 now, and I'd assume Darwin as well. Under the current license there's not much you can do with this Frankenstein's monster, but it's interesting to see. posted by ruffin at 11/13/2002 11:47:00 AM

Tuesday, November 12, 2002
Ha! There's more! Keep refreshing the page... (I'll quit with this now) * Clean Underwear from Amazon's Eddie Bauer Store * Ladybug Rain Boots from Amazon's Nordstrom Store * Suede Headwraps from Amazon's International Male Store * Cheetah Print Slippers from Amazon's Old Navy Store Man, once I have clean underwear, a cashmere sweater, and some nice cheetah print slippers (or should I use the ladybug rain boots? Guess that depends on the weather), I'll really be ready to code! posted by ruffin at 11/12/2002 09:50:00 PM

Just had to blog this... Was looking at Amazon to see if the new O'Reilly book on Netbeans had favorable reviews, and ran into this impulse ad: Customers who shopped for this item [Netbeans O'Reilly book] also wear: * Clean Underwear from Amazon's Gap Store * Cashmere Sweaters from Amazon's Lands' End Store * Tommy Bahama Shirts from Amazon's Nordstrom Store * Performance Fleece from Amazon's Old Navy Store Welp, it's good to know that I'll fit in with the Netbeans crowd once my clean underwear (I knew that stink was coming from somewhere) and cashmere comes in. posted by ruffin at 11/12/2002 09:44:00 PM

Welp, not much to post as I wrap up the [shameless plug alert] GUI for my first shareware app. Oh, I'm a long ways away from done. Still looking towards a release in late December, I believe. But things are working well enough I can occasionally take a break by watching the app work, which is exciting enough that it has me working most of the time my hands are on a keyboard. Been thinking about a number of things while I work, listed here in no particular order. 1.) Licensing schemes. No matter how fancy your means of protection, you're still pretty much stuck with the honor system. I'm hoping I've reached some level of insight in thinking about licensing with the following concepts. First, there are people that aren't going to pay for your software no matter what. Whether you just use a nag screen or you force them to pay before even seeing the software, they ain't shelling out. The only thing making your software harder to crack does is mean that less of these folk are using your software. Not sure if unregistered users using cracked versions of software is a better thing than them not using it at all or not. At any rate, when you think about introducing licensing schemes, you forget these people. Locking them out doesn't, at first glance, make you more money, pretty much by definition. So let's say 65-70% of the people that would pay for your software if they had to, whatever that means exactly, are going to be relatively "honorable" and pay your fee after the trialware cripples. For these folk, all your app needs to do is store the date of first use somewhere in plain text and check it each time it starts, in theory. So licensing schemes only bring in a percentage of that last 30-35% (at least with my dreamt up numbers). Hey, even I might fudge a date in plain text to keep an app working (though I finally even shelled out for WinZip at one point), but if the file's hidden and the format is a little wackier and takes some deciphering, I probably wouldn't. Bam! That's probably half of your wannabe hackers/pirates right there. But much more complicated licensing schemes than that? I doubt many people who decompile the code were potential customers anyway, right? And the people they distribute the app to are probably habitual pirates as well, I'd imagine, and the overlap with people who would pay if they had to is probably pretty low. It's easy to see you'll hit diminishing returns awfully quickly when creating fancier licensing schemes. Right? Right?!! :^\ Still not sure about this one. 2.) "What's the best programming langauge?" It seems most people will flame you until they're blue in the face with their preference, but I can never come to a clear winner. If I shelled out for C#.NET's VS.NET IDE, I'm betting I could cut down on development time over Java with Eclipse by 10%. Using VB6, that's probably more like 30%. I like Java, however, as it allows you to use object-oriented programming techniques (VB6 doesn't; C# does, of course) and it's quite easy to port, to say the very least. I still wonder if I wouldn't do myself a favor to port this source to C# and not worry about Mac and Linux until Mono behaves, but to me that seems like a cheap way out of "doing it right". 3.) Wow! In less than three months, it looks like I should have a product ready to ship, give or take. Boy, in the right company I could be making stuff happen hand over first! That's four products a year! Maybe only three once I think about support, but that's lots of products!! And then it hits me. Even once it's done (even pretending three months is enough time to support three apps), I'm hardly finished. The problem with shareware/trialware/garage programming is that now I have to hock the snake-oil. Brand identity, good manuals, advertising, all those things that make an app worth more than its bits on the hard drive are now my responsibility. I gotta sell this stuff! At least with contract work you've got a guaranteed market before you start programming. Not so lucky in the trailware biz. I might have three apps in a year, but if I have one that sells at all I'd consider myself lucky. posted by ruffin at 11/12/2002 02:57:00 PM

Friday, November 08, 2002
I'll be danged; they're right. I forget where I read it, but there was an interesting list of the top 10 or 50 or some such reasons someone hated VB, and one that I said to myself, "This can't be true. Maybe in VB 4 or something earlier, but no way in VB 6," turns out to be true after all. Say you have a line like this, declaring two TextStreams: `Dim ts1, ts2 As TextStream` Welp, ts2 is a TextStream, but ts1 ain't nuttin' but a Variant. I've even got "Option Explicit" at the top of the page, forcing me to declare each of my varaibles before starting to use them. But somehow the VB compiler hackers decided to take a shortcut and make everything not explicitly next to an "As" cast to a Variant. I wasn't getting Intellisense in my latest "quickapp" and voila, that's why. I was doing the exact same thing, give or take, with ts1 and ts2 (horrible names, I know, but this is a "quickapp for me") and only ts2 was autocompleting. Bizarre. The right syntax for this, fwiw, is apparently: `Dim ts1 As TextStream, ts2 As TextStream` I'm not sure whether to say this is a horribly low-quality hack that MS let out, or to applaud the lazy-but-clever programmer for producing a hack that never got uncovered by QA. :^) posted by ruffin at 11/08/2002 07:23:00 PM

Welp, it's time for my biweekly Joel on Software blowout. Here's an interesting quote, in between the not-so-subtle adverts for Joel's company's upcoming release of one of their projects. ... XUL [from the Mozilla project] may well be a real benefit to Apple and Linux, because application developers finally have a way to deliver to all three platforms for perhaps 110% of the cost of Windows alone. I've read a little on Mozilla's site about XUL, but I'm not nearly an expert. Regardless, Joel's still off-base on this one. Okay, perhaps an xplat GUI is ready for prime time with only 110% the cost of a Windows-only UI in XUL. But I doubt XUL makes GUIs easier to create than they are in Microsoft's IDEs for VB 6 or .NET. And there's no way it makes the libraries underneath doing the proverbial heavy lifting any easier to port. And there's no way in hell it makes XUL savvy programmers easier to find than Visual Basic hackers, which are, I'm not embarassed to say, a dime a for dozen or two (if you don't believe me, hire me). If you want an app that works on every platform in marginally more time that it took to create it, you use Java. I'd say it probably takes three times as long to make an app in Java than in VB for version 1.0. For version 2.0 (aka, "Finish up the crazy tasks we didn't get into 1.0 but we still think are useful), it probably takes about as long to extend your VB app. Java programmers are also quite a bit easier to find than XUL, I imagine. The downfall of Java, and possibly XUL (too naive to know, but if Moz is any indication I think at least that implementation has quirks similar to Java's AWT), is that the apps don't quite have the user's expected native look & feel. Believe it or not, that's a pretty big deal. I'm not just talking about the obvious, like that preferences aren't under Edit in Windows as often as in MacOS and that "About" menus are in different places, but I'm also talking about the very obvious, like that the GUI widgets neither look nor behave exactly like their parallel in other apps. When you see people putting in CDs upside-down in usability tests, you'll begin to release just how important every bit of familiarity can be! posted by ruffin at 11/08/2002 01:59:00 PM

Thursday, November 07, 2002
Confessions of a true Mac addict Welp, Apple's done it again. I'm not sure how, but they've got me wanting to get another one of their computers. In spite of the fact that I'm now 4 of 6 in the Macs enjoyed to Macs purchased ratio, and in spite of the fact that I could get a racin' AMD system for about $400, I think I'm nearly ready to plunk down a few grand for a new PowerMac. And I don't think times could be any less assuring in the Mac world. Take their new Gigahertz Powerbook. A cool system, certainly, with a slot-loading DVD burner in a laptop. Slick looking, for sure. But then so is a Fiero with a fake Lamborghini body. What impresses me even less than the concentration on slick looks is the slick advertising Apple's pulling recently. Here are two examples of Apple's less than straightforward adverts: And it all adds up to wicked-fast performance. In the PC world, you’d be lucky to get this kind of performance in a desktop system. That’s because speed expressed as megahertz alone can be misleading — it’s not an accurate yardstick of overall system performance. Fact is, the PowerBook G4 powers past Pentium 4-based notebooks by up to 44 percent in Adobe Photoshop testing. Well of course there's a catch to that statement. Here's the footnote: Test performed on 1GHz system with Adobe Photoshop 7 (November 2002). So let's translate this one back into English. "The 1GHz, top of the line, $2800 PowerBook G4 can outperform a 1 GHz Pentium 4 notebook in one application of our choosing, and even then only in certain benchmarks. Nor are we going to tell you if the P4 notebook was plugged in -- it might have been using its 'power-save' mode." That's not so good after all, is it? Add to that that, just for reference, you can't even find a 1 GHz P4 notebook over at Dell right now (about $1000 for a 1.9 GHz P4 Mobile, fwiw) and we see that Apple's statement, which makes the new G4 Powerbook sound awful fast, really is less than straightforward. Heck, it's downright misleading. There's something "wicked" going on here, and it ain't how fast the G4 is running. The DVD drive does look cool, though. Move on to the PowerMac. This "benchmark" image is probably my all-time favorite. What does it tell us? The new dual 1.25 GHz G4 PowerMac has 18.3 gigaflops of power versus the old PowerMac's 3.7. Wow! Now that is POWER TO BURN, ain't it? Closer inspection shows that the old PowerMac was a 500 MHz G4 (why not use an old 604e PowerMac while you're at it?). So we have two 1.25 GHz processors, which means 2.5 GHz "total", which is "equal" to five 500 MHz processors, right? Hrm, 3.7 times 5 is equal to 18.5, which is nearly 18.3. So if we were able to harness every single bit of theorhetical power from the old PowerMac and every single bit of power on the new one, the new one would be five times as fast. Wow! An amazing (or is that wicked?) benchmark!!! Not only is this math (I'm sorry, I mean "measure of 'peak performance'") no more than a simple truism, it's not even a real world measurement. Many applications don't take advantage of the second processor, meaning that you've lost half of your "peak performance" right there. Even apps that do don't magically become twice as fast as they would be with just one processor. I'm going to wimp out of digging up benchmarks again, but here's one example that I posted to the mac advocacy group. As I start to figure out in the post, even Apple's own iApps don't do as well with multiple processors as you'd like. So why do I want a PowerMac? A few reasons, I suppose. I've always enjoyed Macs and the "small pond" Mac community. It's easy to get your hands around what's going on, I think. I've also enjoyed the move to OS X, but my 500 MHz G3, 8 meg video chip iBook just can't keep up as well as I'd like. I'm so close to having a great OS; it just needs to run more quickly, just like I hear it does (with Quartz Extreme) on the new PowerMacs. And, admittedly, I enjoy not using Windows, and the Mac is a much nicer alternative than the less user-oriented Linux. There's a reason Linux geeks buy iBooks and Powerbooks now that OS X is out. OS X is the best of both [alternative] worlds. Performance aside, the iApps are also quite nice. Ultimately, they are what are bringing me to desire yet another impractical Macintosh PC. iTunes is great. I haven't found a good replacement for all iTunes does for Windows yet. Winamp, nice, but buggy in my system when I try to rip tunes after installing the plugin. Quintessential mp3 Player (or whatever) is great, but won't play Shorten format. Neither's interface comes close to being as easy to use as iTunes. Same with iMovie. I've got a DV camera, and making Quicktime movies to share really is a snap. iMovie is easy to use and I can edit together pretty good amatuer home video in a hour or so, even on the iBook. I've also got a digital still camera, and iPhoto, though horribly wasteful with hard drive space (it copies your originals in a new location, and the copies, even in the same image format, are often larger than what you started with!), is very well done. Planning to try out the linen covered picture-books you can order from iPhoto this month as well. If iDVD is half as good as these, and I'm banking it is, DVD authoring is right around the corner for me with the shortest learning curve you could imagine. The Macintosh as a "solution provider", rather than a "Swiss-army knife" Windows or Linux PC, is a package that's hard to beat. The solutions provided are right up my alley as well. But knowing Apple, the yet-to-be-released iDVD 4 will require a new G5 processor. And though iDVD 2 will be awfully k3w1, somehow they'll have me wanting to take that last little "inch" to a new computer the same way the iBook has me seeing the proverbial OS X promised land without quite taking me there. And the addiction will continue for years to come as I continue to, against my best judgement, line the coffers of Cupertino. Sheesh. posted by ruffin at 11/07/2002 11:12:00 PM

How in heaven's name does any work get done on "fun" open source projects? I had hoped I would have more time to devote to open source projects that don't directly related to what I'm doing once I was consulting from home, but it's hardly the case. Perhaps once I land a few clients and/or sell a few apps, but certainly in ye olde "start-up" period I've got so much yet to do I can't convince myself to take the time. I'd rather be hacking on my shingle for the web (aka website, of course) or even continuing to work on my own apps! Unlike "work work", which can sometimes be weeks spent adding a feature you don't think is really that useful, working on your own app is always productive. Don't like an approach? Trash it if that's the best move. Nobody to convince, nobody to feel bad that their code wasn't used -- basically no politics. It's a great way to get work done, but you may end up never needing a break [where you could work on "fun" projects, b/c work's 99.44% fun now]!! posted by ruffin at 11/07/2002 12:03:00 PM

Wednesday, November 06, 2002
I spruced up yesterday's post a bit to remove where I'd errorneously said that Java was an interpreted langauge. What I'd glossed over was that Java compiles to interpreted bytecodes, which is, in Java's case (specifically b/c of the way Sun has implemented the Java standard), barely "better". Great for making Java xplat; not great for dimestore software authors. Added a parallel with BASIC apps back in the C=64 days to complete ye olde proverbial spectrum. Of course there's no reason that Java couldn't compile to something a little less easy to decompile. There's nothing inherent in its design that means the bytecodes have to stay so generic. I believe that probably does make it easier to make a virtual machine for different platforms, but as anyone who has an emulator knows, you could make "the machine in VM" more esoteric if you'd wanted. Course then outfits like Blackdown would have had a harder time bringing Java to the Sun-unsupported Liunxes, as an example. posted by ruffin at 11/06/2002 10:34:00 AM

Tuesday, November 05, 2002
Yeeouch. A dual processor 1GHz G4 loses big to a 2+ GHz AMD machine in the graphic design and digital video editing departments. Poor Apple. It's bad when you take it on the nose on your home turf. posted by ruffin at 11/05/2002 09:56:00 PM

"Java shareware". Ever seen any? Probably not, and I know why. Unfortunately I even "have known why" and went ahead and wrote my latest app in Java anyhow. The problem is that a Java application is interpreted by a virtual machine. The code is never "really" or "fully" compiled. Rather, it's compiled into the bytecodes used in the Java virtual machine and the VM finishes the job moving it to pure machine langauge. This has the added problem that Java is relatively easy to decompile, as it's not in true native machine langauge. The bytecodes closely resemble the original Java code so that they're easy to move from one platform to the next. In fact, it's so easy to decompile that it's only one step away from being an interpreted langauge, like the original BASIC. Remember playing some old Commodore 64 games and hitting "break"? Bam, you were right into the code. You could LIST the contents and even change lines to change what happened in the game. Because the BASIC app was never compiled at all, the creators' had to ship the code as the application. Ultimately, as I'll continue to explain, Java applications are quite nearly in the same boat. Here's a partial example taken from Furthurnet, which is open source so they shouldn't mind us taking a peek. Remember, this is from the "binary", not from the actual [open] source. public void hyperlinkUpdate(HyperlinkEvent hyperlinkevent) { if(hyperlinkevent.getEventType() == javax.swing.event.nt.EventType.ACTIVATED) { String s = hyperlinkevent.getURL().toString(); String s1 = "http://furthurnet.com/pcplink.html?"; if(s.startsWith(s1)) { s = s.substring(s1.length()); String s2 = URLDecoder.decode(s.substring(0, s.indexOf("&"))); String s3 = URLDecoder.decode(s.substring(s.indexOf("&") + 1)); try { QueryPanel.download(new QueryResultItem((XmlObject)XmlParser.parse(s3).elementAt(0), s2), null); } catch(Exception exception) { } return; } JEditorPane jeditorpane = (JEditorPane)hyperlinkevent.getSource(); ... Not too bad, eh? Doesn't do a great job of commenting, of course, [because it can't, naturally,] but all in all pretty good source. We'll ignore Furthurnet's horrible exception catching code for the time being. You can use bytecode obfuscators like Retroguard to make things a little more difficult. Then the names of events and some variables become a little more generic and difficult to read and the like. There are more things like the Strings named s, s1, and s2 above. But the source is still all there. If someone wants to crack your app, they've essentially got the code to work with, which is a dream spot for crackers. Even when you use something as "trite" as Visual Basic, which I enjoy using, you're going to have a truly compiled application. People can wade into the machine langauge if they know assembler, but this is a much better way of hiding the way you process, say, license keys, which is pretty important to keep private. The level of effort is just too high for your typical dimestore hacker when something is compiled to native bytes. Of course Java is shooting for crossplatform applicability, and that strikes native bytes almost completely out of the equation. Java programmers' reply to the "open source, like it or not" quandry seems to be, "Anything, even something protected by hardware, is hackable." Well, sure, but it's all about time. As a software vendor, I want to make it difficult enough to deter most dimestore hackers and make it take someone who's really got it in for me long enough to hack the app and distribute it to the pirates that would use it that I can get another version out in the meanwhile. This is also, I believe, why Java and open source go together so well. The source is already there. It's no wonder most of the Java apps I use daily (Furthurnet and Netbeans for the most part, but there are some other small ones I grab once in a blue moon) are open source. And it's no wonder I've never used, that I recall, a commercial Java app. The only apps that can make it are the extremely expensive ones, like enterprise-level IDEs and server code, where the stakes are high enough and the customers are select enough that nobody's going to fudge. Is it okay by me that people hack apps? Absolutely not. Is it stupid for me to assume they won't? Absolutely so. To think any other way would be to lose money. And the prospect of accidently creating a successful application has already got me thinking about porting the code to C# for a Windows version -- though I suppose .NET might behave like a VM as well. I wonder how easily it can be decompiled! Quick update: Yep. It can. Thought so. Wonder what this means for .NET shareware writers and other small software companies. Definitely a vote for web services, like it or not, where you can hide the code on your server. The web services is, unfortunately, what I keep coming back to thinking is the best model for creating applications that can't be cracked [quite so very easily]. More about decompiling .NET here and here. posted by ruffin at 11/05/2002 11:15:00 AM

Monday, November 04, 2002
Well, this guy didn't spare any expense answering the age-old, kindling-as-in-easy-to-create-a-flame question of, "What's the best text editor for creating [in this case] Java apps?" posted by ruffin at 11/04/2002 12:15:00 PM

<< Older \| Newer >>