on Amazon EC2

During a meeting today, Amazon's EC2 service popped into my head, and so I did a little extended thinking on it. I was going to research it some more, but since I didn't see the announcement of this soon enough, I don't have anything to play with anyway.

• Amazon already has a crap-load of 'users'; who doesn't have an 'amazon id'? Won't take long before they take advantage of this by allowing me as a service provider to authenticate folks via 'amazon id', allowing me to somehow charge the users of my service by cpu usage and/or bandwidth, and generally cool social networky things. Not many sites have a user base of this magnitude. Yahoo! comes to mind, perhaps google (via gmail). EBay?
• Micropayments, finally. Or at least close.
• Virtualization on servers. It'll be interesting to see how this scales.
• Real time vs space trade-offs. Most hosting companies I've seen charge you by the amount of bandwidth you use (as one of the limits on your service anyway). Here, Amazon is charging for both cpu and bandwidth. It's interesting to imagine situations, in this new fat client universe, of deciding whether I should pump excess info to my client and let them churn over it, or optimize the amount of data I send, but pay a bit more in CPU. If there's a huge cost difference, it's easy to decide which one. Maybe one provides a better end-user experience, but my users would be willing to pay for it. In the end, it will force people to deal with poorly optimized services, because they will literally paying for all the cpu they are throwing away.
• If this isn't software-as-a-service, I don't know what is.

I think the most interesting thing to me is the micropayments. And thinking about how to charge the users of my services via something like micropayments. Charging just enough so I can actually host my service without it costing me a dime, by charging just a little over what it costs me. Hell, charging a LOT over what it costs me, maybe.

But what if I don't want to be tied to Amazon, and use PayPal or Google Checkout (or whatever) instead? Tough problem, because Amazon's got all the infrastructure all ready to go for this. Including user authentication. Something like Flickr's Authentication API would be nice to have here.

the dangers of transparency

From: [nag generator at my hosting server]
Subject: Re: [Alerts] *** SECURITY information for [my hosting server] ***
Date: Fri, 8 Sep 2006 00:36:09 -0500
To: [me]

Attention: the use of sudo is restricted to staff.

Please do not use sudo in the future.

Thank you.

--  
[sig of nag generator at my hosting server]

On Sep 8, 2006, at 12:32 AM, [me] wrote:

> [my hosting server] : Sep  8 05:32:18 : [my userid] : user NOT in  
> sudoers ; TTY=ttyp0 ; PWD=[my home directory] ; USER=root ;  
> COMMAND=/usr/local/sbin/apachectl restart
>

The ssh session into my hosting server looks purty much like my local shell; I was of course trying to restart my, local, server, not my host's server.

No sandwich for me! (Thanks Josh)

Time to make my PS1 on my host a little more obvious, somehow ...

Of course, what's scary is that I use sudo (and sudo -s) a lot these days, it seems. Almost might as well be using Windows. Gotta do something about that as well ...

guitar signal chain

I'm a guitar noodler. See definition 3, and I'll emphasize the haphazard part. Although I started playing when I was 8, my big problem is I never played with a band (sorry Eric + Mark, biohaz doesn't really count). And I take frequent, multi-month breaks from guitar. But I'm back in one of my phases, and I've got a pretty good set up, so I thought I'd mention it.

I should first mention I was hoping to run everything through my MacBook, but when I tried that, the amount of set up I had to go through every time I wanted to play was just too much, plus, I don't really have room for everything in front of me, plus the chair I live out of doesn't lend itself to comfortable guitar playing.

So, I resigned myself to setting up on my wife's desktop. I bought a Line 6 TonePort UX1 about a year ago. This is a fun box, as it's basically like a traditional Line 6 Pod in it's functionality, only it's really just a USB-based D/A box; all the tone rendering is done on the computer it's connected to, but it doesn't use much CPU. The USB is nice, instead of having to rely on the line-in ports of my sound card; I'll take a USB connector over a 1/8" stereo connector any day. And the latency is basically nil. The UX1, when connected, adds another 'sound device' to windows, but only Ableton Live is listening to that device; luckily, Live actually let's you select audio devices to use instead of just using the system default, like every other program in the universe. I have some headphones always attached to the UX1 also, and the line outs of the UX1 go to an old receiver on that desk, so I can play through stereo speakers, if I'm willing to embarass myself in front of my family.

So, to play, I pull out my guitar, the guitar stand, and the cord. Then, I attach cord to guitar and then to the UX1, and either put on headphones or turn on the receiver. Then start trying to play. Probably less than a minute total. Nice.

version control for one

So I'm planning on getting off my arse and working on some small code projects I've been meaning to work on for a while. It's been so long, and so many machines ago that I've done this, that I don't have a legacy version control system that I must use, so I thought I'd look around a bit.

Actually, that's not quite correct. I was planning on using subversion. I started compiling it a few months ago, to get all the binaries lined up, and actually started using it. Well, reading the docs. Getting started, and reading the docs, means checking out the section of the Subversion book titled Choosing a Repository Layout. At least for a SVN n00b like me. Now, there's something to be said for the relatively clean nature of the SVN's tag and branch story. Quite nice, and logical, compared to CVS.

However, it kind of sucks to be in a position where you have to choose a repository layout like this out front. On one hand, I'd like to have some grand scheme in place for multiple projects, but on the other hand, structure like this usually evolves, or at least you need to have some practical experience, and I don't want to wait for either. I just want to start committing some code.

Not to mention, if I was planning on using Eclipse, I'd have to make the Subclipse vs. Subversive choice, and I have no idea which one would be a better fit for me.

Luckily for me, I won't be needing Eclipse. More on that later :-)

So, poking around at what else I might use, I ran into darcs again, and decided I'd try that for a while. Bonus, TextDrive supports it as well (on the server end).

Took me a few tries to get my initial project dir pushed to my server, and ... guess we'll see how it goes from here.

movie review: Little Miss Sunshine

movie review: Little Miss Sunshine

Sep 1, 2006 by pmuellr product

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!

0.3

This hReview brought to you by the hReview Creator.

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 product

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!

0.3

This hReview brought to you by the hReview Creator.

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.

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!

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

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.