La aventura en ENNE parece que ha llegado a su fin, aunque la fecha precisa del final no lo conocemos. Los trabajadores llevamos sin cobrar desde Diciembre de 2011, con lo que están a punto de cumplirse 6 meses, y después de agotar todos los medios a nuestra alcance finlamente se celebró el juicio en el que la mayoría de la plantilla reclamaba judicialmente la desvinculación de la empresa.

No sé la situación exacta en la que se encuentra la empresa, pero supongo que perder al 98% de los trabajadores sino el 100% será una situación de la que la organización no se recuperará.

A pesar de que es una experiencia que acaba con un sabor claramente amargo, yo me voy agradecido por la experiencia, por la oportunidad y si me permitís la excusa que me hizo lanzarme a la piscina (que resultó más vacía que llena) de vivir en Salamanca.

Y a partir de ahora? El mundo está lleno de posibilidades…

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.JOptionPane;
import javax.swing.JPanel;
import javax.swing.JTextField;

public class HelloWorldSwing extends JFrame {

private static final long serialVersionUID = 4648172894076113183L;

private Container container;
private JPanel panel;
private JLabel label;
private Button button;
private JTextField textField;

public HelloWorldSwing() {
container = getContentPane();
panel = new JPanel();
label = new JLabel(“Label”);
button = new Button(“Click me!”);
textField = new JTextField(“Text”, 10);

button.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
JOptionPane.showMessageDialog(null, “Hello World!”);
}
});
panel.add(label);
panel.add(textField);
panel.add(button);
container.add(panel);

setTitle(“Hello World Swing!”);
setLocation(100,100);
setSize(500, 200);
setVisible(true);
}

public static void main(String…args) {
//        System.out.println(“Hello World!”);
HelloWorldSwing hws = new HelloWorldSwing();
}

}

Permíteme una pregunta, cómo pones precio a tu trabajo? o a tu tiempo, a tus productos…

Lo que se me ha enseñado durante mi formación reglada es que primero haces un estudio de viabilidad. Estimas tus costes fijos, tus costes variables, las unidades que esperas vender, el margen que debes obtener para que todo tenga sentido, y voilà, habemus precio. Ahora estimas si vas a conseguir vender las unidades necesarias, y ya sabes si tu producto es viable o tienes que dedicarte a otra cosa.

Sin embargo en ninguna de mis experiencias laborales en desarrollo de software se ha seguido este proceso para establecer el precio de un proyecto. Sí, he hecho estudios de viabilidad en los que he estimado el coste que tendría el proyecto, y sí se han utilizado para realizar una propuesta técnica y económica al cliente, pero no para fijar el precio. El proceso que se ha seguido en mi experiencia es encontrar el precio máximo que el cliente está dispuesto ha pagar, sin importar casi nada el coste.

Como inciso el precio del mantenimiento de software sí suele estar más correlacionado con su coste.

¿Por qué el desarrollo software es diferente? El proceso de desarrollo software en general, y por tanto el de ventas en particular, es bastante diferente a los modelos tradicionales porque :

1. Reutilización : el producto se desarrolla una vez y se vende “infinitas” veces.
2. Difícil reutilización : producto a medida.

Al primer modelo pertenecen Windows o Angry Birds son ejemplos de productos software utilizado por millones de usuarios que se venden por cientos de euros o unos pocos euros respectivamente. En este modelo resulta extremadamente complicado prever el número de licencias que venderás: 1, 1.000 ó 100.000.000? Como veis sus precios en general no se correlacionan con sus costes, porque es más fácil estimar el precio que tus clientes están dispuestos a pagar.

Un caso particular de este modelo es el software de licencia gratuita, como WordPress, que obtienen sus ingresos de otras fuentes.

Por tanto el éxito en este modelo se basa en un producto de calidad adecuado a un nicho y circunstancias y una buena labor de comunicación.

Al segundo modelo pertenecen los desarrollos a medida medianos, grandes o gigantes. Comercialmente resulta misión casi imposible conseguir que dos clientes diferentes reutilicen un mismo proyecto a medida. Por ejemplo si desarrollar un software que gestione por ejemplo pólizas de seguros costase 1 millón de euros (incluyendo impuestos, márgenes…), y hay por ejemplo 10 clientes potenciales en España, vender el proyecto a 2 clientes por 1 millón a cada uno y desarrollar 2 proyectos a medida es más fácil que desarrollar el producto una vez y vender 2 licencias del mismo por medio millón a los dos mismos clientes.

En este segundo modelo además se añade la poca posibilidad de reutilización. Si el mismo equipo realizase los dos proyectos sin reutilizar código, sólo su experiencia, el coste del segundo sería menor pero parecido al coste del primero (a mismas funcionalidades).

Una vez más, el precio tiene poco que ver con el coste, al menos con el coste potencial. Así, en este segundo modelo la labor comercial es crucial para fijar un precio y cerrar la venta.

Por cierto, en uno de los dos modelos la palabra sinergia tiene un lugar privilegiado reservado y en el otro está desterrada del vocabulario.

En cuanto a las heladas, no han sido supuesto ningún problema a pesar de que ha habido más días de los que yo preveía con -5º o menos, que es el umbral para muchas de las especies que había consultado. El huerto ha aguantado muy bien, se mantiene un par de grados o tres por encima del resto del jardín a pesar de su orientación norte, y el jardín se mantiene un par de grados por encima de la maleza del otro lado de la carretera. De hecho las cencelladas, producidas por la combinación de heladas, niebla y viento, en el huerto han sido inexistentes, en el jardín pequeñas y fuera notables.

Hasta marzo el viento no ha vuelto a ser molesto. A pesar de estar situada en un rincón, la madreselva no termina de despuntar y ha sido derribada nuevamente por una racha de viento recientemente. Nuevamente, el huerto se halla más protegido que el jardín, y el jardín más protegido que la carretera.

En resumen, durante todo el invierno se ha estado muy a gusto tumbado en el jardín a las horas centrales de casi todos los días, debido al abundante sol (por las escasísimas nubes) y la baja intensidad del viento, que han propiciado elevadas temperaturas durante el día. El termómetro en enero llegó a marcar 40 grados al sol!!!, siendo habitual que superase los 30º al sol y rozar los 20º a la sombra. Y lo que es un indicador más claro, los gatos se ponían a la sombra cuando salían al jardín a las horas centrales y se echaban una siesta (después de haber hecho la suficiente cantidad de mal, por supuesto). Una vez adquirida primero la mecedora y luego la hamaca, he podido disfrutar de varias siestas y sesiones de top less

Pero esta situación no es agradable: puede que el aumento de temperatura sea incluso beneficioso, pero sin lugar a dudas la sequía pasará factura.

