Recently we found that our Lab framework caused the JavascriptCore of Safari 5.1 to crash. Safari 5.1 is the latest version available for OS X 10.6. If you have OS X 10.7 or 10.8, then you have Safari 6 which doesn’t have this problem.

Too long; didn’t read solution: do not name your getters the same as your closure variables.

After at lot of detective work I figured out what the problem was. A block of code like this was causing it:

Here is a fiddle of the same code.
If you run that fiddle in Safari 5.1 You will see an reference error to myProperty. Note: you need to make sure script debugging is disabled. If script debugging is enabled then this problem doesn’t occur. That block of code is using a Javascript getter. If you are not familiar with Javascript getters and setters, this post by John Resig is a great place to start.

Then it works! So there is an issue with Safari when a getter has the same name as the variable in the outer closure. This didn’t make sense though. We use this pattern of a getter accessing a variable of the same name throughout much of our code. Those parts of the code worked fine. After more exploration I found the following block of code works fine in Safari 5.1:

This code is using the closure variable in another method that is part of the return object. Based on this, I believe the problem is that Safari is failing to keep the closure variable available when it has the same name as the getter and is only referenced by that getter. I assume it is common for browsers to try to optimize closures by discarding variables that aren’t used. So it seems the code analysis done by Safari to see if a variable is used, is failing to mark a variable as being used when it is in a getter with the same name.

I have submitted a bug to Apple about this. Their bug tracker is private though, so there is no way for you to see that bug.

So to summarize, you should not name your getters the same as your closure variables.

The opposite of Thomas Dolby

I was terrible at the first four weeks of organic chemistry. I just couldn’t get the right pictures into my head.

The depictions of the chemical reaction mechanisms I was supposed to memorize seemed like just so many Cs (and Hs and Os and, alarmingly, Fs) laid out randomly as if I were playing Scrabble. And I swear the letters rearranged themselves every time I looked away, like a scene out of a movie about an art student’s science-class nightmares (minus the extended fantasy sequence in which the letters grow fangs and leap off the page to menace the poor protagonist – unless I’ve blocked that part out).

Fortunately, I knew exactly what to do: I had to start picturing molecules in 3D, and in motion, as soon as possible. That ability seemed to take its own sweet time to develop. But once things “clicked” and I could visualize molecules in motion, the reactions finally made sense, as did all the associated talk of electronegativity, nucleophilic attack, and inside-out umbrellas. I aced the final.

Now, our Molecular Workbench software isn’t specifically designed to help undergraduates get through organic chemistry. It is designed to help students at many levels by letting them interact with simulations of the molecular world so they get the right pictures into their heads, sooner. It’s here to help that future art student and movie director beginning to nurse a complex about the 10th grade science class he’s stuck in right now.

The weight of history

But the “Classic” Molecular Workbench we have now was built for a different world. It runs in desktop Java, for one thing, meaning (among other things) that it’ll never run on iPads. More fundamentally, it was built to be “Microsoft Word for molecules” in a time when Microsoft Word was the dominant model for thinking about how to use a computer:

“Hello, blank page! Let’s see, today I’ll make a diffusion simulation. I should write something about it … Let’s make that 12-point Comic Sans. No, my graphic designer brother-in-law keeps telling me not use that so much, so Verdana it is, then. Now how do I add that model again? Oh yeah, Tools -> Insert -> Molecular Model…”

This model is constraining even though it’s always been possible to download and open Molecular Workbench via the Web, and even though MW saves simulation-containing activities to special URLs.

We have somewhat different expectations these days because of the Web, social media, mobile apps, and casual games. If I build a great in-class “activity” based on a series of molecular models, then I should be able to share that activity with the world with minimum difficulty. And if you find one of the simulations I created particularly illustrative, you should be able to put that model in a blog you control, or include the model as part of your answer to a question on http://physicsforums.com/.

Moreover you ought to be able to perturb the running simulation by reaching out and touching it with your fingers, or simply by shaking your tablet to see what effect that has on the simulation “inside” it. You shouldn’t be required to operate the simulation at one remove, via a mouse and keyboard, when it’s not necessary.

