Xnoccio

Sorprendentemente, a juzgar por la inquietud de su carácter, mi hijo Pablo está mostrando mayor afinidad por el ajedrez que por el fútbol. Eso al menos por el momento.

Y aunque uno lleva retirado ya muchos años del noble arte de la diosa Caissa, no deja de tocarme la fibra sensible que mi vástago sienta la misma inclinación que yo padecí hace ya muchos años.

Lo siento, pero no puedo ocultar mis simpatías por los frikis de cualquier índole o condición, cuando se muestran en todo su esplendor. Y unos de ellos es el monitor de Pablo, trabajador jubilado de CASA que descubrió el ajedrez con más de cuarenta años, y que ahora se dedica a él en cuerpo y alma, reconociéndose humildemente jugador de tercera. No sólo imparte las clases desinteresadamente en el colegio público de Palomares, La Rehuela, sino que además se ofrece para dar clases particulares a domicilio en las mismas condiciones…

Aunque reconozco los efectos positivos que puede tener el ajedrez en la formación del carácter de los niños y en el desarrollo de su intelecto, pienso que es una disciplina no exenta de riesgos. Personalmente, si hubiera empleado el tiempo que dediqué al tablero al aprendizaje de idiomas, hoy hablaría hasta el sánscrito. Y todo ello para no pasar de ser un jugador bastante mediocre… Nunca me olvido del excelente ambiente ajedrecístico que gozábamos en la Facultad de Empresariales, con un equipo de lujo que tuve el honor de integrar junto a Manolo Rivas, entonces campeón de españa, y Ricardo Montecatine, además de otras celebridades de los escaques. Sin embargo, y a pesar de su indiscutible capacidad intelectual, casi ninguno de ellos furon capaces de culminar con éxito las titulaciones académicas emprendidas. Y voy a dejar el “casi” para dejar algún margen al error.

Como para Pablo era un gran acontecimiento, unos días antes estuve enseñándole algunas argucias básicas, para fomentar su interés por el juego, y para que un posible buen resultado en el torneo le sirva de motivación para que mantenga la constancia necesaria. Aprendió el mate pastor y algunas celadas propias de la apertura italiana, que deberá abandonar en favor del estilo posicional cuando se enfrente a jugadores de mayor rigor.

El torneo estuvo organizado bajo el sistema Suizo, es decir, eliminándose por enfrentamientos hasta que sólo quede uno.
Ya en la primera ronda le tocó en suerte a un jugador muy bien considerado por los que lo conocían, que venía acompañado por su madre, todo orgullo ella de la afición demostrada por su hijo. Y allí estaba él; sereno, pausado, con las pautas de conducta propias de un Gran Maestro dispuesto a disputar del match valedero por el título mundial. Enfrente Pablo; que no paraba de de dirigir morisquetas a su público que éramos su padre y Adela, su amiga del alma, que por afinidad personal se había inscrito en el mismo torneo.

Pablo, que jugaba con las blancas, inició el juego con peón de rey. Su oponente no supo defenderse del mate pastor, y en la cuarta jugada lo tenía listo para dar mate en P7AR. Entonces, en lugar de ejecutar sin piedad el movimiento de dama tantas veces practicado, jugó C3T, dejando pasar una oportunidad que a la larga le costó la partida.

No obstante, lejos de adoptar una actitud de frustración se acercó y dulcemente me dice: ¿Sabes Papá? me dió pena ganarle tan pronto…

Adelita no encajó su derrota con la misma actitud; terminamos todos rodeándola para explicarle que el ajedrez no es más que un juego, tan desconsolada estaba ella…

Ayer estuve en una jornada organizada por Avante Formación en la Cartuja sobre Usabilidad. Un evento de autopromoción, vaya, pero con la presencia de Yusef Hassan, un crack de la usabilidad en España. Lo mejor, casi lo único interesante fue lo que él dijo. Y digo “casi” porque hubo una bollería más que decente en el desayuno, y porque Quino Terceño, de Cero4 nos obsequió con esta perla:

“El programador diseña aplicaciones igual que un minero diseña paisajes: cavando zanjas y haciendo montones”

Citaba a Alan Cooper en su libro About Faces 2.0.

Pardiez, qué lucidez.

Otras cosas que me interesaron:

Yusef: diseño centrado en el usuario; modelo que sustituye al de cascada (secuencial e irreversible) por éste otro, conocido como “modelo lavadora”:

Modelo lavadora del diseño centrado en el usuario

Yusef:

• El cliente no es el usuario
• El cliente no es el diseñador
• Nosotros no somos el usuario
• Desde que los ratones tienen ruedecita, no es necesario desviar el foco para hacer scroll, por lo que el contenido no tiene por qué comprimirse en una pantalla

Quino:

