What's Another Word For Scam? Word-of-Mouth.org

I don't want to waste much more of my time than I already have on this, and other people have gone over it better already. Let's just say, avoid word-of-mouth.org. I got an email from them, and I'm sorry I didn't just delete it. If you get an email from that domain, don't even bother reading it, it's a troll for your money. The email will tell you that somebody close to you has filed a report on you, and if you want to know what they're saying, you have to register. There's a fee for that, of course.

http://www.snopes.com/computer/internet/wordofmouth.asp

http://www.rubycon.org/blog/archives/000109.html

Word-of-mouth.org is supposed to be a service where people can anonymously exchange information on other people. In fact, it's a scam. Is it ironic that I'm telling you they're con artists, and my name is right out in front of the report? I'm not sure.

Deep In The Ninth Circle of Debugging

We're in crunch mode over here. Our public beta is approaching fast and I have a very long queue of bugs to fix. My head is swimming, my eyes hurt, and my body feels like it's hollow inside. I'm going on hour 11 with no end in sight.

Fixing bugs under deadline pressure is my single least favorite part of being a programmer. A lot of my programmer friends enjoy debugging, because for them, it's like solving a puzzle. I understand that, and I appreciate a puzzle as much as anyone. It's the part about doing it to meet a schedule that drives me crazy. In addition, debugging one's own code is a very humbling process. Being a programmer is a daily exercise in confronting one's own stupidity. There's always something, like an enumeration that was forgotten in the code, a logical error that somehow slipped through, a miscommunication between the client programmer and the server programmer, a use case that wasn't considered, an assumption that doesn't hold up. As a programmer, I am constantly being reminded that I don't have perfect recall, perfect insight, or perfect typing. As a human being, I accept all of that and I don't think it diminishes my worth, but as a programmer, it all adds up to a lot of long hours at the crunch point of a project, bleary-eyed, hungry, tired, and burned-out, staring at the code, wondering, "how the hell could I have missed that?"

PS: I'm still mad at Flash, because after years spent using a succession of steadily improving debugging tools in my career, suddenly I'm back at approximately the level of debugging support I was used to in GW-BASIC.

In Case of Rapture, This Web Site Will Be Unmanned

Recently I came across a site called Rapture Letters, which has a unique mission in the world. I'll let them explain it:

The rapture: When all the believers in Jesus Christ, who have been born again, are taken up to heaven.

After the rapture, there will be a lot of speculation as to why millions of people have just disappeared. Unfortunately, after the rapture, only non believers will be left to come up with answers. You probably have family and friends that you have witnessed to and they just won't listen. After the rapture they probably will, but who will tell them?

We have written a computer program to do just that. It will send an Electronic Message (e-mail) to whomever you want after the rapture has taken place, and you and I have been taken to heaven.

If you wish to do something now that will help your unbelieving friends and family after the rapture, you need to add those persons email address to our database. Their names will be stored indefinitely and a letter will be sent out to each of them on the first Friday after the rapture. Then they will receive another letter every friday after that.

This site is a deeply original fusion of 20th century technology and 19th century mysticism, which by itself earns my deep respect. Personally, I find this whole school of cosmology silly, but you know, you'll never catch me telling people what they ought to believe. (I leave that to the evangelicals.)

Believers in the Rapture imagine that at the moment the blessed event occurs, no matter where they are, no matter what they are doing, their souls will be magically transported away from their bodies and spirited into heaven. Popular depictions of the event show the spirits of the saved joyously flying through the air to meet God. Unfortunately for the people who are left behind, there's no telling what the "saved" might be doing at that precise instant. Have you seen those bumper stickers which read, "In case of Rapture, this car will be unmanned"? There's an entire school of evangelical writing devoted, in part, to gleefully depicting the immediate impact of the Rapture. Tim LaHaye, in particular, has made a fortune writing in this vein. It's not hard to see that it could be a disaster for those who aren't "saved", and for this reason we occasionally come across Internet rumors like this one, which posits that airlines are in the practice of pairing their Christian pilots with non-Christians just so that in case of the Rapture, there will be someone still piloting the plane.

By the way, the Rapture is not specifically mentioned anywhere in the Bible -- it's an interpretation that had its visions-induced origin in the 1830s.