That’s why we’re excited about the Google-funded, next-generation Molecular Workbench we have started to build. The HTML5 + JavaScript technology we’re using to build the next generation of our MW software (hereafter called NextGen MW for short) will make it much more practical to enable these kinds of uses.

Boldly doing that thing you should never do

But designing NextGen MW to be a native of the real-time Web of 2012 rather than a visitor from the land of 1990s desktop computing means that we’re committed to rebuilding the capabilities of “Classic” Molecular Workbench from scratch. That is, we’re doing the very thing Joel Spolsky says you must never do! But ignoring platforms which run Java badly or not at all isn’t an option, and neither is trying to run Classic MW in a Google Web Toolkit-style compatibility layer that compiles Java to JavaScript. (With the latter option, we would almost surely be unable to optimize either the computational speed or the overall user experience well enough to make it practical to use NextGen MW on phones, inexpensive tablets, or even expensive tablets. But even that misses the point. We’re not a consumer products company trying to optimize the return on our past investment. We’re an R&D lab. We try new things.)

But writing things from scratch poses a challenge. We want the molecular dynamics simulations run by NextGen MW to run “the same” as the equivalent simulations run in Classic MW. But “the same” is a slippery concept. In traditional software development, asking two different implementations of a function or method to produce the “same” result often means simply that they return identical data given identical input, modulo a few unimportant differences.

It would be nice to extend this idea to the two-dimensional molecular dynamics simulations we are now implementing in NextGen MW. Classic MW doesn’t have a test suite that we can simply adapt and reuse. But, still, we might think to set up identical initial conditions in NextGen MW and Classic MW, let the simulations run for the same length of simulated time, and then check back to make sure that the atoms and molecules end up in approximately the same places, and the measurements (temperature, pressure, etc.) are sufficiently close. And, voilà, proof that at least this NextGen MW model works “the same” as the Classic MW model. (Or that it doesn’t, and NextGen MW needs to be fixed.)

Never the same thing twice?

Unfortunately, this won’t work. Not even a little bit, and the reason is kind of deep. The trajectories of the particles in a molecular dynamics simulation (and in reality) exhibit a phenomenon known as sensitive dependence on initial conditions. Think of two identical simulations with exactly the same initial conditions except a tiny difference. Now, pick a favorite particle and watch “the same” particle in each simulation as you let the simulations run. (And assume the simulations run in lockstep.) For a very short time, the particle will appear to follow the same trajectory in simulation 1 as in simulation 2. But as you let the simulation run a little longer, the trajectories of the two particles will grow farther and farther apart, until, very quickly, looking at simulation 1 tells you nothing about where to find the particle in simulation 2.

Very well, you say: maybe simulation 1 and simulation 2 started a little too far apart. So let’s make the difference in the initial conditions a little smaller. Sure enough, the trajectories stay correlated a little bit longer. But a very little bit. Here’s the rub: if you want to simulation 2 to match simulation 1 for twice as long, you need the initial conditions to be some number, let’s say 10, times closer. But if you need the simulations to match for 1 more “time” as long, that is, 3 times as long, you need the initial conditions to be 10 times closer still, or 100 times closer. And if you want simulation 1 to make a meaningful prediction about simulation 2 for ten times as long? Now you need the initial conditions to be a billion(109) times closer. In practice, this means that if there’s any difference at all between the two initial conditions, no matter how seemingly insignificant, then outside of a short window of time the two simulations will predict very different particle locations and velocities.

Perhaps you think this is a contrived situation having nothing to do with comparing Classic MW and NextGen MW. Can’t we start them with, not just similar, but identical initial conditions? Unfortunately, this escape hatch is barred, too. The tiniest and most seemingly insignificant difference between the algorithms NextGen MW runs and the algorithms Classic MW runs right away result in a small difference in the trajectories, and after that point, sensitive dependence on initial conditions takes over: the subsequent trajectories soon become totally different. Trying to run precisely the same algorithms in NextGen MW as in Classic, down to the exact order of operations, would not only intolerably constrain our ability to develop new capabilities in NextGen MW, but would be futile: the differing numerical approximations made by Java and JavaScript would result in yet another small difference which would in short order become a big difference.

