Room Full of Mirrors

A Note On Java Culture And A RESTlet Tutorial

2013-03-22T00:12:28Z

My first real experience with web development was based on PHP. I opted to learn it over Perl because it was more popular at the time and its syntax is very similar to C. One of the things I liked most about PHP was the excellent manual on the official website. The tutorial at the start of the manual was all I needed to get started, and the rest was a great reference. It did, however, take a long time to learn what constituted bad practice with the language. But, I digress.

Nowadays I find that I have to work with Java as a web development platform. The major third-party platforms we use at work are almost always written in Java, or at least against the JVM, so it’s basically what I am forced to deal with. Before being forced to deal with the Java platform in this manner, I didn’t think much of it at all. In fact, I would usually deride it. There are some tools written in Java that I liked, and used, but overall I just wished it would go away. But that attitude has been changing.

Let me backtrack a little. I mentioned that most of our third party software is developed in Java. Well, most of our in-house software is not. No, most of our in-house software is developed in .Net. I thought I wouldn’t mind working with .Net, at first. C# is actually a rather nice language, and the .Net framework has a lot of useful libraries. But then I tried to do web development in .Net. I have never seen a bigger mismatch of technologies than .Net and the web. The .Net name is a total misnomer. It was clearly designed for traditional application development with web development tacked on after-the-fact.

So, I was primarily a PHP web developer in a .Net house that has to manage some Java web applications. Clearly, something had to give. Well, as I spent more time with the Java applications, and learned how they are developed, I started to like the platform a little more. It became clear to me that the Java platform is much better suited to web development than the .Net platform. Thus, I have been trying to learn how to properly do web development with the Java platform.

Notice that I said “trying” — it hasn’t been easy. The Java platform comes from a corporate environment. As such, the knowledgable developers of, and community around, the platform are steeped corporate ways and thinking. This means it is very difficult to find good, free, information on the web, but very easy to find a million overpriced books. Not only that, but all of the innovation has happened in the free spaces like PHP, Python, and Ruby (gee, I wonder why?). So you’ll find a lot of stuff implemented in Java, because the folks working with Java would like to play with the new toys, but no documentation for the Java implementations. This means there are hundreds of ways to get started in Java web development but no clear path.

Anyway, as I mentioned a few posts ago, I had a new idea in mind for a project at work and came to the conclusion that it would be best done in Java. Mostly because I can’t stand .Net more than Java, and because I need to learn how to properly develop web applications in Java for some third party stuff we’ll be dealing with at work soon(ish). This project was to be a web API, and I wanted it to be a “RESTful API“. So I started researching Java APIs.

I started out trying to use the Spring framework because it is the basis for pretty much every major web application developed in Java nowadays (including the third party stuff I’ll have to deal with soon). But that is an exercise in frustration. So I decided to try something else just so that I could actually accomplish something. Thus, I came across the RESTlet API. Again, the API is very poorly documented, but it looked rather clean. So I read the book and found myself really liking the API.

It’s worth noting that the RESTlet site, at the time of this writing, has been updated with a much better tutorial than when I started learning the API a month ago. Evidently the site was, and still is, really, undergoing some major updating. So it is possible to get started with the API without using the book, now.

However, I still think the tutorial is lacking. It doesn’t really show how to use the API. It imparts some information that you really should know, but it doesn’t help the person that just wants to “write a damn application.” So after getting basics of the API figured out myself, I decided I would write a tutorial.

Before I link you to my tutorial I should briefly discuss the format of it. I hate it when a tutorial is basically just a link to some source code. But there really isn’t a better way of introducing this topic (unless you want to write a book). So my tutorial is mostly source code, but I did it a little differently. The tutorial itself is in the comments of the source code, with an overview of the technology, and how things are put together, in the text only part. Additionally, the source code isn’t tucked away in some damn zip file you have to download or just in a web browsable directory. I put it in a Mercurial repository and hosted it on BitBucket. So it is browsable, easily updatable, and you can see the history of the tutorial.

Without further ado the tutorial — https://bitbucket.org/jsumners/restlet-2.1-demo.

I hope you find it helpful. And if you can think of any way to improve it, feel free to send me your suggestions via a pull request.

CacheViewer Continued, A History And Status Update

2013-02-07T21:22:36Z

A word of warning: this situation has me very upset. There will be strong language in this post.

As you may, or may not, know, I maintain a Firefox add-on named CacheViewer Continued. I did not originally author this add-on; it was originally developed by someone named “benki” as “CacheViewer.” This add-on was extremely helpful when doing web development with Firefox. CacheViewer made it very easy to find all of the cached items for a given domain or of a given name. Not only that, but you could preview those items directly from the cache, delete them, or even save them elsewhere. So, CacheViewer was one of the add-ons I always installed in Firefox. Then came Firefox 4.0.

