DirectJNgine 3.0 just released

DirectJNgine 3.0 is finally out!

Version 3.0 signals a change from ExtJs 4.x to 5.x as the officially supported version. This means that I perform development, and especially testing, using ExtJs 5.x -at this moment the exact version is 5.1.0.

It is very likely, however, that ExtJs 4.x will work ok with DirectJNgine 3.0. But due to limited resources, I just can’t keep developing and testing against multiple versions of ExtJs.

What’s New

The main changes from 2.x to 3.0 are as follows:

  • We have moved to ExtJs 5.x as the plataform we use for development and testing.
  • We have a new connector that supports using both CDI and Spring beans at the same time (class SpringAndCdiDispatcher).
  • We have updated to the newer versions of the libraries used by DirectJNgine.
  • We have had to change how we integrate with the ExtJs Direct examples, because the Sencha guys have changed their underlying infrastructure.
  • With regards to CDI and Spring, we are testing against CDI 1.0 and 1.2 and Spring 3.2.x and 4.1.x.
  • Downloads: we have moved to http://www.softwarementors.com/directjngine/downloads/ as the go to place for downloads.

As you can see, there are not many changes, but we felt that it was important to make it clear we are moving from ExtJs 4.x to 5.x: hence the move from version 2.x to 3.x.

Spring and JPA: configuring Spring programmatically for Hibernate, EclipseLink, OpenJpa and DataNucleus

Here is my take at configuring Spring programmatically to support the more popular JPA providers out there: Hibernate, EclipseLink, OpenJpa and DataNucleus.

I am assuming you already know how to programmatically configure a data source, as well as how to use the @Configuration annotation. I’m just providing the @Bean definition for the entity manager factory.

Shared code

The following bean definition code provides common code shared by all JPA providers, and then calls configureProvider: we will isolate all provider specific code in that method.

@Bean
public LocalContainerEntityManagerFactoryBean 
  entityManagerFactory() throws PropertyVetoException 
{
  LocalContainerEntityManagerFactoryBean result =
    new LocalContainerEntityManagerFactoryBean();

  // loadTimeWeaver will be available if 
  //   @EnableLoadTimeWeaving is specified in this 
  //   config class (annotated with @Configuration)
  result.setLoadTimeWeaver(loadTimeWeaver);

  // coreDs should be a DataSource bean, 
  //   configured elsewhere.
  result.setDataSource(coreDs);

  Properties jpaProperties = new Properties();
  // ** Configuration common to all JPA 2.0 managers
  // coreDsDriverName is the database driver name!
  //    used to configure the datasource AND the 
  //    JPA provider
  jpaProperties.put( "javax.persistence.jdbc.driver", 
                     coreDsDriverName);

  // ** Provider specific config isolated here
  configureProvider(jpaProperties, result);

  result.setJpaProperties(jpaProperties);
  result.afterPropertiesSet();
  return result;
}

With this configuration you will have to provide your persistence.xml file. Just do not put a <provider> entry there: it will not be needed, we are specifying the provider programmatically.

However, if you want to remove the persistence.xml file, you can do that by specifying the packages to scan for entities programmatically, calling result.setPackagesToScan.

EclipseLink configuration

This is my very basic EclipseLink configuration. You should add EclipseLink specific configuration properties to jpaProperties, and provide configuration data to the entity manager factory bean (emf) so that it can instantiate the right provider.

private void configureProvider(Properties jpaProperties, 
     LocalEntityManagerFactoryBean emf) {
  // We want EclipseLink to recreate the database schema
  jpaProperties.put("eclipselink.ddl-generation", 
                    "drop-and-create-tables");
  emf.setJpaVendorAdapter(
    new EclipseLinkJpaVendorAdapter());
}

Hibernate configuration

This is my very basic Hibernate configuration:

private void configureProvider(Properties jpaProperties, 
     LocalEntityManagerFactoryBean emf) {
  // We want Hibernate to recreate the database schema
  jpaProperties.put(
        org.hibernate.cfg.Environment.HBM2DDL_AUTO, 
        "create-drop");
  // And we want Hibernate!
  emf.setJpaVendorAdapter(
     new HibernateJpaVendorAdapter());
}

