Lo tenía que poner, hace ya unos días que vi el vídeo de el Kalimotxo de Mamá, y hoy siendo viernes y con los San Fermines tan cerca me hace gracia ponerlo.

Como curiosidad, como podréis haber visto es un vídeo que nos presenta Kukuxumusu, la canción la ha compuesto y canta Pablo Carbonell y la dirección es de Juanma Bajo Ulloa, más sobre el video en sanfermin.com.

Por cierto, este año espero volver a estar por Pamlona por tercer año consecutivo, por la zona de la calle estafeta, hasta que llegue el encierro :).

Como hay cosas que todavía las tengo en mi partición de windows, hoy me he instalado maven para empezar a tocarlo, por ahora no creo que le saque todo el jugo cuando no lo hago demasiado con Ant.

La instalación es bastante sencilla, después de descomprimir el archivo descargado, copiamos el directorio dónde nos parezca, luego simplemente vamos a las variables de entorno y le añadimos a la variable PATH el path de nuestro maven, en mi caso c:\maven-2.0.6\bin.

Debemos asegurarnos que tengamos creada también la variable de sistema JAVA_HOME, con el path de la instalación de la máquina virtual.

Para ver que tenemos todo instalado correctamente, podemos probar en la consola el comando mvn --version, que nos dice que versión de Maven tenemos instalado.

Actualización: VictorR nos cuenta como hacerlo en Mac OS

Aprovechando que he instalado el XAMPP, he estado probando la funcionalidad de NetBeans de conectar a bases de datos.

Para esto nos situamos en la pestaña Runtime de Netbeans, allí nos encontramos los servidores, bases de datos, webservices del proyecto y el catálogo de DTD's y schemas XML.

Desplegamos Databases y, al menos en mi caso, encontramos dos conexiones a Java DB (Derby) que viene embebido y Drivers que es donde debemos añadir el driver de Mysql u otro gestor de base de datos al que quisieramos conectar.

Pulsamos botón derecho sobre Drivers y New Driver, seguidamente buscamos el jar y lo añadimos, entonces ya nos sale dentro de nuestros Drivers.
Seleccionamos el driver de Mysql, pulsamos botón derecho y le damos a Connect Using..., ya sólo nos queda poner la típica cadena de la URL de la conexión jdbc, por ejemplo jdbc:mysql://localhost:3306/test, para la base de datos test que tengo en local, y el nombre de usuario y password de Mysql.

Y ya podemos conectar a la base de datos, donde podremos ver tablas, vistas y procedimientos almacenados además de, como no, ejecutar comandos SQL.

Quería instalarme en ubuntu el típico paquete apache, mysql y php, como ya tengo instalado en windows el xampp, me decidí a instalar su distribución para linux. También las hay para Solaris y MacOS.

Después de descargar xampp para linux, se copia el archivo .tar en /usr/local y se ejecuta el comando sudo tar zxvf /usr/local/xampp-linux-1.5.4a.tar.gz -C/opt, y ya queda instalado en /opt/lampp.

Para ejecutar el servidor, simplemente debemos ejecutar el comando sudo /opt/lampp/lampp start y con stop lo podemos parar.

Juan Palacio ha escrito una entrada con su selección personal de las 55 evidencias de la Ing. de software del libro Facts and Fallacies of Software Engineering (Robert L. Glass).

Algunos de los puntos los he vivido en mis carnes, por lo que las reafirmo como evidencias, entre los que destacaría:

Los mejores programadores son 28 veces mejor que los peores. Dado que las diferencias de paga no alcanzan esta proporción, representan la mayor ganga en el campo del software. No se si la proporción real es esa, pero sí que hay muchísima diferencia.

Añadir personal a un proyecto retrasado lo retrasa más. Me ha pasado y lo he visto varias veces, muy pocas veces es una buena solución.

El entorno de trabajo ejerce gran impacto en la productividad y en la calidad del producto. Completamente de acuerdo.

Normalmente las estimaciones se realizan al comenzar el ciclo de vida. Tiene un cierto sentido, si no fuera porque de esta forma se hace la estimación antes de definir los requisitos, y por lo tanto antes de conocer el problema. Algunas veces cuando luego llegan los requisitos y la estimación final del proyecto, pasa lo que pasa.

En la sección de reutilización completamente de acuerdo con todas esas evidencias, pero destaco una que a veces parece no serlo tanto: La modificación de código reutilizable es especialmente generadora de errores. Si se va a revisar más del 10 o 25% de un componente, es mejor rehacerlo de nuevo.

Una de las dos principales causas de proyectos desbocados es la inestabilidad de los requisitos. Esa inestabilidad se suele traducir en ajustes en los requisitos y nuevas funcionalidades, que raro ;) lo que me lleva a: El error más difícil de corregir de los requisitos es: requisitos insuficientes.

Cuando el programador cree que lo ha probado a fondo, normalmente solo ha ejecutado un 50 0 60% de las trayectorias lógicas. Empleando soporte automatizado como analizadores, puede alcanzarse hasta el 80 ´0 90%. Es prácticamente imposible probar el software hasta el nivel del 100%. ¿Alguna vez alguien ha conseguido el 100%? Hay errores que pueden aparecer meses después de la entrega al cliente.