Jazoon 2013 – Spring Framework 4.0 – The Next Generation

24. October, 2013

Jazoon 2013 badgeIn his talk “Spring Framework 4.0 – The Next Generation,” Sam Brannen gave an overview of the new features of Spring 4.0 (slides on slideshare).

Spring, which has moved to http://spring.io/, is going to version 4 which means they add support for Java SE 8 and Java EE 7.

As a Spring developer, this means better Groovy support, being able to use lambda expressions and method references in Spring callbacks, support for “JSR-310 Date-Time types for data binding & formatting, a new @Conditional mechanism for bean definitions, & a new WebSocket endpoint model.”

Things that I took home from this talk:

  • Spring Boot is a new project to make it easier to set up “Spring-powered, production-grade applications and services with absolute minimum fuss.”
  • @Lazy is now supported to annotate the place where a bean is injected (formerly, you could only use it to make it lazy at the definition)
  • There is a new API for messaging with support for WebSockets. In this context, you may want to have a look at stomp “the Simple (or Streaming) Text Orientated Messaging Protocol.”.
  • Spring 4 supports Java EE 6 through 7 and SE 6 through 8
  • Repeatable annotations will make code more compact

The slides should appear soon on slideshare/sbrannen.


Jazoon 2013 – Spock: boldly go where no test has gone before

24. October, 2013

Jazoon 2013 badgeIf you look at your tests, do you see a lot of repetitive patterns? Or are you looking for a way to express your intent more easily? Then, Spock might be for you. The talk “Spock: boldly go where no test has gone before” by Andres Almiray (slides on slideshare) gave a good introduction to the framework. Here is an example:

class HelloSpock extends spock.lang.Specification {
    def "length of Spock's and his friends' names"() {
        expect:
        name.size() == length

        where:
        name     | length
        "Spock"  | 5
        "Kirk"   | 4
        "Scotty" | 6
    }
}

In a nutshell, this creates three tests, running the assertion name.size() == length for each tuple of values. Here is an example how to test a stack.

But this is just one of many ways which you can use to describe tests that Spock should execute for you. The page “WhySpock” lists 10 reasons.


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?


Jazoon 2012: Stay Human – on the future of men and robots

4. July, 2012

What I like about the Jazoon is that they try to widen your horizon. We had presentations how to publish books, psychology and the NASA. This year, the closing keynote was about androids – as in artificial humans, not Google.

Henrik Scharfe from Aalborg University talked about “Stay Human – on the future of men and robots” and Geminoid-DK, an android which Scharfe had built after his image (production notes). For this project, Time magazine put him on the “100 Most Influential People” list in 2012.

According to Scharfe, we’re all part of the “ultimate project: Make sense of the world” in a perpetual loop. To achieve this, we communicate. A very powerful means of communication is the story. Stories need not be true, they have to be relevant. In a sense, we talk to scale, to widen our influence.

During the presentation, Scharfe gave some insight into the production of the android. How odd it feels to enter a room where a copy of yourself is assembled. When the skin on the head is hanging open like from a nasty wound. When “your” arms are still missing. A head without hair. The different stages of coloring. When a worker stabs a needle through the skin to add the facial hair. Thoughts how the workers will treat your copy when you’re not around.

The team did celebrate its “birthday,” the date when it was first activated. For Henrik, it “felt like a friend waking from a long coma.”

After the android was assembled, automatic movements were programmed. We don’t usually notice but the facial expressions only “work” when all the details are right. This was hard to achieve because of the properties of the silicone skin, it’s thickness and the distance to the actuators. When the android is presented in public, this leads to opposite reactions by children and adults.

While adults are fascinated how human-like the android is, children are frightened by it because they sense that something is wrong. When the automatic movements (breathing, blinking) are deactivated and Henrik switches to manual control, this flips. Now, adult and teenagers are worried but the children suddenly see the android as a toy – something they can relate to.