Firefox 4.0 broke CacheViewer in such a fashion that it wouldn’t even load. I waited several weeks for an update, but benki seemed to have dropped off the planet. Making matters worse, there were no alternatives to CacheViewer (and there still aren’t to my knowledge). So, I decided to look into the problem and see if I could correct it myself. It was a simple fix. Thus was CacheViewer Continued born and since May of 2011 I have been maintaining it as I am able (and is required).

Everything was working out well. I was releasing CacheViewer Continued into the “not fully tested” add-on repository, and people were happy. Then Mozilla noticed that people really liked CacheViewer and it was missing from the “fully reviewed” repository. As a result, Mozilla contacted me to see if I would be willing to submit CacheViewer Continued for full review so that people could install it directly from the browser add-ons tool. I said sure, even though I had planned to clean up the code before doing that. After a while, Mozilla started automatically bumping the supported version number in add-ons after an automated scan confirmed no problems with the next Firefox release. So it was really easy to “maintain” CacheViewer Continued — I didn’t have to do anything! Then they released Firefox 18.

With Firefox 18 they completely fucked CacheViewer Continued. First, I got the usual email after the automated add-on compatibility review. Whereas they normally consisted of “everything’s cool, we’ve bumped the version compatibility number for you,” this one resulted in a whole bunch of red text. Evidently, the guy that maintains the cache API upon which CacheViewer, and subsequently CacheViewer Continued, relied decided it would be cool to up and delete the god damn API. No warning whatsoever was sent to add-on developers; and there sure as hell wasn’t a deprecation notice for at least one release of Firefox. Nope. It’s just fucking gone!

Oh, and you remember that automated email I got about the problem? Yeah, they went ahead and automatically marked CacheViewer Contiued as compatible with Firefox 18 anyway. So that means everyone who uses CacheViewer Continued, almost 52,000 people, see no reason to hold off upgrading their browser. Let me summarize:

Lot’s of people love having CacheViewer Continued
Mozilla breaks the API on which CacheViewer Continued relies without warning
Mozilla tells people CacheViewer Continued will work anyway
I’m fucked

Why am I fucked? The original CacheViewer was written under the assumption that the removed API will always exist. It relied on cache entries being able to be read in real-time. Thus, the code was not structured in such a way that it would be easy, or maybe even possible, to restructure into an asychronous model. Therefore, CacheViewer Continued requires a complete rewrite to solve the problem of the missing synchronous API. At the same time, I

Haven’t used Firefox full-time in at least a year, so the add-on has not been a priority for me
Have been swamped at work so I can’t devote any time to CacheViewer Continued there (where it does benefit me)
Was in the middle of shopping for, and buying, a house

Yes, that’s right, I don’t use Firefox any longer. So why do I maintain an add-on for it? Because I know how useful CacheViewer Continued is to the people who do use Firefox (and know they need the add-on). As long as I am able, I cannot in good conscience leave these people hanging like benki did. But it is really fucking hard to so when when Mozilla does all they can to make it not worth my time. Keeping up with the god damn insane release schedule of Firefox was enough to drive me mad before they started automatically bumping the compatibility number. But now they’re telling users the add-on will work after they tell me it won’t? What the fuck? Even so, I have been working on the rewrite for a month.

The rewrite has not been easy. Like I said, I have a lot going on. But when I do get time to work on it, it’s a slow process. The documentation for Mozilla’s APIs is abysmal which results in a lot of digging just to figure out what I need, much less how to use it. The only saving grace is their new API specifically for add-on development. It is decently documented and has made it relatively easy to get up to the point where I am now — something that lists cache entries, shows entry details, and loads cached images for preview from the original URL. But all of the advanced features, namely deleting and saving of entries and loading entries directly from the cache, requires digging through the poorly documented API and figuring out how to use it from within the new API.

I really wish I could provide you with a release date for something at least more usable than the “about:cache” page built into the browser, but I can’t. I don’t want to release something that is going to upset you, the user, even more than you already are. Please understand that I will make it available as soon as I can.

Update 07 February 2013:

I have submitted a very basic version (0.9.1) for review. Hopefully it will be available directly through the browser add-on manager within a day or so. In the meantime, you can download cacheviewer-continued-3e47cf8e944e.xpi from the BitBucket page.

JavaScript Via Java On The Back Of A Rhino

2013-02-16T02:53:57Z

I have been formulating a project with a couple of at odds requirements:

