1. Your .pem file is an RSA private key. You need to generate an RSA public key from it. On Mac OS X, I did this by typing “ssh-keygen -y > foo.pub” and entering foo.pem when prompted for the key file.
2. Make a copy of your foo.pem file to get rid of the extension. Now you have “foo” as the private key and “foo.pub” as the public key.
3. If Prompt is running on your iPhone, do a hard exit (show the iPhone app switcher UI, long-press the Prompt icon to show the delete adornment).
4. Connect the iPhone to your computer
5. In iTunes, use File Sharing to transfer first foo.pub, then foo.

First, a little background: There’s a programming language called R that is taking the world of statistical computing and data analysis by storm. If you’ve never heard of R, you can read more about it in this New York Times article. But the gist of it is:

“R is really important to the point that it’s hard to overvalue it,” said Daryl Pregibon, a research scientist at Google, which uses the software widely. “It allows statisticians to do very intricate and complicated analyses without knowing the blood and guts of computing systems.”

We’re trying to make R a better language by giving it a better IDE. It’s called RStudio. It’s free as in beer, and free as in speech. You can download it today, or even peruse the source.

We designed RStudio from the ground up to make working with R easier and more productive. It brings your R console, source code, plots, help, history, and workspace browser into one cohesive package. We’ve added some neat productivity features like a searchable endless command history, function/symbol completion, data import dialog with preview, one-click Sweave compile, and more. Many experienced R users have told us that even at this early stage, RStudio is the R IDE that works best for them.

What’s really unique about RStudio, though, is that it can run equally well as a desktop program or as a web application.

What does it mean to run an IDE as a web application? Take a look: Here’s a screenshot of RStudio running in Google Chrome on Windows 7. As you can see, it’s a full IDE—it just happens to be in a browser.

The server I’m using is an 8-proc Ubuntu server with 68.4GB of RAM (it happens to be on EC2). When you run RStudio this way, it’s always the server’s computing resources—CPU, RAM, hard drive—that are being used by R.

Why is this interesting? It turns out that a lot of serious R users share a big, powerful Linux box or cluster with their colleagues. They write their R code on their own desktop or laptop, and execute it on the big server. There’s definitely a lot of friction in this workflow. With RStudio, a lot of the friction goes away because you can do your exploring and iterating directly on the big iron.

If you’re an R user, try it out and let us know what you think!

Since leaving Microsoft in September, I’ve been working almost exclusively with Google Web Toolkit (GWT). Now that I have spent some time with it, I think it’s one of the most exciting advances in web development in years.

I came up with a (possibly) novel way to abstract the code splitting facilities in GWT 2.0 and will try to share it as best I can in this post. (Thanks to my boss, JJ Allaire, for letting me share this code!)

Warning: This post assumes the reader is very familiar with GWT and code splitting, and the ideal reader will have already tried and failed to find a nice way to reuse code split logic. Seriously though, you’ve been warned!

The Problem: Reusing Code Splitting Logic

GWT 2.0 provides a mechanism for splitting your codebase so that some of your code and resources can be loaded on-demand rather than at page load.

The official GWT site recommends the Async Provider pattern as a way to split up your codebase. This is a great start, but you need an excessive amount of boilerplate for each module. Plus, callers now have to use a pretty tortured anonymous class based syntax to get at the API.

Because GWT effectively introduces one split point for each time GWT.runAsync appears in the program source, it’s not obvious how to get around cutting-and-pasting all of this boilerplate.

The Solution: Deferred Binding

Fortunately, GWT gives us the tools we need to get out of this mess. We’ll build on top of the same pattern, but use deferred binding (via my library) to generate the boilerplate at build time.

Terms of Use

I wrote this on company time but thanks to my benevolent employer, the source code and binaries in the library asyncshim.jar are public domain. But use at your own risk.

Prequisites

This library depends on Google Gin. You don’t have to actually use Gin within your project for it to work, but it won’t compile unless gin.jar is in the classpath. Really, though, if your GWT project is big enough to need code splitting, it is big enough to need Gin.

Installing the Library

Download asyncshim.jar and add it to your project’s classpath. Then add the following line to your project’s .gwt.xml file:

<inherits name="com.joecheng.asyncshim.AsyncShim" />

