Lycka Bonita

He who has a why to live can bear almost any how.

Friedrich Nietzsche.

«Muchas personas me preguntan cómo hacer algo. Yo solía decírselo hasta que me di cuenta de que incluso después de haberles dicho cómo hacía algo yo, con frecuencia no lo hacían. Luego me di cuenta de que no es el cómo lograr algo, sino el porqué lograrlo lo que es más importante. Es el porqué lo que te da el poder para hacer el cómo».

Robert Kiyosaki en Retírate joven y rico. Vía blog de Francisco Alcaide, No es el «cómo» sino el «porqué».

La etiqueta (taglib) de JSF convertDateTime aplica por defecto la zona horaria en la que se está ejecutando, por lo que cuando es ejecutada en España (que ahora estamos en la zona horaria GMT+2) lo que hace es restar 2 horas a la hora  que le es informada.

Es decir, ejecutando el siguiente código en España e informando user.createdOn como “01/01/2013 12:00:00″ :

1
2
3

<h:outputText value="#{user.createdOn}">
    <f:convertDateTime pattern="dd/MM/yyyy HH:mm:ss" type="both" />
</h:outputText>

se pintará en pantalla “01/01/2013 10:00:00″. Pero lo que es peor, en Portugal (está en la zona horaria GMT+1) pintaría “01/01/2013 11:00:00″ (creo, no me he desplazado a Portugal para probarlo ).

Y lo que es peor, si estás desarrollando en España y finalmente tu código se despliega y ejecuta en otro país, el resultado será….

Para solucionar esto (ñapa) en España podemos poner la zona horaria en el código:

1
2
3

<h:outputText value="#{user.createdOn}">
    <f:convertDateTime timeZone="GMT+2" pattern="dd/MM/yyyy HH:mm:ss" type="both" />
</h:outputText>

Aunque lo suyo sería que timeZone fuera una variable más a informar desde el servidor, porque sino cuando por ejemplo registremos un evento en el servidor persistiendo new Date(), al visualizar esa fecha se visualizará incorrectamente en clientes que no estén en la misma zona horaria que el servidor, complicando (innecesariamente) una lógica tan habitual como formatear una fecha.

¿Por qué no me gustará ningún código de Sun? ¿Por qué no respetaré las certificaciones de Sun?

Todo evoluciona, hasta tomar pantallazos del contenido de tu navegador, se acabó el “Imprimir Pantalla” e ir luego al MS Paint a retocar, poner flechitas y recortar la imagen.

Awesome ScreenShot es una extensión gratuita tanto para Firefox como para Chrome y Safari para tomar pantallazos del contenido de tu navegador de una forma sencilla, elegante y potente.

Sin duda es una herramienta que mejorará la comunicación entre los usuarios (es que no me funciona cuando pincho el botón!) y los desarrolladores.

Cuando me instalo un nuevo entorno de trabajo con Eclipse, siempre dudo qué plugin de código abierto de SVN instalarme (igual que me pasa con MAVEN), si instalarme Subversive de Polarion o instalarme Subclipse de Tigris (referencia en el mundo SVN), ambas soluciones muy similares funcionalmente, respaldadas por una gran comunidad y muy maduras. Y esta duda es bastante popular y antigua.

Sin embargo hay 3 razones por las que Subclipse brilla más que Subversive:

• Están más involucrados en la evolución de la tecnología SVN.
• Es significativamente más sencillo realizar un merge.
• Soportan mejor cambios externos realizados por otros clientes SVN o directamente la línea de comandos.

La segunda razón sí que la considero suficiente para decantarme por Subclipse ya que hacer un merge es el punto más débil de SVN frente a GIT.

Las transacciones deben cumplir con el acrónimo ACID para ser confiables:

• Atomicity, all or nothing, if one part of the transaction fails the entire transaction fails. Required when there is more than one Resource Manager. Example of two phase commit, marriage, both partners must return ok.
• Consistency, any transaction will bring the database from one valid state to another. The bride can not become married to another broom after her ok if her broom fails and another one gives ok.
• Isolation, can be executed concurrently but appear to execute serially.
• Durability, when a transaction commits its result remains and must survive failures.

Sacado de la charla “Transactions: Over Used or Just Misunderstood?“, de Mark Little de JBoss en InfoQ.

Sin embargo, el teorema de Brewer nos condena a convivir con el fallo si queremos escalar nuestro sistema, para lo cual utilizamos transacciones que se conforman con que eventualmente nos encontraremos en un estado consistente y con ofrecernos respuestas aproximadas, cumplen con el acrónimo BASE:

• Basic Availability
• Soft-state
• Eventual consistency