Finalmente, durante todo el invierno he estado enterrando los residuos orgánicos en la tierra a modo de compostaje. Únicamente he podido procesar una tira de tierra de unos 3 metros por metro y medio, que espero utilizar ahora en primavera para plantar las nuevas plantas del huerto en la modalidad de bancal profundo.

Click here to view the embedded video.

Impresionante en una clase de Ciclo Indoor, letra e imágenes que no te (deberían) dejan indiferente.

You shout it loud, but I can’t hear a word you say
I’m talking loud, not saying much
I’m criticized, but all your bullets ricochet
you shoot me down, but I get up

I’m bulletproof, nothing to lose
fire away, fire away,
ricochet you take your aim
fire away, fire away

(you shoot me down, but I won’t fall
I am titanium) (x2)

Consiste en incluir en mitad del contrato, lo más oculto posible entre el resto de cláusulas y condiciones, una simple cláusula en la que el grupo exigía que en su camerino debería haber en todo momento, desde la llegada del grupo hasta la finalización de su actuación, un recipiente con M&Ms (cacahuetes de varios colores) pero que no debía contener ningún M&M de color marrón. En caso de que esta cláusula no se satisficiese, la banda se reservaba el derecho a cancelar el contrato pero cobrando su integridad.

Por qué? Por qué resulta tan altamente recomendable?

Piénsatelo un solo momento por favor…

Esta cláusula de muy bajo coste para el proveedor supone sin embargo un riesgo inasumible para el mismo. De hecho, yo no la firmaría tal cual bajo ninguna circunstancia. La renegociaría ya que da la posibilidad al cliente de traerse de casa un M&M marrón, añadirlo al recipiente con los demás, y reclamar posteriormente la cancelación del contrato así como el importe íntegro por sus servicios no prestados.

Supongo que ya verás por donde van los tiros.

Es un mecanismo que permite al grupo conocer nada más llegar si el proveedor ha cumplido su contrato como se esperaba, ya que si no había un recipiente con las golosinas, sin ninguna de color marrón, significa que el proveedor no se ha leído o no ha prestado atención al contrato, o que directamente ha decido ignorar detalles que consideraba banales (pero que quizás no lo fuesen para el cliente). Por tanto, la banda podría esperar más “detalles” ignorados por el proveedor en otros aspectos como seguridad, sonido, iluminación…

En lo personal es un pequeño truco que he utilizado cuando debo seleccionar personas. Suelo incluir alguna observación no técnica aparentemente superficial y desligada del objetivo, consiguiendo así una reacción más natural del candidato.

San Antonio, probablemente el mayor beneficiado con el intercambio Richard Jefferson por Stephen Jackson, y en la otra cara de la moneda Golden State que parece que ha recibido poco a cambio de Monta Ellis.

Mitch Kupchak va camino de ser inmortalizado como ejecutivo, se ha desecho de dos contratos tóxicos (Fischer, Walton), ha corregido el error de fichar a Kapono. Tampoco ha conseguido gran cosa a cambio de estos jugadores que ya no pueden aportar más, pero son dos movimientos importantes de cara al futuro financiero.

El movimiento incógnita, Denver. Sus razones tendrán para intercambiar a McGee y Turiaf por Nenê recién renovado por ellos en un traspaso a tres bandas con Clippers.

Pero lo importante para mí como aficionado, Portland se deja llevar y comienza la reconstrucción sin el afamado “desarrollador” de talento McMillan, por fin, quien ha dejado la franquicia como un vertedero. Espero ansioso saber qué va a ser de “mi” franquicia, con aún gran potencial por explotar, y que seguramente contará con una alta elección en este draft.

El tiempo nos dirá.

Click here to view the embedded video.

Qué gran época en la que vivimos que nos permite disfrutar de este espectáculo, a pesar del empeño que ponemos en (AUTO) destruirlo.

Entonces dos consejos:

1. Como fuente primaria de información siempre elige la documentación oficial. Vamos, que te manejes como Peter on the house (o era in, o quizás at… umm…) con el inglés.
2. No pares de practicar y aprender.

Así que, a qué esperas para ponerte con estos manuales de Java de la página oficial de Oracle? Al menos, ponte con los que más te interesen…

Este interesante video puede aportar mucho más al debate.

El mayor problema que nos encontraremos con Maven es que la “filosofía” de GWT es muy antigua, Java de finales de los años 90 con notables deficiencias desde un punto de vista actual de desarrollo de software aún en las versiones más recientes (como mezclar código fuente con código generado), en las que los proyectos son GWT o no en lugar de utilizar GWT como un simple framework más que simplemente se utiliza en la vista y el control.

El mayor problema que nos encontraremos en Spring Framework es que GWT crea las instancias de las RPCs asíncronas, que a su vez utilizan componentes creados por Spring (los servicios) y gestionados en su contexto. Ojo, no confundir Spring Framework para gestionar dependencias con Spring MVC para gestionar la capa de control: utilizar Spring MVC para gestionar la capa de control no es el objetivo de esta kata aunque bien podría dar para otra kata diferente y luego compararla con la solución de esta kata.

Para esta kata se propone un orden concreto, primero convertir el proyecto GWT en proyecto Maven y luego introducir Spring, pero bien se podría realizar otra kata más al revés: primero introducir Spring en el proyecto GWT y luego convertirlo a un proyecto Maven. El resultado final debería ser el msimo.

Las versiones recomendadas para la realización de la kata son GWT v2.4, Maven v2.1 y Spring Framework v2.5. Las versiones antiguas de Maven y Spring Framework se deben a necesidades del proyecto para el que necesitaba aprender/enseñar, no creo que haya mayores diferencias con las respectivas versiones v03.xx.

Igual que en la anterior kata, no dudes en contactarme si tienes dudas, sugerencias o mejoras, publicaré mi solución pero te recomiendo encarecidamente que primero resuelvas la kata y luego la consultes, y agradeceré si decides compartir tu solución con nosotros.

Ejercicio 01 – Integración Maven con GWT

Objetivos

• Conseguir que cualquier ejercicio de la kata de GWT (preferiblemente el último) funcione bajo Maven.

Restricciones

• La configuración del proyecto debe ser gestionado por Maven.
  • Las dependencias del proyecto (librerías) se deben gestionar con Maven.
  • El ciclo de vida del proyecto se debe controlar con Maven: limpiar, compilar, ejecutar, depurar y empaquetar.

Ejercicio 02 – Integración Spring con Maven con GWT

Objetivos

• Partiendo del anterior proyecto, utilizar Spring para inyectar las dependencias.

Restricciones

• Las mismas que en el ejercicio anterior.

La versión de GWT recomendada es la v2.4, o al menos versiones v02.xx. Se recomienda utilizar Eclipse como IDE junto con el plugin de GWT para Eclipse que proporciona Google.