When used as a mannequin, customers are hesitant to touch the clothes on the android while they have no problem to touch the dummies.

Looking at the future, Prof. Scharfe sees new modes of presence. Instead of traveling to Australia for a presentation, you might send your android (or just the skin). Over time, there will be a blended presence.

Beware: His android always causes a commotion at customs (when they stuff him into the X-ray) and the cabin crew (“Who is flying?” “I thought you were!”)

Of course, that causes questions: What happens if someone gets hurt by your android? Or when someone hacks into the remote control? As the androids get smarter (= they will be able to do more things on auto pilot like finding a room in a building), are they allowed to protect themselves against theft or attack?

Do we want to allow people to build androids for recreational activities? What about sex?

What if I order an android that looks like my girl friend? My ex-girl friend? Adolf Hitler? The pope? The President of the United States? My beloved dog? A Saber-toothed tiger (scale 1:1)? A child of mine that died in an accident or from an illness (like in A.I. Artificial Intelligence)?

Can I destroy this android? Walk it to a public square and club it with a baseball bat? Run it over with a car? Shoot it? Have it beg for mercy while I’m doing this? It’s just a recording, right?

If androids get really smart, will we grant them rights? How will you feel when your android greets you in the evening with “Honey, we need to talk. There is this really cute model at the other end of the city. Oh, and I’ll keep the kids.”

Will it be murder when I wipe the memory of such an android?

As you can see, these questions are important because technology just plows on. Technology doesn’t decide what’s right or wrong, we do. Answers will come through technology but we must still ask the questions. We must stay human where it counts.

To do that, more advanced research structured need to be built. It must be more simple for researchers to find relevant information (Watson comes to mind). It must be easier to share research. To collaborate. Today, it’s hard to combine resources. Some things aren’t on-line. Instead of individual PCs, universities and high-schools need to offer cloud services for their staff and students.

And most importantly, research needs to get out of the lab. It’s a neat story that people greet Geminoid DK when they enter the lab and say goodbye even when it’s switched off. But seeing surprise in the faces of children in a crowd only happens on the street.

Related:


Jazoon 2012: CQRS – Trauma treatment for architects

4. July, 2012

A few years ago, concurrency and scalability were a hype. Today, it’s a must. But how do you write applications that scale painlessly?

Command and Query Responsibility Segregation (CQRS) is an architectural pattern to address these problems. In his talk, Allard Buijze gave a good introduction. First, some of the problems of the standard approach. Your database, everyone says, must be normalized.

That can lead to a couple of problems:

  • Historic data changes
  • The data model is neither optimized for writes nor for queries

The first problem can result in a scenario like this. Imagine you have a report that tells you the annual turnover. You run the report for 2009 in January, 2010. You run the same report again in 2011 and 2012 and each time, the annual turnover of 2009 gets bigger. What is going on?

The data model is in third normal form. This is great, no data duplication. It’s not so great when data can change over time. So if your invoices point to the products and the products point to the prices, any change of a price will also change all the existing invoices. Or when customers move, all the addresses on the invoices change. There is no way to tell where you sent something.

The solution is to add “valid time range” to each price, address, …, which makes your SQL hideous and helps to keep your bug tracker filled.

It will also make your queries slow since you will need lots and lots of joins. These joins will eventually get in conflict with your updates. Deadlocks occur.

On the architectural side, some problems will be much easier to solve if you ignore the layer boundaries. You will end up business logic in the persistence layer.

Don’t get me wrong. All these problems can be solved but the question here is: Is this amount of pain really necessary?

CQRS to the rescue. The basic idea is to use two domain models instead of one. Sounds like more work? That depends.

With CQRS, you will have more code to maintain but the code will be much more simple. There will be more tables and data will be duplicated in the database but there will never be deadlocks, queries won’t need joins in the usual case (you could get rid of all joins if you wanted). So you trade bugs for code.