• Los errores hay que representarlos contextualmente (nos enseñaba el diseño de un procedimiento extenso, con múltiples páginas y formularios)

Por último, nos metieron con cuña una presentación de Microsoft Expression, para el diseño de interfaces. Para Ethel, la web del futuro es algo así como “Microsoflash 2.0″. Esta chica se ve que no visita mucho el sitio de O’Reilly.
Supuse que eran ellos quienes pagaban los pastelitos y el café, así que fui prudente y no hice preguntas.

OpenOCES ha anunciado la release de su nueva version 1.7.0.

Desde aqui no podemos sino primero congratularnos y segundo sentirnos orgullosos de que uno de los nuestros sea el creador/colaborador de una de las nuevas funcionalidades incluidas en esta version:

Changes since v1.6.3:
- fixed access to Microsoft CryptoAPI keystore when IE runs in protected
mode on Microsoft Vista (bug #31)
- added a Java control panel keystore. Contributed by Félix García
Borrego
- explicitly specify source file encoding (bug #52)

http://www.openoces.org/pipermail/announce-development/2007-May/000041.html

Nuestro Felix es un crack!

Tenia que decirlo.

Continuando con las crónicas de Japón, en este segundo episodio vamos a hablar de la seguridad en el trabajo.

Ya comenté lo extremadamente cuadriculados y minuciosos que son los japoneses en cuanto a hacer las cosas bien. Una buena prueba de ello la detectamos un día en el metro de Tokyo al ver unos trabajadores cambiando unos simples tubos fluorescentes. Había hasta 4 personas, cada una con una función bien definida. Uno realizando el trabajo sucio, otro de apoyo logístico por lo que pueda pasar, otro aguantando la escalera para evitar cualquier caída inesperada y un cuarto cubriendo el perímetro para evitar un acercamiento descuidado de cualquier transeúnte.

Versión Japo del cambio de un tubo fluorescente.

Para sorpresa nuestra al llegar a Atocha a la vuelta de nuestro viaje, nos encontramos con la situación análoga a la española. Creo que en ningún caso como en este una imagen vale más que mil palabras, o mejor dos imágenes para contrastar una y otra. Busque las diferencias.

Versión Española del cambio de un tubo fluorescente.

Por cierto, seguramente los dos obreros que faltan en la versión española con respecto a la versión japonesa, estarían echando una cervecita.

David tiene una apotación del tema de seguridad en el trabajo en su versión marroquí. Tampoco tiene desperdicio.

Pues sí señores, tras una larga espera y mucha incertidumbre (la mayoría lo dábamos por imposible) el pasado Viernes 18 de Mayo del 2007 tuvo lugar un evento en Seul (Korea) que solo puede calificarse de un modo: El retorno del Rey.

Y no hablo de la (fantástica) trilogía de Tolkien, sino del rey de los videojuegos: Blizzard anunció el retorno de Starcraft, y ni cortos ni perezosos mostraron videos de Starcraft II que hicieron temblar el pabellón. Y no es para menos: Korea es cuna de campeones en este juego, donde es incluso un deporte (hay gente que cobra por jugar al Starcraft).

Sin más preámbulos, os dejo con la octava maravilla del mundo lúdico, el único juego que de verdad he jugado hasta exprimirlo.

Web oficial Starcraft II

Como diría un marine, ¡Oh síii!

Vale, por una vez me voy a dejar de foos y bars y voy a extraer un pedacito de un codigo que ando ultimamente refactorizando…

En la situacion de partida, tenia un codigo de Java1.4, pero nos hemos migrado a Java5, asi que siempre que puedo toqueteo por aqui y por alla para que el codigo tenga un look&feel java5 real. :)

El fragmento de codigo del que partiamos era el siguiente:

//Recuperamos el tipo de rendicion (MODELO: NORMAL, SIMPLIFICADO, BASICO)
String modelo = request.getParameter("modelo");
if(modelo==null ){
modelo = Constantes.MODELO_RENDICION_NORMAL;
}
if(!modelo.equalsIgnoreCase(Constantes.MODELO_RENDICION_NORMAL) &&!modelo.equalsIgnoreCase(Constantes.MODELO_RENDICION_SIMPLIFICADO)
&& !modelo.equalsIgnoreCase(Constantes.MODELO_RENDICION_BASICO)){
//Trampas
modelo = Constantes.MODELO_RENDICION_NORMAL;
}
log.debug("Tenemos MODELO DE RENDICION: "+modelo);

No creo que requiera mucha explicacion, pero basicamente ese codigo chequea que no nos hacian trampas, y nos llegaba un modelo vacio, o distinto de uno de esos tres: NORMAL, SIMPLIFICADO, BASICO.

Para los que venimos de la escuela del C/C++ encontramos ese codigo, nos resulta, poco menos que realmente horrible por el uso de las constantes (a la manera de #define).

Vale, aqui llego yo de pasada, y apesar de las prisas no puedo evitar meterle mano. Me “cargo” las constantes, y creo un enum…

Las constantes:

//Moved to TipoCuenta enum
public static final String MODELO_RENDICION_NORMAL = TipoCuenta.NORMAL.getModeloRendicion();
public static final String MODELO_RENDICION_SIMPLIFICADO = TipoCuenta.SIMPLIFICADO.getModeloRendicion();
public static final String MODELO_RENDICION_BASICO = TipoCuenta.BASICO.getModeloRendicion();

El enum:

/**
* To distinguish among the different types of accounts avoiding
* the *risky* use of constants
* @author dbejar
*
*/
public enum TipoCuenta {
NORMAL		("Normal","N04","xxxxxx","xxxxxx","xxxxxx"),
SIMPLIFICADO	("Simplificado","S04","xxxxxx","xxxxxx","xxxxxx"),
BASICO		("Basico","B04","xxxxxx","xxxxxx","xxxxxx"),

private String nombreCuenta;
private String modeloRendicion;
private String tipoCuenta;
private String nsCuenta;
private String validacionLiq;

TipoCuenta(String nombreCuenta, String modeloRendicion, String tipoCuenta, String nsCuenta, String validacionLiq){
this.nombreCuenta=nombreCuenta;
this.modeloRendicion=modeloRendicion;
this.tipoCuenta=tipoCuenta;
this.nsCuenta=nsCuenta;
this.validacionLiq=validacionLiq;
}
public String getnombreCuenta(){
return nombreCuenta;
}
public String getModeloRendicion(){
return modeloRendicion;
}
public String getTipoCuenta(){
return tipoCuenta;
}
public String getNSCuenta(){
return nsCuenta;
}
public String getValidacionLiq(){
return validacionLiq;
}
}

Tengo que decir que tengo la mania de codificar en ingles, y que las xxxxxx, son censura :)

Vale, ahora el codigo original seria equivalente a:

//Recuperamos el tipo de rendicion (MODELO: NORMAL, SIMPLIFICADO, BASICO)
String modelo = request.getParameter("modelo");
if(modelo==null){
modelo = TipoCuenta.NORMAL.getModeloRendicion();
}
if(!modelo.equalsIgnoreCase(TipoCuenta.NORMAL.getModeloRendicion()) &&!modelo.equalsIgnoreCase(TipoCuenta.SIMPLIFICADO.getModeloRendicion())
 && !modelo.equalsIgnoreCase(TipoCuenta.BASICO.getModeloRendicion())){
//Trampas
modelo = TipoCuenta.NORMAL.getModeloRendicion();
}
log.debug("Tenemos MODELO DE RENDICION: "+modelo);
rendicion.setModelo(modelo);

Con lo que no estamos haciendo ningun uso real de las ventajas de utilizar enums.

El codigo refactorizado quedo asi:

//Recuperamos el tipo de rendicion (MODELO: NORMAL, SIMPLIFICADO, BASICO)
//Modelo NORMAL por defecto
String modelo = request.getParameter("modelo");
if(modelo==null ){
modelo = TipoCuenta.NORMAL.getModeloRendicion();
}
//This is just to check that we got a valid TipoCuenta
try{
switch (TipoCuenta.valueOf(modelo)){
case BASICO: /*NOOP*/
default: /*NOOP means no operation*/
break;
}
}catch(IllegalArgumentException e){
//Trampas
modelo = TipoCuenta.NORMAL.getModeloRendicion();
}
log.debug("Tenemos MODELO DE RENDICION: "+modelo);

Bueno, en realidad, he añadido lo de case BASICO: para ilustrar mejor a todos los javeros sin experiencia en C la diferencia entre la chapuza de las constantes, y un codigo robusto con enum.

Hala pues,

Os dejo algunas fotos del último duelo de Paintball Viavansi.

Sera mejor dejar los nombres de los integrantes de cada equipo en el anonimato, ya que el duelo estuvo muy desequilibrado. El equipo verde gano al equipo guerra por 8-1.

Si alguna empresa se quiere batir en duelo…

Si la decisión de hacer libre un proyecto o librería ya está tomada, aún queda la ardua labor de elegir la licencia que más nos conviene. En nuestro caso concreto, siendo una PYME, la elección ha sido la GPL. Enumero y explico nuestras motivaciones:

- La licencia GPL es vírica por lo que si algún proyecto utiliza el código liberado, éste tendrá que ser a su vez publicado como GPL. Con esto conseguimos por un lado colaborar con la comunidad y por el otro evitar la competencia desleal de otras empresas del sector, que podrían utilizar el código sin proporcionarnos un beneficio recíproco.

- La licencia GPL nos permite liberar el código y a la vez, como titulares del copyright, seguir utilizando éste, si es necesario, en desarrollos no-libres. Incluso nos permite mantener una licencia dual, comercial y libre (el ejemplo más claro lo tenemos en MySQL).

- Hemos descartado licencias tipo BSD, ya que no nos otorga ningún tipo de protección frente al uso del código por terceras empresas. Incluso Microsoft podría incluir parte de vuestro código (Como el caso típico de la implementación de la pila TCP/IP tomada prestada de BSD) :) …

