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

April 13th, 2014 1 comment

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:

Chaining URL View resolvers in Spring MVC

February 16th, 2014 3 comments

Standard Java EE forward to internal resources go something like this:

public class MyServlet extends HttpServlet {

  public void doGet(HttpServletRequest req, HttpServletResponse resp) {

    req.getRequestDispatcher("/WEB-INF/page/my.jsp").forward(req, resp);
  }
}

Admittedly, there’s no decoupling between the servlet code and the view technology, even not with the JSP location.

Spring MVC introduces the notion of ViewResolver. The controller just handles logical names, mapping between the logical name and the actual resource is handled by the ViewResolver. Even better, controllers are completely independent from resolvers: just registering the latter in the Spring context is enough.

Here’s a very basic controller, notice there’s no hint as to the final resource location.

@Controller

public class MyController {

  @RequestMapping("/logical")
  public String displayLogicalResource() {

    return "my";
  }
}

Even better, there’s nothing here as to the resource nature; it could be a JSP, an HTML, a Tiles, an Excel sheet, whatever. Each has a location strategy based on a dedicated ViewResolver. The most used resolver is the InternalResourceViewResolver; it meant to forward to internal resources, most of the time, JSPs. It is initialized like this:

@Bean
  public ViewResolver pageViewResolver() {

    InternalResourceViewResolver resolver = new InternalResourceViewResolver();

    resolver.setPrefix("/WEB-INF/page/");
    resolver.setSuffix(".jsp");

  return resolver;
}

Given this view resolver available in the Spring context, the logical name "my" will tried to be resolved with the "/WEB-INF/page/my.jsp" path. If the resource exists, fine, otherwise, Spring MVC will return a 404.

Now, what if I’ve different folders with JSP? I expect to be able to configure two different view resolvers, one with a certain prefix, the other with a different one. I also expect them to be checked in a determined order, and to fallback from the first to the last. Spring MVC offers multiple resolvers with deterministic order, with a big caveat: it does not apply to InternalResourceViewResolver!

Quoting Spring MVC Javadoc:

When chaining ViewResolvers, an InternalResourceViewResolver always needs to be last, as it will attempt to resolve any view name, no matter whether the underlying resource actually exists.

This means I cannot configure two InternalResourceViewResolver in my context, or more precisely I can but the first will terminate the lookup process. The reasoning behind (as well as the actual code), is that the resolver gets an handle on the RequestDispatcher configured with the resource path. Only much later is the dispatcher forwarded to, only to find that it does not exist.

To me, this is not acceptable as my use-case is commonplace. Furthermore, configuring only "/WEB-INF" for prefix and returning the rest of the path ("/page/my")  is out of the question as it ultimately defeats the purpose of decoupling the logical name from the resource location. Worst of all, I’ve seen controller code such as the following to cope with this limitation:

return getViews().get("my"); // The controller has a Map view property with "my" as key and the complete path as the "value"

I think there must be some more Spring-ish way to achieve that and I’ve come to what I think is an elegant solution in the form of a ViewResolver that checks if the resource exists.

public class ChainableUrlBasedViewResolver extends UrlBasedViewResolver {

  public ChainableUrlBasedViewResolver() {

      setViewClass(InternalResourceView.class);
  }

  @Override
  protected AbstractUrlBasedView buildView(String viewName) throws Exception {

    String url = getPrefix() + viewName + getSuffix();

    InputStream stream = getServletContext().getResourceAsStream(url);

    if (stream == null) {

      return new NonExistentView();
    }

    return super.buildView(viewName);
  }

  private static class NonExistentView extends AbstractUrlBasedView {

    @Override
    protected boolean isUrlRequired() {

        return false;
    }

    @Override
    public boolean checkResource(Locale locale) throws Exception {

      return false;
    }

    @Override
    protected void renderMergedOutputModel(Map<String, Object> model,
                                           HttpServletRequest request,
                                           HttpServletResponse response) throws Exception {

      // Purposely empty, it should never get called
    }
  }
}

