★★★★★ Sandy and I saw this two weeks ago. Loved it. It's funny, serious, sad, but mostly fun. Especially the end. And I'm a sucker for Alan Arkin.
We saw it at the Galaxy in Cary, which is a great place to see movies; they serve beer and wine, and excellent popcorn. Please patronize so we have a decent alternative to the mega-plexes!
This hReview brought to you by the hReview Creator.
Sandy and I have been going out on 'dates' almost every week since the kids were really small. A slight respite from the madness of a teen and pre-teen. We often take in a movie, if there's anything we really want to see, and there often is.
I've been meaning to do reviews, but never really got a round tuit, and just ran into another reference to hReview, so I figured it was time to take the plunge. I created this review with the hReview creator, which is a nuts&bots JS app to build the microformat as I type in the HTML form, suitable for pasting into something like a blog.
So, here goes; I'll probably frig with my template to add some more css styles to try to make it purty.
★★☆☆☆ I was quite prepared to review this movie as a good "bad movie", but it either wasn't bad enough, or was too bad, not sure which. I was certainly wincing at the end with the video of the band.
There were definitely some stupid and therefore funny scenes. Over the top funny. Places where people got bit. The speed at which people died.
And Sandy and I even both flinched at one scene, which rarely happens to me in movies.
Expected something ... better or worse, but it didn't quite cut it for me. Maybe the sequel will be worse!
This hReview brought to you by the hReview Creator.
Joe Gregorio has a nice, short article describing Python coolio stuff to Java programmers; Dave Johnson responds with some links to scripting languages implemented in Java that can do the stuff that Joe talked about, so you can have your cake and compile Java too!
Joe's article is great, will definitely have to keep that link handy, especially now that I gotta new job assignment involving scripting.
So I've actually played with some of these scripting languages in Java, and was even on the Groovy JSR Expert Group for a short time (a funny story why I left, that will cost you a measily beer). Note my most recent experiences were with Rhino playing with Eclipse Monkey. Some observations:
I really, really wanted to use scripting in some, I thought, fairly obvious places, but it's always ended up just not working out for me. What a bummer.
If I still thought there was hope for scripting Eclipse, I'd definitely check out Aptana, based on Bjorn Freeman-Benson's glowing descriptions. Instead, I'm going to try living out of TextMate for a while ...
BTW, Tim Bray has an interesting set of blog posts on his experiences with JRuby.
I recently decided to finally dump my membership with the Association of Computing Machines and do something interesting with what I was paying for dues. I decided to finally get an external hosting site. Ever since I've had broadband, I've been running an HTTPD out of my house, serving up various vhosts for myself, the kid's sports teams, neighborhood stuff, the PTA, etc. I thought it'd be fun to do a little less management for a change.
I didn't look real hard; I had already been eyeing TextDrive for a while, and also Yahoo!. I decided on TextDrive. I won't go into details, but some the reasons I like it are things that most people probably don't care about.
Let the web app hacking begin!
So as I was reading some of the textmate manual last night, I happened to think ... 'I really don't know the bash shell scripting language at all!'. And that I really should make an effort. Since I use it everywhere (except Windows, but I try not to use Windows). So I went looking through my bookshelf ... have I ever bought a book on shell programming? Like Bill, I suffer from a problem of buying too many books. * I figured I probably had bought one at one point. And sure enough, I found a book on the Korn shell book from O'Reilly. But I didn't want to try to figure out what the difference between the Korn shell and Bash were. So I kept looking.
And then I found some buried treasure. "Unix Power Tools", First Edition published by O'Reilly in 1993. Huge book. 1100 pages. No longer in print, but here's the modern version. What's so cool about this book is the peek it gives us on what the 'unix' world was like back then. Here are some reminders:
No Linux, no BSD, no python or php. No web, no http. Not even gopher. No ssh.
My god ... the dark ages.
It's easy to poke fun at some of this, but honestly, the book still has some value. Chapters on find, sed, etc, that I'm sure I'll read again some day, and understand the tool for a short while before forgetting again. How often has find really changed in 13 years, anyway?
It also has the traditional huge O'Reilly index, which is nice. And the chapters are split into sections, and both the page number, chapter number, section number are on ALL the pages. If there's one thing I hate, it's books that use numbered sections, they do intra-book linkages using the section numbers, but the pages don't have the section numbers.
So I think I'll keep it rather than sell it at our next yard sale, or otherwise dispose of it. And leave it sitting around for a while to read up on find again.
* psss ... if you suffer this debilitating book buying disease, here's at least one step you can take; stop buying non-technical books and use your local library for those, assuming you have one. And look into BookMooch (on my list of things to do).
My illness began back in the early 80's when I was a co-op at IBM, working on an IBM mainframe. We used XEDIT as our text editor. XEDIT had a 'macro' language, which happened to be the same 'macro' language used by the shell, REXX. Our application program was written in REXX, so once you knew how to program it, and figured out the trivial interface to writing macros for XEDIT, you could really make that sucker fly. In fact, most of the interesting GUI programs that ran on VM/CMS at the time were implemented with XEDIT as the GUI interface.
One of the first programs I bought for the first computer I bought, a PCjr, was Manfield's KEDIT, pretty much a complete clone of XEDIT, along with a pretty decent implementation of REXX. (Also had Turbo Pascal and Smalltalk/V running on that puny thing).
Fast forward a few years and I found myself in the IBM Cary Regency lab (aka "The Country Club") working on a text editor for IBM. That never saw the light of day. Except as the GUI engine behind my graphical rexx debugger RxD. My job on the editor team was to expose the functionality of the editor in REXX. You could write macros in C, but who wants to do that.
Fast forward a couple of years and while working on something where I was on AIX all the time, I spent the time to learn Emacs and even write some macros.
Fast forward a couple of years and while working on Smalltalk I found a few hook points in the ETWindow hierarchy so I could customize the basic text editor. Since the one provided was quite bare-bones. Customize it with Smalltalk, of course.
Things have never been quite the same since. I still use KEDIT to this day, for certain tasks, on Win32. But more often than that I'm in Crimson Editor. Pretty much stick to vi on Linux (my arm position when I'm couch coding doesn't lend itself to all the ctrl/alt/shift madness of Emacs). On my mac, where I spend most of my time, I use BBEDIT. And for anything half-way serious I'm usually in Eclipse.
One of the common denominators for these environments (save KEDIT) is that they aren't programmable. Or, at least, easily programmable. Nothing like writing macros in REXX, Lisp, or Smalltalk anyway.
So, I was quite excited when reading the manual for TextMate, that they have a macro programming capability built in. And the language is ... anything you want. Basically, shell scripts; so stick a #!/usr/bin/env ruby at the top of your macro and write it in ruby. They even support back-tick 'include the output of this command' in the code templating system.
I got a new toy.
My buddy Todd Lothery's movie, A Reel Man, is making the rounds. Here's a short blurb I pulled from the Indianapolis International Film Festival:
A Reel Man is a profile of Skip Elsheimer, a Raleigh, North Carolina resident who collects educational films. Skip started collecting these 16mm films many years ago, and he now has almost 17,000. His archive includes films from the 1940s, ‘50s, ‘60s, ‘70s and ‘80s on every conceivable instructional topic – sex education, personal hygiene, public safety, driver’s ed, occupational training, the dangers of drugs and alcohol, how to be popular, etc. The films in Skip’s archive are campy, amusing and not a little propagandistic, but they’re also valuable, fascinating time capsules that reflect America’s social attitudes and cultural values throughout the last half-century.
A Reel Man appears to also have been shown on a public tv network in South Carolina.
I saw A Reel Man as Todd's project at the Center for Documentary Studies at Duke, where he honed his craft. The movie had it's first public showing at the Asheville Film Festival.
Cool.
For Raleigh-ites, you may remember Todd as a movie reviewer for the News and Observer a few years back. He and his wife Kay Wiles headed back home to Indy to be closer to family. We miss 'em!
Also for Raleigh-ites, Skip's A/V Geeks web site has a list of events where he'll be showing his movies, including free showings fairly often at the NC Museum of Natural Sciences.
For everyone, A/V Geeks has lots of stuff available for purchase, and some downloadable movies.
I gotta get Todd to upload his movie to YouTube after it makes the rounds.
My love affair with JSON is over. I'm going to outline the problems I've got with it, and then also reiterate some of the things I do still like about it.
So, like I said, this is a weak point, since as Crockford himself says, JSON parsers and generators are easy to write. It's just ... a shame.
Unfortunately, for my purposes, this isn't good enough. The objects I'm dealing with right now at work are actually classically designed object-oriented instances of classes. That can be subclassed. JSON has no built-in way to indicate the actual type of the object, just the properties on the object. Every object is 'anonymous'. Or again, just a hash table.
You can kind of fix this by including a type name as a property of the object, but this is a bit of a hack. And it's non-standard. And if you actually looked at some of the stuff we were JSON-ing, you'd realize that you'd really like to have something like XML namespaces to help cut down on string duplication, if your type names are long (ie, they include an XML namespace, package, module name). That's hard to fix.
XML on the other hand, does a pretty good job of this. Type names can end up becoming actual element names, using namespaces to end up with a short form of the longer, universally unique class name. With the long name declared up front, kinda like a Java import statement. Nice.
Instead of using eval(), you should really use some code which actually parses up the JSON text. Like every other language does. But, you gotta wonder, what's faster, a JSON parser written in JavaScript, or the existing DOM engines to parse XML? My bet's on the DOM engines. Complete guess. But even if for some reason a JSON parser was faster than XML, it still means you have to carry around this wad of JS code to parse JSON for your pages. Baggage.
So, what do I still like about it?
Great post over at Hacknot about debugging: "Debugging 101". I've been doing this crap for 20 years, so it's not like any of this is new, but it's certainly interesting to see it all written down in one place, and even though I've done it all, I don't neccessarily remember it every time :-)
A couple of highlights/issues:
Wooden Indian: I can't remember how many times over the last decade or so I've done this with Tim Wolf, and him with me, back when I was working at the OTI building in Raleigh. It just always seemed to be so funny to be describing a problem to him, when he really had no idea what I was working on in general, and just a few interesting questions from him, and the lightbulbs start going off in my head. And vice versa. And of course, asking lots of questions is an important way for junior folk to learn from their elders. Hint: I know I ramble; don't be afraid to call me on this.
Avoid Debuggers: I take issue with this. To me, that's like saying don't use them fancy compilers; they're just a crutch; you should write all your code in ASM! Perhaps learning to use a debugger properly is the key. Here are two of Mr. Ed's points:
It's not like adding code to the problem isn't going to cause it's own problems; not that it always does, but it sometimes does; and unless it's actually logging code you're adding, you're going to have to remove/comment out/neuter that trace code before you back into your team repository (or production). Which you will someday forget to do.
In fact, I frequently debug exactly like the tracing description; add breakpoints to help narrow down the interesting points where I want to watch what's happening.
That's just silly. It's a tool. Not a magic eight ball. Folks who wait for the debugger to show them the problem quickly stop using debuggers, since debuggers don't do this.
It's not like a nice 'graphical' debugger will save your ass every time. There are plenty of other things that you will sometimes need to do (read the article!). But I'd be screwed if I couldn't use a nice debugger like Eclipse's Java debugger for debugging the incredibly complicated Java code that I live in. In fact, I typically do my 'launches' under debug mode; bonus with Eclipse (at least when using a J9 VM, not sure about the Sun VM) is you get tasty hot code replace when you run under debug.
I have a long history with 'graphical' debuggers. When I started my IBM career I was doing CICS application programming in PL/I. The debugger the system shipped with, CEDF, would only pause before and just after your system or database calls. You couldn't step through your code at all. Even see it. Shortly before I moved onto my next job, we got a trial usage of a product called Intertest (which appears to still be around). Oh. My. God. Stepping through code, a line at a time. Inspecting local variables. It was like freaking magic. It costs an arm and a leg, but I managed to convince the folks on site that we absolutely needed this.
Later, when I was one of those OS/2 hippies, I wrote RxD, which I think was using the coolio text editor control that was the day job. That was fun. Nothing like actually writing a debugger.
In Smalltalk, it was fairly easy to hook into the debug system, so I did some whacky stuff like audio break points; set a .wav file to play when a statement was hit. Nothing like listening to your code 'play'.
Man, am I old, and a geek.
Got some sad news this weekend. Kim Clohessy passed away. Mike Milinkovich also covered this today. +1 on everything said there.
I first met Kim when I went on assignment from IBM to OTI in 1997. I had specifically started working with the embedded software group in Phoenix, and Kim was one of the technical/executive leads there. Kim was one of those great executive and technical guys; worked great in front of customers selling our stuff, but he also knew our stuff. Hell, he helped invent it! But you know, there just aren't enough folks like that.
Kim is actually the only person I personally know who wrote a practical app for Palm with the J9 VM, which was our baby back then; some kind of farm/ranch management tool for his horses, IIRC. He was obviously proud of it, I remember him mentioning it more than once. Of course, he deserved to brag, J9 on the Palm wasn't the easiest thing to work with in early days. You pretty much had to be a rocket scientist.
The picture on Mike's blog is a great picture to remember Kim by; smiling like he usually did.
Later, dude.
