Douglas Crockford's humor...
Before video terminals became cheap, Basic was usually accessed with Model 33 Teletype machines that could only print a subset of the ASCII character set. They couldn't handle lower case or some of the special characters. I called that subset Half-ASCII.My first paid programming gig was in BASIC on an IBM 5100.
See that red switch between the tiny screen and the streaming tape drive? That determined whether you were programming in BASIC or APL!
(via stpeter) Tivo wanted to send messages from their servers to your Tivo and so they are doing so with XMPP.
The Tivo Lovers Blog says...
Yep, TiVo is basically using instant messaging for real-time communication. Now when the TiVo server has a new recording to schedule, it will IM the TiVo to tell it. Or if there is a download to pull, it will IM the TiVo to tell it to do so. This is a much more efficient system and it eliminates latency. It is really a clever idea.
Gregory Brown and Brad Ediger write about some Rubyware from why the lucky stiff, et al....
If Merb is a paragon of professionalism and class, Shoes is a monkey on LSD. Shoes, by why the lucky stiff, is an incredibly compact cross-platform GUI toolkit for Ruby, but it looks nothing like the other cross-platform toolkits out there. For one thing, it is lightweight. Shoes lets you build GUIs in Ruby whose code actually looks like Ruby, not XML or Java. Shoes is under heavy development right now, but it will eventually form the basis for the new Hackety Hack, _why's programming environment for kids.I love that by page three of why's Shoes book, the crab is toasting us on our adventure with a glass of champagne. I hope I am not giving anything away with that.So, what are a web framework and a GUI framework doing together, you might ask? We are going to build a pastebin as a repository for our own code snippets and pieces of text we want to save. We'll build a GUI frontend using Shoes, and connect it to a Merb backend that will handle the database...
Michael Nygard tilts a little too much toward the enterprisey in his recent post on outbound email.
Some of his complaints seem to be about the JavaMail API specifically. e.g. "one connection per message" is not a limitation of SMTP. I suppose his concern is that the JavaMail API has a lot of setup and teardown cost for each message.
But regarding his concern about holding up request-handling threads and recovering mail messages when connecting to the mail transfer agent fails... he goes on to recommend using a message bus/queue like JMS or an ESB, for goodness sake, in *addition* to the SMTP server. An intermediary for the intermediary??
Rather than doing running some other kind of server, why not make sure you're running a fairly stable SMTP server? He writes...
...keep in mind that SMTP servers aren't always 100% reliable...But I thought the point of his book is that *no* system is always 100% reliable. (btw is there such a thing as "sometimes 100% reliable"? :^)
And so even with a bus/queue or an ESB in between your system and the SMTP server there are still opportunities to fail. In fact, there seem to be *more* opportunities to fail.
Another quote from Michael...
Yes, you can log an exception when your connection to the MTA fails. But that only lets the administrator know that some amount of mail failed. It doesn't say what the mail was!But if you can log the exception, certainly you can log the message that would have been sent, and then either automatically or "manually" resend it.
How would you handle this situation?
This seems like a general problem, and not specific to SMTP. For example, let's say instead of SMTP you'd like to publish a message to a collection on an Atompub HTTP service. Would you recommend a bus/queue or an ESB as a stepping stone between your system and the HTTP server?
How is this similar or dissimilar to the SMPT scenario?
A handy quote...
The time taken to learn things isn't as important as how useful they are once learned.
I guess people are out looking for that new language they're going to learn in 2008, or something.
I like seeing the Io language get some attention. I've been reading Steve Dekorte's blog for a long time because I enjoy his posts on architecture and design, generally, as well as his policital/economical/sociological posts.
I only played with Io once, for an afternoon, several years ago with a friend who was getting into it at the time. He walked me through the basics of Io's reflection and "meta" capabilities as I typed his instructions into the repl.
What strikes me about all these aspects of Steve is the common theme of minimalism. Io certainly holds the "minimalist" point on the range of language options.