Si tienes dudas sobre el enunciado del ejercicio, sus objetivos o restricciones no dudes en contactarme, así como si tienes sugerencias o mejoras. La semana que viene espero publicar mi solución, pero antes de consultarla recomiendo fuertemente trates de hallar tu propia solución. También agradecería que compartieseis vuestras implementaciones.

La estructura del proyecto requerida se muestra en la siguiente imagen:

Se implementará un patrón MVC (Modelo Vista Controlador).

• El Modelo será utilizado por todas las capas del proyecto, no sólo la Vista y el Controlador.

• La Vista se encargará de la implementación de la  Interfaz de Usuario.

• El Controlador se encargará de atender las llamadas procedentes del cliente y despacharlas al método de negocio que le corresponda.

Ejercicio 01 – GWT – Hello World!

Objetivos

• Partiendo de un workspace vacío, debemos crear un proyecto web con GWT que al ser ejecutado nos muestre una página con un botón.

• Al pulsar el botón nos debe aparecer un mensaje con el literal “Hello World!”.

Restricciones

• Utilizaremos GWT para implementar la vista y el controlador
  • En la parte de la vista, crearemos un módulo GWT con un entry point que carga una página que contiene un botón que tiene asociado un manejador de eventos que dispara la ventana emergente con el mensaje recibido del servidor, todos ellos creados por nosotros como clases de nuestra aplicación.
  • En la parte del controlador, utilizar llamadas RPC para conseguir una comunicación asíncrona.

• El controlador invocará un servicio.

• El servicio invocará un DAO.

• El DAO no consultará ninguna estructura de persistencia, sino que devolverá siempre el mismo mensaje esperado, “Hello World!”.

• Utilizar APIs en servicio y persistencia.

• Aunque es suficiente utilizar un objeto java.lang.String para transportar el mensaje, utilizar otro objeto de modelo creado por nosotros (por ejemplo, Message) para encapsularlo.

Ejercicio 02 – GWT – Bye World!

Objetivos

• Partiendo del proyecto resultante de la kata anterior, Hello World!, ampliaremos el proyecto con otro nuevo módulo similar al anterior pero el mensaje que se nos devolverá será “Bye World!”.

Restricciones

• Para el nuevo código seguiremos las mismas restricciones válidas para el Ejercicio 01.

• Toda la nueva implementación debe ser completamente independiente del código anterior, y se empaquetará en paquetes diferentes, cero reutilización (“cero” quiere decir la mínima posible, obviamente sólo puede haber un fichero web.xml…).

• En este punto, el proyecto debería tener dos módulos diferentes y funcionando.

Observaciones

• Si utilizamos la palabra “Adiós”, comprobaremos que el carácter “ó” no lo muestra correctamente. Esto es un problema de internacionalización, pero a priori queda fuera del alcance y podría ser objeto de otra kata.

Ejercicio 03 – GWT – All World!

Objetivos

• Partiendo del proyecto resultante de la kata anterior, Bye World!, refactorizar para llegar a un proyecto con otro nuevo módulo que nos cargue una página con dos botones.

• Un botón devolverá el mensaje “Hello World!” y el otro devolverá el mensaje “Bye World!”.

Restricciones

• Para el nuevo código seguiremos las mismas restricciones válidas para el Ejercicio 01.

• Sólo implementar el código imprescindible, reutilizar cuando sea posible pero sin refactorizar el código existente.

• En este punto deberíamos tener 3 módulos GET diferentes funcionando correctamente con código completamente independiente entre módulos.

Ejercicio 04 – GWT – All World! Reloaded

Objetivos

• Partiendo del proyecto resultante de la kata anterior, All World!, refactorizar para llegar a un proyecto con las mismas tres funcionalidades pero con la máxima reutilización posible.

Restricciones

• Máxima reutilización posible.

Kata

Code Kata es un término utilizado en la industria del software para referirse a ejercicios simples para ejercitar y perfeccionar el dominio de algún aspecto técnico. Al igual que las katas de artes marciales, pueden ser ejercicios individuales o en grupos.

A pesar de ser un término recientemente acuñado, estos ejercicios son buenas prácticas que se utilizan desde el principio de los tiempos! Por ejemplo el típico ejercicio de Hola Mundo! que acompaña a casi cualquier tecnología para explicar el uso de la misma.

El gran enemigo del conocimiento no es la ignorancia, sino la ilusión de conocimiento.
Stephen Hawking

Pueden ser utilizadas como ejercicios para aprender una nueva tecnología o mejorar nuestras habilidades de codificación / implementación, como katas sobre algoritmos. Una forma muy buena y muy extendida de aprender diferentes lenguajes de programación es codificar el mismo algoritmo con diferentes lenguajes.

Lo que no se sabe expresar, es que no se sabe.
Friedrich Engels

Cada maestrillo tiene su librillo, pero generalmente una kata son tareas simples que se pueden resolver en alrededor de una hora mediante una serie de pasos que puedas explicar después.

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
Antoine de Saint-Expury

Dado que típicamente existe más de una forma de resolver un mismo problema, y que no todas las soluciones que funcionan son aceptables, resulta muy saludable ejercitar sin haber visto la solución de otras personas. Eso sí, después compara tu implementación con la de otras personas y discutid las razones que os han llevado a tomar vuestras decisiones. No se trata de hacerlo mejor que el resto, sino de aprender lo máximo posible en el menor tiempo posible!

Si tú tienes una manzana y yo tengo una manzana y las intercambiamos, entonces ambos aún tendremos una manzana. Pero si tú tienes una idea y yo tengo una idea y las intercambiamos, entonces ambos tendremos dos ideas.
George Bernard Shaw

En el mundo real seguramente no nos encontremos problemas tan sencillos, pero dominando (de verdad) estas tareas simples podemos abordar las más complejas con confianza y eficacia. Por ejemplo, si debes migrar una aplicación que actualmente está utilizando para inyectar dependencias de Spring Framework a Guice, sería una excelente idea hacer una pequeña kata previa para poder estimar el tiempo que llevará la migración, afrontarla con confianza justificada y elegir el enfoque óptimo.

Me lo contaron y lo olvidé; lo vi y lo entendí; lo hice y lo aprendí.
Confucio

Kanban sugiere corregir esta ineficiente situación parando la producción de la cadena y que cada operario deja de trabajar en su puesto para ayudar a desatascar el problema. Una vez solucionado el problema se vuelve a la normalidad.

Kanban, en la práctica: nuestro problema

Hasta ahora no había tenido la oportunidad de enfrentarme a una situación similar en la vida real, además una situación similar al descrito en la imagen que acompaña esta entrada: no podemos desplegar una versión.

Nuestras circunstancias :