Science!

So, wait a minute: You can’t test NextGen MW against Classic MW because even the tiniest difference between them makes them behave … totally differently? How do we trust either program, then? And how is this science again?

Well, notice that I didn’t say quite say the two programs behave totally differently. Yes, the exact trajectories of the molecules will quickly diverge, but the properties we can actually measure in the real world — temperature, pressure, and the like — unfold according to laws we understand, and should be the same in each (not counting minor, and predictable, statistical fluctuations.) After all, we can do beautifully repeatable experiments on “molecules in a box” in the real world without knowing the location of the molecules exactly. Indeed, when van der Waals improved on the ideal gas law by introducing his equation of state, which includes corrections for molecular volume and intermolecular attraction, the notion that molecules actually existed was not yet universally accepted.

So what we need are molecular models whose temperature, pressure, diffusion coefficient, heat capacity, or the like depend in some way on the correctness of the underlying physics. Ideally, we would like to be able to run a Classic MW model and have it reliably produce a single number which (whatever property it actually measures) is demonstrably different when the physics have been calculated incorrectly. Then we could really compare NextGen MW and Classic MW — and perhaps even find a few lingering errors in Classic MW!

Unfortunately for this dream, our library of models created for Classic MW tend to be complex interactives which require user input and aim to get across the “gestalt” of molecular phenomena (e.g., one model encourages students to recognize that water molecules diffusing across a membrane aren’t actively “aiming for” the partition with a higher solute concentrations but move randomly). The models are not intended to be part of numerical experiments designed carefully to produce estimates otherwise-difficult-to-measure properties of the real world. They require substantial rework if they are to generate single numbers that are known to reliably test the physics calculations. For that matter, there aren’t many Classic models at all that conveniently limit themselves to just the features we have working right now in NextGen MW, and we can’t just wait until we develop all the features before we begin testing.

Charts and graphs that should finally make it clear

Therefore, we have turned to making new Classic MW models that demonstrate the physics we want NextGen MW to calculate, and comparing the numbers generated in Classic MW to the numbers generated when the equivalent model is run in NextGen MW. I’ve begun to think of this process as creating the “datasheet” for Classic and NextGen MW, after the datasheets which contain charts and graphs detailing the performance characteristics of an electronics part, and which an engineer using the part can expect it to obey.

So far, we’ve just gotten started creating the MW datasheet. I’ve written a few ugly scripts in half-remembered Python to create models and plot the results and so far, sure enough, it looks like an issue with the NextGen MW physics engine that I knew needed fixing, needs fixing! (The issue is an overly clever, ad hoc correction I introduced to smooth out some of the peculiar behavior of our pre-existing “Simple Atoms Model.” But that’s good fodder for a future blog post.)

But we have ambitions for these characterization tests. Using the applet form of Classic MW, we hope to make it possible to run each of these “characterization tests” by visiting a page with equivalent Classic and NextGen MW models side by side, with output going to an interactive graph. But with or without this interactive form of the test, once characterization tests have been done they will help us to find appropriate parameters for automated tests that will run whenever we update NextGen MW, so that we can be sure that the physics remain reliable.

Summary: I created a prototype of Learn.Ember.js, an interactive tutorial application for web developers who want to learn about Ember.js. Along the way I was reminded that one of the most useful things about HTML5 is that it helps us to blur the app vs. document distinction in useful ways.

Here at the Concord Consortium we believe that interactive computational simulations are powerful tools for learning about the world in ways that were not previously practical, or even possible. Google seems to agree; their philanthropic arm Google.org recently gave us a substantial grant to make an HTML5 version of our Molecular Workbench molecular simulation environment.

Changing the world