It must interface with an Oracle database
It should be easily extensible via a language others wouldn’t mind

Requirement #2 leads me to JavaScript, it being the most common programming language available. So, I could do this project as a Node.js based project, but the Oracle driver is a pain to setup since it depends on the “instant client” binaries and SDK (particularly on OS 10.7 or later; unless you like running Node.js in 32-bit mode). There is also a JDBC driver for Node.js, but it’s incomplete, hasn’t been worked on it two years, and would add Java as a dependency. Thus, why not skip straight to Java? Oh, but there’s that pesky problem of wanting to use JavaScript for extensibility.

Enter Rhino. Rhino is a JavaScript library for Java that provides a JavaScript interpreter. As a side note, it sounds like Rhino may be superceeded by a new library, Nashorn, in late 2013. In any event, I want to share what I have learned. The documentation for Rhino is a bit difficult to follow, so a simple introduction is warranted.

This brief introduction will:

Read an external JavaScript file
Create an instance of the Rhino interpreter
Use the Rhino interpreter to provide a new host object to the JavaScript script
Execute the JavaScript script
The source code in this article is available for download. The zip contains all of the code in this article, the Rhino library, and a Bash script to build and test the code.

Let’s first look at meat of the program:

package com.jrfom;

import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.io.File;

import org.mozilla.javascript.Context;
import org.mozilla.javascript.Scriptable;
import org.mozilla.javascript.ScriptableObject;

public class JavaScriptRunner {
    public static void main(String[] args)
        throws java.lang.Exception,
        java.io.IOException,
        java.io.FileNotFoundException
    {
        if (args.length < 1) {
            System.err.println("Must pass in a JavaScript file to run.");
            System.exit(1);
        }

        File scriptFile = new File(args[0]);
        if (!scriptFile.exists()) {
            System.err.println("Script file '%s' does not exist.".format(args[1]));
            System.exit(1);
        }

        // Read in the JavaScript file.
        byte[] buffer = new byte[512];
        StringBuilder sb = new StringBuilder();
        BufferedInputStream bis = new BufferedInputStream(new FileInputStream(scriptFile), 512);
        int bytesRead = bis.read(buffer);
        while (bytesRead != -1) {
            sb.append(new String(buffer));
            bytesRead = bis.read(buffer);
        }
        String script = sb.toString();

        // Initialize the interpreter.
        Context context = Context.enter();
        context.setLanguageVersion(Context.VERSION_1_8);
        Scriptable scope = context.initStandardObjects();
        ScriptableObject.defineClass(scope, Foo.class);

        if (!context.stringIsCompilableUnit(script)) {
            Context.exit();
            System.err.println("Script is not compilable!");
            System.exit(1);
        }

        // Try to run the JavaScript through the interpreter.
        try {
            context.evaluateString(scope, script.trim(), null, 1, null);
        } finally {
            Context.exit();
        }
    }
}

Lines 40 through 56 are where Rhino is loaded, the new host object defined (line 43), and the script executed (line 53). The rest of the code is merely checking for error conditions and reading in the JavaScript file.

So, what is this new host object, Foo? It is a plain Java object that extends an object provided by the Rhino library:

package com.jrfom;

import org.mozilla.javascript.ScriptableObject;

public class Foo extends ScriptableObject {
    private String bar;
    
    public Foo() {}

    @Override
    public String getClassName() {
        return "Foo";
    }
    
    public void jsConstructor() {
        this.bar = "";
    };
    
    public void jsSet_bar(String value) {
        this.bar = value;
    }
    
    public String jsGet_bar() {
        return this.bar;
    }
}

Our Foo class follows some Rhino specific requirements in order to expose our Java methods to the JavaScript being interpreted. First, we define the JavaScript class name by the getClassName method. Next, we define the constructor that will be called when we do new Foo() in our JavaScript; if the Java class doesn't have a jsConstructor method then one will be derived. From defineClass:

If no method is found that can serve as constructor, a Java constructor will be selected to serve as the JavaScript constructor in the following manner. If the class has only one Java constructor, that constructor is used to define the JavaScript constructor. If the the class has two constructors, one must be the zero-argument constructor (otherwise an EvaluatorException would have already been thrown when the prototype was to be created). In this case the Java constructor with one or more parameters will be used to define the JavaScript constructor. If the class has three or more constructors, an EvaluatorException will be thrown.