• Somos un equipo distribuido de 5 personas en 2 centros de trabajo a varios cientos de km de distancia.
• Se trata de un proyecto que nos ha sido entregado recientemente para que llevemos su mantenimiento correctivo y evolutivo.
• El proyecto está basado en versiones antiguas de tecnologías en cuya integración no tenemos conocimiento ni experiencia suficiente. Además presenta importantes puntos de mejora en más de un área.
• Una de las primeras cosas que hemos hecho al recibir el control del proyecto ha sido eliminar todo el código de pruebas… qué locura no? nuestras razones teníamos
• Partimos de un punto en el que el proyecto arranca, funciona y ha sido validado por los usuarios en un ambiente de preproducción.
• Nuestro primer objetivo, simplificar. Llevamos una reducción del 75% en el tamaño del WAR, en el tiempo de compilación y arranque, también una importante simplificación de la estructura del proyecto… pero no arranca correctamente.

En estas circunstancias, los desarrollos no pueden ser validados hasta conseguir arrancar el proyecto y comprobar si funcionan. Qué debemos hacer?

• Debemos parar todos los desarrollos y poner a todas las personas a reparar la línea base hasta conseguir desplegar esta versión?
• O debemos seguir cada uno con lo nuestro? Una persona o un equipo arreglando la línea base y el resto continuando con los desarrollos, que se validarán cuando la línea base se arregle?

Kanban, en la práctica: qué hicimos?

La primera semana después de romper la línea base seguimos al pie de la letra la recomendación de Kanban. Paramos la cadena de producción y nos pusimos todos a intentar que el proyecto arrancase nuevamente. 5 pollos sin cabeza, cero resultados, cero avance.

A la semana optamos por la segunda solución. Nos dividimos el trabajo.

Un centro se dedicaba a aprender e investigar sobre las versiones más modernas de las tecnologías y su integración, para después preparar la formación al otro centro y acometer la migración del proyecto a las nuevas versiones (arreglando la línea base en el camino).

El otro centro se dedicaba a sustituir partes de la arquitectura. Es decir queda fuera de la cadena de producción de código, pasando a trabajar en otra cadenas de montaje independiente (arquitectura). Cuando arreglemos el problema volverán a nuestra cadena para desarrollar pruebas desde cero.

Fallo de Kanban? Fallo en nuestra aplicación de Kanban? Nuestra respuesta es un atajo?

Creo que no, no y no. Creo que es un fallo en la gestión del proyecto, nunca debimos ir tan lejos sin conocimientos más avanzados en las tecnologías involucradas. Si hubiésemos abordado en primer lugar la (auto)formación no nos hubiésemos encontrado en esta situación que nos ha hecho perder al menos una semana de trabajo de 4 personas. Con la segunda solución retrasamos la salida de esta incómoda situación, pero al menos no desperdiciamos trabajo.

Por qué no utilizar Java para la capa de vista?

Bendita solución.

GWT nació en 2006 de la necesidad de Google en proporcionar a sus usuarios interfaces ricas, claras, ligeras, intuitivas y sobre todo dinámicas. Dado que ninguna herramienta externa o lenguaje cubría sus necesidades, decidieron desarrollar su propia solución, que posteriormente convirtieron en código abierto, generando JavaScript a partir de código Java y solucionando problemas comunes como la internacionalización, la comunicación asíncrona, el histórico de navegación y la compatibilidad entre navegadores.

Y lo consiguieron, los resultados desde el punto de vista de usuario son muy buenos y el desarrollador se abstrae completamente de AJAX y JavaScript.

Monstruo avernal.

Sin embargo GWT no se imponía en el mercado, no se convertía en estándar, el número de proyectos y profesionales GWT no despegaba e incluso recientemente ha empezado a decaer.

¿Por qué? Yo no entendía la razón… hasta que he tenido que involucrarme profesionalmente. Quizás las lagunas que le encuentro a estas versiones de GWT sean debidas a mi desconocimiento de la propia tecnología y a mi escasa experiencia de un par de meses, lo que en el mejor de los casos sitúa a GWT como una tecnología con una curva de aprendizaje poco suave debida a su buena pero escasa documentación oficial, su gran número de rígidas convenciones (no documentadas) y sobre todo al enfoque erróneo en sus orígenes de aspirar a gestionar el proyecto en lugar de ser una simple herramienta más que se utiliza únicamente en la vista y en el controlador para las llamadas asíncronas.

Colaboración, intercambio y estandarizar: se debió crear una fundación sin ánimo de lucro y dotarla de fondos o colaborar con las existentes, para encontrar una solución común para resolver un problema común ajeno a sus negocios. Sin embargo Google buscó una ventaja competitiva sobre su competencia haciendo algo que no pertenece a su core de negocio, pan para hoy…

Las versiones v01.xx son muy “noventeras” : rígidas (pensadas para las necesidades de Google), implementa supuestamente el patrón MVP (a mí me parece una arquitectura de dos capas cliente-servidor), mini-manuales, sota caballo y rey, tu proyecto pasa a ser un proyecto GWT, el desarrollo será rápido pero cogido con chinchetas (si funciona no toques, por qué tocas?), el mantenimiento será infernal y las migraciones eternas. Salvando las distancias, recuerdan a Alfresco.

Las versiones v02.xx han mejorado enormemente : existe un plugin de Google para Eclipse, un plugin para Maven con el que colaboran Codehaus, Sonatype y Google, se creó GIN (Gwt Injection) para inyectar dependencias, es más flexibilidad, existe más documentación.

Sin embargo aún debe avanzar hacia una hipotética versión v03.xx más simple, más documentada, con menos convenciones para reconvertirlas en configuraciones, una simple herramienta del proyecto en lugar de ser el centro del proyecto, lo que facilitaría su integración para gestionar la Vista con otras herramientas MVC como Struts, Spring MVC o las que aparezcan en un futuro.

Ángel o demonio?

Depende de cómo lo utilices.

Si te estás planteando utilizar GWT para tu nuevo desarrollo, o migrar tu actual proyecto a GWT, no creo que sea una mala idea, pero antes de hacer nada profundiza, aprende, practica con una pequeña kata y sé consciente del riesgo que estás introduciendo en tu proyecto y de que la curva de aprendizaje será mayor de lo esperado.

Anoche mismo me tomé una ensalada igual, y no me produjo la misma sensación. Será casualidad, pero la diferencia acaso radique en que la lechuga era de mi huerto, al igual que la zanahoria, procedentes de la primera recolección de mi huerto, el 28/11/2011.

Voy a regodearme un poco más en esta sensación cacofónica de placer bucal, vuelvo dentro de unos minutos.

Ya estoy. Sigo igual, pero voy a seguir escribiendo.

Aún no había helado en este magnífico otoño. Las temperaturas han sido suaves pero se mantuvieron constantemente por encima de los 10 grados incluso por las noches hasta finales de noviembre. La siguiente quincena la temperatura se mantenía entre los 5 y los 10 grados por la noche, y la última entre los 0 y los 5 grados. A medio día los días de sol la temperatura casi llegaba a la treintena de grados, pero según progresaba el otoño iban disminuyendo tanto el pico de temperatura como la duración de esta banda.