Getting Started

Now that you’ve got the library loaded and inherited, it’s time to remove some boilerplate. Here’s the example module from the Async Provider documentation:

public class Module {
  // public APIs
  public void doSomething() { /* ... */ }
  public void somethingElse() { /*  ... */ }

  // the module instance; instantiate it behind a runAsync
  private static Module instance = null;

  // A callback for using the module instance once it's loaded
  public interface ModuleClient {
    void onSuccess(Module instance);
    vaid onUnavailable();
  }

  /**
   *  Access the module's instance.  The callback
   *  runs asynchronously, once the necessary
   *  code has downloaded.
   */
  public static void createAsync(final ModuleClient client) {
    GWT.runAsync(new RunAsyncCallback() {
      public void onFailure(Throwable err) {
        client.onUnavailable();
      }

      public void onSuccess() {
        if (instance == null) {
          instance = new Module();
        }
        client.onSuccess(instance);
      }
    });
  }
}

We’ll start by deleting all the boilerplate, leaving behind only the public APIs:

public class Module {
  // public APIs
  public void doSomething() { /* ... */ }
  public void somethingElse() { /*  ... */ }
}

It’s worth nothing that “Module” can be almost any kind of class—it doesn’t need to extend or implement anything in particular. It can be a widget, a class from the JRE or GWT framework, etc. It can have lots of methods (even public ones) that you don’t want to be part of the public API. And in case it wasn’t obvious, it definitely doesn’t need to be called “Module”. All this is to say, if you haven’t been following the Async Provider pattern, hopefully there is still a class that’s already in your codebase that you can point to and say, “Yes, this is the perfect module thing for split point A”.

Next, introduce a new abstract class (it can be inner static if you want) that subclasses AsyncShim and specializes it to Module. Add abstract versions of the public API methods. And finally, create a singleton instance of it, using GWT.create.

public abstract class ModuleShim extends AsyncShim<Module> {
  public abstract void doSomething();
  public abstract void somethingElse();
}

Pretty simple. Now all your callers just need to get their hands on ModuleShim instead, and once they do, they can simply call the public API methods on it instead of directly on a Module instance. The first time a public API method is called, it will cause the split point code to load (if it’s not loaded already), an instance of Module to be instantiated, and the corresponding method on the new Module instance will be called. (On subsequent API method calls, the existing instance of Module will be reused.)

To create/initialize instances of ModuleShim, you have two options.

If the Module is Gin-injectable then just use Gin to inject ModuleShim. Done.

Otherwise, use GWT.create(ModuleShim.class) to get an instance of ModuleShim, then call the ModuleShim.initialize(Provider<Module>) method. The Provider<Module> can be as simple as an anonymous class that does “new Module()” (although if that’s all you were going to do, you could’ve just used Gin). You must ensure that initialize is called before ModuleShim is first used—otherwise the public API will fail, as no instance of Module will be available.

Slightly More Realistic Example

Here’s the Module-like class, the one we want to use as the locus of our split point. It’s a dialog box. There’s lots of code, but we’re not introducing any new methods that are going to go into the public API (though we could if we wanted to, mind).

public class ComposeMessageDialog extends DialogBox {

  @Inject
  public ComposeMessageDialog(Server server) {
    // whatever...
  }

  // lots and lots of code...
}

Here’s the shim we’re wrapping around it. Any code that could load before the split point should go through this shim and its public API. (Notice how one of the methods we’ve chosen to put in the public API takes a PositionCallback?)

public class ComposeMessageDialogShim
    extends AsyncShim {

  // Public APIs. These are from DialogBox, actually.
  public abstract void show();
  public abstract void setPopupPositionAndShow(
                         PopupPanel.PositionCallback callback);
  public abstract void hide();
  public abstract void hide(boolean autoClosed);

  // See below to learn about onDelayLoadFailure  @Override
  protected void onDelayLoadFailure(Throwable reason) {
    Window.alert("Error: " + reason.getMessage());
  }
}

And finally, here’s the constructor for a ButtonPanel class—it’s part of the main UI of our app (i.e. will load before the split point) and goes through the shim.

