Star Trek Rocks (spoiler free)

The new Star Trek movie is just great.  If you liked the original series, go see this.  If you liked making fun of the original series, still go see it.  Just be careful what you say to your Trekkie friends, because they might bite.

The new movie has all the old characters back, but this time with more life and before their rough edges were sanded off.  McCoy is more paranoid than ever.  Spock is more infatuated with logic than ever, yet less equipped due to being just out of college.  Scotty is crazier and drunker than ever.

Somehow they all come off as much less stiff this time around.  In the original series, you could almost see the rod going up their backs--whooooaaa, Trekkies.... take it easy.  They looked like they could put on a snappy 50s-era suit and be right at home carrying a briefcase and shaking hands.  This time, they have big gestures.  They move around.  When Scotty is needed in engineering, or Chekov is needed in the transporter room, they RUN there.  Except Spock.  He's an uptight nerd with pursed lips and a bad poker face, and it stands out wonderfully as the guy you don't want at a party.  My favorite?  The security guards are no longer polite.  You meet them as they start a bar brawl and beat the crap out of someone you like.  Later, when the stuff hits the fan, you're glad they are there.

The fight scenes are upgraded, too.  Kirk still has his signature endless haymakers--gut and face and gut and face.  The others have branched out, though.  Best is that one of them fights with a sword.  All movies should have ninjas or samurais, if not both, and now Star Trek has a futuristic samurai.

I'll admit that the movie is a rather strong cheese, difficult at times to get down.  I love that they say all their old lines, straight, but those lines have been jokes for so long that it's hard to stay in the movie when they say them.  Many scenes are way beyond believable, and you just have to go with it.  Chance encounters, gauntlets of fire, diseases with effects that aren't physically possible--they're all there, and you have to simply enjoy the cheese.

Overall, I give it a hearty thumbs up.  Go see Star Trek if you haven't already.

One cat, a chihuahua, and a turtle

After a sudden decline, our cat Einstein had to be put to sleep after fifteen years.  He had been stable but slow-moving for months.  Last week, soon after a slight change in his meds, he hit a hard enough bump in the road that he just stopped eating.

Deciding how long to give him before letting him go was an awfully hard decision.  This cat has been with Fay through multiple life phases.  We wanted to give him every chance possible, but not to draw things out and make him miserable.  We did our best.

Here he is playing with the baby cat:

Here he is concentrating on something he heard outside:

Bye bye, kittie.  Our place is emptier now.

A high-level language on the JVM

Alex Payne: I think programmers who’ve never worked with a language with pattern matching before should be prepared to have that change their perceptions about programming. I was talking to a group of mostly Mac programmers, largely Objective-C developers. I was trying to convey to them that once you start working with pattern matching, you’ll never want to use a language without it again. It’s such a common thing that a programmer does every day. I have a collection of stuff. Let me pick certain needles out of this haystack, whether its based on a class or their contents, it’s such a powerful tool. It’s so great.

Robey Pointer: I wanted to talk a bit more about starting to use Scala. It definitely wasn’t a flippant choice we made over a few beers one night. We actually agonized over it for quite a while. Maybe not agonized, but certainly discussed it for a long time. One of the biggest draws for us to Scala as opposed to another language, was that once you’d started writing in a really high level language like Ruby, it can be difficult and kind of annoying to go back to a medium level language like Java, where you have to type a lot of code to get the same effect. That was a really big draw for us. With Scala we could still write this really high level code, but be on the JVM.

That's from an Artima interview about the guys behind Twitter evaluating Scala.

It sounds about right to me.  Scala is adventuresome in the high-level features it gives you access to, e.g. pattern-matching, higher-order functions, and mixins.  However, it runs and is integrated with the JVM, so you can always use a Java library or write in low-level Java if you run into performance issues or need some API that Scala doesn't provide.

SMTP relaying from OS/X

I like to relay my laptop's mail through a personal mail relay, so that no matter where I send mail from, it has a tunnel to a mail server that can send it on to the outside world.  I previously posted the details for doing this on a Debian laptop.  Here's what I have found for an OS/X laptop.