Digressive Dialogue

Um, don't people who believe in the Rapture believe that the Bible is the literal word of God?

Why, yes, they do, Bobby.

Then, um, what are they doing interpreting it?

They're doing the same thing everyone else does with it.

But when we interpret it in a different way from them, they say we're going to hell for that.

Why, yes, they do, Bobby.

Are they right about that?

I don't really know, but probably not.

However, I'm game to entertain the possibility of a Rapture, and being technically inclined, my mind naturally turned to the technical question: Just how does the Rapture Letters server detect the fact that the Rapture has occurred? What sort of program could you write, what kind of circuit could you build?

The only workable solution, it seems to me, is a "deadman's switch", run by a system operator who was certain to be taken in the Rapture. Every day the certainly-saved sysadmin would advance a timer on the computer system. Perhaps the timer is set to a time 72 hours ahead; perhaps two weeks. However far ahead it's set, the system will detect when the timer runs out, implying that the sysadmin is no longer on Earth, and triggering the release of the Rapture letter to the "lost". In fact, I emailed raptureletters.com and received confirmation that this is exactly what they do, and the site implies that the timeout value is about a week. Aside from the irony of the name ("deadman's switch", heh) this is a pretty good system, but I have to wonder: how does the sysadmin know he or she is "saved"? The obliging folks at raptureletters.com answered that question as well, though I feel the answer was a bit terse: "I am the sysadmin and I am saved,"

Before I got that answer, I imagined a couple of ways around the problem. If there are several sysadmins, and all of them are required to advance the timer, then there is a relatively high probability that the event will be correctly detected. Let's say each sysadmin has a 90% chance of being taken; therefore if you have two sysadmins, there's a 99% chance the server will detect the Rapture, and if you have three sysadmins, there's a 99.9% chance. As a backup, the sysadmins surely know someone who would be taken (you'd think, wouldn't you?), and they could initiate the email flood manually. (But do they pretend they're not around to answer return emails? And what do they tell their unbelieving friends? "The Rapture's occurred, just like I told you it would, and no, I wasn't taken"?)

When I got the answer back from the sysadmin, though -- "I am the sysadmin and I am saved," I realized it was a waste of time to imagine solutions to this interesting technical question. Rational solutions to real problems require uncertainty to be taken into account, and web sites look like they'd need rational people running them. After all, they run on rules. But we make the assumptions that undergird those rules and they don't need to be rational. The certainty displayed by the Rapture Letters sysadmin, the irrational certainty, is admirable in its own way. He or she is saved, that's the end of the story. There's no need to consider alternatives, and no requirement to wonder about possible failure modes. Leaving aside yet another question -- isn't it God's decision whether you're actually saved? -- it must be very comforting to be that certain that you, too, will be taken on that glorious day, and you will be vindicated to everyone who didn't believe as you do ("they just won't listen"). Too bad I can't see my way into being that certain without being dishonest with myself in a really fundamental way.

I do have one final question for the sysadmin of Rapture Letters. When their server sends out thousands, possibly millions of identical emails, how do they intend to keep them from being filtered out as spam?

PS. I signed up to get an email, just so I'll be sure I don't miss it when it happens.
PPS. I know. I'm going to Hell.

Bartleby.com

Bartleby.com : This is a very good site. It's a free repository of reference materials, and a fun place to browse besides. There are literally hundreds of books here, including encyclopedias, dictionaries, histories, quotations... it's an entire reference section distilled into a single site. There is also a selection of classic (i.e. public-domain) fiction and nonfiction, and although it contains many classic books, it's a distinctly limited set. Nevertheless, a terrific site. Ad-supported, but the ads don't really get in the way.

GW Bush Went AWOL

GW Bush Went AWOL Title says it all. His Floridacy's chutzpah in dressing up like a real serviceman is just breathtaking, considering the fact that he couldn't be bothered to actually show up for more than a year of his own service, even after it had been watered down to only having to serve in the Texas Air National Guard. But we all know that in Emperor George II's world, there are two sets of rules: one for the rich and well-connected, like himself, and one for the rest of us. Bush's true contempt for America is illustrated by nothing so well as the cavalier way in which he shirked his military obligation, and then, when it turned convenient for him, decided he was a "pilot" as well as a "patriot".