How does it work? Split your application into two main parts. One part takes user input and turns that into events which are published. Listeners will then process the events.

Some listeners will write the events into the database. If you need to, you will be able to replay these later. Imagine your customer calls you because of some bug. Instead of asking your customer to explain what happened, you go to the database, copy the events into a test system and replay them. It might take a few minutes but eventually, you will have a system which is in the exact same state as when the bug happened.

Some other listeners will process the events and generate more events (which will also be written to the database). Imagine the event “checkout”. It will contain the current content of the shopping cart. You write that into the database. You need to know what was in the shopping basket? Look for this event.

The trick here is that the event is “independent”. It doesn’t contain foreign keys but immutables or value objects. The value objects are written into a new table. That makes sure that when you come back 10 years later, you will see the exact same shopping cart as the customer saw when she ordered.

When you need to display the shopping cart, you won’t need to join 8 tables. Instead, you’ll need to query 1-2 tables for the ID of the shopping cart. One table will have the header with the customer address, the order number, the date, the total and the second table will contain the items. If you wanted, you could add the foreign keys to the product definition tables but you don’t have to. If that’s enough for you, those two tables could be completely independent of any other table in your database.

The code to fill the database gets the event as input (no database access to read anything from anywhere) and it will only write to those two tables. Minimum amount of dependencies.

The code to display the cart will only need to read those two tables. No deadlocks possible.

The code will be incredibly simple.

If you make a mistake somewhere, you can always replay all the events with the fixed code.

For tests, you can replay the events. No need to a human to click buttons in a web browser (not more than once, anyway).

Since you don’t need foreign keys unless you want to, you can spread the data model over different databases, computers, data centers. Some data would be better in a NoSQL repository? No problem.

Something crashes? Fix the problem, replay the events which got lost.

Instead of developing one huge monster model where each change possibly dirties some existing feature, you can imagine CQRS as developing thousands of mini-applications that work together.

And the best feature: It allows you to retroactively add features. Imagine you want to give users credits for some action. The idea is born one year after the action was added. In a traditional application, it will be hard to assign credit to the existing users. With CQRS, you simply implement the feature, set up the listeners, disable the listeners which already ran (so the action isn’t executed again) and replay the events. Presto, all the existing users will have their credit.

Related:


Jazoon 2012: Spring Data JPA – Repositories done right

4. July, 2012

Oliver Gierke presented “Spring Data JPA – Repositories done right” at the Jazoon. The motto of Spring Data could be “deleted code doesn’t contain bugs.” From the web site:

Spring Data makes it easier to build Spring-powered applications that use new data access technologies such as non-relational databases, map-reduce frameworks, and cloud based data services as well as provide improved support for relational database technologies.

Spring Data is an umbrella open source project which contains many subprojects that are specific to a given database. The projects are developed by working together with many of the companies and developers that are behind these exciting technologies.

When you use any form of JPA, you will eventually end up with DAOs which contain many boring methods: getById(), getByName(), getByWhatever(), save(), delete(). How do you like this implementation:

interface MyBaseRepository<T, ID extends Serializable> extends Repository<T, ID> {
  T findOne(ID id);
  T save(T entity);
}

interface UserRepository extends MyBaseRepository {
  User findByEmailAddress(EmailAddress emailAddress);
}

“Wait a minute,” I can hear you think, “these are just interfaces. Where is the implementation?”

That is the implementation. You can now inject those interfaces as DAOs and call the methods. Behind the scenes, Spring will generate a proxy for you that actually implements the methods. 0 lines of code for you to write for 95% of the basic DAO methods.

The queries can even be more complex:

List findByEmailAddressAndLastname(EmailAddress emailAddress, String lastname);

The method will generate SQL that searches by those two columns. See the documentation for more examples how you can write queries that use joins.

On top of that, they built a REST exporter which exposes your DAO interfaces with a REST API to a web browser plus a web front end to explore the repository, to run the queries and to create new objects. Impressive.