But Google didn’t approach us just because they agree that simulations of molecular behavior are a great way to learn about science. They approached us because we have spent 10 years writing well-regarded content for Molecular Workbench. We don’t just make simulations. We embed them in documents that introduce topics gently, encourage you to play with the simulation in productive ways, and in general encourage you to think.

It turns out there are many other domains that can benefit from open-ended tools embedded in structured “learning activities” available via browser. In particular, web development itself can benefit.

Inspiration from learn.knockoutjs.com

Here at Concord I mostly do client-side web app development, and so recently I found myself surveying the new crop of client-side MVC libraries. I was looking for a lighter-weight alternative to SproutCore (which we have used for a few projects) while we waited to see what would come of on the greatly slimmed-down, SproutCore-inspired library then that was then supposed to become SproutCore 2.0, and is now a separate project called Ember.js.

But there a lot of “maybe” development tools out there — tools which might be useful someday, but which I don’t need urgently, and which aren’t such breakthroughs that they need to be understood for their own sake. One of the “maybe” libraries I came across was Steve Sanderson’s impressive Knockout.js.

Since I wasn’t doing this survey “for real”, there was a chance that I would have read through the Knockout documentation in detail, downloaded the library, and made sample pages to play with its features. A small chance. There are only so many hours in a day.

But Knockout.js has a secret weapon: its companion tutorial site, learn.knockoutjs.com. Without quite intending to, within a few minutes of stumbling onto the tutorials I built and ran working examples that felt like plausible components of a Knockout-powered app, right in the tutorial page itself. After I finished the first tutorial I had a much better idea of what kind of problems Knockout solves, and how it solves them, than I would have gotten from the usual desultory flip through the Knockout homepage. (You should try the tutorials yourself!)

Prototyping Learn.Ember.js

As it turns out, Ember.js (née SproutCore 2.0) is shaping up to be a cleanly designed and powerful library with a solid team behind it, and I am enthusiastic about its future.

And as Scott has previously blogged, we at Concord would like to create more value for the open source ecosystem. So I’ve begun work on a side project I call Learn.Ember.js. You can see the first public prototype here. (Warning: this does not work in some browsers, notably older versions of Firefox and — wait for it — IE.)

Once I had the most basic functionality working — 2 Ace editors for the Javascript code and the view template, and an embedded iframe for the results — I wanted to focus on establishing a clean visual design. That meant I had to stop writing code and stop dreaming up potential features long enough to focus on design. Fortunately I was saved from withdrawal symptoms by all the opportunities which that opened up for obsessive font fiddling and CSS tweaking.

The challenge here was not so much the design of the text content — though I tried to borrow the best from well-designed, readable sites I like, such as the new Boston Globe website, the Nieman Foundation’s Nieman Labs blog, arc90’s Readability tool, and Mark Pilgrim’s Dive Into HTML5. Rather, the challenge proved to be finding a way to keep all the buttons and assorted interactive knobby bits from interfering with the text.

My first attempts weren’t very promising. I couldn’t put my finger on why until I realized that the 4-box layout of learn.knockoutjs.com just wasn’t working for me. Somehow I got the idea that in order to make the tutorial readable, I would have to find a way to “unbox” the design and make it look something like a page of a good technical book that just happened to be able to run code. But that introduced its own problems. Where to put the results of the program the user writes (which is an interactive web app unto itself)? Put that in a box, and, together with the Javascript and Handlebars/HTML input, which seem to need to be in boxes — de facto, you have four little boxes again!

Gradually, it occurred to me that the program output could be in flow with the text, right below whichever paragraph prompted you to try running the updated program. Then, with just a little position: fixed and fluid-layout magic, it would be perfectly reasonable to have the whole page scroll, and the tutorial content with it. That is to say, I rediscovered the basic design of every web page ever.

You say app, I say document. Let’s call the whole thing off.

I mention this particular, uh, discovery because for some reason it seems to be common to design news and learning interactives to have little snippets of text written in large type and stuffed into little boxes. I confess to having cargo-culted this particular design idea not long ago; last year I even fired up an ancient Multimedia Beethoven CD-ROM made some time in the last century to confirm that, yup, instructional text is supposed to be really short and go into a little box on the left!