OpenJpa configuration

OpenJpa basic configuration follows:

private void configureProvider(Properties jpaProperties, 
     LocalEntityManagerFactoryBean emf) {
  // We want EclipseLink to recreate the database schema
  jpaProperties.put("openjpa.jdbc.SynchronizeMappings", 
                    "buildSchema");
  jpaProperties.put("openjpa.InitializeEagerly", 
                    "true");

  emf.setJpaVendorAdapter(
     new OpenJpaVendorAdapter());
}

DataNucleus configuration

If you are using DataNucleus as your persistence provider, you are a bit out of luck, as Spring does not implement a vendor adapter for DataNucleus. We need to use a different approach, as follows.

private void configureProvider(Properties jpaProperties, 
     LocalEntityManagerFactoryBean emf) {
  // We want DataNucleus to recreate the database schema
  jpaProperties.put("datanucleus.autoCreateSchema", 
                    "true");
  emf.setPersistenceProviderClass(
     org.datanucleus.api.jpa.PersistenceProviderImpl.class);
}

Thats’ it!

DirectJNgine & the JEE-DJN connector 2.3 beta 1 are publicly available

The DirectJNgine 2.3 beta 1 as well as the JEE-DJN connector are now publicly available!

The main feature in DJN 2.3 will be support for pluggable adapters that will allow users to support integration with Spring, CDI/JEE, Guice, etc.

That means that it will be possible to define action classes as beans and inject Spring beans, CDI/JEE beans, etc. in them, making it very easy to work with Spring, CDI, etc.

Beta 1 is providing support just for the JEE-DJN connector, and can be downloaded from the DirectJNgine site.

Spring-DJN: integrating Spring into DirectJNgine

I have created an Spring connector for DirectJNgine, spring-djn which is currently in alpha!

This connector will integrate Spring into DirectJNgine, making it possible to use Spring beans as Ext Direct actions. This means that you will be able to get the benefits of Spring built-in lifecycle support. Besides, you will be able to inject Spring beans into your own action classes, greatly simplifying Spring usage with ExtJs.

The beta version of spring-djn should be made public in two to three weeks.

“Estamos en la última fase de desarrollo y encontrando muchos defectos, así que podremos entregar el producto en breve”…

Más de una vez he oído algo así como “todo el mundo está trabajando duro, encontrando defectos a porrillo, así que podremos entregar el producto en breve”. Esto suele decirse bajo la asunción implícita de que “los encontramos tan rápido que acabaremos con la mayoría en un plis plas”.

Pues no, la práctica demuestra todo lo contrario, si estás encontrando muchos defectos es casi seguro que quedan muchos más.

Si uno pesca muchos peces, puede asumir que probablemente quedan muchos: que vayamos a acabar con ellos en breve es una asunción bastante arriesgada -a menos que tengamos información adicional que apunte a ello.

De hecho, solo si uno encuentra cada vez menos peces debe empezar a preguntarse si acaso no está pescando los últimos. Vamos, que encontrar muchos peces solo prueba que hay o había muchos, ¡no que quedan pocos!

Pues con los defectos pasa lo mismo: si uno sigue encontrando muchos defectos lo más probable es que queden muchos más.

“Tribal Leadership” review

I started reading Tribal Leadership a while ago, and wrote about my first impressions here.

To being with, the books emphasizes that if you change language, you change behavior, so it will focus very much on language. Beliefs, cognition and whatever else are therefore not addressed in the book, as they are not important for practical purposes, according to the authors.

The first key concept the book introduces is that of tribe, the group of people that makes change successful or not, no matter who mandates the change: even the CEO won’t be able to accomplish some change if the tribe decides  it does not want the change.

This tribe concept is important for two reasons: first, it makes clear that we must collaborate with and involve people to get real change, it just won’t happen without them.