Ha habido varios días sueltos totalmente nublados y una racha de una semana con niebla a finales de Noviembre, un par de días hasta las 14:00h, pero en general las horas de sol han sido abundantes para la época.

Además el agua ha sido generosa y constante los dos primeros meses, sólo una gran lluvia pero el suelo se ha mantenido siempre húmedo. El último mes ha sido más bien seco.

La primera helada de la temporada ha llegado el 29/11/2011, dejando una vista de Salamanca preciosa con los campos bellamente blancos para presentar una Salamanca apenas perceptible al otro lado del río por la niebla y nubes bajas en la que destacaba la poderosa silueta de la Catedral mientras un tenue Sol luchaba por levantarse. Fría vista, pero cálida sensación de belleza de una manaña de Noviembre digna de inmortalizar. Únicamente ha habido otras dos más durante los dos últimos días del Otoño.

Han prosperado aproximadamente un 60% de lo esperado por lo sembrado, lo que atribuyo a novatada, hormigas, aves, gatos… Nada preocupante, en especial si siembro en semillero.

Las plantas han crecido sustancialmente menos de lo esperado, lo que atribuyo por un lado a la mala calidad del suelo, a que han crecido demasiado juntas, a la orientación norte pero sobre todo al verse entre dos edificios que disminuye significativamente las horas de sol. La razón por la que el huerto está situado ahí es para buscar la protección que ofrecen los edificios, menos viento, menos sol abrasador en verano y más fácil de cubrir con un plástico, pero habrá que replantearlo. Respecto a la proximidad entre semillas, habrá que hacer una segunda plantación con un bancal profundo.

Y de la calidad de lo cosechado, como comento al principio, no me puedo quejar en absoluto.

El Momento de la Verdad

Aunque es un libro sobre calidad y atención al cliente, sus lecciones se pueden extraer y extrapolar a cualquier ámbito.

3 compañías, 3 problemas diferentes, 3 enfoques diferentes.

Estudiar las necesidades en cada caso. No hay soluciones universales, no hay balas de plata, no hay buenas o malas decisiones, sino las decisiones adecuadas a cada necesidad.

Los empleados son un activo fundamental de la compañía. Por tanto tener a los empleados motivados y mantenerlos así resulta vital para que marquen la diferencia.

Para conseguir motivarlos Carlzon recomienda comunicar internamente el nuevo paradigma (visión) de la organización y delegar responsabilidades para que cada empleado opere ajustándose al nuevo paradigma

“Queríamos que todo el mundo en la compañía entendiera el objetivo”.

En este caso el paradigma es satisfacer al cliente, así que la plantilla tenía autoridad para decir “sí” para satisfacer las necesidades del cliente, pero debía pedir permiso para decir que “no”. ¿Funcionaría este enfoque en España?

Para mantener a los empleados motivados resulta vital el desempeño de los responsables.

Para mantener a los empleados comprometidos con la visión de la organización resulta vital el desempeño de los líderes.

El principal objetivo es consguir clientes satisfechos, comunicando efectivamente al mercado la nueva visión y cumpliendo sus expectativas.

Objetivo claro

Todas las acciones de Carlzon se guiaban bajo un único objetivo: que su compañía consiguiese marcar la diferencia con respecto a su compentencia.

You practically need to mentally turn the organization upside down to become a customer-driven service company. When I was at SAS, we said: “We used to fly airplanes – now we fly people.” [1]

Tienes que cambiar la mentalidad de la organización prácticamente de arriba a abajo para convertirte en una compañía de servicios orientada al cliente. Cuando yo estaba en SAS decíamos que “nosotros solíamos hacer volar aeroplanos; ahora hacemos volar a personas”.

1 nuevo enfoque : Momentos de la Verdad

El cambio de paradigma fue considerar a sus clientes satisfechos como los verdaderos y más importantes activos de su compañía, y por tanto cada contacto entre un cliente y cualquier parte de la compañía era un Momento de la Verdad. Estos momentos son los que determinan si una organización tendrá éxito o fracasará.

Anytime a customer comes into contact with any aspect of your business – whether with staff at the front line or however remote – is an opportunity to form an impression. [1]

Cualquier ocasión en que un cliente entra en contacto con cualquier aspecto de tu negocio [...] es una oportunidad para formar una impresión.

De ahí la importancia de los empleados, especialmente los que tienen trato directo con el cliente. Esta “primera línea” de contacto con el cliente disponía de libertad de acción y decisión sobre los burocráticos procedimientos para conseguir satisfacer al cliente en los escasos 15 segundos de media que duran estos momentos. Sí se producían errores, pero :

Los errores pueden ser corregidos generalmente más adelante; el tiempo que se pierde no tomando una decisión nunca puede recuperarse.

(y yo que creía que la agilidad la “descubrieron” ayer dos “gurús” del software, españoles)

Jefe / Responsable / Líder

Es un concepto que tengo claro antes de mi primera lectura de este libro, hará casi una década. Un jefe no tiene que tomar todas las decisiones o producir o saber hacer el trabajo de sus subordinados mejor que sus subordinados.

Un responsable tiene que crear la atmósfera para que el equipo funcione mejor.

Un líder comunica su visión y guía a su equipo.

Algo que ya hacía Sócrates hacía miles de años.

Referencias

[1] Extraído de esta entrevista a Jan Carlzon.

Algo así pasaba con las metodologías tradicionales en cascada hace unos años, algo así pasa ahora con las metodologías ágiles aceptadas en la actualidad, y algo así pasará con las nuevas metodologías que nos sorprenderán este año.

Y con cada cambio de metodología, nos toca aprender. En España suele ser “aprender”, pero por lo que Dilbert nos cuenta pasa es algo universal:

Vamos a probar algo llamado Programación Ágil.

Significa que no vamos a planificar más, y no más documentación. Simplmente empezad a escribir código y a quejaros.

Me alegra que eso tenga un nombre.

Eso ha sido vuestra formación.

No tengo ninguna duda que las metodologías ágiles sí representan una sustancial mejora respecto a sus predecesoras, no en vano estos últimos años han desaparecido de la primera línea los últimos dinosaurios del software (Sun, IBM, ASF) y ha aparecido un gran nuevo actor (Oracle). Está siendo sin duda una década de cambios, todo fluye y nada permanece que diría Heráclito.

Hoy no me imagino enfrentarme a ningún proyecto sin un enfoque ágil y en la importancia de la integración continua sino como objetivo sí como guía, pero en mi modesta opinión le añado una vuelta de tuerca antes de comenzar a enfrentarse a un problema: el poder de las katas, para iniciarse / dominar en las tecnologías y arquitecturas a emplear.

Pero guardaros de los jefes-pelos-punta (o clientes / comerciales / compañeros) que se leen un libro y repiten como en una misa los nuevos nombres molones sin entender lo que dicen, guardaros de esos falsos mesías e ídolos.

