Recently in Geeky Category

There have actually been several interesting things to note about the book of late.

The first interesting thing to note is that you can now purchase the book from REAL Software when you go to renew or purchase a license for REALbasic. w00t!

Also, you are now able to order Ramblings on REALbasic through the store if you live in Canada or Mexico! The shipping cost will be 11$ to anywhere in those two countries. Sorry, but still no solution for shipping internationally in a more generic fashion.

Which brings me to my final note of interest. I've done away with the ability to ship the book via FedEx express saver. You might think this is sad news -- but wait for the punchline. ;-) I've decided to use USPS Priority Flate Rate for all domestic shipping. This is awesome news for anyone purchasing the book through the store. Media mail (the previous option) would usually arrive within 2-3 weeks. But for the same price at the post office, I can send the book to you in 2-3 (business) days. So this is actually pretty awesome news!

If anyone is interested in having a chat about Ramblings, REALbasic, the weather, etc -- you should stop on by the ARBP chat room at 8pm EDT tomorrow (Wed, the 28th). We're going to be having a get together, and it should be a lot of fun. Alas, but due to the diversity of locations, I can't buy the first round of drinks. ;-(

If you aren't able to make it, but still have a question you'd like to see asked, feel free to email it to me or Paul Lefebvre before 8pm EDT. Since this is an online chat, I am told there will be transcripts available afterward.

Hope to see you there tomorrow!

Since people like to say things like "Just Google it", and "I googled for that yesterday", I had an interesting thought last night. What if you use Bing as your search engine? "Just Bing it" is natural enough, but what about the past tense? Does one Bang? "I banged that yesterday" seems like something which should be spoken outside of polite company.

Thoughts to ponder, for sure...

As you may have already heard (thank you Amazon), I am proud to announce my forthcoming book Ramblings on REALbasic. This book is an edited and updated compilation of over 200 of my best blog entries, including new content that's never been seen before. In it you will find tips & tricks for REALbasic that are not available in any other source. Weighing in at around 550 pages, Ramblings on REALbasic covers topics such as the REALbasic language, design patterns, user experience and Windows-specific technologies.

Hear what others are saying about Ramblings on REALbasic:

"Ramblings (the blog) was one of the most useful resources I ever found for getting stuff done in REALbasic. But what I liked best about it was that almost every time a new entry came out, I could be sure of a really good read."
-- Steve Garman

"I've been reading Aaron's Ramblings blog for a few years and have always picked up some pearls on REALbasic programming, as well as programming in general. Aaron has an in-depth knowledge of compilers, language construction and language usage plus the rare knack for communicating clearly and definitively to both beginners and experts. If you want to be a better REALbasic programmer, read everything Aaron's got to say!"
-- Dr. Scott Steinman

I would like to extend a heartfelt "thank you" to Brandon Warlick and the folks at Sunbelt Business Graphics, Inc. Their help, dedication, and experience in the printing industry made this book possible.

So the internet broke up with me today. Thankfully, it was only a short divorce. It got about as far as Fargo, then turned around and came back to me. We've reconciled our differences and will be resuming our happy marriage with fervor. However, during our brief hiatus, I caught a glimpse of what life is like without the internet. Here's a sample:

I was in the middle of composing a fairly involved email to a coworker of mine when I lost connectivity. My email is actually an Outlook account which requires a VPN connection to hit the server -- so when the network goes down, I get these lovely modal dialogs that say "cannot connect to blah blah blah." Since the net appeared to be gone forever, and I was tired of seeing these stupid dialogs, I wanted to close my email client down. However, I didn't want to lose my long email. So I tried to save a draft.

And then I found out that for my case, drafts are saved on the server and only on the server. Not locally.

I can understand saving drafts on the server. It's kind of handy to be able to write a draft at home on the desktop, then go to the airport and continue the draft from the laptop. However, what I can't understand is Thunderbird's incredibly stupid behavior when there's no connection to the Outlook server. Not everyone has stable network connections, and failing to save data when the internet is down is a horrible user experience. To a normal user (aka, not a computer geek like myself), the two don't even correlate!

Hopefully, since the net and I have resolved our differences, I won't ever have to run into this situation again. But it'd be nicer still if I never ran into it because Mozilla implemented a fall-back mechanism for saving drafts.

Here's a little gotcha that people probably aren't aware of in the RB community. Operator_Convert has a dangerous side-effect.

Class Class1

  Dim mData as Integer


  Sub Operator_Convert( rhs as Class2 )

    mData = Val( rhs.mData )

  End Sub

End Class

Class Class2

  Dim mData as String

End Class

Dim c1 as Class1

Dim c2 as Class2

c1 = c2

MsgBox Str( c1.mData )

It's a tricky one -- the problem is that we never instantiated Class2, so it is nil. When we make the c1 = c2 assignment, we are passing in a Nil object. c1's convert doesn't test for it, and so we get a NilObjectException. But you probably expected that. But wait, there's more! (RIP: Billy Mays)

Let's say you check for Nil in the Operator_Convert function and get rid of the exception. Now what? No more unhandled exceptions! Doesn't that strike you as a bit odd? I would expect an exception on MsgBox Str( c1.mData ), yet one doesn't happen!

That's the true scary problem of the convert to operator. Aside from throwing exceptions, there is no way for the call to fail. So even though c1 should be Nil, it won't be.

Thankfully, the Nil chameleon type doesn't act as a Class2 instance in the compiler when it comes to conversion operators. So if you say c1 = Nil, it will be Nil, regardless of the conversion operator. However, I don't recall that as being something explicitly enforced by the compiler so much as it just happening to work that way. I certainly hope that behavior doesn't change, as it would make a bad situation much worse!

Regardless of the behavior of Nil, this insidious problem can still sneak up to bite you if you're not careful. It certainly isn't intuitive behavior that an assignment from a nil object will create a non-nil object when Operator_Convert exists, but create a nil object when Operator_Convert doesn't exist!

I had an enlightening discussion with one my coworkers today about JavaScript. He's been a good resource when I want practical knowledge about how JavaScript programmers work. All of my knowledge of the language has come from the specification and is from a compiler writer's perspective, which makes it easy to miss concepts that are obvious to anyone who actually works in the language.

I've been having an incredibly hard time wrapping my mind around why anyone would want to use JavaScript. To me, it's truly a horrible language that was obviously thrown together with very little refinement. It's not that I don't know how to get work done in it. It's that I don't know why I'd want to do work in it in the first place.

During our discussion, I came to a realization. There are short-term programming languages, and long-term programming languages. In some languages, you write code intending it to be used for decades. In other languages, you write code without that intention. A convenient split for these time frames is web programming versus desktop or server programming. When you write a desktop or server application, it is expected to live for a long time. You expect to refactor the code, evolve the functionality, etc. You don't expect to have to rewrite it for a while. However, when you write a web application, it's implicitly understood that it only needs to work for a short while.

If you don't believe me, check out the totally off-the-cuff timeline I came up with. 15 years ago, we were all writing static HTML web pages. 12 years ago we started adding dynamic information via Perl. 10 years ago we began using applets written in Java. 7 years ago we started to switch our Perl code over to PHP and JavaScript. 5 years ago we started to ditch the PHP code for Ruby and Python. 2 years ago we started building up AJAX frameworks. By and large, every few years "the next big thing" comes along in the web space and we rewrite our code.

That's not to say that mistakes aren't made on both sides. We've all seen web applications that seem to live forever and evolve like desktop applications. Similarly, what desktop programmer hasn't produced terrible code which barely lasted a few months before being rewritten entirely? But the generalization holds true -- web applications are typically more short-lived than desktop applications.

This is why I have a hard time wrapping my mind around why people use JavaScript. The language doesn't support access control, or type safety and I find that to be a flaw. However, I'm looking at it from a long-term perspective as a desktop programmer which is incorrect. I should be looking at the fact that it's blindingly easy to just blast some code onto the page and hack it together to work. That's the "web way!" That's also why I would make a terrible web programmer.

Can anyone spot what's wrong with this code?

void foo( void )
{
  struct Test {
    int a;
  };

  std::vector< Test * > tests;

  tests.push_back( new Test );

}

Here's a hint: it compiles fine in Visual Studio, but not in XCode. The real answer lies in section 14.3.1.2 of the C++ language specification. Namely,

A local type, a type with no linkage, an unnamed type or a type compounded from any of these types shall not be used as a template-argument for a template type-parameter.

My question is: why? It strikes me as being rather odd that templates behave this way, since (AFAIK) there is no other language construct in C++ which disallows locals in this manner. Any ideas as to the reasoning behind this?

While helping Elissa with her thesis presentation, I got really annoyed at PowerPoint for its incredibly stupid habit of saving external data as absolute paths. Yes, I know absolute paths are unavoidable on Windows. However, that doesn't mean you get a free pass on user experience!

The problem boiled down to having external sound files in the document. You'd import the sounds, test them out, and be happy. Then you'd move to another machine and oops, sounds may or may not work. Three very intelligent people in the ento department were utterly baffled by this behavior. Things would work, then randomly stop working. I knew immediately that the issue was the fact that the ppt and sound files were being stored on a flash drive, and that different computers were assigning different drive letters to the drive upon insertion. So if it happened to get the same drive letter, everything was fine. But if the drive letters differed, then the sound files wouldn't work.

What's ridiculous about this entire situation is that the sound files were relative to the PowerPoint presentation! This is a very common use case, especially for people who put presentations onto a flash drive. So why not store two pieces of information in the file format? An absolute path is very quick and easy to work with, but relative paths aren't difficult to generate or parse. Save them both so you have a fallback in case drive letters change.

This isn't just a problem for Microsoft. Anyone developing an application for Windows should keep this in mind. There's no excuse for your application failing to perform properly just because the user happens to plug their flash drive into another computer. Bugs like that are a great example of why many people think computers are "magic." Consistent results are the key to making a good user experience, and PowerPoint utterly dropped the ball. Don't make the same mistake in your own applications!

Like most remote employees, I have to deal with forms via PDF files fairly regularly. This isn't usually a problem, except for two minor details: 1) I hate wasting paper with printing crap out and then scanning it back in, 2) I don't have a printer or a scanner at home anymore. But this is the computer age, surely there's a concept out there that can assist me! Oh yeah! Just edit the PDF file. It's a simple concept really. Use the typewriter tool to enter in whatever text I need to enter in, and then import a picture of my signature (from way back when I had a tablet PC and stored off a signature image) for any places that needed a valid signature. Sounds reasonable, right?

Wrong.

Not because the technology isn't there, but because it isn't readily available in a reasonable format. PDF is the "free" way to deal with portable documents. But thanks to Adobe, that's become "only when reading." Everyone, even F/OSS programs, have jumped on the "pay for this basic editing functionality" bandwagon and it pisses me off. PDFs are ubiquitous, just like text files have been. Imagine just how frustrating your life would be if Notepad (BBEdit, whatever your poison) decided to only let you view text files. If you wanted to edit them, it'd save with an illegible and pointless watermark over it. It's ridiculous.

I spent almost an hour today looking for a free PDF editor that would do those two simple things (fill out text fields, import a picture) and couldn't find ONE that could do even that little. FoxIt, which used to be my favorite free PDF viewer and editor has decided to start whoring itself out with ridiculous toolbars, and multiple versions of the product with various plugins, etc. Worthless because importing images means you get watermarks. CutePDF, which used to be the gold standard before FoxIt, won't even install for me because they're too lazy to make a UAC compliant *installer* for the application. They actually have the balls to tell you to turn off UAC just to install their shitty software. Wow. I also tried some off-brand PDF editors, including Bullzip (which is just a print driver, and that doesn't solve my problem), PDFill (which watermarks even simple editing like typing in fields) and a few others.

Quite honestly, with all the incredibly terrible software that's out there in the PDF market, I was tempted to just give Adobe some money for a version of Acrobat that allows me to edit PDFs. Then I realized I'd just be supporting the stupid concept that I hate anyways. Don't call it a portable document format, because that's not what it is. Document implies reading and writing. Call it a portable viewing format, because that's all it is.

There's probably some obscure piece of software out there that does exactly what I need it to do (and if you know of it, please let me know -- my requirements aren't hard: edit text fields, import an image, save to PDF with no watermark). However, after an hour and a pissed-off blog entry, I'm not interested in searching much more.

Once I move back to MN, I'll be buying a printer/scanner/fax machine.