- Otra licencia interesante es la licencia de Apache, pero está más pensada para grupos de proyectos y grandes organizaciones. Estas licencias no son víricas, por lo que son compatibles con cualquier otro proyecto con la única limitación de hay que indicar en los créditos a los autores. Además son licencias muy complejas, más adecuadas para librerías y aplicaciones que se deban integrar con código heterogeneo.

- Usar la GNU GPL exige que todas las versiones mejoradas que se publiquen sean software libre. Con esto evitamos el riesgo de tener que competir con una versión modificada de forma privada de nuestro propio trabajo.

-La LGPL (renombrada a GPL Reducida), es una buena opción, pero nos da menos ventaja por ser autores, ya que al estar pensada inicialmente para librerías, no obliga a que las aplicaciones que hagan uso de éstas, sean a su vez libres.

-La GPL no plantea problemas si utilizamos bibliotecas no GPL, siempre y cuando indiquemos de forma clara su existencia.

-La EUPL, es una apuesta de futuro promovida por la Unión Europea y que tiene previsto adoptar para la liberación de software en las administraciones públicas de Europa. Dado el ámbito público en el que se suelen mover nuestros proyectos, en cuanto esta licencia empiece a funcionar, no cabe duda de que sera nuestra mejor opción.

Quizás la decisión no sea la más adecuada ya que existen licencias libres para todos los gustos:

• Academic Free License
• Adaptive Public License
• Apache Software License
• Apache License, 2.0
• Apple Public Source License
• Artistic license
• Attribution Assurance Licenses
• New BSD license
• Computer Associates Trusted Open Source License 1.1
• Common Development and Distribution License
• Common Public License 1.0
• CUA Office Public License Version 1.0
• EU DataGrid Software License
• Eclipse Public License
• Educational Community License
• Eiffel Forum License
• Eiffel Forum License V2.0
• Entessa Public License
• Fair License
• Frameworx License
• GNU General Public License (GPL)
• GNU Library or “Lesser” General Public License (LGPL)
• Historical Permission Notice and Disclaimer
• IBM Public License
• Intel Open Source License
• Jabber Open Source License
• Lucent Public License (Plan9)
• Lucent Public License Version 1.02
• MIT license
• MITRE Collaborative Virtual Workspace License (CVW License)
• Motosoto License
• Mozilla Public License 1.0 (MPL)
• Mozilla Public License 1.1 (MPL)
• NASA Open Source Agreement 1.3
• Naumen Public License
• Nethack General Public License
• Nokia Open Source License
• OCLC Research Public License 2.0
• Open Group Test Suite License
• Open Software License
• PHP License
• Python license (CNRI Python License)
• Python Software Foundation License
• Qt Public License (QPL)
• RealNetworks Public Source License V1.0
• Reciprocal Public License
• Ricoh Source Code Public License
• Sleepycat License
• Sun Industry Standards Source License (SISSL)
• Sun Public License
• Sybase Open Watcom Public License 1.0
• University of Illinois/NCSA Open Source License
• Vovida Software License v. 1.0
• W3C License
• wxWindows Library License
• X.Net License
• Zope Public License
• zlib/libpng license

(Fuente http://opensource.org)

No creo que nunca encuentre tiempo para escribir sobre David Kellogg Lewis, y el Realismo Modal… Muy muy muy brevemente, para Lewis, no es que otros mundos sean posibles, es que, efectivamente, *existen* otros mundos.

El caso es que me he encontrado esta impresionante presentacion en flash, que me parece genial, para entender la teoria de las super cuerdas, la filosofia de Lewis, y obviamente tener una idea mental de las diez dimensiones. Que significa cada dimension, y porque nos quedamos en un numero finito de dimensiones, y, de hecho, porque exactamente 10.

Desgraciadamente para muchos, tiene el audio unicamente en ingles.

http://www.tenthdimension.com/flash2.php

Cuantos axones neuronales usados en conocimiento inutil, lo se.

Hala pues,

Pon que queremos sustituir todos los foo-n donde n es un digito cualquiera, por, por ejemplo: bar_n

Con “Regular expressions” marcado.

En find: foo-([1234567890])
En replace: bar_$1

En este sencillo ejemplo no hubiese hecho falta usar expresiones regulares, pero os puedo asegurar que nos ha ahorrado mucho tiempo en algunas refactorizaciones nominales.

Hala pues,