There are two things that I have found that should be changed to use the external relay: Mail.app and Postfix. Mail.app, the built-in mail reader, can be configured through its preferences GUI.  I don't remember all the individual steps, but I remember it being straightforward.  The first time you send email, you'll be warned about an untrusted certificate.  In that dialog, you can specify both that the certificate is good for sending email through, and that the certificate is in general legitimate.

The other thing that might need modifying, depending on what you do with your laptop, is Postfix.  From some web searching, I found this page by Michael Prokop.  In short, the magic contents of /etc/postfix/main.cf are as follows:

relayhost = mail.vc-graz.ac.at
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth
smtp_sasl_security_options = noanonymous

Note that if your mail relay runs on port 26, you can put the port number on the relayhost line, like this:

relayhost = mail.vc-graz.ac.at:26

You then have to set up /etc/postfix/smtp_auth with your client password information.

Overall, it takes a few minutes to set it all up, but you end up with your laptop being able to send email from pretty much any Internet connection.  I'm posting it here in case anyone else finds it convenient.

Ivan Krstic on security-friendly languages

Ivan Krstic writes:

Now, while I’m already grossly overgeneralizing, I think the first group is almost useless, the second group is almost irrelevant, and the third group is absolutely horrible at explaining what the hell they’re talking about.

He and the commenters then give some good introductory links.

Installing top-level code with JavaScript's eval

JavaScript is wonderfully dynamic, so it is odd that its eval function is so unportable.  I already knew that it was tricky if not impossible to use eval to install code in an arbitrary nested scope.  Today I learned that even the simple case of installing code into the global scope is different on each browser. Here's what I found after some digging around on the web and some experimentation.

First, there are a lot of web pages discussing this topic.  Here's one of the first ones I read, that tipped me off that there is a well-known problem:

http://piecesofrakesh.blogspot.com/2008/10/understanding-eval-scope-spoiler-its.html

The following page also discusses the problem, but has a really good collection of comments:

http://dean.edwards.name/weblog/2006/11/sandbox/

UPDATE: Prototype has gone through the same issue, and come up with similar conclusions as mine.  Here is a page with all the bike shedding:

http://prototype.lighthouseapp.com/projects/8886/tickets/433-provide-an-eval-that-works-in-global-scope

Based on reading these and on tinkering on different web browsers, here are some techniques that look interesting:

1. window.eval, what I tried to begin with
2. window.eval, but with a with() clause around it.  Some people report better luck this way.
3. window.execScript, a variant of window.eval
4. window.setTimeout
5. adding a script tag to the document
   

What I did in each case was try to use the technique to define a function foo() at the global scope, and then try to call it.  I tested these browsers, which I happen to have handy:

1. Safari/Mac 3.1.1
2. Firefox/Mac 3.0.6
3. Firefox/Linux 2.0.0.20
4. Firefox/Windows 3.0.3
5. IE 6.0.2900.xpsp_sp3_gdr.080814-1236 updated to SP3
6. Chrome 1.0.154.48

Here are the browsers where each technique works.  I lump together the Firefoxes because they turn out to behave the same on all platforms:

1. window.eval: FF
2. window.eval with with: FF
3. window.execScript: IE, Chrome
4. window.setTimeout: Chrome, FF, Safari
5. script tag: IE, Chrome, FF, Safari

Conclusions

1. The window.execScript function is available on IE and Chrome, and when present it does the right thing.
2. The window.eval function only works as desired on Firefox.
3. Adding a with(window) around the window.eval does make a difference, but I couldn't get it to do precisely what is needed for GWT.  In particular, GWT does not have a bunch of "var func1,func2, func3" declarations up front, but such vars are assumed in some of the other web pages I read.
4. I could not find a synchronous solution for Safari.  Instead, setTimeout and script tags work, but they won't load the code until a few milliseconds have gone by.
5. Script tags work on all browsers.
6. Surprisingly, I couldn't get setTimeout to work on IE.  From some web browsing, it looks like the setTimeout callback might run in the wrong scope, but I didn't investigate far.  On IE, execScript is a better solution for the present problem.

