pmuellr is Patrick Mueller

other pmuellr thangs: home page, twitter, flickr, github

Friday, September 15, 2006

I take it back

I've decided that I don't think I want closures / blocks in Java after all. Never mind.

Thursday, September 14, 2006

movie review: The Illusionist

movie review: The Illusionist

Sep 14, 2006 by pmuellr
The Illusionist

★★☆☆☆ Sandy and I were kinda looking forward to this; we both like Edward Norton and Paul Giamatti. And it started off pretty hopeful. But it was quite, quite predictable. Wait for the DVD.

If you like Giamatti, check out: The Amazing Screw-On Head.

This hReview brought to you by the hReview Creator.

Tuesday, September 12, 2006

Just when you thought it was over

I hardly expected to see a new Smalltalk come out of the woodwork, much less from Sun, but ... there ya go.

I remember hearing about Animorphic (sp?) back in the day, and I think even that Sun had bought them. Ten years ago, I guess. Wow.

Now just waiting for:

  • Intel Mac binaries
  • File-based, class-per-file sources
  • to see what the startup time is like; I want to use this as a command-line shell programming language

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.