I wonder if this design habit is an artifact of the days of Flash and native applications built using layout manager APIs and visual UI builders. I get the impression that it’s both difficult and out of the ordinary to try to get text and interactive elements to flow together using those technologies. After all, the designer usually doesn’t know what the text is going to be in advance, and you, the developer, would have to come up with a way to keep track of where in the text the widgets go, then create the appropriate widget objects and break up the text string at the appropriate spots, so that you can feed it all to a layout manager that you would probably have to tweak and fiddle for your somewhat unusual use case. Which suggests a great idea — perhaps we could invent tokens that mean “a widget goes here” and have the author use those to mark up the text somehow…

I kid. But in a serious way, because one of the things I liked least about SproutCore is the way it seems to want to pretend that the web hasn’t been invented yet. It provides widgets that are really meant to be a particular size and at a particular, absolutely-positioned offset specified in Javascript. Until the oddly named StaticContentView was invented, the standard UI widget for displaying text was called a LabelView and wanted, again, to be a particular size (regardless of the size of its content) and at a particular location (regardless of the size of the content surrounding it).

The theory was that SproutCore is for designing “apps” rather than “documents”. But as you might guess, I don’t find that distinction very compelling in late 2011. Yes, clearly, there will always be some apps whose UI is legitimately just a box of buttons or a glorified data entry form. And “everything in its right place, and just where it was last time” is exactly the right motto for such apps.

But much of the interesting stuff in your life happens in some kind of stream of context. Facebook and Gmail (especially the new look) are containers for what are basically documents relevant to your life, yet their designers are not shy about inserting app widgets — stuff that does stuff — right into the middle of that “document”-like flow.

You occasionally hear “technology X is for app builders, and web technology Y is really for documents“–but that ignores an important category of innovation that is going on right now: apps that are documents. Or, wait, is that documents that are apps…?

What’s next for Learn.Ember.js

But, back to Learn.Ember.js and what’s next. The single page of tutorial text and the trivial example code I have so far are somewhat lazily inspired by the first page of the Knockout.js tutorial; I just needed some text that isn’t plain lorem ipsum. So I need to write more content. But it’s of equal importance to make it trivial for anyone to clone the Learn.Ember.js repo and submit pull requests with new content — or to simply host their own version, modified as they see fit.

For the time being the tutorial text itself is written as a Handlebars template with embedded expressions that tell where to put the buttons; and the initial example code is a string-valued property of a Javascript object. So far, it’s been pretty painless to edit the tutorial text in Handlebars form, but the need to include view class names into the text is an obvious mixing of unrelated concerns — and, worse, the tutorial text is transported to clients as a compiled Handlebars template that is completely invisible to search engines. (Until Javascript gets to work, the index.html file consists of a blank page.)

I think the solution is to put the actual tutorial content, written in clean, semantic HTML5, into the body of the index.html file. Then we can agree as a convention to identify the “run” buttons by applying a particular CSS class, and to represent the location of the output by inserting an empty div with a particular CSS class. The Learn application can then easily use jQuery to scan the DOM as needed, inserting Ember.js views into the right places using Ember.View’s appendTo method and a little bit of DOM manipulation magic.

A remaining question would be whether and how to specify the initial code and the working “help me” code inside the HTML document. Putting the code in script tags with a fake MIME type (text/x-example-javascript) would make it easy to insert the code without having to HTML-escape it and without it running on page load, but then the code isn’t visible to user agents — like search engines — that don’t execute Javascript. Perhaps that is enough, or perhaps the code should go, properly escaped, into hidden <div> elements.

If that were done, then anyone could write their own interactive Ember tutorial by writing an appropriately-marked up HTML file and inserting a few lines into the head of the document to include the Javascript code of the Learn application, which would take care of translating the tutorial document into a working app. And if they were to publish the HTML file to a server, it would be fully searchable.

Before I get that far, of course, I’ll have to tackle navigation between tutorials and pages of a tutorial — a bit of design I left for later. As fodder for a new blog post, of course!