Based on these, the following chunk of code is one portable way to install code on any of the major browsers.  It uses execScript if it's available, and otherwise it adds a script tag.

if (window.execScript) {

  window.execScript(script)

} else {

  var tag = document.createElement("script")

  tag.type = "text/javascript"

  tag.text = script

  document.getElementsByTagName("head").item(0).appendChild(tag)

}

The Code

Here is the code for the above examples, for anyone who wants to know the details and/or to try it for themselves.

The wrapper script is as follows:

function installFoo() {

  var script = "function foo() { alert('hi') }"

  // varying part

}

installFoo()

window.foo()

For the versions that install the code asynchronously (setTimeout or script tags), I changed the window.foo() line to be:

window.setTimeout(function() { window.foo() }, 100)

The "varying part" is as follows for each way to load the code.  Note that some of them include a gratuitous reassignment of window to $w; that's how I first ran the test and I don't want to go back and redo all of those.

// window.eval

window.eval(script)

// window.execScript

window.execScript(script)

// window.eval with a with

var $w = window

with($w) { $w.eval(script) }

// setTimeout

window.setTimeout(script, 0)

// script tag

var tag = document.createElement("script")

tag.type = "text/javascript"

tag.text = script

document.getElementsByTagName("head").item(0).appendChild(tag)

Why not inject dependencies "manually"?

I just read the first half of the Guice User's Guide.  I stopped there because the motivation already left me hanging, and the very first feature I saw seems at odds with dependency injection.

I agree with the general sentiment of the user's guide: don't use new so much, and don't even use static factories.  Instead, "inject"  a class's dependencies via constructor parameters.  That way, the class is abstracted over both the service implementation as well as from where the service comes from.  This style of programming is already emphasized in at least the Joe-E and Scala communities.  I like it.  OO designers like it.  PL developers like it.

However, I don't understand the difficulty in doing this "manually".  The guide gives this lovely example of substituting a mock service in a test case:

public void testClient() {
  MockService mock = new MockService();
  Client client = new Client(mock);
  client.go();
  assertTrue(mock.isGone());

}

So far so good.  Here we see the payoff of moving the new ServiceImpl() out of Client is that the constructor of a Client can instantiate the service in an unusual way.  Where I get lost is in the instantiation of the normal production version of the client.  The manual gives this code sample:

public static class ClientFactory {
  private ClientFactory() {}
  public static Client getInstance() {
    Service service = ServiceFactory.getInstance();
    return new Client(service);
  }
}

Where did these two factories come from?  I find them odd, because one of the beauties to me of dependency injection is that it composes well.  In most cases, the production version would know exactly which concrete client and service to instantiate.  In the remaining cases, the code assembling them should itself have parameters influencing how to construct things.  Percolating this idea to the top level of the application, the parameters to the top-level application factory would be precisely those things configurable via configuration files and command-line arguments.

So far my experience matches this intuition.  The Scala compiler is implemented in a dependency-injection style.  Almost all modules find out about their dependencies by having a reference to the dependency passed in at construction time.  The Scala group has not taken advantage of this with testing mocks, even though that would seem straightforward.  However, I can attest that it was straightforward to reassemble the components to make an X10 variant of the compiler.

Overall, I believe that dependency injection is a good style.  However, I have not yet seen an example where it leads to extraneous code.  At least, the example in the guide isn't very good.  Further, the one tool feature I managed to read before being turned away by motivation was the ability to designate a "default" implementation of an interface.  Isn't this a temptation, though, not to use a dependency-injection style?  I would think if you are injecting dependencies, then any code constructing an implementation would already know enough to choose which one to construct.

Probably there is a breakdown somewhere in this argument.  Tools get popular for a reason.  At the least, though, the counter-argument is not documented in any easily findable place.