The second reason is that it acknowledges that organizational change affects and is affected by more people than we might think: simply put, a development team is not the unit of organizational change, so you better pay attention to the surroundings too.

While this is not very original, it is worthwhile to say it explicitly time and again. Now, using the tribe keyword is a way to avoid using organization or group, words that might lead us to old preconceptions, but I think there is not much else in the concept.

That of tribal leader is another key concept: a tribal leader listens for the cultures of the tribe and updates it to a higher level of effectiveness, doing the work for the good of the tribe -not his own.

The stage idea is the third key concept. The authors state that tribes exist at five different stages (levels) of effectiveness. Tribes and people at at a certain stage have a characteristic and very different way of speaking (language is powerful!), different behavior and different structures of relationship among them.

What’s more, what you need to do move to a higher stage differs according to the stage you are currently in, and there will be different leverage points that can be used to upgrade to the next stage. Do not try to apply the same techniques you used to move from stage 1 to stage 2  to move from stage 4 to 5. Besides, you must move from a stage to the next stage without skipping any: you just can’t move from stage 1 to stage 4 directly.

To me, this is the key idea in the book, one that is often overlooked: different levels of competency show different vocabulary and behavior, require different upgrade tools and techniques and come with different leverage points.

Most change models acknowledge the existence of several levels (stages), but not many insist on the need to use different leverage points to upgrade to a higher level. This can be a nice tool to add to your change toolkit.

A chapter is devoted to each stage: how to identify whether a tribe is at that stage as well as techniques to move to the next stage are discussed at length in them.

The five stages identified by the authors are as follows:

  • Stage 1: tribes and people at this stage speak as if “life sucks”, behavior expresses despairing hostility.
  • Stage 2: speak as if “MY life sucks” (therefore others might not suck), and behavior is that of apathetic victims.
  • Stage 3: speak like “I am great”, with an unexpressed “-and you are not”. Behavior revolves around outperforming others and dominance, relationship are two sided.
  • Stage 4: speak like “WE are great”, with an unexpressed “-and they are not”. Behavior radiates groupal pride, and relationships are three-sided.
  • Stage 5: speak like “LIFE is great”. The idea of external enemy (you in stage 3, them in stage 4) disappears.

The meat of the book revolves around stage 4 (chapters 7 to 11), which is the higher for which the authors can provide advice. They discuss at length the need to identify the tribe values so that it is possible to get the kind of alignment that will make it much more effective, or finding a noble cause to unite the tribe, as well as many other issues.

To be fair, I liked the discussion on group values in Built to Last better, but  that might be just me (see the More Than Profits chapter).

Now, let me tell you about the book’s weak points. First of all, the book is hard to read, requiring a lot of chewing. Of the last three books on change I’ve read, this was (by far!) the hardest one to read.

I feel that it contains a bit too much chaff, and that they could have done better with less pages. Half the pages would have worked.

Now, do I recommend the book? Well, I do, but be aware that it will be hard work. If you are short on time and are just curious about change, you might do better reading some other easier to read book.

La importancia de ir a la raíz de las cosas: un ‘gran resultado’ que es síntoma de un gran problema

Hace un par de semanas recordé una anécdota que si no recuerdo mal (no estoy 100% seguro) contaba Steve Maguire en su libro Debugging the Development Process, un libro con muchos años pero que aún resulta refrescante y relevante.

La cosa era que un programador había conseguido cierto prestigio como una especie de crack de la depuración porque encontraba una cantidad de defectos increíble…hasta que de un modo u otro se descubrió que ello era debido a que simplemente producía muchos defectos. Y es que cuando hay muchos peces en el estanque es fácil conseguir una buena pesca.

En este caso se había asumido que el hecho de encontrar muchos defectos era un gran resultado, cuando en realidad no era más que el síntoma de un gran problema.

La lección que uno puede sacar de esta anécdota es que no hay que dar por cierto casi nada, y que uno siempre debe mirarlo todo con ojos críticos (que no criticones). Y, en particular, que uno debe buscar siempre la causa raíz de las cosas.