Scala on Android and stuff: lessons learned

June 1st, 2014 3 comments

I play Role-Playing since I’m eleven, and me and my posse still play once or twice a year. Recently, they decided to play Earthdawn again, a game we didn’t play since more than 15 years! That triggered my desire to create an application to roll all those strangely-shaped dice. And to combine the useful with the pleasant, I decided to use technologies I’m not really familiar with: the Scala language, the Android platform and the Gradle build system.

The first step was to design a simple and generic die-rolling API in Scala, and that was the subject of one of my former article. The second step was to build upon this API to construct something more specific to Earthdawn and design the GUI. Here’s the write up of my musings in this development.

Here’s the a general component overview:

Component overview

Reworking the basics

After much internal debate, I finally changed the return type of the roll method from (Rollable[T], T) to simply T following a relevant comment on reddit. I concluded that it’s to the caller to get hold of the die itself, and return it if it wants. That’s what I did in the Earthdawn domain layer.

Scala specs

Using Scala meant I also dived into Scala Specs 2 framework. Specs 2 offers a Behavior-Driven way of writing tests as well as integration with JUnit through runners and Mockito through traits. Test instances can be initialized separately in a dedicated class, isolated of all others.

My biggest challenge was to configure the Maven Surefire plugin to execute Specs 2 tests:

<plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.17</version>
    <configuration>
        <argLine>-Dspecs2.console</argLine>
            <includes>
                <include>**/*Spec.java</include>
            </includes>
    </configuration>
</plugin>

Scala + Android = Scaloid

Though perhaps disappointing at first, wanting to run Scala on Android is feasible enough. Normal Java is compiled to bytecode and then converted to Dalvik-compatible Dex files. Since Scala is also compiled to bytecode, the same process can also be applied. Not only can Scala be easily be ported to Android, some frameworks to do that are available online: the one which seemed the most mature was Scaloid.

Scaloid most important feature is to eschew traditional declarative XML-based layout in favor of a Scala-based Domain Specific Language with the help of implicit:

val layout = new SLinearLayout {
  SButton("Click").<<.Weight(1.0f).>>
}

Scaloid also offers:

  • Lifecycle management
  • Implicit conversions
  • Trait-based hierarchy
  • Improved getters and setters
  • etc.

If you want to do Scala on Android, this is the prject you’ve to look at!

Some more bitching about Gradle

I’m not known to be a big fan of Gradle – to say the least. The bigest reason however, is not because I think Gradle is bad but because using a tool based on its hype level is the worst reason I can think of.

I used Gradle for the API project, and I must admit it it is more concise than Maven. For example, instead of adding the whole maven-scala-plugin XML snippet, it’s enough to tell Gradle to use it with:

apply plugin: 'scala'

However the biggest advantage is that Gradle keeps the state of the project, so that unnecessary tasks are not executed. For example, if code didn’t change, compilation will not be executed.

Now to the things that are – to put in politically correct way, less than optimal:

  • First, interestingly enough, Gradle does not output test results in the console. For a Maven user, this is somewhat unsettling. But even without this flaw, I’m afraid any potential user is interested in the test ouput. Yet, this can be remedied with some Groovy code:
    test {
        onOutput { descriptor, event ->
            logger.lifecycle("Test: " + descriptor + ": " + event.message )
        }
    }
  • Then, as I wanted to install my the resulting package into my local Maven repository, I had to add the Maven plugin: easy enough… This also required Maven coordinates, quite expected. But why am I allowed to install without executing test phases??? This is not only disturbing, but I cannot accept any rationale to allow installing without testing.
  • Neither of the previous points proved to be a show stopper, however. For the Scala-Android project, you might think I just needed to apply both scala and android plugins and be done with that. Well, this is wrong! It seems that despite Android being showcased as the use-case for Gradle, scala and android plugins are not compatible. This was the end of my Gradle adventure, and probably for the foreseeable future.

Testing with ease and Genymotion

The build process i.e. transforming every class file into Dex, packaging them into an .apk and signing it takes ages. It would be even worse if using the emulator from Google Android’s SDK. But rejoice, Genymotion is an advanced Android emulator that not only very fast but easy as pie to use.

Instead of doing an adb install, installing an apk on Genymotion can be achieved by just drag’n’dropping it on the emulated device. Even better, it doesn’t require first uninstalling the old version and it launches the application directly. Easy as pie I told you!

Conclusion

I have now a working Android application, complete with tests and repeatable build. It’s not much, but it gets the job done and it taught me some new stuff I didn’t know previously. I can only encourage you to do the same: pick a small application and develop it with languages/tools/platforms that you don’t use in your day-to-day job. In the end, you will have learned stuff and have a working application. Doesn’t it make you feel warm inside?

 

Categories: Java Tags: , , , ,

My summary of JEEConf 2014

May 26th, 2014 No comments

2014 saw my first participation in JEEConf (Kiev, Ukrain) as well as my farthest travel East so far. I’m so glad I could attend! As a speaker, I was not only shown Kiev during a guided tour, I also had the privilege to attend a true traditional Ukrainian banya (bath), complete with wet leaves, cold water and full head-to-toe scrubbing. I do not know if there’s a tradition of Ukrainian hospitality, but if there’s one, it was more than upheld! As conferences go, I was also very happy to meet new people from all over the world.

Apart from these nice asides, I also followed the following sessions:

Easy Distributed Systems using Hazelcast by Peter Veentjer
A presentation of Hazelcast, an in-memory data grid. This presentation was focused on Hazelcast main capabilities and usage: caching and clustering using distributed data structures. The format was especially interesting, as the speaker used small shell scripts showing examples of the capability just presented. As I attended a presentation about Hazlecast more than one year ago, this presentation served as a nice refresher for me.
Mobile functional testing with Arquillian Droidium by Stefan Miklosovic
Given I’ve currently writing Integration Testing from the Trenches, I admit I was expecting much from this talk since Integration Testing and End-to-end Testing are somehow related. I learned new tools related to end-to-end testing on mobile I didn’t know of previously, but to be frank, 50 minutes were too long for the information provided: I could have learned the same amount of information in a blog post much quicker. I don’t know if this feeling comes from my high expectations or the speaker’s performance, but the fact is we didn’t met.
Holding down your Technical Debt with SonarQube by Patroklos Papapetrou
I think I know SonarQube very well as I’m an early adopter, but I attended this talk nonetheless because I wanted to Patroklos Papapetrou’s performance first-hand. I was not disappointed: not only does he know the subject deeply, he’s also a very good presenter of Code Quality Analysis in general and SonarQube in particular. Icing on the cake, it appears we share opinions on the subject though we never me before nor talked about that. Highly recommended talk to attend to!
Reflection Madness by Heinz Kabutz
A list of reflection tricks, this talk’s conclusion was not to use it unless really really (really!) required, as it can lead to doing stuff that cross the boundaries of the langage (e.g. adding a new enum value at runtime). It must have been a very interesting presentation, but at this point, the banya of the day before had worn me out and I confess I slept for most of the talk.

I also had the privilege of presenting two talks myself:

I think both received a warm welcome from the audience, but I cannot be the judge of that, of course.

JEEConf is really a one of a kind conference. For example, one of the sponsor had the crazy idea to bring a live racoon (though I wouldn’t have dared kiss it like the guy: the trainer had numerous bite marks on his hands). This is something highly unusual in tech conference! I enjoyed the 2014 edition I really hope to join JEEConf 2015: since the date is already set to May 22-23, you know what to do if you want it too!

PS: now I have this song playing in my head endlessly – bonus points for a good translation (Google Translate is not a good one)

Categories: Event Tags:

Dead simple API design for Dice Rolling

May 18th, 2014 No comments

I wanted to create a small project where I could achieve results fairly quickly in technologies I never (or rarely) use. At the Mix-IT conference, I realized the few stuff I learned in Scala had been quickly forgotten. And I wanted wanted to give Gradle a try, despite my regular bitching about it. Since my Role-Playing crew wants to play Earthdawn (we stopped for like 20 years), I decided to create a Dice Roller app in Scala, running on Android (all of my friends have Android devices) and built with Gradle (I promised it at Devoxx).

I soon realized that there were a definite Dice Rolling API that could be isolated from the rest. Rolling a die in Earthdawn has some definite quirk – if you roll the highest result, you re-roll and add it to the result and so on until you roll not the highest, but the basics of rolling a die is similar in every system. It was time to design an extensible API. By extensible, I’m talking about something I could re-use in every RPG system.

I’d already been trying to create such an API and the root of it is the roll() method signature. Before, I used 2 methods in conjunction:

roll:Unit

getResult:T

This is a big mistake, as implementations will require state handling! This created plenty of problems, among them:

  • creating instances each time I needed to roll
  • calling 2 different methods in the right order, also known as time coupling

This time, having learned from my mistake, I replaced that with the following:

roll:T

This time, implementation can (and will) do without state.

The next design decision is about the result type. I’m not really sure about this point, but I formerly returned only the result. This time, I returned the result as well as the object itself, so I can pass both along and it let users know which die was rolled as well as the result. This is possible without creating a new class structure thanks to Scala’s out-of-the-box Tuple2. My final interface looks like:

trait Rollable[T] {
  roll:(Rollable[T],T)
}

As I’m aiming toward RPG, I just need to set the sides number as a parameter (to be able to create those strange 12 and 20-sided dice). A naive implementation is very straightforward:

class Die (val sides:Int)extends Rollable[Int] {

  var random:SecureRandom

  override def roll:(Die, Int) = (this, random.nextInt(sides) + 1)
}

Seems good enough. However, how can we test this design? If I need to build upon this, I will need to be able to set desired results: in this case, this is not cheating, it’s faking! As it turns out, I need to pass the random as a constructor parameter (but without a getter).

class Die (val sides:Int, random:Random)extends Rollable[Int] {

  override def roll:(Die, Int) = (this, random.nextInt(sides) + 1)
}

That’s better, but only marginally. With this code, I need to pass the random parameter each time I create a new instance. A slightly better option would be to add a constructor with a default SecureRandom instance. However, what if the next Java version offers an even better Random implementation? Or if the API user prefers to rely on an external secure entropy source? It would he would still have to pass the new improved random for each call – back to square one. Fortunately, Scala offers this one nice language feature called implicit. With implicit, API users only have to reference the random generator once in a file to use it everywhere. The improved design now looks like:

class Die (val sides:Int)(implicit random:Random) extends Rollable[Int] {
  override def roll:(Die, Int) = (this, random.nextInt(sides) + 1)
}

object SecureDie {
  implicit val random = new SecureRandom
}

Callers then just need to import the provided random, or to use their own and call the constructor with the desired sides number:

import SecureDie.random // or import MyQuantumRandomGenerator.random

val die = new Die(6)

The final step is to create Scala object (singletons) in order to offer a convenient API. This is only possible since we designed our classes with no state:

import SecureDie.random

object d3 extends Die(3)
object d4 extends Die(4)
object d6 extends Die(6)
object d8 extends Die(8)
object d10 extends Die(10)
object d12 extends Die(12)
object d20 extends Die(20)
object d100 extends Die(100)

Users now just need to call d6.roll to roll dice!

With a simple domain, I showed how Scala’s most basic feature can really help getting a clean design. Results are available on Github.

In the next article I will detail how I got Scala to run on Android and pitfalls I stumbled upon. Spoiler: there will some Gradle involved…

Categories: Development Tags: ,

Playing with constructors

May 4th, 2014 1 comment

Immutability is a property I look after when designing most of my classes. Achieving immutability requires:

  • A constructor initializing all attributes
  • No setter for those attributes

However, this design prevents or makes testing more complex. In order to allow (or ease) testing, a public no-arg constructor is needed.

Other use-cases requiring usage of a no-arg constructor include:

  • De-serialization of serialized objects
  • Sub-classing with no constructor invocation of parent classes
  • etc.

There are a couple of solutions to this.

1. Writing a public no-arg constructor

The easiest way is to create a public no-arg constructor, then add a big bright Javadoc to warn developers not to use. As you can imagine, in this case easy doesn’t mean it enforces anything, as you are basically relying on developers willingness to follow instructions (or even more on their ability to read them in the first place – a risky bet).

The biggest constraint, however, is that it you need to be able to change the class code.

2. Writing a package-visible no-arg constructor

A common approach used for testing is to change visibility of a class private methods to package-visible, so they can be tested by test classes located in the same package. The same approach can be used in our case: write a package-visible no-arg constructor.

This requires the test class to be in the same package as the class which constructor has been created. As in case 1 above, you also need to change the class code.

3. Playing it Unsafe

The JDK is like a buried treasure: it contains many hidden and shiny features; the sun.misc.Unsafe class is one of them. Of course, as both its name and package imply, its usage is extremely discouraged. Unsafe offers a allocateInstance(Class<?>) method to create new instances without calling any constructors whatsoever, nor any initializers.

Note Unsafe only has instance methods, and its only constructor private… but offers a private singleton attribute. Getting a reference on this attribute requires a bit of reflection black magic as well as a lenient security manager (by default).

Field field = Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
Unsafe unsafe = (Unsafe) field.get(null);

java.sql.Date date = (java.sql.Date) unsafe.allocateInstance(java.sql.Date.class);
System.out.println(date);

Major constraints of this approach include:

  • Relying on a class outside the public API
  • Using reflection to access a private field
  • Only available in Oracle’s HotSpot JVM
  • Setting a lenient enough security manager

4. Objenesis

Objenesis is a framework which sole goal is to create new instances without invoking constructors. It offers an abstraction layer upon the Unsafe class in Oracle’s HotSpot JVM. Objenesis also works on different JVMs including OpenJDK, Oracle’s JRockit and Dalvik (i.e. Android) in many different versions by using strategies adapted to each JVM/version pair.

The above code can be replaced with the following:

Objenesis objenesis = new ObjenesisStd();
ObjectInstantiator instantiator = objenesis.getInstantiatorOf(java.sql.Date.class);

java.sql.Date date = (java.sql.Date) instantiator.newInstance();
System.out.println(date);

Running this code on Oracle’s HotSpot will still require a lenient security manager as Objenesis will use the above Unsafe class. However, such requirements will be different from JVM to JVM, and handled by Objenesis.

Conclusion

Though a very rare and specialized requirement, creating instances without constructor invokation might sometimes be necessary. In this case, the Objenesis framework offers a portable and abstract to achieve this at the cost of a single additional dependency.

Categories: Java Tags:

The Visitor design pattern

April 27th, 2014 5 comments

I guess many people know about the Visitor design pattern, described in the Gang of Four’s Design Patterns: Elements of Reusable Object-Oriented Software book. The pattern itself is not very complex (as many design patterns go):

Visitor UML class diagram

I’ve known Visitor since ages, but I’ve never needed it… yet. Java handles polymorphism natively: the method call is based upon the runtime type of the calling object, not on its compile type.

interface Animal {
    void eat();
}
public class Dog implements Animal {
    public void eat() {
        System.out.println("Gnaws bones");
    }
}

Animal a = new Dog();
a.eats(); // Prints "Gnaws bones"

However, this doesn’t work so well (i.e. at all) for parameter types:

public class Feeder {
    public void feed(Dog d) {
        d.eat();
    }
    public void feed(Cat c) {
        c.eat();
    }
}

Feeder feeder = new Feeder();
Object o = new Dog();
feeder.feed(o); // Cannot compile!

This issue is called double dispatch as it requires calling a method based on both instance and parameter types, which Java doesn’t handle natively. In order to make it compile, the following code is required:

if (o instanceof Dog) {
    feeder.feed((Dog) o);
} else if (o instanceof Cat) {
    feeder.feed((Cat) o);
} else {
    throw new RuntimeException("Invalid type");
}

This gets even more complex with more overloaded methods available – and exponentially so with more parameters. In maintenance phase, adding more overloaded methods requires reading the whole if stuff and updating it. Multiple parameters are implemented through embedded ifs, which is even worse regarding maintainability. The Visitor pattern is an elegant way to achieve the same, with no ifs, at the expense of a single method on the Animal class.

public interface Animal {
    void eat();
    void accept(Visitor v);
}

public class Cat {
    public void eat() { ... }
    public void accept(Visitor v) {
        v.visit(this);
    }
}

public class Dog {
    public void eat() { ... }
    public void accept(Visitor v) {
        v.visit(this);
    }
}

public class FeederVisitor {
    public void visit(Cat c) {
        new Feeder().feed(c);
    }
    public void visit(Dog d) {
        new Feeder().feed(d);
    }
}

Benefits:

  • No evaluation logic anywhere
  • Only adherence between Animal and FeederVisitor is limited to the visit() method
  • As a corollary, when adding new Animal subtypes, the Feeder type is left untouched
  • When adding new Animal subtypes, the FeederVisitor type may implement an additional method to handle it
  • Other cross-cutting logic may follow the same pattern, e.g. a train feature to teach animals new tricks

It might seem overkill to go to such lengths for some simple example. However, my experience taught me that simple stuff as above are fated to become more complex with time passing.

Categories: Java Tags:

Introduction to Mutation Testing

April 20th, 2014 2 comments

Last week, I took some days off to attend Devoxx France 2014 3rd edition. As for oysters, the largest talks do not necessarily contain the prettiest pearls. During this year’s edition, my revelation came from a 15 minutes talk by my friend Alexandre Victoor, who introduced me to the wonders of Mutation Testing. Since I’m currently writing about Integration Testing, I’m very much interested in Testing flavors I don’t know about.

Experience software developers know not to put too much faith in code coverage metrics. Reasons include:

  • Some asserts may have been forgotten (purposely or not)
  • Code with no value, such as getters and setters, may have been tested
  • And so on…

Mutation Testing tries to go beyond code coverage metrics to increase one’s faith in tests. Here’s is how this is achieved: random code changes called mutations are introduced in the tested code. If a test still succeed despite a code change, something is definitely fishy as the test is worth nothing. As an example is worth a thousand words, here is a snippet that needs to be tested:

public class DiscountEngine {

    public Double apply(Double discount, Double price) {

        return (1 - discount.doubleValue()) * price.doubleValue();
    }
}

The testing code would be akin to:

public class DiscountEngineTest {

    private DiscountEngine discounter;

    @BeforeMethod
    protected void setUp() {

        discounter = new DiscountEngine();
    }

    @Test
    public void should_apply_discount() {

        Double price = discounter.apply(new Double(0.5), new Double(10));

        assertEquals(price, new Double(5));
    }
}

Now, imagine line 16 was forgotten: results from DiscountEngineTest will still pass. In this case, however, wrong code updates in the DiscountEngine would not be detected. That’s were mutation testing enters the arena. By changing DiscountEngine, DiscountEngineTest will still pass and that would mean nothing is tested.

PIT is a Java tool offering mutation testing. In order to achieve this, PIT creates a number of alternate classes called mutants, where the un-mutated class is the initial source class. Those mutants will be tested against existing tests targeting the original class. If the test still pass, well, there’s a problem and the mutant is considered to have survived; if not, everything is fine as the mutant has been killed. For a single un-mutated class, this goes until the mutant gets killed or all tests targeting the class have been executed and it is still surviving.

Mutation testing in general and PIT in particular has a big disadvantage: the higher the number of mutants for a class, the higher the confidence in the results, but the higher the time required to execute tests. Therefore, it is advised to run Mutating Testing only on nightly builds. However, this cost is nothing in comparison to having trust in your tests again…

Out-of-the-box, PIT offers:

  • Maven integration
  • Ant integration
  • Command-line

Also, Alexandre has written a dedicated plugin for Sonar.

Source code for this article can be found in IntelliJ/Maven format there.

Categories: Java Tags: ,

Can we put an end to this ‘Estimate’ game of fools?

April 13th, 2014 4 comments

When I was a young software programmer, I had to develop features with estimates given by more senior programmers. If more time was required for the task, I had to explain the reasons – and I’d better be convincing about that. After some years, I became the one who had to provide feature estimates, but this did no mean it was easier: if the development team took more time to develop, I had to justify it to my management. Now, after even more years, I have to provide estimates for entire projects, not just fine-grained features.

But in essence, what do we need estimates for? For big enough companies, those are required by internal processes. Whatever the process, it goes somewhat along these lines: in order to start a project, one needs estimate in order to request a budget, then approved (or not) by management.

Guess what? It doesn’t work, it never did and I’m pretty sure it never will.

Note: some organizations are smart enough to realize this and couple estimates with a confidence factor. Too bad this factor has no place in an Excel sheets and that it is lost at some point during data aggregation :-(

Unfortunately, my experience is the following: estimates are nearly always undervalued! Most of the time, this has the following consequences, (that might not be exclusive):

  1. In general, the first option is to cancel all planned vacations of team members. The second step is to make members work longer hours, soon followed by cutting on week-ends so they work 6/7. While effective in the very short-term, it brings down the team productivity very soon afterwards. People need rest and spirit – and developers are people too!
  2. After pressure on the development team, it’s time to negotiate. In this phase, project management goes to the customer and try to strike a deal to remove parts of the project scope (if it was ever defined…). However, even if the scope is reduced, it generally is not enough to finish on budget and on time.
  3. The final and last step is the most painful: go back to the powers that be, and ask for more budget. It is painful for the management, because it’s acknowledging failure. At this point, forget the initial schedule.
  4. Meanwhile and afterwards, management will communicate everything is fine and goes according to the plan. Human nature…

In some cases (e.g. a bid), that’s even worse, as the project manager will frequently (always?) complain that those estimates are too high and pressuring you to get lower ones, despite the fact that lowering estimates never lowers workload.

You could question why estimates are always wrong. Well, this is not the point of this post but my favorite answer is that Civil Engineering is around 5,000 years old and civil engineers also rarely get their estimates right. Our profession is barely 50 years old and technology and methodologies keep changing all the time.

I’m not a methodologist, not a Project Manager, not a Scrum Master… only a Software Architect. I don’t know if Agile will save the world; however, I witnessed first-hand every upfront estimate attempt as a failure. I can only play this game of fools for so long, because we’re all doomed to loose by participating in it.

My recap of JavaLand

March 30th, 2014 No comments

This week, I have been attending the first edition of JavaLand in Brühl, organized by Oracle User Groups of Germany, Austria and Switzerland. Here’s quick recap of my experience there.

The first thing that deserves special mention is that the event took place in a theme park. Picture this, an empty theme park (or more likely a part of it) only opened for specially privileged geeks (like me).

You can imagine that some people doing this stuff non-stop, like 8 times in a row – where in standard conditions you wait like 1.5 hours to enjoy it. Pretty crazy, huh?

Now, the serious stuff: sessions I attended. Note that only could choose from English sessions, as my German is quite poor.

Is It A Car? Is It A Computer? No, It’s a Raspberry Pi Java Carputer by Simon Ritter
A feedback on how to wire a Raspberry Pi into one’s car and get car metrics – such as torque, nicely shown on a graphic display. Doing that require some hands-on manipulation, as well as some hardware knowledge, but if you happen to have both, you can really create great stuff. Despite me having none of them, I learned that modern-day cars provide interfaces to read data from.
JavaFX Apps in the Real World
Six talkers for a 45 minutes slot, of various interest. The most stunning piece was a demo for a JavaFX application involving Sudoku grids. That app is able to parse a Sudoku grid presented to a connected webcam, resolve it and then display the final result on the video image embedded in the app!
55 New Features in Java SE 8 by Simon Ritter
A nice refresher of all new stuff brought by Java 8. Of course, lambdas were (again) much talked about, but also static and default methods for interfaces as well as the new APIs (including Date & Time) and various enhancements. This is was a very worthwhile talk in a limited amount of time.
JVM and application bottlenecks troubleshooting with simple tools by Daniel Witkowski
Description of the JVM, its memory model (Eden, Young Generation, Old Generation, …) and its available options. Despite the talker warning and apparent good will, I couldn’t quite shake the feeling this was a pep talk: the conclusion was JVM tuning is hard (as if people didn’t know) and the simple tool referenced in the title is a commercial product.
Modular JavaScript by Sander Mak, Paul Bakker
Real interesting stuff about designing JavaScript applications with modularity in mind. Basically, a detailed typology of JavaScript modularity solutions according to different locations (server, client and both) was presented. In particular, the talk described Asynchronous Module Definition (AMD) and the RequireJS implementation. I definitely have to re-read slides, once they are available.
Spring 4, Java EE 7 or Both? by Ivar Grimstad
This talk picked my curiousity. After having presented Spring 4 and JavaEE 7 in the context of web applications, the speaker showed leads on how to develop applications integration both Spring 4 and JavaEE 7. However, IMHO, the talk missed the real point: why would do that? I would have expected this to have been the main point of the talk…
Apache TomEE, JavaEE Web Profile and More on Tomcat by David Blevins
Presentation of the famed TomEE (pronounced Tommy) application server, as well its backing company, Tomitribe. I did learn nothing new, but it was a pleasure to see David Blevins on stage!
The Adventurous Developer’s Guide to Application Servers by Simon Maple & Oliver White
A really good show about Rebel Labs Great Java Application Server Debate, with interactive data from the audience set back into the presentation. I already read the report, but the presentation was really entertaining.
Testing the Enterprise Layers: The ABCs of Integration Testing by Andrew Lee Rubinger
A presentation built around the Continuous Enterprise Development book, written by the speaker and Aslak Knutsen. The latter presents the basics as well as the Arquillian tool. I really have to read the book!

Myself, I presented Cargo Culting and Memes in JavaLand (I’ll let people say what they thought about it in the comments).

All in all, I have to say that for a first edition, it was really interesting as well as packed with geekyness. See you there next year, and Jatumba!

Categories: Event Tags:

Vaadin and Spring integration through JavaConfig

March 9th, 2014 No comments

When I wrote the first version of Learning Vaadin, I hinted at how to integrate Vaadin with the Spring framework (as well as CDI). I only described the overall approach by providing a crude servlet that queried the Spring context to get the Application instance.

At the time of Learning Vaadin 7, I was eager to work on add-ons the community provided in terms of Spring integration. Unfortunately, I was sorely disappointed, as I found only few and those were lacking in one way or another. The only stuff mentioning was an article by Petter Holmström – a Vaadin team member (and voluntary fireman) describing how one should do to achieve Vaadin & Spring integration. It was much more advanced than my own rant but still not a true ready-to-be-used library.

So, when I learned that both Vaadin and Spring teams joined forces to provided a true integration library between two frameworks I love, I was overjoyed. Even better, this project was developed by none other than Petter for Vaadin and Josh Long for Pivotal. However, the project was aimed at achieving DI through auto-wiring. Since JavaConfig makes for a cleaner and more testable code, I filled an issue to allow that. Petter kindly worked on this, and in turn, I spent some time making it work.

The result of my experimentation with Spring Boot Vaadin integration has been published on morevaadin.com, a blog exclusively dedicated to Vaadin.

Categories: JavaEE Tags: , ,

Teaser for Cargo Culting and Memes in JavaLand

March 2nd, 2014 No comments

At the end of the month, I will be speaking at the JavaLand conference in a talk called “Cargo Culting and Memes in JavaLand”. Without revealing too much about this talk, here is a teaser article that I hope will make you book a place at JavaLand if you have not done so at this point.

Basically, Cargo Culting is a way to reproduce outer aspect, in order to gain some properties. It became famous just after WWII when primitive tribes from the Pacific began building makeshift radios and airports, as a way to attract planes full of cargo – hence the name. In software, this is unfortunately more widespread than expected in regard to our scientific and rational background.

Take Data Transfer Object also known as Transfer Object, for example. This pattern was originally proposed as a way to transfer business data despite limitations of Entity EJBs. Strangely, despite Entity Beans never having been extensively used in the past(to says the least), and being used even less (read – not at all) currently, DTOs are like a Pavlovian reaction to many a software developer when setting up a new Java Web project.

Cargo Culting is bad, but is just applying a technique with no understanding of the context. It can be mitigated and even removed completely if Cultists are willing to listen to reason and improve their skills. Memes up the ante to another whole new level as they are based on faith – and how can you convince a faithful to renounce his faith? An example of interaction between a Software Engineer driven by logic and one following a Meme would go like this:

- Good code is self-documented, it doesn’t require comments!
- But obviously, this snippet require comments…
- Then it’s bad code!!!

There’s no way to convince one party or the other that there’s might be a kernel of truth in the opposite party point of view.

If at this point, you want to know more, you know what to do: meet me at JavaLand for the whole talk!

Categories: Development Tags: