Links

pmuellr is Patrick Mueller, an IBMer doing dev advocate stuff for node.js on BlueMix.

other pmuellr thangs: muellerware.org, twitter.com/pmuellr

Saturday, September 02, 2006

movie review: Little Miss Sunshine

movie review: Little Miss Sunshine

Sep 1, 2006 by pmuellr
Little Miss Sunshine

★★★★★ 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.

Friday, September 01, 2006

Movie Reviews

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.

movie review: Snakes on a Plane

Sep 1, 2006 by Patrick Mueller photo of 'Snakes on a Plane'
Snakes on a Plane

★★☆☆☆ 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.

Thursday, August 31, 2006

Scripting Languages in Java

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:

  • If you're expecting to call into existing Java classes from your scripting language, one thing your likely going to miss in your scripting IDE are things like code completion. Assuming you even have code completion for your scripting language (hard task without easily obtained string typing information that Java has), it's highly unlikely that you'd get code completion when you are calling out to Java. Which is where you really need it. I found that without code completion, trying to talk to existing Java code, I had to leave a JavaDoc browser open, and was sometimes cutting/pasting stuff between that and the editor.
  • There are a few language level mis-matches. I know Jython and Rhino had/have issues with Java arrays. Any time you needed a Java array, to pass into some existing API, there was some kind of little piece of poop you had to run. Was quite unnatural.
  • Environments can be unfriendly to the limitations of scripting. I've tried a couple of times to do some scripting of Eclipse, in the plugin sense, and Eclipse just doesn't make this easy. Expects you to have classes all over the place, based on gunk in .xml files, and without pre-compiling my scripts into Java, I was going to have to have at least some small Java stubs just to have someone for Eclipse to talk to, and then the stub could invoke the script.
  • Debugging. argghhh
  • Reload and run. Typically when you're scripting, it's not just that you don't have a compile step, but you also have a very short test restart cycle. For JavaScript in a browser, typically you're talking about F5, and then maybe some work to get you into a testing state. In Smalltalk, we'd just change the code, run the test again. In Eclipse, writing plugins, you have to launch a new workspace, debug away, and then generally have to bring the workspace down before making significant code changes. Hot code replace in Java is definitely sweet, but it can't tolerate class shape changes, and those happen far too often.
  • I've often thought of all the languages Groovy was probably going to be the easiest to use simply because it had no non-Java version it ever had to live up to. And had first class notions of dealing with Java.

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.

Wednesday, August 30, 2006

hosting providers ... it's the little things

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.

  • ssl-protected IMAP / SMTP
  • python
  • ruby
  • php 5
  • svn

Let the web app hacking begin!

Tuesday, August 29, 2006

Unix Power Tools circa 1993

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:

  • There are no references to Linux, anywhere. Nor BSD (by itself). A CD of utilities is provided with the book, with precompiled binaries for "seven of the most common Unix platforms":
    • Sun4 SunOS 4.1.1
    • Sun3 SunOS 4.1.1 (is Sun3 vs Sun4 a hardware statement?)
    • DEC Ultrix 4.1
    • IBM AIX 3.2
    • HP-UX 8.07 (what a big version number!)
    • SCO XENIX 2.3.2 (shudder)
    • SCO UNIX 3.2.x
  • For word processing, use nroff / groff
  • For version control, use sccs or rcs (aside: I have a funny story about Walter Tichy, a prof of mine at Purdue, who wrote RCS; it will cost you one measily beer to hear it!)
  • "A summary of common UNIX networking and communications utilities:
    • The Internet (I will spare you the description)
    • mail
    • ftp
    • uucp
    • telnet
    • other usual stuff rlogin, rcp, rsh, NFS
  • Number of pages describing these common UNIX networking and communications utilities: 1
  • Number of pages spent on vi: 52
  • Number of pages spent on emacs: 14
  • Number of pages spent on awk: 36
  • Number of pages spent on perl: 10

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).

Monday, August 28, 2006

Programmable Text Editors

I have to admit that I'm a sucker for programmable text editors.

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.