subscripción
.: El Blog de Inwe :. » Programación
Reconocimiento facial
Enero 30th, 2009 - [Enlace local]
Como muchos ya saben, el nuevo iPhoto (ILife 09) incorpora el reconocimiento facil dentro de las fotos de nuestras fototecas, pudiendo así visualizar las fotos donde aparece cada persona. Hace poco que he probado esta nueva funcionalidad, y la verdad es que reconoce la gran mayoría de caras que aparecen en las fotos, pero no sólo caras, he aquí un ejemplo:
Entradas relacionadas
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
Micromanagement
Enero 29th, 2009 - [Enlace local]
Hoy he caído por casualidad en una tira sobre micromanagement en Geek Hero Comic:
Está claro que esta tira no es Sinergia Sin Control, pero me ha hecho pararme a pensar si tengo un problema: me he visto reflejado con el tipo del peinado de el de Simply Red (o el Actor Secundario Bob, o Bisbal, o mi amigo Valle ^_^).
Tengo que admitir que soy muy maniático con muchos detalles que considero importantes, y, más que importantes, malos síntomas. Hoy mismo, en una presentación sobre metodología de desarrollo que he hecho para los compañeros, me he declarado un entrometido maniático, y les he pedido disculpas por anticipado al respecto.
Concretamente, soy MUY maniático con estos detalles (entre otros), que si seguís el blog ya habréis visto comentados:
- Programar usando el ratón en vez de dominar (progresivamente) los atajos de teclado.
- No aprovechar las vistas de Eclipse, en sus diferentes variantes: ordenar el código mediante algún criterio en vez de utilizar la vista 'outline'; no utilizar //TODOs y //FIXME para que aparezcan en Tasks; no explotar las posibilidades de la depuración...
- ¡Cortapegar!
- Nomenclatura de variables.
- ...
Tengo que admitir que me siento bastante representado en unos cuantos puntos (la Wikipedia lo asocia a desórdenes obsesivos compulsivos, no sé si diría que tanto, pero casi), así que debo reconocer mi errores al respecto (alguno ciertamente grave). En mi defensa, diré que mi intención siempre fue intentar ayudar, pero está claro que no siempre fue de forma correcta.
Prometo esforzarme en mejorar :).
Una vez hecho este ejercicio de autocrítica...
¿Dónde está la barrera que separa el micromanagement del management y del mentoring? Parece claro que los tres son prácticas relacionadas. Diría incluso que el micromanagement es la perversión de la unión de los otros dos, es llevarlos al extremo. Pero ¿dónde comienza uno y empieza el otro? Creo que es algo subjetivo, que depende de los implicados. Lo que a una persona le puede parecer una ayuda, una sugerencia, a otro le puede parecer un entrometimiento. Seguramente llegar al punto de la confrontación es un síntoma, pero hay otros, como la falta de percepción de confianza, que no son tan fáciles de ver.
Sin embargo, ¿no son herramientas como Checkstyle una forma de micromanagement? ¿No lo es el Daily Scrum? Yo los veo como herramientas para mejorar la calidad del producto y uno mismo, pero esa es mi percepción...
¿Qué opináis? ¿Microgestionais? ¿Lo habéis sufrido alguna vez? ¿Creéis que con ciertas personas o en ciertos momentos puede ser necesario adoptar posturas así? ¿Cómo lo evitaríais?
Supongo que, como siempre, in medio stat virtus.
P.D.: a los compañeros que leáis esto, no dudéis en atarme en corto en este aspecto ;)
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
Trazabilidad
Enero 25th, 2009 - [Enlace local]
Podríamos explicar la trazabilidad (bidireccional) en el contexto del desarrollo de software como "dado un requisito llegar a la línea de código que lo implementa, y al contrario, dada una línea, saber con qué requisitos corresponde"(a grandes rasgos, no cortapegéis esto para nada importante ;) ).
Esto tiene muchos matices y complicaciones, tanto teóricas como prácticas. ¿Realmente es importante? ¿Necesitamos bidireccionalidad? La trazabilidad es claramente una función no biyectiva: una misma línea probablemente corresponde con varios requisitos, y un requisito corresponde con muchos fragmentos de código dispersos.
Hasta hace poco siempre había visto esto como algo imposible de conseguir -a un coste razonable-. Los requisitos se registraban en un procesador de textos, las tareas en un diagrama de Gantt, y el código en un repositorio, todo desconectado. Los intentos que ví para solucionar esto eran añadir funcionalidad a estas herramientas para lograr lo que se necesitaba. Por ejemplo, hay (caros) plugins para Word que añaden "orientación a requisitos", permitiendo, por ejemplo, versionarlos. En las tareas del Project habría que meter los códigos de los requisitos. En los commits de código, los códigos de las tareas... Trabajo, trabajo, trabajo. Al final, se abandonaba.
El problema era de planteamiento. Es inutil forzar el uso de herramientas para un fin ajeno a los objetivos del implicado: al programador no le da ningún beneficio el esfuerzo extra de añadir el código de la tarea. Al analista, el uso de herramientas más complejas que el word le supone también más trabajo. El gestor del proyecto probablemente no tiene ni tiempo ni ganas de actualizar o comprobar el diagrama de gantt...
La solución ha venido de forma conjunta a la adopción de técnicas ágiles y el cambio de herramientas integradas. Las tareas se añaden en el gestor de incidencias (Trac en nuestro caso). Esto, de paso, soluciona el problema del versionado. Además, al ser información estructurada, al estar en una base de datos, se pueden generar informes y vistas en función de las necesidades. Al programador se le da el Eclipse con Mylyn, que le da valor añadido. Indicar la tarea en la que está trabajando no sólo no es trabajo (hacer un click en ella), sino que le aporta valor añadido, ya que el entorno recuerda el contexto (la perspectiva, las vistas, los ficheros abiertos...), haciéndole más fácil alternar entre tareas. Al final, en el gestor tenemos los requisitos (con su histórico) y podemos ver el código relacionado.
¿Moraleja? Si tienes que forzar a tu equipo a algo, la culpa no es del que no te hace caso, sino tuya. Las herramientas adecuadas para las tareas adecuadas.
» Leer más, comentarios, etc...
jordisan.net blog: sobre lo humano, lo divino... y lo técnico: desarrollo
Mis tropiezos con Google App Engine
Enero 24th, 2009 - [Enlace local]
Hace bastante tiempo que tengo en mente una idea para desarrollar una aplicación web y, cuando me decidí por fin a implementarla, elegí Google App Engine, a pesar de que no conocía Python, el único lenguaje que soporta ahora mismo (aunque ha sido una buena excusa para aprender) y a pesar de algunas limitaciones propias de un servicio gratuito y en pruebas.
Al fin y al cabo, esos inconvenientes parecían quedar ampliamente superados por las ventajas de usar la misma infraestructura que usa Google para sus propias aplicaciones: robustez, existencia de un entorno de desarrollo, APIs de gestión de usuarios, de almacenamiento de datos, etc.
Sin embargo, los primeros desarrollos han hecho que dos de esas limitaciones se conviertan en importantes barreras para desarrollar una aplicación que tiene que acceder a otros sitios web:
- Google App Engine funciona únicamente para aplicaciones interactivas, del tipo "petición web"-"respuesta", proceso que debe ser completado en pocos segundos. Dicho de otro modo: no existe soporte para procesos batch o planificados de mayor duración. A pesar de que existen algunas soluciones más o menos válidas para evitar restricción, sería deseable que Google incluyera esa funcionalidad en su servicio; de hecho, es una de las más reclamadas por los usuarios.
Esta limitación es especialmente restrictiva cuando la aplicación tiene que acceder a sitios web de terceros: las conexiones son lentas, los servidores tardan en responder, … Al final sólo se pueden visitar unas pocas URLs antes de que se produzca el timeout.
- Los accesos a otros sitios web se realizan a través de un API específico de Google, que impide que se puedan modificar determinadas cabeceras HTTP; entre ellas, la cabecera
User-Agent. Esto no sería mayor inconveniente si no fuera porque otros sitios web (por ejemplo, el API de Delicious) leen su valor para decidir si responden a la petición o no; y parece que no responden alUser-Agentque envía Google.
Es decir, Google App Engine no permite modificar esa cabecera en las peticiones, y Delicious parece bloquear las peticiones con la cabecera que envía. Un problema que parece poco importante en principio pero que tiene difícil solución.
Estos temas hacen que me esté cuestionando si, a pesar de sus incuestionables ventajas, Google App Engine fue una elección adecuada o no. ¿Tenéis alguna idea al respecto, o conocéis otras alternativas a Google App Engine?
Actualización 11-mar-2009
Buenas noticias. Ahora mismo parece que ya se puede acceder desde Google App Engine a la API de Delicious sin problemas, seguramente porque Delicious ha dejado de bloquearlas. Además, parece que está en los planes de Google, entre otras cosas, dar soporte a tareas planificadas y procesos en background.
Bien por las empresas que escuchan a sus usuarios y dan respuesta a sus necesidades.
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
Calidad de Código
Enero 24th, 2009 - [Enlace local]
Practiques Integración Contínua o no, creo que tus scripts de compilación deberían ejecutar también unas cuantas herramientas de calidad de código. En mi opinión este tipo de herramientas es útil tanto para controlar (y mejorar) la calidad del código en sí como para formar al equipo en una mentalidad de mejora contínua.
Yo acabo de integrar las siguientes (y la lista probablemente siga aumentando):
¿Qué otras herramientas utilizáis?
» Leer más, comentarios, etc...
.: El Blog de Inwe :. » Programación
Colección de utilidades para desarrolladores de PHP
Enero 21st, 2009 - [Enlace local]
Smashingmagazine publica una serie de herramientas que nos facilitará la programación en PHP. La lista la conforman no sólo IDEs, sino también frameworks, herramientas online, debuggers, herramientas de pruebas y optimización, documentación, seguridad, manipulación de imágenes y gráficos, control de versiones, extensiones, clases, plugins para Firefox, etc.. como se puede comprobar es de lo más completo, sin duda indispensable para cualquier desarrollador de PHP.
Enlace: 50 Extremely Useful PHP Tools
Entradas relacionadas
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
Informática Corporativa
Enero 20th, 2009 - [Enlace local]
En muchas organizaciones, y muy notablemente en la Administración, se viene creando un departamento (o movimiento, o tendencia, o normativa...) de "Informática Corporativa". Procede de que la organización crece horizontalmente y la informática, que es transversal (ya que afecta y se desarrolla en todos los departamentos), se vuelve heterogénea en la organización. Esta heterogeneidad es vista como algo negativo, ya que en apariencia aumenta los costes:
- El personal es menos flexible, ya que un especialista en la tecnología de un departamento puede no serlo para otro.
- Los recursos hardware son menos versátiles, ya que las aplicaciones desarrolladas en un departamento no son desplegables en otro.
Esto, visto desde el punto de vista funcional, desde la organización se pretende interpretar como algo fantástico: durante uno o dos (o más) años estudiamos las tecnologías disponibles, para seleccionar la más mejor, especializarnos en ella, y utilizarla para todo.
En la práctica, lo que sucede es que las organizaciones tardan dos años en seleccionar una tecnología que ya está obsoleta para cuando se implanta por primera vez, y se pelea contra ella durante años. Los errores cometidos durante el estudio (todos nos equivocamos) en vez de solventarse se parchean, para mantenerse de forma supuestamente ortodoxa en la normativa. El personal de toda la organización se especializa (en el mejor de los casos) en herramientas que carecen de interés en muy poco tiempo, y se estancan en ellas. Por tanto, todo intento de cambio se percibe como una amenaza, una intromisión en su trabajo. Además, como la arquitectura se convierte en normativa, se prohíbe la instalación en la red interna de todo aquello que se salga de ella.
La informática cambia con mucha frecuencia. Y, aunque no cambiase, no hay balas de plata. Intentar hacer norma de una tecnología es una locura: no hay nada que sirva para todo (ni en metodologías ni en herramientas) y lo menos malo para todo lo es hoy pero no mañana.
No me gusta señalar problemas sin proponer alternativas. ¿Solución? Normaliza el cambio:
- Establece una política de formación que permita que la gente no sólo se recicle periódicamente, sino que también evolucione constantemente.
- Haz una revisión tras cada proyecto para analizar los puntos positivos y negativos.
- Haz un estudio de viabilidad real, en el que de verdad se estudien alternativas de implementación.
PD: mañana tengo que trabajar en mostrar que un cambio es positivo, ¡deseadme suerte! ;)
» Leer más, comentarios, etc...
.: El Blog de Inwe :. » Programación
Nuevo documento de texto en Leopard
Enero 19th, 2009 - [Enlace local]
Una de las cosas que más echaba de menos de Windows, era la posibilidad de añadir un nuevo documento de texto vía el menú contextual, y en el directorio sobre el que estamos en el Finder. Pero vamos, como dije antes echaba de menos, porque por fin di con la forma de hacerlo en Leopard, y es a través de los poco usados (al menos por mi, hasta ahora) AppleScripts.
Para ello, tendremos que hacer lo siguiente:
- Lo primero, bajarnos, si no lo tenemos ya instalado, la aplicación Big Cat Scripts.
- Una vez bajado el paquete (.zip), lo descomprimimos y copiaremos los scripts en el directorio ~/Libreria/Application Support/, donde ~ indica nuestro directorio de inicio (en mi caso /Users/inwe/).
- A su vez, copiaremos el archivo BigCat.plugin en la carpeta ~/Libreria/Contextual Menu Items/
- Ahora crearemos, en la carpeta ~/Libreria/Application Support/Big Cat Scripts/Files/ un archivo, que llamaremos “Nuevo documento de texto”. Para ello, usaremos, por ejemplo, el editor TextWrangler (gratuito) o cualquier otro que disponga de un Editor de Scripts, y ponemos lo siguiente:
on main() tell application "Finder" try set _folder to (the target of the front window) as alias on error beep end try display dialog ¬ "New text file name:" default answer "" buttons ¬ {"Cancel", "Create"} default button 2 set _fname to text returned of result if exists file _fname of _folder then display alert "A file named ‘" & _fname & ¬ "’ already exists in this folder." as informational return -- ends script end if set _path to quoted form of ((POSIX path of _folder) & _fname) do shell script "edit " & _path end tell end main - Ejecutamos el código y lo guardamos (~/Libreria/Application Support/Big Cat Scripts/Files/Nuevo documento de texto).
Pues bien, ahora ya sólo nos queda cerrar la sesión, y al volver, cuando en cualquier lugar del Finder, usemos el menú contextual, en Más > Scripts aparecerá nuestro Nuevo documento de texto, el cual nos abrirá una ventana donde introduciremos el nombre del archivo y el editor para que pongamos lo que queramos.
Entradas relacionadas
» Leer más, comentarios, etc...
.: El Blog de Inwe :. » Programación
Entorno de desarrollo de Android con Netbeans
Enero 19th, 2009 - [Enlace local]
El entorno normal para desarrollar en la plataforma Android es Eclipse, pero por suerte, todos aquellos que usamos NetBeans como IDE, también disponemos de un entorno para el desarrollo de aplicaciones de Android. Para ello debemos instalar varios complementos (3), que nos darán toda la funcionalidad necesaria para trabajar con esta plataforma.
El método más sencillo de instalación es a través del Administrador de complementos, para ello vamos a:
Herramientas > Complementos y ahí la pestaña Configuración
Le damos al botón Agregar, le damos el nombre que queramos y añadimos el siguiente enlace:
Automáticamente comprobará el sitio y en Complementos disponibles nos aparecerá Android, bajo la categoría Mobility. Con lo que ya sólo nos queda seleccionarlo y empezará la instalación de los complementos. Y así, tras reiniciar, ya podremos crear nuevos proyectos para esta plataforma.
Enlace: Android plugin for Netbeans
Entradas relacionadas
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
X enlaces de esta semana
Enero 18th, 2009 - [Enlace local]
Unas cuantas cosas que me han llamado la atención esta semana:
La LOPD y el Cloud Computing
Interesante artículo sobre las implicaciones legales de externalizar los datos.
100 Interview Questions for Software Developers
Preguntas que debes hacer (o para las que te debes preparar) en una entrevista de trabajo.
Getting ready for the cloud
Desplegar una aplicación Java existente en Amazon EC2.
» Leer más, comentarios, etc...
design-nation.blog/es
Keep Your Word 1.4
Enero 14th, 2009 - [Enlace local]
Keep Your Word 1.4 acaba de publicarse. Las nuevas funcionalidades más importantes son:
- Soporte para dos textos diferentes por cada significado de la palabra.
- Esos dos textos pueden utilizarse en el modo Flash Cards.
- Las palabras pueden duplicarse.
- Un nuevo panel de entrada rápida.
- Navegación por teclado mejorada.
Aquí están las release notes completas, y la aplicación puede descargarse de aquí.
» Leer más, comentarios, etc...
.: El Blog de Inwe :. » Programación
Conectando los puntos
Enero 13th, 2009 - [Enlace local]
Esta mañana, uno amigo me ha pasado por Google Talk un enlace a un vídeo que Steve Jobs dió en la Universidad de Stanford (hace un par de años). En un principio, como no tenía ni idea de que iría, pensé en verlo sólo por la presencia del “Dios” de todo maquero (nuevo o viejo), esperando ver si dice algo interesante… y ya creo que lo hizo. Jamás hubiese pensado que me llegaría tan adentro, es sin duda uno de las mejores interpretaciones que he escuchado sobre cómo afrontar la vida y con qué actitud.
Aquí os dejo el vídeo, espero que os sirva tanto como a mi:
Entradas relacionadas
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
Buenas prácticas: Tratamiento de Excepciones
Enero 13th, 2009 - [Enlace local]
Entrada rápida que resume algo que ya he escrito en otros sitios, y que me gustaría tener público (¡y recibir comentarios!).
Criterios a tener en cuenta al tratar excepciones en Java:
- Es mejor que la aplicación falle a no saber que ha fallado (y qué ha fallado). Corolario: si no vas a tratar una excepción correctamente, mejor no hagas nada y que la aplicación falle.
- Siempre que se produzca un error en la aplicación tiene que haber información sobre el error en pantalla, al menos indicando que se ha producido un error. Corolario: no te limites a trazar el error en el log, ¡no siempre habrá alguien mirando!
- No traces mediante System.out o System.err, utiliza un sistema de logging.
- Si sólo vas a relanzar la excepción, no la relances, haz que el método lance ese tipo de excepción.
- No loguees y relances constantemente, no es necesario. Los únicos puntos que no deben lanzar excepciones son los métodos invocados directamente por la aplicación, para que no le llegue al navegador la traza del error. Y si utilizas un framework que gestione bien las excepciones (como Seam), incluso puedes saltarte esta norma.
- Cuando escribas en el log, escribe información significativa, como los parámetros recibidos por el método. Lo trivial (el nombre del método, por ejemplo) ya se verá en la traza.
- Al trazar, no concatenes el mensaje de la excepción, vuelca la excepción en sí (toda la traza).
- Un método no debería declararse como throws Exception, ya que enmascara todas las excepciones, sin permitir gestionar el error concreto. No pasa nada, por ejemplo, por que lance varias: throws IOException, MiOtraException. De esta forma, el que la invoque sabrá a qué tipos de error se debe enfrentar.
- } catch(Exception e) { }; : se ocultan los errores, es imposible saber qué ocurre.
- } catch(Exception e) { System.err.println(e) }; : estamos trazando en err, ni se ve nada en pantalla ni en el log, así que en explotación no sabremos qué ocurre.
- } catch(Exception e) { log.debug("Ha ocurrido algo malo: "+e); }; : el nivel de log es incorrecto (debería ser error), no se dan datos sobre el error, estamos concatenando la excepción, no estamos relanzando...
- } catch(Exception e) { log.error(e) }; : no se dan datos sobre el error, y no estamos lanzando nada, así que en pantalla no se verán los errores.
- } catch(Exception e) { log.error("Identificador: "+id, e); throw new MiExcepcion(e) }; : trazamos el error (la excepción) e indicamos un parámetro que puede estar provocando el error. Además, lanzamos una excepción (que contiene la provocada, para no perder traza) para que el nivel superior pueda seguir tratando el error. Esto sería incorrecto, de todas formas, si en nuestro sistema esto vuelca la traza en el interfaz de usuario. Aparte, probablemente incluso sea innecesario hacer esto (ver último ejemplo correcto).
- } catch(Exception e) { log.error("Identificador: "+id, e); anhadirMensajeDeErrorAlUsuario(e) }; : trazamos el error (la excepción) e indicamos un parámetro que puede estar provocando el error. Además, mostramos un mensaje de error en pantalla. Esto sería incorrecto, de todas formas, si este método es invocado por un nivel que necesita procesar el error específicamente.
- ...) throws IOException : si el método no va a hacer nada interesante con la excepción, ¿para qué capturarla?
» Leer más, comentarios, etc...
.: El Blog de Inwe :. » Programación
Reunión del GUM Murcia
Enero 12th, 2009 - [Enlace local]
Bueno, este sábado es la reunión del GUM (Grupo de Usuarios de Macintosh) Murcia, y la verdad es que estoy bastante ilusionado, ya que es mi primera “kedada” dentro del mundillo Mac, y que mejor que hacerlo con los que están más cerca 
. Por si hubiese alguien interesado, la reunión es el próximo 17 de enero, a las 10 horas en el salón de actos de la Facultad de Informática de la Universidad de Murcia (Campus de Espinardo).
Más información en la web de GUM Murcia
Entradas relacionadas
» Leer más, comentarios, etc...
.: El Blog de Inwe :. » Programación
Usabilidad de los sistemas operativos
Enero 12th, 2009 - [Enlace local]
Hace poco recibí un correo muy interesante sobre un estudio que hicieron en no sé que univeridad, sobre el nivel de usabilidad de los sistemas operativos más usados (Windows, Linux, Mac OSX) según las taréas más comunes que se realizan. Estos fueron los resultados 
Entradas relacionadas
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
Dos enlaces de esta semana
Enero 11th, 2009 - [Enlace local]
Uno de morralla comercial y otro de programación:
SOA ha muerto. Larga vida a los servicios
¿Qué significa "SOA ha muerto"? ¡Nada! Lo único que consiguen grupos como Burton con declaraciones como estas es cambiar las conversaciones de enteradillos que los directivos que no saben de qué están hablando mantienen entre reuniones. Igual, siendo malpensado, consiguen también redirigir inversiones: ya han conseguido vender su consultoría acerca de SOA, ahora tienen que conseguir vender otra, y ya sabemos que este es el año del Cloud Computing...
Lead developer, Are Yoy Mentoring?
Un buen artículo sobre cómo reintegrar a un programador negativo. En vez de quejarse, tener iniciativa, preguntarle, utilizar herramientas de análisis estático...
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
Introducción a Seam
Enero 8th, 2009 - [Enlace local]
Como apoyo para una próxima sesión de formación he preparado una modesta presentación/resumen de lo que es Seam, muy por encima. Las principales fuentes son el manual de referencia y "Seam in Action", así que si quieres conocerlo en profundidad, nada como las fuentes originales, mucho más detalladas y sin mis gazapos (ni tonterías de mi cosecha ni relación con trabajo previo mío).