Y recordad la lección de Wally, en realidad no es nada nuevo, sólo distinto perro con el mismo collar: únicamente se ha cambiado el énfasis, pero el que hacía buen software ayer es casi seguro que lo seguirá haciendo hoy y mañana.

Pincha en la imagen para verla ampliada. Oringinal en la tira de xkcd, GOTO.

Podría reestructurar el flujo del programa, o podría usar un pequeño “GOTO”…

Bah, que le den a las buenas prácticas. Qué mal puede hacer? goto main_sub2; *COMPILE*

Yo empecé a programar a los 10 años, así que he sufrido el BASIC, sus líneas de código numeradas… pero sobre todo los GOTOs en programas monolíticos de miles de líneas… así que la modularización, reutilización y control de flujo los tengo muy interiorizados.

Hoy en día espero que ningún lenguaje de alto nivel mantenga algo que únicamente debería existir en lenguajes de bajo nivel (recordáis el ensamblador del Motorola 8Mhz?), así que resulta complicado explicar brevemente a todos los que os habéis iniciado en lenguajes más modernos por qué hay que modularizar, reutilizar y mantener un flujo lineal.

Pero todos los lenguajes de alto nivel modernos tienen lógicamente estructuras de control de flujo, algunas TAN odiosas para mí como break o continue de Java que afortunadamente sólo utilizan una ínfima minoría de “profesionales”, para mí leerlas es como recibir sendas bofetadas y mi opinión de tu profesionalidad me la ahorro.

Cuesta concienciar de por qué no utilizar más de un return por cada método, o por qué evitar salidas inesperadas lanzando excepciones o invocando returns en métodos void… Parece inocuo, al fin y al cabo es algo que puedes ver en los códigos fuentes de casi todos los frameworks, pero qué curioso, los bugs tiene predilección por estos métodos en tu código.

Ójala pudiera invocar al monstruo del GOTO cada vez que tengo que arreglar uno de esos…

MORALEJA

Las buenas prácticas son buenas por algo, porque antes de ti ha habido miles de profesionales que durante décadas se han pelado con tu mismo problema: mantén un flujo lineal, una entrada y una salida en cada método.

No son obligatorias de seguir, pero no seguirlas supone un coste… No te quejes cuando tengas que pagarlo, aunque desgraciadamente suele ser otro el que se encuentra tus muertos bajo la alfombra.

Pues con una imagen, que por algo vale más que mil palabras, y si encima contiene humor pues mejor. Os parecerá una tontería, y lo es, pero es algo que he utilizado en más de un documento y correos, alguno para enmarcar jejeje.

Así que voy a crear una nueva categoría en esta humilde bitácora donde recopilar tanta sabiduría visual, comenzando con mañana!

Estén atentos y sintonicen esta bitácora!

Este proceso es como jugar un hoyo de golf.

Cuando te enfrentas a un hoyo, lo primero que haces es estudiarlo para encontrar el plan más óptimo según el hoyo, la meteorología, tu equipo, la variedad de golpes de tu repertorio y tu habilidad para ejecutarlos.

En un circuito profesional embocar de un golpe es improbable cuando no es imposible, así que el objetivo real del primer golpe es alcanzar primero un objetivo más genérico, el green, con una superficie de unos 500 metros cuadrados, en el menor número posible de golpes. Si el green está fuera de tu alcance actual, buscas una posición óptima, estable y segura en la calle que te permita acceder al green en el futuro más inmediato posible.

Si el green estuviera exageradamente fuera de alcance incluso con varios golpes, por ejemplo en un hoyo de 500 metros si sólo eres capaz de alcanzar 50 metros por golpe, no te molestes en trazar un gran plan, sólo en que tu actual golpe te deje en las mejores condiciones posibles para el próximo.

En cada golpe (iteración) te replanteas la situación, las condiciones meteorológicas, los obstáculos presentes y futuros (Riesgos potenciales), seleccionas una herramienta y cómo utilizarla, ejecutas el golpe y compruebas el resultado.

No siempre el resultado del golpe es el esperado: fallos en la estrategia o en la ejecución, obstáculos previsibles (fuera de límites, agua, bunker, árboles) e imprevisibles (ráfagas de viento, botes inesperados, animales…). Riesgos que se han materializado.

La desviación del objetivo suele traer consigo una serie de problemas e incluso penalizaciones: podemos alcanzar el lado no óptimo de la calle o el semi-rough que rodea la calle con la hierba más alta (menos potencia al golpe, menos precisión), que limita con el rough que es hierba sin cuidar o directamente suelo, algún obstáculo (árbol, bunker, agua) o salirnos del campo (fuera de límites) que nos obliga a volver a lanzar desde el mismo lugar y además nos penaliza.

En ocasiones sin embargo la suerte nos sonríe: un árbol, piedra o animal nos evita salirnos de calle o caer en un obstáculo. Es algo que raramente ocurre y es el peor veneno para los necios: cuanto peor es su situación más confían en esta suerte, porque les ocurrió en una ocasión y ahora esperan que les ocurra siempre.

Resulta vital saber cuándo avanzamos más frenando o incluso retrocediendo. Puede ser más seguro utilizar un hierro en lugar de una madera para sacrificar metros por precisión, o dejar un siguiente golpe más largo por el elevado riesgo del actual, o avanzar sólo unos metros pero asegurarnos de que volvemos a calle, incluso si eso significa retroceder. Es de cobardes retroceder siempre, pero de sabios acertar cuándo se debe retroceder.

Según nos acercamos cobra más importancia la precisión, hasta que finalmente alcanzas el objetivo deseado: el green. Pasamos de un objetivo general y difuso a un objetivo muy específico de 108 milímetros de diámetro. Si no te sales del green tarde o temprano embocarás, pero de nada sirve recorrer 500 metros en 2 ó 3 golpes si necesitas 7 para los 5 metros que te quedan: es el momento de la verdad, el que marca si tiramos por la borda todo el trabajo anterior.Leer su relieve es imprescindible para acertar, todo lo que no llega no entra, nunca salirse del green.

Et voilá, has embocado. La práctica lleva a la perfección, a elaborar mejores planes, a comprender mejor los riesgos, a decidir mejor, a ejecutar mejor.

En la vida real sería más loco y divertido jugar en ocasiones como si estuvieras jugando al croquet en el País de las Maravillas, con una Reina de Corazones cambiando las reglas del juego mientras ordena cortar cabezas, un Conejo Blanco que llega tarde a cambiar las banderas de los hoyos entre sí convirtiendo el hoyo que estás jugando en el número 5 en lugar del 2, Jardineros tapando el hoyo cuando estás preparando el putt mientras hacen otro agujero en otra parte del green, y un Naipe pasando el cortacésped cuando ejecutas el golpe.

En el software es casi siempre así, no hay margen para el aburrimiento .

PD, efectivamente, estoy planteándome volver al golf en el mejor campo que he conocido, en Zarapicos, Salamanca.

UML

Nace del intento de unificar los lenguajes de modelado visuales más extendidos en 1994 (Booch, OMT…). En 1996 OMG lanzó una RFP (Request for Proposal) aceptado en 1997, marcando el nacimiento de UML. Hoy es un estándar de facto abierto en la industria del software.

UML concibe el mundo como colecciones de objetos que interactúan, por eso resulta idóneo para utilizarse en desarrollo de software con lenguajes orientados a objetos. Se utiliza para especificar o describir sistemas, artefactos, métodos y procesos durante todo el ciclo de vida del sistema sin importar la implementación ni el proceso de desarrollo, incorporando las mejores prácticas de modelado para que puedan ser fácilmente legibles por personas e implementarse por las herramientas software de modelado.

Existen dos aspectos en un modelo UML que no están completos el uno sin el otro.

• Estructura estática, describe qué tipo de objetos conforman el sistema y cómo se relacionan.
• Comportamiento dinámico, describe los ciclos de vida de estos objetos y cómo interactúan entre sí para entregar la funcionalidad requerida.

Un modelo UML tiene al menos dos dimensiones:

• Textual, contiene las especificaciones de los diferentes elementos de modelado.
• Gráfica, muestra gráficamente el modelo textual utilizando diagramas e iconos, son simplemente vistas o proyecciones visuales de ese plano posterior semántico. Pueden existir elementos elididos (si no se muestran gráficamente), incompletos (pueden faltar en ambas dimensiones) e incoherentes (contradicciones entre los elementos).

UML se compone de 3 Bloques de Construcción.

• Elementos.
  • Estructurales. Son los nombres de un modelo UML, como una clase, interfaz, colaboración…
  • Comportamiento. Son los verbos de un modelo UML, como interacciones, actividades, máquinas de estado.
  • Agrupación. Paquetes que se utilizan para agrupar los elementos semánticamente en unidades cohesivas.
  • Anotación. Notas que se anexan al modelo para capturar información ad hoc.

• Relaciones, unen a los elementos entre sí especificando cómo dos o más elementos se relacionan semánticamente.
  • Dependencia. El elemento origen depende del elemento destino y se puede ver afectado por cambios en éste.
  • Asociación. La descripción de un conjunto de vínculos entre objetos.
  • Agregación. El elemento destino es una parte del elemento origen.
  • Composición. Una forma de agregación más fuerte, más restringida.
  • Contención. El elemento origen contiene el elemento destino.
  • Generalización. El elemento origen es una especialización del elemento destino más general y se puede sustituir por éste.
  • Implementación. El elemento origen garantiza llevar a cabo el contrato especificado por el elemento destino.
• Diagramas, nos muestran qué hará el sistema (diagramas a nivel de análisis) o cómo lo hará (diagramas a nivel de diseño).

UML utiliza 4 Mecanismos comunes para conseguir objetivos específicos:

• Especificaciones, descripciones textuales de la semántica de un elemento.
• Adornos, que se añaden a los elementos gráficos para hacer visibles aspectos de la especificación del elemento textual.
• Divisiones comunes.
  • Clasificador/instancia (abstracción/especificación). Comparten icono pero las instancias tienen el nombre subrayado. UML proporciona 33 clasificadores (actor, clase, componente, interfaz, caso de uso…)
  • Interfaz/implementación. Separando lo que se hace de cómo se hace, los contratos ocultan la complejidad.
• Mecanismos de extensión. UML no puede ser universal y satisfacer las necesidades presentes y futuras de todos los proyectos, por los que incorpora:
  • Restricciones, cadena de texto entre llaves que especifica cierta condición o regla sobre el elemento. UML define como una extensión estándar OCL (Object Constraint Language o Lenguaje de Restricción de Objetos).
  • Estereotipos, variaciones de un elemento de modelo existente con la misma forma pero con un propósito modificado, representado con el nombre del nuevo elemento entre cursores, <<…>>.
  • Valores etiquetados, son palabras claves que puede tener un valor anexado, al modo del valor de una propiedad.

TDD

Proceso de Desarrollo En Cascada

En realidad no supone un gran cambio respecto al proceso tradicional en cascada, pero el énfasis que pone en dos aspectos claves cambia la forma de ver el ciclo de desarrollo, al igual que una tilde o una coma pueden cambiar completamente el significado de un texto.

Una vez que el equipo de desarrollo y el cliente comprueban todo el valor que aportan a un producto, se preguntarán cómo han podido vivir antes. Pero para llegar a este estado se debe contar con el apoyo claro de la dirección del equipo de desarrollo.

Primero las pruebas [1]

TDD - Core

Tradicionalmente primero se desarrolla y luego se prueba. Este proceso propone intercambiar el orden las cajitas de desarrollo y pruebas para que las pruebas guíen el desarrollo (incluso hay quien dice que deben guiar el diseño) :

• Primero especificar y desarrollar pruebas que debe superar el producto.
• Después se desarrolla. Este paso no se da por finalizado hasta que se superan todos los test. Esta es la razón por la que se dice que las pruebas guían el desarrollo.
• Finalmente se refactoriza (cambiar la estructura interna de un sistema sin afectar a sus funcionalidades) tanto las pruebas como el código para mejorar el diseño interno. Al igual que el paso anterior, esta tarea no se da por completada hasta que se superen todos los test.

Se consigue mejorar la comunicación entre equipos, aumentar la comprensión de lo que realmente se debe desarrollar y al automatizar las pruebas se reduce muy significativamente el tiempo dedicado a pruebas manuales (tanto por el equipo de desarrollo como por el cliente al validar los entregables) a la vez que se aumenta la confianza en el producto.

Entregas frecuentes [2]

Waterfall vs Iterative Waterfall

Por otro lado aconseja la repetición de ciclos de desarrollo muy cortos. En cada iteración (o entrega) se parte de un estado estable y confiable (el código supera todas las pruebas automáticas) y finalizamos en otro estado estable y confiable.

También aporta grades beneficios a nivel global del proyecto. Si debemos especificar menos requisitos y partimos de un prototipo podremos ser más específicos y rigurosos, y las entregas continuas facilitan el control del desarrollo (garantizando que la comprensión del producto es la correcta y mejorando el diseño interno) y en la fase de explotación aumentan el valor del producto reduciendo el tiempo de entrega.

Ajustando los parámetros : cobertura

El precio a pagar por la utilización de este proceso es que desarrollar pruebas significa que hay más código que mantener, más tiempo de desarrollo inicial, más código que probar (las pruebas no tienen por qué estar libre de errores, desarrollamos pruebas para las pruebas? Y también pruebas para las pruebas de las pruebas?…). También es posible encontrar pruebas que no cubran efectivamente el código y/o no han evolucionado mientras el código que cubren sí.