@Inject
public ButtonPanel(ComposeMessageDialogShim shim) {
  Button compose = new Button("Compose", new ClickHandler() {
    public void onClick(ClickEvent event) {
      shim.show();
    }
  });
  Button cancel = new Button("Cancel Compose", new ClickHandler() {
    public void onClick(ClickEvent event) {
      shim.hide();
    }
  });
  // ...
}

That’s all there is to it.

Going (Slightly) Deeper

Well, maybe not all. Your AsyncShim subclasses, e.g. ModuleShim, have some additional features besides loading Module and delegating calls to it.

Success/Failure Callbacks

You can override AsyncShim.onDelayLoadSuccess(T) and onDelayLoadFailure(Throwable).

onDelayLoadFailure will be called if GWT fails to download the code for this split point.

onDelayLoadSuccess is called after the shimmed type (e.g. Module) is successfully instantiated, with the new instance passed as a parameter. This is a handy place to finish whatever initialization needs to be finished before any of the public API methods actually fire. For example, if your Module is actually a Widget then you can have this method add the newly created Widget to the Panel where it should appear.

Prefetching

Prefetching is easy: just call forceLoad(true, null) on your shim. (See the source comments for an explanation of the arguments.)

Inheritance

If you have a bunch of code that you want to reuse between your different Shim subclasses (different split points), for example to have common error handling code, you can create a common Shim base class with common logic for onDelayLoadSuccess and/or onDelayLoadFailure. Inheritance should work as it normally does. Any public abstract void methods that appear in the inheritance hierarchy will become part of the public API (and you’ll get a compile error if the compiler doesn’t like the results).

Limitations

The shim causes public API methods to be executed asynchronously. As a result, all public API methods must return void. If callers need access to the result of a computation, then design your public API method to take a callback as a parameter (which is perfectly cromulent—public API methods absolutely can have parameters!).

Also, multiple calls to the public API methods are not guaranteed to be executed in the order they were called (i.e. no FIFO guarantee). This wouldn’t be hard to add, I just haven’t gotten around to it yet.

Hope That Helps…?

To be honest, it’s been harder to try to explain this library than to actually implement it in the first place. If you’re just not getting it from my explanation but like the idea of clean, reusable GWT.runAsync, drop me a comment below or on Twitter (I’m @jcheng).

For the last three and a half years, it’s been my distinct pleasure to be part of the Windows Live Writer team. It’s been deeply satisfying to help ship this simple yet sophisticated program that has put a smile on so many bloggers’ faces. From our first public beta, we’ve had nothing but love from the blogging community, and I can’t tell you how awesome that feels.

So it’s with decidedly mixed emotions that I’m moving on from Microsoft and Windows Live Writer. My last day is this Friday, 9/11/2009.

Thank you to all the colleagues, partners, and especially users who have made the last few years so exciting and rewarding. It’s been an amazing experience for me, and I’ll always be proud of what we accomplished.

Next for me will be another stint working for JJ Allaire. I’ll be working from home, which will be something new for me. No details to share about the project for a while, except to say that it will be something totally different (nothing to do with blogging, sorry).

I couldn’t have been happier as a developer on Writer. There’s something simple and pure about creating features, fixing bugs, and solving customer problems. A good day meant that when I went home, Writer did something cool that it didn’t do when I had arrived in the morning.

Being a lead, so far, has been anything but simple, even though I’m only managing two developers. I’m finding it much harder to measure my contribution or to even know what’s the most important thing to work on at any given moment. “Time management” for me used to mean making sure I don’t spend too much time on YouTube or TechMeme. Now it means having 12 hours a day worth of work each day I could be doing, and deciding what subset of it I’m actually going to spend time on. It means deciding which of the three meetings I have scheduled for 1PM I will actually go to. All the while knowing that things I’m leaving undone, and the meetings that I’m deciding are not as important, all have the potential to bite me in the back down the road.

And that work, and those meetings, are not always clear and simple like building a feature or fixing a bug. I spend a lot of time these days just “getting on the same page” as people. Having arguments without reaching clear resolution. Planning to plan. How do you measure whether you’ve been successful at these kind of things? How do you determine the impact on the product, on your users?

Messy.

That all being said, I’m glad to have this opportunity. Going up the steep part of any learning curve is by definition both challenging and rewarding. To be honest, it’s been a while since I’ve hit any really steep learning curves as a developer. And even after this short time, I’m starting to get comfortable in the role and learn how to find real satisfaction in what I’m doing.

