Jazoon 2013 – STJS: Managing JavaScript application complexity

24. October, 2013

Jazoon 2013 badgeThe talk “STJS: Managing JavaScript application complexity” by Alexandru Craciun (LinkedIn) and Nicolas Piguet (LinkedIn) focused on one of the major pains with JavaScript: It’s easy to get started, you have can quickly build a useful app which then just as rapidly turns into a maintenance nightmare (slides).

They used ST-JS as a tool to reign the dragon.

In a nutshell, ST-JS is a tool that parses Java code and converts it into JavaScript.

What ST-JS isn’t: It’s not GWT (see the FAQ). The code can be edited in your IDE, it compiles but it doesn’t run directly. The Java code is just used to allow you to write type-safe code using all the amenities of a modern Java IDE to write JavaScript. But if you want, you can implement so parts – think about sharing POJOs between your Java code and the script in the browser.

This works by writing thin wrappers (usually just a bunch of Java interfaces) to simulate the API layer of a JavaScript framework like jQuery. This code is called a bridge, here is a list of already available ones. You can then write code using code-completion, JavaDoc popups and type safety. You can apply tools like PMD, FindBugs, SonarQube (formerly Sonar), dead code analysis, …

The tool will then convert this code into JavaScript. A standard JUnit runner can now execute it by opening a browser window or simulating one using env-js and Rhino.

The output of the tool is plain JavaScript. To run it, you just need to include stjs.js which you can serve statically from your server.

As I see it, this project has the following benefits over anything else I’ve seen so far:

  • Full support from your Java IDE – Code completion, refactoring, type/JavaDoc popups, jump-to-definition, …
  • You can split the JavaScript mess easily into classes and packages
  • Not intrusive, low complexity
  • Easy to build bridges to other JavaScript frameworks
  • Allows to share POJOs between Java and JavaScript

Jazoon 2013 – Test First Saves The World

24. October, 2013

Jazoon 2013 badgeThe opening keynote “Test First Saves The World” by Joe Justice introduced WIKISPEED. The project aims “to deliver a mass-production, ultra-efficient, Comfortable Commuter Car, the C3“.

You can find the current list of bugs here.

Some important points about this car: Building the first road-worthy prototype took only 3 months. A team of untrained individuals can build one of them in about one day. It runs on 2.8 l gasoline per 100 km.

In comparison: Professional car manufacturers need hundreds of people and 3 years to build something which dozens of trained teams can assemble in a few hours. And the result is either four times as expensive or pollutes the environment more.

Sounds good? They use scrum. They proved on several occasions that the method works very well for hardware, too (Forbes, CNN Money).

I agree with Joe that scrum is now entering the 3rd phase of the hype cycle: Only the most conservative companies remain cautious.

But scrum isn’t easy – if our problems were easy to solve, we wouldn’t need help, right?

While you can spend some money on training (for example, by asking scruminc to send Joe to your place), you need to remember one of the most important points of scrum: Continuous improvement.

Conclude every spring with a retrospective, identify one item that the whole team wants to have solved – more plants, better soap, an additional microwave, more light, new computers, you name it. Put that as the first item in the next spring and work on it first. Don’t forget to define acceptance criteria.

Or do you like working in a place where the general mood is that “nothing ever changes – especially not for the better”? Everyone knows that happiness and quality will make teams more productive. It’s high time to take a stand in the face of “it’s just the way it is.”

Joe’s next project? A $100 house for homeless.

What’s your’s?