My first attempt was trying to return null within the buildView() method. Unfortunately, there was some NPE being thrown later in the code. Therefore, the method returns a view that a. tells caller that the underlying resource does not exist b. does not allow for its URL to be checked (it also fails at some point if this is not set).

I’m pretty happy with this solution, as it enables me to configure my context like that:

@Configuration
@EnableWebMvc
@ComponentScan(basePackages = "ch.frankel.blog.spring.viewresolver.controller")
public class WebConfig {

  @Bean
  public ViewResolver pageViewResolver() {

    UrlBasedViewResolver resolver = new ChainableUrlBasedViewResolver();

    resolver.setPrefix("/WEB-INF/page/");
    resolver.setSuffix(".jsp");
    resolver.setOrder(0);

    return resolver;
  }

  @Bean
  public ViewResolver jspViewResolver() {

    InternalResourceViewResolver resolver = new InternalResourceViewResolver();

    resolver.setPrefix("/WEB-INF/jsp/");
    resolver.setSuffix(".jsp");
    resolver.setOrder(1);

    return resolver;
  }
}

Now, I’m pretty well inside Spring philosophy: I’m completely decoupled, and I’m using Spring nominal resolver ordering. The only con is that one resource can shadow another another by having the same logical name pointing to different resources given different view resolvers. As it is already the case with multiple view resolvers, I’m ready to accept the risk.

A showcase project can be found here in IntelliJ IDEA/Maven format.

Categories: JavaEE Tags:

Reusing front-end components in web applications

February 9th, 2014 2 comments

In the Java SE realm, GUI components are based on Java classes with the help of libraries such as AWT, Swing or the newer JavaFX. As such, they can be shared across projects, to be inherited and composed.

Things are entirely different in the Java EE world, as GUI components are completely heterogeneous in nature: they may include static HTML pages, JavaScript files, stylesheets, images, Java Server Pages or Java Server Faces. Solutions to share these resources must be tailored to each type.

  1. Since Servlet 3.0 (Java EE 6), static resources, such as HTML, JavaScript, CSS and images can be shared quite easily. Those resources need to be packaged into the META-INF/resources folder of a JAR. At this point, putting the JAR inside the WEB-INF/lib folder of a webapp will make any such resource available at the webapp’s context root.
    A disadvantage of this approach is that shared resources are also exposed publicly, including JSP that are not meant to be.
  2. An alternative to share resources protected under WEB-INF, which is also available before Servlet 3.0, is to leverage the build tool. In this case, Maven offers a so-called overlay feature through the Maven WAR plugin. This requires both adding the WAR containing resources and dependencies as well as some POM configuration.
    <project...>
      ...
      <build>
        <plugins>
          <plugin>
            <artifactId>maven-war-plugin</artifactId>
            <version>2.4</version>
            <configuration>
              <overlays>
                <overlay>
                  <groupId>ch.frankel.blog</groupId>
                  <artifactId>resources</artifactId>
                </overlay>
              </overlays>
            </configuration>
          </plugin>
        </plugins>
      </build>
      <dependencies>
        <dependency>
          <groupId>ch.frankel.blog</groupId>
          <artifactId>resources</artifactId>
          <version>1.0.0</version>
          <type>war</type>
          <scope>runtime</scope>
        </dependency>
      </dependencies>
    </project>

    At this point, resources belonging to the dependent WAR artifact will be copied to the project at build-time. Not resources existing in the project may be overwritten… on purpose or by accident. The biggest disadvantage of WAR overlays, however, is that resources have to be packaged in the WAR artifact while corresponding classes have to be in another JAR artifact.

  3. I’ve not much experience in Java Server Faces technology, but it seems sharing pages across different webapps requires the use of ResourceResolver.
  4. Finally, some frameworks are entirely built toward sharing GUI resources. For exaemple, with Vaadin, GUI components are based on Java classes, as for Java SE, thus making those components inheritable and composable. Furthermore, using images can be achieved in a few lines of code and is easy as pie:
    Image image = new Image("My image", new ClassResource("ch/frankel/blog/resources/image.png"));
    ui.setContent(image);