It's About Time

Al Gore finally found his voice last night and spoke out about the intolerable torrent of lies and distortions emanating from the current administration. And it's about time. It's about time a prominent Democrat spoke out. It's well past time that the Democrats in Congress ended their shameful acquiescence to the current state of affairs, in which the Administration's blatant lies and distortions are allowed to go utterly unchallenged. I don't know if Al Gore finally, finally decided to start speaking up because he noticed that Howard Dean is starting to get some traction from his tough-on-Bush stance, but I suppose that it ultimately doesn't matter. What matters, more than anything at this point in our history, is that this is a beginning, not a one-shot. The Democrats have to start being an opposition party once more, or they're doomed, and that means being forthright and calling a liar a liar. Gore was civil about it, of course; being forthright doesn't mean being Rush Limbaugh. Come to think of it, in fact, Rush isn't just civility-impaired, he's a liar, too. Rush is essentially part of the Republican leadership, and he parrots whatever falsehoods are spewing from the White House and the Republican National Committee anyway. The important thing is that there is a glimmer of hope. I just hope that Al delivers with some follow-through. The jerks in charge of Washington have lied us into a couple of big messes in the past couple of years, namely Iraq and the biggest deficit in history; not to mention a handful of lesser messes. They're going to find these messes impossible to lie their way out of, so they're going to try to pin the blame on somebody else. With Murdoch et al helping them spread their message, they might just succeed. Somebody has to stand up to this pack of liars before it's too late.

Programs and Writings by Bill Hees

Bill Hees is a friend of mine. He's got a pretty cool web site which he fills from time to time with his musings, programs, and links.

Building Applications in ActionScript: Promise and Problems

or, "The Trouble With ActionScript"

In my previous posts on my experiences as a developer in the world of ActionScript (here) and (here), I've complained about the difficulties inherent in application development in Flash and ActionScript. I believe we're in uncharted territory; I'm not aware of any other development efforts underway which match the scale of what we're trying to do at Applied Messaging. Therefore, I think my perspective might prove to be valuable to other people who are considering similar projects.

After helping to develop an extremely complex product over the course of the last nine months, I have come to believe that Flash has a future as a real internet application development tool. It's a very difficult and frustrating tool to use at present, however, and it has a lot of growing up to do. On the other hand, I've worked with a lot of tools and environments which were immature, hard to use, and frustrating -- and some of them, over time, were improved to the point of being useful and relatively easy to use. I hope Flash becomes one of them, and on the basis of the conversations we've had with Macromedia, there's a lot of reason to be optimistic. I think on balance there is a good chance that Flash will mature the way it should, and when that happens, it could be very cool.

In the meantime, I have to live with what Flash is, rather than what I hope it will mature into, and here we have a wealth of problems.

ActionScript is a feature-complete language: it provides the necessary infrastructure to perform almost any computing task. There is no formal reason why one cannot build large, complex applications in ActionScript. However, that doesn't mean that ActionScript is a particularly good tool for doing so. In fact, if you are developing a complex application, unless you have a compelling reason to develop in ActionScript, you probably don't want to do so.

ActionScript, as I mentioned before, is well-designed to create simple applications. If you are developing a simple application, then doing so in ActionScript may well save you a great deal of time. However, if you are developing a complex application, then doing so in ActionScript will actually cost a lot more than it would in a more mature environment. Let me digress for a few paragraphs to explain why.

Simple applications and complex applications differ in the number of interfaces which the programmer is required to maintain. An interface exists anywhere where one object or routine is calling another object or routine. Simple applications may only have a handful of objects and their associated routines. Complex applications may have hundreds of objects and thousands of functions. Our current application has over two thousand separate functions.

Simple and complex applications also differ in the stability of the requirements and the design. Simple applications are easy to understand and easily specified. A simple application's requirements do not change much over the (short) course of the application's development and deployment. However, this is not the case for complex applications, where it's a common occurence for the final product to look and behave substantially different from the product which was originally envisaged. There are a number of reasons why this might occur. The problem might turn out to have been incompletely specified (this happens a lot, actually). The customer's needs might change. The original design approach might need to be altered for performance. The server backend might need to be migrated to a different system with a different protocol, necessitating a client change, etc. All these changes need to be propagated through the application's codebase and its associated interfaces. The interfaces consist of function calls within the application, and network requests outside the application.

In the case of simple applications, the time to build the application (i.e. the cost) is dominated by the time required to code the application. However, as an application grows, the number of interfaces to maintains grows roughly as the number of objects squared. Therefore, as an application grows in complexity, the time to build the application soon becomes dominated by the time spent testing and debugging the interfaces. This problem is compounded by the fact that complex applications are subject to the additional stress of changing requirements/designs, as mentioned above.

ActionScript is a typeless language with minimal error-checking and a forgiving compiler. It doesn't require variables to be declared or typed; it has a very simple and flexible object model, and errors such as uninitialized variables and mismatched function signatures do not generate any warnings or exceptions. On the other hand, a language such as C++ is strongly typed, with loads of error checking and a strict compiler. Coding and compiling an application in C++ is difficult and frustrating compared to doing the same in ActionScript, because there are a lot of details which have to be precisely specified, and the compiler generates a lot of errors and warnings. However, the compiler's insistence on rigor from the programmer helps to insulate the program from errors which arise when one part of the program isn't consistent with the other parts. This makes C++ programs relatively robust in the face of design/requirements changes, and makes ActionScript programs, by contrast, relatively brittle. Because of this, it usually takes much longer to change an interface, and to test that change, than it does in a more mature environment. Creating, debugging, and maintaining a complex application in ActionScript therefore takes several times as long with Flash and ActionScript than it would with another tool like Visual Studio.

If your application is straightforward, if it should only require an afternoon to code, ActionScript is a very good tool. It doesn't require a lot of preparation to get an application up and running, and because the compiler is not very strict, it's not intimidating for nonprogrammers. Plus, of course, it's part of Flash, giving you an excellent display layer, as well as access to a good API with components and a set of network interfaces. However, if your application is very complex, you should consider very carefully whether ActionScript is the tool for you. The brittleness of ActionScript applications with respect to design changes is its most serious weakness, but not its only problems. ActionScript applications are also very slow, because they are only compiled down to virtual machine code, to be interpreted within the context of the Flash player. Finally, good debugging facilities for ActionScript applications are practically nonexistent, further adding to the time and cost for building complex applications.

Macromedia claims that many of the current deficiencies in Flash and ActionScript will be largely resolved in the next release of Flash. In fact, what I've seen of the new tool is very promising. However, if you're building an application now, you don't have the luxury of working with next year's tool. Flash 6 (a.k.a. Flash MX) is an enormous improvement over Flash 5, and I expect Flash 7 to be even better. Alas, that doesn't help me now.

Some advice if you've come this far and you still want or need to develop in ActionScript:

Plan Ahead Very Carefully. Because changing your architecture in the middle of your project will be fraught with difficulty, be as complete as you possibly can in your initial design and try to minimize how much the specifications will change while you're in the midst of development. This will reduce the possibilities for introducing bugs as you modify your code.

Shift the Burden as Much as Possible Off Your Flash Client If you're building an application which consists of a Flash client and a server based on some other technology, try to make the server do as much work as possible, and try to make the Flash client do little more than serve as a display and control layer for the user. It's likely that the server can be coded in a more robust fashion.

Don't Expect Much Help From the Flash Debugger. We almost never use the Flash debugger. This is for a number of reasons and some of them are unrelated to the platform itself, but partly this is because the Flash debugger is, in fact, a poor debugger. We have developed a number of in-house tools which do some of the jobs which a real debugger would perform, and we have made do with these.

Build Lots of Instrumentation and Scaffolding. Make sure your program keeps a lot of state information, allowing you to find and diagnose bugs when they occur. Our tools essentially encapsulate a local shared object which maintains a running record of trace-like statements, coupled with interactive runtime expression evaluation. These tools are dependent on a lot of instrumentation in our application.

Coherence Engine

After noticing it prominently displayed on the Blogger sidebar, I took a look at Coherence Engine. It's a very interesting site and I'm noting it for future reading.