Monthly Archives: April 2010

1-2-3 guide to modifying your DirectJNgine app to support AppEngine (proposal for DJN 1.3 alpha 1)

In order to work around AppEngine’s limitations in your existing DirectJNgine application, you need to follow three steps:  

Step 1

First of all, we have provided a new way to reference the files: if you were adding a script entry in your HTML to reference the DirectJNgine generated api/MyApi.js API with the following src attribute,  


now you will write it as follows 


where XXX is the context.  

This will always work, whether you are running under AppEngine or not!  

Step 2

Next, you will need to set the new createSourceFiles servlet parameter to false to avoid the DirectJNgine servlet to attempt to create the server side javascript files, as follows:  



Step 3

Lastly, you will need to to set the batchRequestsMultithreadingEnabled servlet parameter to false too, because Google’s AppEngine does not support multithtreading.  

That’s it!  

For more details, check the User’s Guide.

DirectJNgine 1.3 alpha 1 adds support for Google’s AppEngine

Today I am releasing DirectJNgine 1.3 alpha 1. You can download it from

New in DJN 1.3: support for Google’s AppEngine

We are providing support for AppEngine, overcoming the limitations it has with respect to file handling and multithreading.

Check this post for information on how to make an existing DirectJNgine application AppEngine-friendly.

New in DJN 1.3: tested against ExtJs 3.2.0

New DirectJNgine released are tested against ExtJs 3.2.0.

Updated User’s Guide

We keep the documentation up to date: we have added a new Chapter, “9. Google AppEngine support” with detailed instructions on how to set up DirectJNgine to support AppEngine.

Other enhancements in DJN 1.3

– The only (!) bug found in DJN 1.2 has been fixed.

– I am using FindBugs to help ensure DJN is a high quality product.

Best practices for FindBugs in new projects

I have been testing FindBugs effectiveness and ease of use in an existing project, DirectJNgine, a small 7000 lines project. With this experience in hand, I have arrived to a small set of preliminary best practices and recommendations for new projects.

Turn all settings to the max

  • Set Analysis effort to Maximal.
  • Check all detectors, except those with the “TEST” pattern.
  • Set Minimum priority to report to Low.
  • Check all reported bug categories, except Bogus random noise.

Tip: only deactivate FindBugs real-time analysis if it noticeably slows down your development (i.e., if it breaks your train of thought, it is bad; if it is just a little nuisance you will probably survive). If you do, make sure you run the analysis manually often.

Never commit source code if there is any warning

This is so important I’ll repeat it:

  • Do not commit source code if there is any outstanding FindBugs warning.

Always have an automated check process for FindBugs

  • Make running FindBugs part of the “pre commit to version control system” process.
  • Make running FindBugs part of your Continuous Integration system. Make it fail if there is any warning.

Use the Nullability Annotations extensively

  • @NonNull: mark parameters, method return values and fields that must not be null (for fields, we refer to being null after construction).
  • @CheckForNull: mark parameters, method return values and fields that might be null.
  • Set the following default annotations for packages (use
  • @DefaultAnnotationForParameters(value=CheckForNull.class)
  • @DefaultAnnotationForFields(value=CheckForNull.class)
  • @DefaultAnnotationForMethods(value=NonNull.class)

Use the Resource Management Annotations

  • @CleanupObligation: mark resource manager classes.
  • @CreateObligation: mark the constructor(s) that acquire the resource(s).
  • @DischargesObligation: mark the method(s) that release the resource(s).

Use the @CheckReturnValue annotation

Annotate those methods that:

  • Return diagnostic info or other data that should never be ignored by the caller.
  • Belong to immutable classes, and return a new object that is the result of applying an operation that would otherwise end up mutating the original object.

Handle warning supression with care

  • Warnings are your best friends: do not disable them unless you really must.
  • If you have to disable a certain kind of warning, do that globally: never use the @SupressWarnings annotation.
  • If you have to use the @SuppressWarnings annotation, check twice that you are 100% sure that’s what you really need.
  • If you use SuppressWarnings, always write the reason in the justification attribute. If you can’t write it in a way that makes you feel good, then you should probably not supress the warning.

Recommended warning supression

Warnings to supress globally on a per-project basis:

  • InefficientMemberAccess.

Other issues

  • Use the FindBugs plugin for your current IDE.
  • If you use the Eclipse plugin, take into account that it will not issue some kinds of warning just because you save a file: you will want to perform global checks periodically.

No todos los errores son iguales…

The failure of failure es una reflexión bastante interesante publicada en el Harvard Business Review -¡no solo de artículos de informática vive el hombre!

Una frase especialmente interesante:

“The essential insight is that partial failures are far more valuable than total breakdowns.”

De ‘Rework: Change The Way You Work Forever’

Entre ayer y hoy me he dedicado a leer “Rework: Change The Way You Work Forever“, un libro de 37 signals.

Aunque no estoy de acuerdo al 100% con todo lo que dicen los autores, creo que el libro está lleno de buenos consejos y tiene una gran capacidad de impacto, algo esencial.

Porque con frecuencia no hacemos cosas en función de lo mucho que un tercero nos haya “convencido” de ello, sino de cuánto nos consiga impactar.

Y este es un libro con opiniones fuertes.

Como muestra, un trocito del capítulo Say no by default:

If I’d listened to customers,
I’d have given them a faster horse.
– Henry Ford

It’s so easy to say yes. Yes to another feature, yes to an overly optimistic deadline, yes to a mediocre design.

Soon, the stack of things you’ve said yes to grows so tall you can’t even see the things you should really be doing.

Start getting into the habit of saying no -even to many of your best ideas. Use the power of no to get your piorities straight. You rarely regret saying no. But you often wind up regretting saying yes.


Uno puede estar de acuerdo o no (yo lo estoy al 90% 99%), pero no se puede negar que los autores saben cómo hacer reaccionar al lector.

Además de movilizar, el libro está repleto de sentido común (!) y se lee muy fácilmente (!!).

Un gran libro, pues.