I think Java EE is sadly lacking regarding reuse of front-end resources. Of course, one can choose client-based frameworks to overcome this limitation though they bring their own pros and cons. In all cases, ease of reuse should be an important criteria for choosing front-end technologies.

Categories: JavaEE Tags: ,

Doubly geeky stuff: AngularJS meets Marvel comics

February 2nd, 2014 4 comments

Let’s face it: despite us having very serious titles like Principal Consultant, Senior Software Architect or Team Leader, most of us are geeks through and through. Each shows it in a different way; some fiddle with machines, some like cosplay, me I like comic books.

When I learned that Marvel Comics provided a developers REST API, I couldn’t resist playing with it. I’m more of a backend guy, and though I love Vaadin, using it to call REST services would be like proxying with no added value. Though I’ve no prior experience with AngularJS, this is a much more relevant option in this case. This article is by no mean a how-to article, on the contrary, it contains many questions and some answers I’ve come across. In no particular order, those are the following:

Using webjars with Maven
Front-end is front-end, period. I used Maven with webjars to get AngularJS and Bootstrap dependencies, but it doesn’t add anything. Worse, it adds an unecessary build process. It would have been to better to use a relevant tool like Bower. Lesson learned: use tools tailored to your language.
Using Tomcat inside IntelliJ IDEA
Likewise, using a back-end tool means no added value value but instead added complexity. It only slows down the development process. A simple web server would have been good enough.
Knowing about $resource
After using $http for a few hours, I learned about $resource. It is much better and more usable than $http. However, this requires an optional AngularJS module, ngResource, which in turn needs an additional <script> include in the HTML page.
AngularJS and Bootstrap integration
I’ve used Bootstrap for styling, because I suck at doing style sheets myself. Fortunately, there’s an dedicated Bootstrap directive for AngularJS, but I didn’t use it.
Fragment cache
I used ngView to create a Single-Page Interface application. However, AngularJS has some powerful caching features, that prevents the rendered page to be updated. In order to bypass caching, I used Firefox’s private window.
Paging synchronization
The Characters list REST service has paging capabilities. Using $index in ngRepeat for numbering with $resource fetching, I get some de-synchronization between the renumbering that occurs nearly instantly and the resource fetching.
Variable columns
I have tried multiple combinations of ngClass, ngSwitch and ngIf directives to have div columns spanning different Bootstrap units… to no avail. Any suggestion?

The project has been published on Github. Pull-requests are welcome, as well as advices, so I can improve. In all cases, please provide the reason behind, I’m an engineer after all.

Categories: Development Tags:

Extrinsic vs intrinsic equality

January 26th, 2014 5 comments

Note: the following article is purely theoretical. I don’t know if it fits a real-life use-case, but the point is just too good to miss :-)

Java’s List sorting has two flavors: one follows the natural ordering of collection objects, the other requires an external comparator.

In the first case, Java assumes objects are naturally ordered. From a code point of view, this means types of objects in the list must implement the Comparable interface. For example, such is the case for String and Date objects. If this is not the case, or if objects cannot be compared to one another (because perhapsthey belong to incompatible type as both String and Date).

The second case happens when the natural order is not relevant and a comparator has to be implemented. For example, strings are sorted according to the character value, meaning case is relevant. When the use-case requires a case-insensitive sort, the following code will do (using Java 8 enhanced syntax):

Collections.sort(strings, (s1, s2) -> s1.compareToIgnoreCase(s2));

The Comparable approach is intrinsic, the Comparator extrinsic; the former case rigid, the latter adaptable to the required context.

What applies to lists, however, cannot be applied to Java sets. Objects added to sets have to define equals() and hashCode() and both properties (one could say that it’s only one since they are so coupled together) are intrinsic. There is no way to define an equality that can change depending on the context in the JDK.

Enters Trove:

The Trove library provide primitive collections with similar APIs to the above. This gap in the JDK is often addressed by using the “wrapper” classes (java.lang.Integer, java.lang.Float, etc.) with Object-based collections. For most applications, however, collections which store primitives directly will require less space and yield significant performance gains.

Let’s be frank, Trove is under-documented. However, it offers what is missing regarding extrinsic equality: it provides a dedicated set implementation, that accepts its own extrinsic equality abstraction.

A sample code would look like that:

HashingStrategy<Date> strategy = new MyCustomStrategy();

Set<Date> dates = new TCustomHashSet<Date>(strategy);

A big bonus for using Trove is performance, though:

  1. It probably is the first argument to use Trove
  2. I never tested that in any context

To go further, just have a look at Trove for yourself.

Categories: Java Tags:

WebJars and wro4j integration

January 19th, 2014 3 comments

WebJars is an easy way for server-side developers (such as your humble servant) to manage client-side resources such as Bootstrap, jQuery and their like, within the same package management tool they use for their server-side libraries.

In essence, what WebJars does is package a set version of the client-side resource (CSS or JavaScript) in the META-INF/resources of a JAR and upload it on Maven Central. Then, any Java EE compatible web-container makes the resource available under a static URL. For example, for a JAR packaging META-INF/resources/webjars/bootstrap.3.0.3/js/bootstrap.js, it can be referenced by webjars/bootstrap/3.0.3/css/bootstrap.css.

Most providers offer a minified version of their resource, and it is packaged along in the JAR, so using a minified resource is a no-brainer (if the minified resource is packages along, of course). However, when using multiple WebJars, this increases the number of browser requests. Outside the context of WebJars, minimizing the number of requests could easily be achieved by using wro4j, a tool that manages both minifying and merging resources through lists of pre- and post-processors. A typical wro4j use-case was already described in an earlier article.

The good thing is that WebJars and wro4j can be integrated with ease through wro4j.xml configuration file. As it stands, wro4j.xml configures resources merging. Those resources may come from a variety of sources; typically, they are internal resource and are referenced by their path relative from the webapp root:

/sample.css

However, the power of wro4j is to be able to reference other kind of resources, including those packaged inside JARs:

classpath:META-INF/resources/webjars/bootstrap/3.0.3/css/bootstrap.css

And with this configuration line only, we merge the resource inside the WebJar with other resources. From this point on, the merged resource can be referenced as the single resource inside our webapp. The following displays a wro4j configuration file that creates a compound.css file from an internal sample.css and the Bootstrap WebJar.

<?xml version="1.0" encoding="UTF-8"?>
<groups xmlns="http://www.isdc.ro/wro">
    <group name="compound">
        <css>classpath:META-INF/resources/webjars/bootstrap/3.0.3/css/bootstrap.css</css>
        <css>/sample.css</css>
    </group>
</groups>

An example project in Maven/IntelliJ format is provided as an attachment.

Warning: though having a single minified resource for JavaScript (and one for CSS) improves performance with HTTP/1.1, it seems it might not be the case with HTTP/2.0.

Categories: Java Tags: , , , ,

Guava is an heavyweight library and I would like this to change

January 12th, 2014 4 comments

Google Guava is an useful library that offers many different but unrelated features:

However, this article is not about those features but about offering a single heavyweight Uber JAR for all. From Google’s point-of-view, providing an Uber library for all projects makes sense: “Hey guys, just add this dependency and it will meet your every requirement”. However, from my point of view, this is just making my applications heavier.

Cohesion is at the root of good software development. Many framework providers, such as Spring and JBoss, release nicely cohesive packages and manage dependencies between them through a Dependency Management tool. What is strange is that most Guava’s features are not coupled together, so a having single library is not mandatory. Even stranger, Guava has previously been released in different JARs but Google stopped doing that with version r03.

I have found no solution beside creating separate JARs and handling dependencies myself, then storing them in a Maven Enterprise Repository. Since these tasks are required for each release, I never found the ROI interesting enough. The easiest way would be for Google to do that at build time.

Dear Google engineers, if by chance you happen to stumble upon this article, I’d be very grateful if you’d consider it.

Categories: Java Tags: ,