Over the past few months I’ve gotten some great management advice from some great managers. I’ve also had some thoughts percolating for some time, that being a lead has helped crystallize. I hope to blog as I learn, partly to give some food for thought for other new managers out there, but mostly as a journal I can look back on after a few years, and wonder at how naïve I was.

Ack. We’ve had a few users report that they’re getting into a state where Windows Live Writer 2009 can no longer start. They see the splash screen, then an error, then nothing.

We’re getting ready to ship an update that fixes the problem, but in the meantime, there is a straightforward workaround to get Writer running again:

1. Start | Run
2. On Vista, enter this command:
   %AppData%\Windows Live Writer\Keywords
   On XP, enter this command:
   %UserProfile%\Application Data\Windows Live Writer\Keywords
3. You should see a bunch of files whose names begin with “keyword” and end with lots of letters and numbers. Delete all of these files.

That should fix it.

The problem, as you may have guessed, is that one of these files is getting corrupted. This is due to a race condition in our code where the settings file can be closed while it’s still in the middle of being written. Our update will both fix the race condition, and also deal more gracefully with corrupted settings files (by ignoring them).

Fortunately, these files merely contain a copy of tags that are also stored on your server. After you delete these files, you may find that our server-side tagging feature no longer suggests tags to you. You can get your tags back by hitting the little refresh button (two arrows chasing each other) right inside the “Set tags” textbox.

However, if you prefer a different URL shortening service, like is.gd or snipr, you might be able to get the plugin to use that instead, with a simple registry tweak.

Under the following key:

HKEY_CURRENT_USER\Software\Microsoft
\Windows Live\Writer\Preferences\PostEditor\ContentSources
\CECF2903-51B3-4173-A932-76E4EE4C01CF

Add a String Value called UrlShortener. Here are some examples of known good values:

http://tinyurl.com/api-create.php?url={0}

http://cli.gs/api/v1/cligs/create?url={1}

The plugin will replace {0} or {1} with the URL of your post. ({0} will just drop the URL in, while {1} will URL-encode the URL first. The latter seems more correct, but TinyURL and is.gd both expect the former.) Then it will make a web request to the resulting URL, and assume that the entire response is the shortened URL.

Not all URL shortening services will work. For example, bit.ly has an API but it returns JSON or XML, not just the bare URL, so at best you’ll get a bunch of garbage in the post. Update April 1, 2010: See comment below by Max for bit.ly instructions.

You can also choose to skip the shortening step and just put the whole URL in there; just create the UrlShortener string value but leave it empty.

If you’re still on an older build of Writer, go download it now!

If you’re using WordPress 2.3.1 or later, look for either Keywords or Tags near the bottom of the screen. You may first have to press F2 (or click the little up-arrow) to expand the property panel.

Better yet, if you’re using WordPress 2.7 (or WordPress.com) and Windows Live Writer 2009 RC or later, you’ll get tag autocompletion! The tags field also moves upwards, adjacent to the categories field.

The same instructions apply for BlogEngine.NET, though I don’t think a build has been formally released yet that supports tag autocompletion.

The confusion stems from the fact that there is also an older, non-native style of tagging that was in common use in 2006 when we launched Writer. At the time, none of the popular blog platforms had any built-in tagging features, per se—it was all about categories. Tagging usually meant manually inserting HTML links into the actual body of each post, with rel="tag" attributes on each link. Technorati and other search engines could detect these tags, but because it was all commingled within the post body, the actual blogging platforms could not.

The second public beta of Writer added support for this primitive form of tagging, and it remains in the product to this day. If you do “Insert Tags” from the main menu, edit toolbar, or sidebar, you’ll get this kind of tagging. And if your blog software supports native tags, as WordPress does, this is almost certainly not what you want.

It’s definitely bogus that we have two related-but-different tagging features, without making it easy for the user to know which to use. We didn’t have time to solve this problem for WLW 2009, but it’s quite possible we will do something about it in a future release.

It plays nice with the Crop and Tilt features.

No, you cannot currently provide a caption to be written on the border. If that’s important to you, you might consider the “Polaroid Picture” plug-in.