Finally, we define getters and setters for our one property by prepending jsGet_ or jsSet_, respectively, to method names. We could also define static methods on our Foo object by prepending jsStaticFunction_ to method names. Additionally, we can create global JavaScript functions via our Java class by prepending jsFunction_ to method names (but I'd shy away from this one to prevent polluting the global space).

So, now that we have the Java written, what about the JavaScript? Here's a simple "hello world" type example:

"use strict;"

var foo = new Foo();

foo.bar = "This is a string";

java.lang.System.out.println(foo.bar + " from JavaScript!");

Running this script through our Java program will result in "This is a string from JavaScript!" being printed to stdout via the Java System object. Notice that we don't have to reference our Foo object in any special way, other than instantiating an instance of it. This works just like the standard Array object, except it doesn't have a literal syntax.

Notice, also, how we have used a standard Java library in our JavaScript. Rhino provides a new host object named Packages. The properties of this Packages object are all of the Java libraries available to the JVM under which the program is running. In our script, we use an alias, java, defined by Rhino to access the Packages.java objects. Further information about this, and other scripting additions, can be read in the Scripting Java article.

This isn't as sexy as Node.js. But it does provide a convenient way to include JavaScript into a Java based application that is more flexible than the javax.script interface.

RE: The Pew Pew Manifesto

2012-06-18T22:50:21Z

Ben Simpson made a post to Twitter a few days ago about an article that advocates avoiding writing applications directly in JavaScript. I reponded that the article is worthless, and Mr. Simpson wanted to know which points, specificially, I think are “hogwash.” There a few reponses in the article’s comments section that highlight my simple summary, but I’m going to attempt to go into a bit more detail here.

I have a hard time believing that the author of the article really thinks his arguments are accurate. His suggestion is to use Adobe’s ActionScript language instead of JavaScript. This makes sense because he is an Adobe employee. But he did write the article, or at least attached his name to it, so let’s dig into this load of bunk.

“JavaScript is not suitable for large web apps”

This is the “point” that Mr. Simpson found most interesting and the one that I think is the biggest fallacy. I would like to include a small quote from this section, but it’s all so ludicrous I can’t pick a single representative part to quote. The author’s argument breaks down to the following points:

He was asked to help work on a large internal JavaScript based project
The project’s source code was organized in a horrible fashion
The project’s code was written by people who didn’t understand the language

The author then blames all three of these points on JavaScript itself. First, the project evidently contained large chunks of JavaScript in “few files.” In this regard, he says that ActionScript, the language, leads the coder to using multiple files for various classes and such. You can do the same exact thing with JavaScript. Case and point: jQuery. jQuery is a large, very popular, JavaScript project. Its source code is broken down into different components with each component being defined in its own source file. These files are then “compiled” into a single JavaScript file that is “jQuery.”

The primary, somewhat, valid complaint in this section is about JavaScript functions returning inconsistent data types. His example code consists of the following two functions:

  // (bad) JavaScript
  function createBunnyOrToaster(createBunny)
  {
    if( createBunny )
      return new Bunny();
    return new Toaster();
  }

  // (bad) JavaScript
  function feedBunnyOrToaster(bunnyOrToaster)
  {
    if( bunnyOrToaster instanceof Toaster )
      bunnyOrToaster.insert(new Toast());
    else
      bunnyOrToaster.feed(new Carrot());
  }

How are these functions the fault of the language? They’re not. They’re the fault of a programmer being stupid. What would “proper” JavaScript of this example look like? First, understand that the example assumes the coder is being lazy about creating “class” based objects. Second, recognize that
createBunnyOrToaster()

is the constructor for two class based objects. Thus, we would write something akin to:

  var Bunny = function(bunnyName) {
    if ( !(this instanceof Bunny) ) {
      return new Bunny();
    }

    this.name = bunnyName;
  };

  var Toaster = function(toasterModel) {
    if ( !(this instanceof Toaster) ) {
      return new Toaster();
    }

    this.model = toasterModel;
  };

With this code, the programmer can still be lazy (e.g.
var myBunny = Bunny(“FooFoo”);

), but the JavaScript isn’t total garbage. John Resig has written an excellent article on this pattern.

His second example,
feedBunnyOrToaster()

, assumes the usage of the constructor that we just showed is ridiculous. Therefore, I will not waste any further time on it. Suffice it to say, if the code is written in a sane manner, then the constructor will always return the correct type. Thus, functions that require type inference are pointless.

“JavaScript is the browser’s assembly language”

This point(?) doesn’t even really deserve acknowledgement if it weren’t referenced in the next couple sections. This one just dumbfounds me. I’m going to let a couple “Hello World” examples deal with this one for me. First up, vanilla x86 assembly:

  section .data
    msg db "Hello World!", 0x0a

    len equ $-msg

  section .text
    global _start

  _start:
    mov ebx, 0x01
    mov ecx, msg
    mov edx, len
    mov eax, 0x04
    int 0x80

    mov ebx, 0x00
    mov eax, 0x01
    int 0x80

JavaScript (as run in a browser):

  (function() {
    var msg = "Hello World!";
    alert(msg);
  }());

Some garbage about high level languages

I’m going to address the “Choose a high-level language for developing web apps” and “Cross-compile from a high-level language to JavaScript” points at the same time. Put simply, as I illustrated in the previous section, JavaScript is a high-level language. There is absolutey no reason to use another high-level language to write JavaScript.

Here’s the thing. If you choose something like CoffeeScript, one of the more popular options that the author recommends, then your code is going to be “compiled” at least twice: first by the “high-level” language’s compiler and second by the runtime’s (e.g. browser’s) JavaScript interpreter. When you go the route that the author suggests, then the compiler for your chosen high-level language is merely translating the code you wrote into JavaScript. As has been shown in the original article, and this article, that code may not be appropriate. Yet, that is the code that will be run by the JavaScript interpreter.

“It’s optimized so it’s better!”

That’s the title I’m giving to the “Use Google’s Closure Compiler for optimizing JavaScript” and “Optimized JavaScript is obfuscated and protects your intellectual property” points. Unless you use Closure’s “advanced” option, the code returned from Closure is the exact same code as the code you wrote. The only difference is reduced white space and variable name length. The only benefit here is a smaller file size to be sent to the client. The advanced option will try to alter your code to be more efficient, but that can have serious side effects. Don’t trust it implicitly as the author seems to suggest.

Along the same lines, the author equates “optimized” JavaScript with hard to read assembly or deliberately confusing code. This is utter nonsense. As I have already stated, this optimized code is nothing more than compressed code. Run the compressed code through something like JsFormat (a SublimeText 2 plugin) and you’ll get code that is quite legible. Sure, the variable names won’t be pretty, but the logic is still there.

“Use best practices”

The last two points, “Let your app degrade gracefully when OS features are missing” and “Invade every Web Platform!”, are nothing more than the statement “use best practices” written in many more words. If the JavaScript you are writing has a chance of being run in more than one environment (Internet Explorer, Firefox, Node.js, etc.), then you should be checking to make sure the features you need are present. It’s a very old concept to people writing JavaScript for the web. There’s nothing special or new about these two points.

My summary

Back when JavaScript was first introduced, and people used it for really annoying garbage like snow flakes, I was one of the people who hated the language. What I was too young, or uneducated, to realize is that I hated how the language was being used (and implemented). Nowadays, it’s one of the most impressive languages available. The runtimes/interpreters are phenominal, and the subtleties of the language have been exposed. So when I read FUD like the referenced article, it grates me the wrong way.

If you find yourself looking for ways to write JavaScript without writing JavaScript (see the above mentioned CoffeeScript), then you need to stop and re-think what you are doing. Take a little time to learn the language. You don’t have to read JavaScript: The Definitive Guide to get a handle on the language. Familiarize yourself with the basics and then read JavaScript: The Good Parts and JavaScript Patterns. Both are short books, but they will teach you (almost) everything you need to know to write some damn fine JavaScript.

WinLN – A Windows Symbolic Link Manager

2012-05-23T18:07:42Z

Prices on SSDs have been dropping fast lately. I’ve been wanting one for my gaming computer for some time, and one of the recent deals was very acceptible to me. Which is to say, I just added a new 250GB SSD to my gaming computer. Since I could fill up 250GB with all of my games in a hurry, I decided to manage it a little bit differently. I am using symlinks from my existing installation locations to the new locations on my SSD for the games that I copy over.

This works great. It doesn’t matter how the games were installed. The game could have been installed via a traditional installer or via Steam, they still work. I simply move the game from its installed location to my SSD, and then create a symlink from the SSD to the “old” install location, using the original directory name for the link name.

There’s a caveat to this, however. When I say “gaming computer,” what I really mean is “Windows computer.” Since Windows Vista, Windows has supported symlinks (took them long enough), but the CLI for Windows is the worst ever invented. So I needed a way to manage these links easily. There are few GUI tools out there, but they all fall short in at least one of two ways:

All of the ones I found that were open source were just frontends to the mklink utility.
None of them kept a history of the links they created.

Thus, I decided that I would have to write my own tool. That tool is WinLN. It’s written against the .NET Framework because writing a GUI for Windows any other way is worse than using a plastic spoon to dig out your own beating heart. It isn’t much better with the .NET Framework, either. But it’s done, and I think it works quite well. Enjoy.