Por tanto se puede recuperar con creces la inversión en el tiempo desarrollo de las pruebas o lastrar el proyecto.  Así, la cobertura de los test, es decir el código que se cubre efectivamente con un test, resulta una decisión crucial para optimizar el proceso y maximizar el ROI de aplicar este proceso.

Sobre la cobertura de los test hay opiniones para todos los gustos, incluso propuestas tan disparatadas como perseguir el 100% de cobertura o valorar la calidad de tu código en función del % de código que está cubierto por test. La opción mayoritaria, que es la que yo recomiendo, es cubrir con test hasta que nuestra confianza en el sistema sea aceptable. Cómo?

• Recomiendo definir un criterio de validación para cada funcionalidad, automatizar estas pruebas de aceptación así como las posibles APIs (puntos de entrada de terceros a nuestro sistema).
• Recomiendo utilizar los datos que se utilizaron para definir los requisitos como Datos de Entrada para alimentar las pruebas. Para ello se pueden utilizar Hojas de Cálculo y/o Bases de Datos. Las Hojas de Cálculo son fácilmente entendibles y mantenibles por los propios usuarios, se pueden adjuntar como anexos al contrato del proyecto y pueden ser leídos por un programa informático.
• Prefiero probar el negocio que los servicios o la persistencia ya que el negocio no puede funcionar si no funciona correctamente el resto.

No más, no menos. Más significa más código a mantener y evolucionar (y posibilidades de error) sin que nos aporte valor, simplemente tardaremos un poco más de tiempo en encontrar exactamente el fallo en un test que no se pasa. Menos significa que nuestro sistema no es confiable.

Para profundizar…

De mi cosecha añadiría también un tercer cambio de paradigma o énfasis. El artefacto entregable es un sistema software (como tradicionalmente lo hemos visto) pero también es un producto (como realmente lo ve un usuario): es importante que el desarrollador lo entienda también como un producto para maximizar el valor del sistema para el cliente y poder reutilizar los máximos componentes posibles.

Los seguidores de TDD recomiendan desarrollar siguiendo los principios KISS (“Keep It Simple, Stupid”, lo simple es bello, efectivo y eficaz) y YAGNI (“You Ain’t Gonna Need It”, no lo vas a necesitar). Yo recomiendo utilizar KISS para todo en esta vida, y YAGNI con mucho cuidado, ya que en ocasiones no seguirlo resulta útil para detectar fallos en el diseño: estás seguro de que no lo vas a necesitar?

[1] Imagen vista en nilclass.

[2] Imagen vista en Agile101. Para ampliar información, consultar The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictures!).

La percepción sobre el expertise de una persona no se basa en sus habilidades ni conocimientos sino sobre su habilidad para comunicarlos. En esta época de velocidad máxima, esta percepción se basa casi únicamente en el número de indicadores de credibilidad que es capaz de presentar. “Doctor en medicina” es un ejemplo de indicador de credibilidad.

Por ello la palabra “experto” ha diluido (por lo menos para mí personalmente) en gran medida su significado y fuerza, siendo un paraguas bajo el que nos encontramos a churros y merinos, expertos y farsantes. Hoy cualquiera puede convertirse en un “experto” en cualquier materia, y bajo tal etiqueta ser presentado a nivel nacional o mundial.

Por supuesto estoy pensando en el 90% de los políticos y de los cargos que adjudican, digooo, en el broker que la semana pasada salió en medios de todo el mundo, provocó reacciones de nuestros iluminados líderes políticos y en la blogosfera, fue trending topic en twitter y luego confesó ser un aficionado.

Es culpa de la falta de rigor periodístico, sí. Si fuera periodista estaría pidiendo que rodarán cabezas de los responsables, por aquello de contrastar las fuentes y tal. Pero también tenemos todos un poquito de prisa y nos creemos lo que nos dice cualquier medio sólo “porque sale por la tele”.

Quieres probar tú? Quieres convertirte en experto planetario? Tim Ferriss te sugiere en su libro La semana laboral de 4 horas cómo lograrlo siguiendo estos sencillos pasos:

• Hacerse miembro de 2 ó 3 organizaciones sectoriales.
• Leerse los 3 libros más vendidos sobre tu materia y resumirlos en 1 folio.
• Ofrecer cursillos gratuitos en universidades, centros educativos…
• Ofrecer cursillos gratuitos en pequeñas empresas y filiales.
• Colaborar con revistas sectoriales.
• Suscríbete a ProfNet, www.expertclick.com o similares, lugares donde los periodistas buscan a expertos para que opinen sobre una materia para sus artículos.

Encuestilla

Esto me recuerda… Por 25 céntimos de peseta, qué eventos vistos/leídos por más del 50% de la población mundial son una auténticas farsas?

Un hombre de negocios se fue de vacaciones a un pueblecito costero. Dando un paseo por el muelle vio atracar a una pequeña barca con un único pescador que traía varios atunes. El hombre de negocios felicitó al pescador por la calidad de su pescado.

-          Cuánto has tardado en cogerlos?  – le preguntó al pescador el hombre de negocios.

-          Sólo un ratito – contestó el pescador.

-          Por qué no se queda más tiempo y pesca más?

-          Tengo suficiente para mantener a mi familia y dar algunos a amigos.

-          Pero… qué hace con el resto del tiempo?

-          Me levanto tarde, pesco un poco, juego con mis hijos, me echo la siesta con mi mujer y voy al pueblo todas las noches dando un paseo, donde bebo vino y toco la guitarra con mis amigos. Tengo una vida plena y ocupada, señor.

-          Señor, soy licenciado en administración de empresas y puedo ayudarle. Debería pasar más tiempo pescando y con las ganancias comprar una barca más grande. En poco tiempo podría comprarse varias barcas al ser mayor la redada. Con el tiempo tendría una flota de barcos de pesca. En lugar de vender lo que faena a un intermediario lo vendería directamente al consumidor, hasta abrir su propia enlatadora.

>  Tendría que marcharse de esta pequeña aldea costera de pescadores claro, para mudarse a la capital para preparar su salto como multinacional rodeado de un equipo directivo en condiciones.

-          Pero señor, cuánto tiempo me llevará todo eso?

-          15 ó 20 años. Como mucho 25.

-          Pero luego qué, señor?

-          Eso es lo mejor. Cuando llegue el momento anunciaría su salida a bolsa y vendería sus acciones al público haciéndose muy rico. Ganaría millones.

-          Millones, señor? Y luego qué?

-          Luego se jubilaría y se mudaría a un pequeño pueblecito pesquero donde se levantaría tarde, pescaría un poco, jugaría con sus hijos, se echaría la siesta con su mujer e iría al pueblo todas las noches dando un paseo, para beber vino y tocar la guitarra con sus amigos…