![[SJF Logo]](../../images/sjflogo.gif)
A good friend (who must remain nameless) recounted this story that was too good not to share:
My neighbor who is retired and doesn't drive much at all has become a constant pain in the ass. He fills his gas tank up every Friday and I swear he waits until I'm in the back yard on Saturday morning to ambush me and gloat over his car's 26 MPG.Eight weeks ago, I took to sneaking out in the middle of the night twice a week and adding a gallon of gas to his car on each trip. I did this for 4 weeks. I then spent the same 4 weeks listening to how he will never buy anything but Chryslers ever again as after those suckers got broke in, they'll get 30 MPG.
The last 4 weeks I've been sneaking out in the middle of the night twice a week and siphoning out a gallon each trip. The poor bastard is beside himself, he's had the car to the dealer twice now because he's only getting 19.6 MPG.
I think maybe the real solution would have been to put the fence up another two feet.
I recently got a new cellphone, and it has text messaging. I've found this feature to be remarkably handy, but found that one person couldn't send me messages. I can call and send text messages to a friend in Canada, but only phone calls come back: text messages to my phone just get lost. We've run some tests between our phones and that of other subscribers and are sure that it's not any of our individual accounts: it seems that Rogers/AT&T Wireless (in Canada) subscribers cannot send text messages to Verizon subscribers in the US.
My friend's analysis:
My theory was that the text messages are received using separate gateways. We operate on gateway #1, your carrier on gateway #2. After further investigation, my theory proves correct. Essentially what this means is you can send text to us but we can't send text to you. This is the result of a roaming parameter which exists on the backend configuration for inter-carrier communication. It's not something that's related to hardware or network socs. Given that, there's nothing we can do at this time.
I suppose I could imagine some situation where any two carriers had to make some kind of arrangement to exchange messages -- kinda like internet peering -- but the fact that messages just get lost is astonishing to me. We're not talking about an occasional dropped message - perhaps this is inevitable - but a consistent, reproduceable black hole. And in only one direction!
Rogers/AT&T is the largest cellular carrier in Canada, and Verizon is very large in the US. This is an enormous perception-of-reliability issue, and I'm just flabbergasted that such a thing could exist.
I'm building some software for a customer, and it involves using a third-party DLL that was created in Japan. The documentation is about what you'd expect - horribly translated - but even the header files provide some entertainment. The list of error codes contains what you'd expect (Error_DeviceNotFound, Error_Busy and the like), but the catch-all error is:
Error_Something
I recently received an email from Sleepycat Software announcing version 4.1 of the Berkeley DB. I'm on their mailing list, so this is completely opt-in, and the content was appropriate for this kind of message.
In the message was the notice:
You've received this email message because your name appears on a list of people who have asked for notification of new releases of Berkeley DB from Sleepycat Software. If you prefer not to receive these announcements, please reply to this message and we'll remove your name from the list. A real human being will read your reply.
Test your mailing list software before a large blast!
After I don't know how many years of using perl, l I finally decided to take 5 minutes and figure out how exception handling works, and I'm ashamed that I didn't really dig into this a long time ago. It's wonderful. Duh.
The magic eval construct does this, and it traps any perl errors that happen within, retaining control over execution. eval returns the result of its last expression, and sets the $@ variable to any error string upon failure.
In my example, I had a set of routines that had a lot of parsing to do, and if any errors happened, we could just bail and return to the caller by calling die with an error string. The eval intercepted the die and set the $@ variable to the error string.
In the main code:
while ( my $input = <STDIN> )
{
my $result = eval { parser($input) };
if ( $@ )
{
print "Error: $@ on line $.\n";
}
else
{
# process $result as usual
}
}
....
sub parser {
my $line = shift;
...
if ( failure condition )
{
die "Something broken in parser()\n";
}
...
return "result";
}
See the perl docs for full info on eval.
This morning I spent too much time tracking down a bug in my Kodak 8500 Photo Printer Ghostscript driver, and it ended up being a mismatch between the format and parameters on a printf-like function. This can normally happen to anybody, but not to me, because I always use the GNU __attribute__ mechanism to tell the compiler how to check this out, but I forgot this time. Doh!
GNU C compilers support a __attribute__ keyword that allows associating "attributes" with function declarations, and one of these tells the compiler that the function is printf-like, and it will perform substantial inspection of the parameters and format string. It's a lifesaver, and easy to set up.
Just above the printf-like function definition, I added a new declaration that included the proper __attribute__ syntax. This done, the compiler will inspect all the calls to writecmd and will let me know when I mismatch a string with an int or simply forget a parameter.
static int writecmd(FILE *ofp, const char *format, ... ) __attribute__((format(printf, 2, 3)));static int writecmd(FILE *ofp, const char *format, ... )
{
va_list args;
char buf[64];va_start(args, format);
vsprintf(buf, format, args);
va_end(args);
...
I've written up a Tech Tip on this: Using GNU C __attribute__
It seems that a Microsoft researcher has found the earliest recorded use of the smiley -- :-) -- from 1982 at Carnegie Mellon University. Article on ZDNet.
How fun!
I finally got my friend Steve Gardiner to use Yahoo! IM, but we found when using it from his office, it made him logout and back in all the time - it was getting very annoying. He figured out the problem was firewall NAT timeouts, and I've written this up in a Tech Tip to reflect how to fix it: Sonicwall access rules for Yahoo! IM
Circuit Cellar Magazine is a magazine devoted to embedded hardware design, mainly with low-end microcontrollers. It was started by my hardware hero Steve Ciarcia (of Byte Magazine fame) around 15 years ago, and I read it every month even though I haven't done any real MCU design since I was in college.
The September 2002 issue (#146) has a stunning feature article by Jim Brady: Build Your Own 8051 Web Server.
The Intel 8051 is a workhorse 8-bit microcontroller, and it's been in use for more than 20 years. Though getting a web server on an 8051 is a great feat in any case, when I read the headline I was sure that Jim had "cheated" by using one of the external networking chipsets that implements Ethernet and TCP/IP in firmware, and the main MCU talks to the network chipset over a serial connection. I read the article. No way.
He did a TCP/IP stack and web server on an eight-bit microcontroller in 22 kilobytes of codespace and 2 kilobytes of RAM. This is just spectactular. He implemented ARP, IP and TCP (no UDP), as these are all that are required for a working web server. The source code suggests that the stack handles ICMP as well, though this is not mentioned in the article.
One of the points that particularly caught my fancy was this:
Can a CPU with only 2 KB of RAM really handle large Ethernet messages and the complexities of protocols such as TCP and ARP? Surprisingly, it turns out that even a few hundred bytes would suffice. Small RAM footprints work with TCP because you can tell the other end to limit the message size. TCP can, for example, advertise a maximum segment size of only 100 bytes.
This solves a hardware problem (limited RAM) in software. I love it.
To be fair, the stack doesn’t appear to be anywhere near a full one: plenty of things look unimplemented, such as fragmentation and many of the TCP options. I note with amusement that “Respect other end's max segment size” is not implemented. I doubt that the device would fare well in a hostile environment, such as directly connected to the internet, but none of these limitations take away for the magnitude of the accomplishment: when you teach a dog to talk, you don’t worry so much about bad grammar.
The source code is quite readable and the hardware design is straightforward: just nothing about this not to like.
Jim Brady – you da man!
Even though I'm a UNIX guy, I still use Windows NT/2000 all the time - it's part of being a full-service consultant, and I do actually like it. But I'm still a command-line guy at heart, and I do most of my software development there (with vi) instead of the wimpy IDEs.
One long-standing annoyance has been to have a .ZIP or .PDF file in the current directory and have to go navigate with Explorer to open it. What a pain!
I found the way around this: the CALL command. This is normally used to launch one batch file from another, but when given the name of a file whose extension has an action associated with it, that action is launched.
So CALL FOO.PDF fires up the Adobe Acrobat reader on the file from the command line, and this apparently works for any of the file associations. The full list of assocations can be found with the assoc command, and the programs associated with an action can be found with ftype.
This has saved me a ton of time.
Yahoo! released their 5.5 version of Y! IM recently (shortly after the 5.5 beta), and it's really not ready for prime time. There are some new features that look promising, such as a much higher-res camera (and a "super" mode that streams a at much higher rate in peer-to-peer mode), but all my friends who've gone to 5.5 have downgraded for the same reasons.
The webcam support - though higher resolution - is strangely blurry, and it's annoying as hell. The additional bummer is that a 5.5 webcam can't be seen by a 5.0 user.
The most annoying for me is that the little "ZZZZ has logged on" notifications that appear in the lower right are no longer always on top. This means that if I've got my browser window maximized, I'll hear the knock-knock-knock of a friend coming online, but I have to quickly hit the Window-M sequence to minimize all my windows to see who it was. This is exceptionally irritating.
Thankfully I saved the 5.0 installer available upon request and was able to downgrade myself and my friends, but even this doesn't make Y! IM a perfect experience.
There have been longstanding problems with the Y! servers too: now and then I get logon/logoff notifications for people who are not on my buddy list, and once in a while it's for somebody I've never heard of. A friend is having the same problem. Refreshing my online friend list (with control-R) sometimes toggles friends who are online or offline, and I get logged out now and then randomly. AOL IM has never ever had these kinds of stability problems.
My final annoyance with Y! IM is that there doesn't seem to be an official channel that I can find for reporting bugs. I have the email addresses of the developers, but there is just no way you should have to "know somebody" to report problems, and I simply won't pester these people.
I would love to have a paid option that perhaps enabled some features, gave access to tech support, and disabled the ads in the webcam. For me, something like $50/year would be a no-brainer - where do I send the money?
I wish more people would support the subscription model, which is based on the bizarre notion that paying for a service is more likely to have that service stick around for a while. I'm much better served by a Y! that makes money on me than by a service that goes away due to a bad business model even if I got it for free.
I work mostly at home, so I'm in my office many hours every day, and I've had the usual parade of mediocre office chairs. They break after a couple of years, so I get another one at the local used office furniture place.
Last December I decided to get a good chair, one I had read about in an inflight magazine recently. I got a Steelcase Leap chair, and I cannot believe how much I love a chair.
It's strictly an ergo chair - not an "executive leather" status symbol - and it adjusts in places I didn't know I had places. The arms go up and down, in and out, and they pivot, and it makes for an exceptionally comfortable experience when I'm typing or mousing or other things that cause me to move around.
When I lean back, the seat actually glides forward to help keep the center of gravity over the center of the chair. There are a half dozen other adjustments that really, really just work. It's got the sturdy quality you'd expect from Steelcase, but it's stylish and not industrial-ugly.
It was expensive - about $750 - and the only mistake I made was not getting the cloth-covered armrest caps. Working in short-sleeve shirts meant that my arms were resting on plastic, and it was very uncomfortable. I ordered replacement arms, and now it's perfect.
I write this now because I have spent all weekend moving a customer from one office to another, and after many hours of moving and lifting and crawling under desks, I'm home now noting how comfortable it is to sit in this chair.
Excellent background on this chair can be found here. I bought mine at BKM in Tustin, Calif, and my sales guy (Jim Hayes) was just fantastic - even though this was just a one-chair sale, he took care of me as he would an office ordering 100.
Nothing about this whole experience not to like.
Steelcase rocks. I love my chair.
Did kasia break steve's weblog?
Let's see what the answer is..
k.
Well, my webmistress got mod_perl working on our server, so now Movable Type is much faster - wow! The old CGI version was just un-Godly slow on the dual-CPU 366Mhz Pentium Linux box, but now it's fast enough that I can fool with templates and the like.
Woo hoo!