Updated 1am Monday, December 19 with better information about browser compatibility after I made a quick fix to the Learn.Ember.js prototype itself to make it work in Safari, and with a link to all of our open positions rather than just the developer position.

Developers at the Concord Consortium work on a wide variety of grants, and in the process we create reusable pieces of code. With a little work some of these reusable bits of code can be turned into spin-off projects that have a life of their own. In my opinion these spin-off projects have the best potential for broad long-term impact.

We strive to make our individual projects successful, but often their technology is complex and not easy to re-use. The impact of the individual project is the research enabled by the technology, or demonstrating the usefulness of a new concept. However, the collection of technologies used in the project normally becomes a one-off: it is no longer used once the project reaches its 2-5 year end.

Alternatively, within these complex projects are reusable pieces of code that are simple, easy to maintain, and solve a common need. Because of this they have potential to be popular outside of our organization. We do have some partial successes with spin-offs like this.

MozSwing – mostly abandoned, though it was used in at least one commercial product

Java Sensor Library – collection of JAR files for communicating with a variety of sensors available in schools

None of these has become a successful open source spin-off project. To be successful, such a project needs an active community that includes both developers and users. And the amount of work required to maintain it by Concord Consortium developers needs to be small enough that it doesn’t prevent us from reaching the goals of individual grant projects.

The MozSwing project would require too much maintenance. The Java sensor project is too intertwined in our other Java code. RaphaelViews and CapybaraTestrunner don’t have the above problems, but they have not been polished and announced to the right audience. I don’t think the polishing would take a lot of effort, but making the time and finding the support to do so is hard. We are always working on the next big thing, so it takes discipline to really finish up what is already working internally.

There are more potential open source spin-off projects within the technology at the Concord Consortium that have wider audiences than the ones above. With luck, we can change our culture to encourage this work more and make more of this great stuff accessible.

Do you agree that we should be spinning off more projects?
Do you have experience with spinning off projects like these? Any tips?

In a simple implementation a map could be used to define the code to add a child object. So for investigation it would be {activities<<child}, and for page it is {add_element(child)}. The creation of of the objects could use factory girl so the names could be any of the existing factories.

I’m curious if anyone has seen something like this that is already written?
And I’m wondering if there is something like haml that uses indentation for blocks but defaults to “ruby mode” so there wouldn’t be a need for the “- ” before each line.

For years we have been using several layers of Java, Java Native Interface, and native driver code to support common access to sensors from multiple Probeware interfaces from different vendors. We’ve been calling these layers the org-concord-sensor framework.

Our Java/OTrunk framework which has supported many kinds of interactive educational activities uses the org-concord-sensor framework to route data from sensors to real-time graphs and as input into dynamic models.

jsPerf.com lets you write two equivalent ways to accomplish something in JavaScript and it then measures how fast each method is in every browser you run the test in. Other people’s performance tests can be browsed here Browse test cases.

Taking a look at a specific test could show data where you might want to pick an approach that is 25% slower in Chrome …

For example operator-vs-localecompage shows that FireFox starts out seven times slower than Chrome and the slower method in Chrome runs twice as fast in FireFox as the faster method in Chrome.

Other people who view your test can contribute new results when it is run in their browser also.

Ruby is a powerful and dynamic open-source object-oriented language we have been using extensively at CC in the last few years for the web applications that manage and coordinate authoring and deployment of activities based on the SAIL/OTrunk framework .

The standard Ruby VM is written in C and we’ve been using version 1.8.6, the latest stable release on our servers. A beta version of the next major release, version 1.9.1 has recently been released.

Ruby 1.9 looks to be about twice as fast as Ruby 1.8.6.

I’m even more impressed by the recent performance increases in JRuby however. This is a version of Ruby that runs in Java. Programs written in JRuby can easily access code written in Java which makes integration with the rest of our Java codebase much easier.

A year ago programs written in JRuby were often slower than ones written in version 1.8.6 of C Ruby. Now for some benchmarks JRuby is twice as fast as Ruby 1.9.