Fetishcode...Thinking in objects
Encuesta sobre JDeveloper
Abril 29th, 2009 - [Enlace local]
A
» Leer más, comentarios, etc...
Blog del grupo SQUaC
Mañana miércoles, en el Encuentro Ideas Emprendedor 2.0
Abril 28th, 2009 - [Enlace local]
Manaña miércoles, 29 de abril, asistiremos al Encuentro Ideas Emprendedor 2.0: Internet como Oportunidad de Negocio que se ha organizado en el campus de la Universidad Politécnica de Valencia (UPV).
El acto contará con una charla de Eduardo Manchón, co-fundador de Panoramio y que actualmente trabaja en Google.
¡Nos vemos allí!
» Leer más, comentarios, etc...
MadeInFlex
Supervising Presenter
Abril 27th, 2009 - [Enlace local]
Este patrón permite extraer la lógica de presentación de la vista en una clase conocida como ‘Presenter’. La vista tiene alguna autonomía, y el control en la vista puede estar ligado directamente a un dominio o value objects.
» Leer más, comentarios, etc...
xailer.info (esp)
Cambiando el compilador de C
Abril 27th, 2009 - [Enlace local]
Como casi todos sabeis, hace tiempo que decidimos que ya era hora de cambiar de compilador de C, no porque BCC++ no esté haciendo bien su trabajo, que salvo por un par de bugs se está comportando muy bien, sino porque desgraciadamente es un compilador sin futuro:
- No genera código para 64 bits ni para otras plataformas, ni parece que tengan planes para hacerlo.
- En cualquier momento puede desaparecer de la web de Embarcadero (que es la empresa que ha comprado los compiladores de Borland), y nos deja completamente con las manos vacias.
Hay muchos otros compiladores que podríamos escoger, pero lógicamente nos hemos centrado en aquellos que son gratuitos, para no obligar a nuestros usuarios a hacer un desembolso económico extra. Entre los que conocemos están:
- MinGW
- Pelles C
- MSVC
- Watcom C
- Digital Mars
- LCC
Seguramente hay mas, pero estos son los que conocemos. Los tres últimos los descartamos casi desde el principio simplemente porque no los conocemos lo suficiente o creemos que no son suficientemente “populares”. Y MSVC (en su versión gratuita, VS Express 2008) la descartamos porque hay que descargar casi 1 GB para hacerlo funcionar, entre el propio VS y el Platform SDK. Además, aunque genera código para 64 bits, para ARM no es gratuito. Y también estaríamos siempre con la inseguridad de que MS podría dejar de ofrecerlo gratis en cualquier momento.
Finalmente nos hemos centrado en los dos primeros. Respecto a Pelles C, no es que sea muy popular, pero ciertamente es un paquete compacto de compilador y utilidades muy bien cuidado. Las primeras impresiones, antes incluso de intentar compilar ni siquiera el propio xHarbour, se pueden resumir así:
| Pros | Contras |
|
|
| Pros | Contras |
|
|
Con todo esto presente, nos ponemos ‘manos a la obra’ y empezamos por lo más inmediato… compilar el propio xHarbour:
- MinGW: Tuvimos bastantes problemas, ya que no está totalmente claro de antemano qué hace falta (make, msys, variables de entorno, etc.), pero finalmente, corrigiendo algunas cosas de los ficheros make, pudimos compilarlo. No obstante, no terminó todo el proceso, aunque sí está la parte que más nos interesa por ahora que es el compilador y las librerías. Esperabamos algo así, dada la falta de usuarios de xHarbour-MinGW, pero francamente fue un poco desesperante.
- Pelles C: perfecto, sin ningún tipo de problemas. Y completo. Esperabamos que fuera más fácil que con MinGW, pero sinceramente no creíamos que fuera a salir a la primera.
Respecto a los tiempos de compilación, Pelles C es sólo un poco más lento que BCC++ (en torno a un 20%), mientras que MinGW es anormalmente lento. Tardó aproximadamente el triple que BCC++, contando sólo hasta el punto donde falló. En cualquier caso, no vamos a pararnos aquí, ya que la tarea de compilar xHarbour no es muy habitual, y por supuesto no tiene porqué recaer en el usuario; nosotros ya nos encargamos de eso y entregamos un paquete instalable listo para trabajar.
El siguiente paso consiste en compilar Xailer, pero como nos hemos vuelto muy cómodos y en vez de usar ficheros make y bat lo compilamos todo con XEdit, pues primero hay que modificar XEdit para que soporte estos otros compiladores de C. En la próxima entrada veremos estos cambios.
» Leer más, comentarios, etc...
Najaraba.com: Software libre, negocios y más.
Computación y Ajedrez
Abril 26th, 2009 - [Enlace local]
Ciertamente tengo el ajedrez bastante olvidado, y hace años -demasiados- que no juego ni una partida. Un día volveré a recuperarlo de mis aficiones, al menos para enseñarle lo básico a mi hijo. Pero el ajedrez y sus conexiones con la informática son bastante interesantes. Ya hace unos meses escuché la historia de Deep Blue de mano de uno de sus "entrenadores", Miguel Illescas, y resultó muy
» Leer más, comentarios, etc...
Blog de Julio César Pérez Arques
Historia de una integración (iv): Colaboración
Abril 26th, 2009 - [Enlace local]

Personajes
Esta historia tiene muchos personajes. Además de los usuarios, el cliente, mi equipo y mi jefe, están los distintos equipos de cada módulo SAP con su consultor a la cabeza. Y por supuesto el analista interlocutor del cliente, el llamado Product owner de Scrum, como nexo de todos.Él es el verdadero héroe de esta historia. Trabajador, comprometido, eficaz, comprensivo, dialogante mediador y afable. Rompe con todos las ideas preconcebidas que se pueden tener del cliente funcionario.
La clave para vencer la complejidad humana está en la colaboración. Parece fácil, al fin y al cabo todos teniamos el mismo objetivo: sacar el proyecto adelante.
Pero no sólo fue difícil, en algunos casos ha sido absolutamente agotador. Las personas mediocres tienden a adoptar una postura defensiva y esquiva, están más preocupados por salvar su culo que por el proyecto. Convierten cualquier asunto en una crisis y no se dan cuenta de que así sólo ponen más de manifiesto su ineptitud.
Afortunadamente también había buenos profesionales con los que ha sido una satisfacción trabajar. En realidad me voy a ahorrar los detalles. Supongo que lo entenderéis.
Comunicación
En cualquier caso la mejor forma de colaborar de forma productiva es cuidando la comunicación y las relaciones interpersonales. No hay por qué llevarse mal sólo por ser de diferentes empresas.Respecto a la comunicación me gustaría hacer una serie de observaciones/recomendaciones:
- Usa el medio de comunicación más adecuado. Cara a cara, teléfono o correo electrónico. El correo electrónico es el más flexible pero también es el más frio y propenso a malentendidos, tanto de significado como de actitud.
- Evita discusiones por correo, usa el teléfono y luego mandas un correo resumen.
- Comunícate con la persona adecuada directamente. Evita los intermediarios, simplemente ponles en copia o al tanto.
- Asegúrate 2 veces antes de señalar el fallo de otro.
- Incluye siempre toda la información relativa que puedas, como mensajes, capturas de pantalla, fecha y hora, etc.
- Ser amable o pedir disculpas no es pecado.
- Sé comprensivo. Ponte siempre en el lugar del otro. Piensa que no eres el único que tiene trabajo y que tú también te equivocas.
Problemática de un proyecto de integración
Los problemas técnicos de colaboración en un proyecto de integración se resumen en disponibilidad de entorno y de juegos de datos de pruebas. El entorno de desarrollo/pruebas no siempre está disponible. Y aún con el entorno disponible, no siempre existe el juego de datos requerido.Para minimizar esto lo mejor es usar Mocks que simulen el entorno y devuelvan los datos requeridos. De esta forma te independizas del entorno hasta el último momento, las pruebas de integración. Es la evolución del llamado hardcodeo.
Pero para que los Mocks sean realmente eficaces es necesario que los interfaces estén clara y explicitamente definidos. No sólo el nombre, tipo y orden de los campos de entrada y salida. También los formatos (fechas, cantidades, etc.). Esta definición debe hacerse en un lenguaje formal y procesable por una máquina para (1) evitar errores de interpretación y (2) automatizar la construcción de clientes y servicios. En el caso de los servicios web SOAP se usa el estándar WSDL.
Finalmente me gustaría destacar la importancia del documento Pruebas de integración. Debe estar actualizado y contener un completo juego de casos de prueba que cubra toda la casuística de entrada y salida. Incluidos los posibles errores. Además estas pruebas deben automatizarse cuanto antes para poder usarse como pruebas de regresión.
En resumen, las personas somos más difíciles que la tecnología. Por lo que colaborar no es sencillo. Pero es la única forma de sacar un proyecto adelante. Haz más fácil el trabajo de los demás y el tuyo será más fácil. No seas mezquino.
» Leer más, comentarios, etc...
Ingenieria de Software / Software Engineering
Project Management Tool
Abril 26th, 2009 - [Enlace local]
Desde PMHut leo este artículo sobre características que debiera tener una herramienta de administración de proyectos, de las 3 características que presentan con las 3 concuerdo.
» Leer más, comentarios, etc...
Arragonán
A remix Manifesto
Abril 25th, 2009 - [Enlace local]
Vía un post de Ricardo Galli, me encuentro el documental A remix Manifesto (que es un proyecto open source), que se emitió en TV3 doblado al catalán.
El documental habla sobre los actuales problemas que sufrimos gracias a las leyes de copyright, muy centrado en el caso de la creación de remixes o mashups a partir de otras obras, aunque se muestra también el punto de vista de consumidor.
Y seguirán tratando de ponerle puertas al mar…
Por cierto, no conocía Girl Talk, está bastante bien
» Leer más, comentarios, etc...
{ Radamanthys }
Obtener un arreglo sin valores duplicados
Abril 24th, 2009 - [Enlace local]
Buscando la forma mas simple de generar un arreglo a partir de otro, pero sin tomar en cuenta los valores repetidos de este ultimo, siempre me topaba con array_unique().
print_r(array_unique($orders));
Array ( [0] => 135 [2] => 136 [3] => 138 )
Que si bien es cierto, me devolvia un arreglo con valores unicos, aun me faltaba regenerar el indice(necesitaba que iniciara de 0 en incrementara en 1).
Al final, me tope con esta forma.
print_r(array_keys(array_count_values($orders)));
Donde $orders es un arreglo compuesto de la sgte. forma:
$orders = array('135', '135', '136', '138', '138', '138', '136');
Lo que sucede aqui, es que array_count_values($orders) me duvuelve un arreglo, con un indice, el cual sera cada valor encontrado en $orders y su correspondiente valor sera la cantidad de ocurriencias encontradas, es decir:
Array ( [135] => 2 [136] => 2 [138] => 3 )
Posteriormente, le paso este nuevo arreglo a array_keys(), quien me generara otro nuevo arreglo, con indice numerico, inicializado a partir de cero, que incrementara en 1, y su valor seria cada clave(indice) del arreglo pasado como paremetro (lo que realmente necesitaba).
Array ( [0] => 135 [1] => 136 [2] => 138 )
» Leer más, comentarios, etc...
Blog del grupo SQUaC
Nuestro primer día en el WWW2009
Abril 22nd, 2009 - [Enlace local]
Hoy hemos asistido en Madrid a nuestra primera jornada en el WWW2009, uno de los eventos internacionales más importantes (si no el que más) en lo que respecta a la web.
Puede hacerse un seguimiento en tiempo real del evento en Twitter, o ver algunas imágenes en Flickr. De nuestra experiencia personal, y en lo que respecta a la temática del blog, nos gustaría destacar esto:
- Tim Berners-Lee, uno de los fundadores iniciales de la web, ha insistido un par de veces... [sigue ...]
» Leer más, comentarios, etc...
MadeInFlex
Presentation Model
Abril 22nd, 2009 - [Enlace local]
Este patrón se basa en la idea del patrón Model-View-Controller.
Un modelo de presentación es una abstracción de la vista, es decir, el model representa el comportamiento y estado de la vista. La vista representa una proyección o representación del modelo en la pantalla. Cuando hay un cambio en el presentation model, la vista se actualiza en la pantalla.
» Leer más, comentarios, etc...
Blog de Julio César Pérez Arques
Historia de una integración (iii): El desarrollo
Abril 22nd, 2009 - [Enlace local]
El entorno de desarrollo estaba implantado, la arquitectura estaba definida, el análisis estaba en marcha. Era el momento de iniciar el desarrollo, antes de que el tiempo (y el cliente) se echara encima.
Pero pronto quedó claro que los servicios web SAP iban a tardar más de lo previsto. De hecho, ni siquiera disponiamos de los ficheros WSDL que describen el interfaz, que empezaron a llegar por cuenta gotas un par de meses después. Por supuesto, más de uno tuvo que ser modificado y remodificado. Esta situación nos obligó a ser extremedamente ágiles, cambiando la prioridad de los módulos, reconstruyendo los clientes webservices y modificando el modelo de la aplicación a menudo.
Metodología
No hemos seguido ninguna metodología concreta al pie de la letra. Aunque sí es cierto que nuestra forma de trabajar está ampliamente inspirada en Scrum y las prácticas ágiles que promueve. Sobre Scrum podeis leer más aquí y aquí.Os dejo algunas notas de la estrategia que utilizamos:
- Desarrollo incremental con una versión mayor por módulo. Empezando por el módulo de Administración.
- Los requisitos fueron traducidos en nuestro JIRA a tareas de tipo New Request dentro de la versión correspondiente. Los cambios en los requisitos fueron añadidos como tareas de tipo Improvement. Desgraciadamente cuando la versión estaba cerrada no siempre se añadían como tareas hijas...
- Simulación de los servicios web SAP mediante Mocks de los clientes webservices. Como ya he dicho los servicios no estaban, pero nosotros necesitabamos ya disponer de datos que pintar en las pantallas! Así que simplemente implementamos los interfaces de los servicios con unas clases tontas que devolvian datos más tontos aún. Mocking manual pero efectivo.
- Testing de la capa Middleware. Toda la lógica de la aplicación está en nuestras clases service que son llamadas desde las pantallas mediante DWR. Los controladores web (Actions de Struts) practicamente sólo realizan navegación y precarga de campos de formularios. Focalizar el testing en la capa Middleware permitió independizarse totalmente de la capa Presentación y el servidor de aplicaciones, aumentando así la velocidad de desarrollo global.
- Testing de la capa Acceso a base de datos. Para probar los distintos daos de esta capa usamos un script sql para inicializar la bbdd a un estado conocido junto con los tests transaccionales de Spring que automaticamente hacen rollback evitando la modificación del estado y la fácil configuración entre datasources dependientes e independientes del servidor de aplicaciones. Una más del montón de cosas que te facilita Spring.
- Integración contínua. Básico en cualquier fase de test seria. Además de actuar como control de calidad de nuestro código. Pero de Hudson ya hablé en su día...
- Estructura del proyecto. Para atajar la dificultad en un proyecto es básico tener una estructura inteligente y ordenada del mismo. Nuestra estructura de código fuente estaba formada por un gran paquete por módulo, más un paquete comun. Luego dentro de cada módulo, los subpaquetes web, dao, ws, modelo y services.
- Tags, branches y merges. El cambio de prioridades entre módulos que sufrimos más el desarrollo incremental por módulos podrían habernos costado más de un disgusto serio sin una buena estrategia de control de versiones.
Dificultades
Hasta aquí parece que ha sido un paseo, pero en realidad hemos sufrido lo nuestro también. A parte del tema de la colaboración con el resto de equipos, tuvimos que hacer frente a varias dificultades en:- Integración mediante webservices. Se veía venir. Sinceramente e IMHO, los servicios web SAP están, como mucho, diseñados regularmente. Abundan los datos duplicados e innecesarios, no existen namespaces ni schemas comunes y aún nadie me ha podido explicar por qué existe un servicio web por cada operación! Además los WSDLs son generados por alguna herramienta SAP de forma automática que no cumple el WS-I. Lo que nos obligó a usar XMLBeans como OXM (Databinding Java-XML), aunque esto no tiene nada de malo, y también a tener que modificar a mano un par de WSDLs. Y luego está el tema de la infraestructura de red del cliente en producción y sus proxys, pero ésto también lo he contado ya.
- Pruebas de los servicios web. Descubrimos muchos bugs en los servicios web SAP. Yo diría que sus equipos de desarrollo los probaban poco. Las modificaciones, a veces, ocasionaban nuevos bugs donde antes funcionaban. Pronto quedó claro que no tenían una fase seria de test. Al final tuvimos que programar nosotros las baterias de tests para los servicios web SAP.
- Gestión de requisitos. Sabiamos que los requisitos iban a cambiar. Pero no tanto. El sistema de gestión de requisitos antes comentado no favorece el control de cambios en los requisitos, es demasiado frágil y requiere demasiado trabajo en mantener la descripción de la tarea inicial y las hijas, además de mezclarse aspectos de descripción de funcionalidad con pura implementación. En el futuro probaremos con una Wiki para los requisitos y el JIRA para las tareas exclusivamente con referencias al Wiki.
- Formación. Inicialmente, y para mi sorpresa, el nivel de dominio del equipo en Spring e Hibernate era más bajo de lo esperado. Esto nos dió problemas especialmente en mapeos avanzados de Hibernate que provocaban que (1) algunas operaciones fallaran y (2) se realizaran más consultas de las necesarias. También destacar la dificultad, al principio, de trabajar con multiples ficheros de configuración Spring debido al número de módulos y las necesarias configuraciones para mocks y testing.
Luego la cosa mejoro. Aunque a día de hoy Hibernate sigue sin convencer a más de uno pero con Spring todos han caido rendidos.
- Proceso de sincronización. Todas las noches debe actualizarse una estructura de 7 tablas con PKs y FKs compuestas con casi 100 mil registros obtenidos mediante cientos de llamadas a 2 servicios web. Es una operación compleja y costosa, con o sin Hibernate. Fue necesario rediseñar los servicios web SAP para operaciones de consultas masivas que minimizaran el número de llamadas y optimizar los mapeos Hibernate así como los algoritmos usados. Al final pasamos de más de 1 hora de ejecución (tiempo inaceptable) a apenas 10 minutos.
- Testing en la capa de presentación. En su momento no conseguimos hacer funcionar los tests funcionales web basados en Selenium en nuestro servidor de integración contínua, así que esta parte de test se hizo de forma manual. Como la aplicación era una aplicación web RIA bastante grande que tenía que funcionar en IE6, sumado a los cambios de requisitos y modificaciones en los servicios web, os podeis imaginar lo que hemos pasado...
Creo que no me dejo nada. Los temas de colaboración e implantación proximamente...
» Leer más, comentarios, etc...
Fetishcode...Thinking in objects
Oracle compra Sun
Abril 22nd, 2009 - [Enlace local]
A
» Leer más, comentarios, etc...
Arragonán
Jobsket en el podcast de debug_mode=on
Abril 22nd, 2009 - [Enlace local]
Han publicado ya en debug_mode=on, la entrevista que nos hicieron para su primer podcast a Jordi y a mi para hablar de Jobsket.
Para grabar la charla-entrevista, aprovechamos que yo tenía previsto un viaje a Barcelona y lo grabamos en las oficinas del SeedRocket, que es donde está trabajando actualmente el equipo de debug_mode=on. El estar todos en la misma sala, excepto Jorge Rubira, hizo que poco a poco fuera más distendida la grabación(creo que se nota que también había confianza :)).
Hablamos bastante de qué es Jobsket como proyecto, y mucho también de cuáles son nuestras herramientas de desarrollo: Java, Grails, Groovy, Lucene, Hudson, Eclipse… incluso un poco sobre microformats y, aunque fue muy por encima, hasta sobre Grails vs Ruby on Rails.
» Leer más, comentarios, etc...
Picando Código
Queen - Bohemian Rhapsody con computadoras y hardware antiguo
Abril 22nd, 2009 - [Enlace local]
Video impresionante que publicaron en Slashdot. De esos que te dejan “perlplejo”: alguien se dedicó a reproducir el tema “Bohemian Rhapsody” de Queen con una Atari 800XL (piano/órgano principal), Texas Instruments TI-99/4a como guitarra, un disco floppy de 8 pulgadas como bajo, disco duro de 3.5 pulgadas como gong y una HP ScanJet 3C para las voces. Está dedicado a fanáticos de Queen y Mike Myers y Dana Carvey de Wayne’s World.
En teoría, todos los sonidos son reproducidos con el hardware nombrado:
Excelente versión… [Aplausos]
» Leer más, comentarios, etc...
Picando Código
2 números de Linux+ gratuitos
Abril 21st, 2009 - [Enlace local]

Linux+ Abril
La revista Linux+ tiene una promoción este mes. Queda poco tiempo, así que a escanear:
¿Quieres recibir 2 números de archivo en versión pdf gratuitamente? ¡Nada más fácil!
Compra el número de abril de Linux+, envíanos el recibo escaneado a la dirección: es@lpmagazine.org e indica qué números de archivo te gustaría recibir. Puedes pedir los números que tratan los temas que te interesan especialmente, entra en: http://media.software.com.pl/linuxplus/es/portadas.pdf y elige entre todos los números de Linux+ publicados hasta ahora.
¡La oferta es válida hasta el día 30 de abril!
¡Aprovecha la oferta y recibe los números que te gustaría leer!
Equipo de LiNUX+
www.lpmagazine.org/es
» Leer más, comentarios, etc...
Arragonán
SQLite, booleanos y buenas prácticas
Abril 21st, 2009 - [Enlace local]
Hace unas semanas estuve implementando un sencillo sistema de votaciones con la ayuda del plugin acts_as_voteable, para un proyecto con Rails, donde me surgió un problemilla que gracias a los tests resultó menos doloroso.
Tras tener ya prácticamente escrita la acción para votar, implementé el test para el controlador con sus diferentes contextos(que sí, que TDD, pero uno todavía está en la fase de acostumbrarse :P). Cuando ejecuté el test por primera vez, esperando que me diera algunos fallos en mi código, me llevé la sopresa de un error SQL con origen en el plugin, que no existía la columna TRUE ¿¿en el where vote = TRUE??.
Lo primero fue pensar que no era posible, con ActiveRecord de por medio eso era un poco raro, por lo que las sospechas fueron para SQLite, que era el gestor de bases de datos en el entorno de tests. Probando a ejecutar los tests con una base de datos MySQL, fallaba mi código y no el del plugin, se confirmó la sospecha.
Una vez implementada completamente la funcionalidad y los tests pasando, tocó perder unos minutos para ver qué estaba pasando y google contesta rápido. Resulta que para utilizar booleanos en queries con SQLite debe utilizarse ‘true’ y ‘false’, al mirar el código del plugin se confirmaba el problema:
votes = Vote.find(:all, :conditions => [
"voteable_id = ? AND voteable_type = ? AND vote = TRUE",
id, self.type.name
])
El valor de vote estaba hardcoded, pues como tocaba cambiar el código, aproveché a cambiar self.type que está deprecated, por self.class:
votes = Vote.find(:all, :conditions => [
"voteable_id = ? AND voteable_type = ? AND vote = ?",
id, self.class.name, true
])
Y al ejecutar los tests con SQLite, los pasó. Pero luego resulta que había alguien que ya había solucionado el problema, como era de esperar en la comunidad Rails, en el plugin vote_fu (llegando a combinar funcionalidades complementarias de tres plugins distintos).
Después de crear la migración para eliminar la tabla de acts_as_voteable y crear la de vote_fu, ejecuté los tests del controlador para ver si tocaba cambiar algo, pero pasaban correctamente.
Conclusiones, además de lo aprendido con los booleanos de SQLite:
- Aprovechar (en la medida de lo posible) la independencia de bases de datos que aportan ActiveRecord u otros ORMs, sobre todo si estamos desarrollando componentes reutilizables.
- Y a procurar seguir mejorando en cuanto a la automatización de tests. Desde que empecé a escribir tests, hago commits con la conciencia más tranquila :).
» Leer más, comentarios, etc...
Blog del grupo SQUaC
AccUsa: support tool for accessibility and usability engineering
Abril 21st, 2009 - [Enlace local]
Various guides, documents and templates are available to perform usability and accessibility evaluations. However, for daily work we missed a structured integrated tool to manage and centralize the required information for these processes.
In order to solve that need, we have published in our "Descargas" (downloads) section a first version/prototype of AccUsa, which is a supporting and documentation tool for the processes of accessibility and usability engineering. Specifically, it supports the techniques accessibility evaluation and heuristic usability evaluation.
The aim of... [sigue ...]
» Leer más, comentarios, etc...
Yet Another Programming Weblog
Bitácoras de Programación: selección personal
Abril 20th, 2009 - [Enlace local]
Llego tarde a la discusión generada con la entrada en la bitácora de leonidas en barrapunto que rvr pasó a portada acerca de blogs y feeds en general relacionados con la programación. Salen por supuesto muchos de los agregadores y planetas que consumo, como reddit, hacker news (uhmm, éste no sale), dzone o planeta código. Pero después de leer todas las respuestas me ha entrado la "necesidad" de hacer mi propia selección personal basada únicamente en gustos. Son bloggers que creo que son un poco distintos y, en su mayor parte combinan el bloguerío con un alto nivel técnico que dejan ver el sus posts. Allá van:
- Mbpfernand0's Blog, el nuevo blog técnico de "nuestro" fernand0. El tema fundamental es la programación y la seguridad, aunque creo que no hace ningún asco a temas relacionados. Por cierto, que promete su propia selección de blogs sobre programación. Habrá que estar atento.
- El valle del Viento Helado de Drizzt, el Drizzt de barrapunto también. Sistemas operativos, compiladores, administración y seguridad. Muy interesante.
- .NET o no .NET, esa es la cuestión. Puedes no compartir sus preferencias tecnológicas, pero para mi es uno de los que mejor escribe y destila conocimiento y experiencia por todos los bits.
En inglés:
- intertwingly de Sam Ruby. La web y sus estándares. Para mí, imprescindible.
- jeffr_tech's Journal. Detalles internos del desarrollo de FreeBSD. No actualiza mucho pero merece la pena estar suscrito.
- daniel.haxx.se de Daniel Stenberg. Del autor de curl y Rockbox entre otros, el blog de un desarrollador prolífico.
- Coding Relic de Denton Gentry. Normalmente sobre Software embebido, pero toca otros palos.
- Ulrich Drepper. El blog del mantenedor de la glib. Poco prolífico, pero para no perderse ni una sola entrada.
- Nynaeve: Adventures in Windows debugging and reverse engineering. No se me ocurriría un mejor título nunca
- Y por fin el imprescindible Sutter’s Mill: Herb Sutter on software, hardware, and concurrency
Ahora no se me ocurre ninguno más, pero pueden ser las prisas...
Actualización: He publicado este texto más o menos en un comentario por aquello de completar la información en su sitio. También lo pongo aquí y lo replicaré en mi bitácora en barrapunto, que a su vez se copiará en planeta código, por aquello de que lo que se replica queda y de que hay URLs que desaparecen...
» Leer más, comentarios, etc...
Bitácora de Javier Gutiérrez Chamorro (Guti)
Parodia de Richard Stallman
Abril 20th, 2009 - [Enlace local]
No hace falta recurrir al sobadísimo "Developers, developers" de Steve Ballmer, y por eso en su momento rescaté el tremendo spot de Windows en plan Miami Vice.
Ahora le toca el turno a una parodia en plan "nave del misterio", protagonizada por un Richard Stallman combinado con Carlos Jesús.
¡Que os lo paséis bien!
» Leer más, comentarios, etc...
Cerebro en la Sombra » Técnico
Motivar y desmotivar en la gestión de personal
Abril 19th, 2009 - [Enlace local]
Estas vacaciones de Semana Santa que he pasado en Túnez (pronto contaré la experiencia como siempre
) me han servido para terminar de leer un libro (en realidad dos) que se me había atragantado un poco, El mito de la motivación, como escapar de un callejón sin salida, de Reinhard K. Sprenge. Lo empecé en diciembre pero hacia la mitad se me hizo un poco pesado, algo que después cambia y se hace mucho más llevadero pues el libro es realmente interesante y de recomendable lectura a cualquiera que tenga gente a su cargo.
Reinhard, a partir de su experiencia en multitud de empresas, diferencia claramente entre motivación y manipulación, desmitificando cualquier tipo de sistema de incentivos, léase por objetivos, pagas de beneficios, comisiones… Para él cualquiera de estos sistemas son la respuesta a la acción desmotivadora de algún directivo que no sabe cómo reconducir a su gente después de haber provocado, sin saberlo, la situación que viven.
En un momento del libro, Reinhard dice algo así,
Si nuestros colaboradores son gente adulta, con hipotecas, niños a los que criar y educar, parejas por las que luchar… ¿Por qué hemos de pensar que en su vida profesional alguien tiene que tratarlos como críos diciéndoles en cada momento lo que deben hacer y cortando su iniciativa?
Nuestros colaboradores son gente con conociemientos, preparación y experiencia y no quieren un trabajo de marionetas, quieren retos, afrontar problemas y tomar decisiones, pero si alguien se hace responsable permanentemente de las decisiones sin permitir que los demás tomen la inciativa y demuestren su valía nos plantamos en eso que se conoce como “desmotivación”. ¿Quién es el culpable entonces?
Intentar motivar es absurdo e imposible una vez se ha caído en la desmotivación. Por muchos intentos que se hagan por conseguirlo, normalmente a base de incentivos económicos, su éxito será sólamente efímero puesto que el dinero se valora y disfruta en un primer momento, cayendo en el olvido o en la costumbre en los siguientes.
La verdad es que en el libro no se cuenta nada que, desde la perspectiva de los que estamos por debajo, no hayamos visto siempre como “de cajón“, pero parece que hay mucha gente que nunca ha tenido este punto de vista y hay que mostrárselo.
Un libro que todos los directivos y managers deberían leer para entender muchas de las cosas que ocurren a su alrededor.
» Leer más, comentarios, etc...
Cerebro en la Sombra » Técnico
RETD, la primera red de conmutación de paquetes mundial fue española
Abril 18th, 2009 - [Enlace local]
Leyendo hoy un artículo de la serie de El Cedazo Historias de un viejo informático de Macluskey me entero de algo que es prácticamente desconocido para la mayoría de informáticos actuales. Resulta que allá por el año 1971 se inauguró en España la primera red de transmisión de datos mundial que utilizaba la conmutación de paquetes (igual que hoy en día hace Internet): RETD (Red Especial de Transmisión de Datos), que a la larga sería IBERPAC. En este otro enlace podéis encontrar la historia de de este hito de las telecomunicaciones en nuestro país, de lectura más que recomendable. No sería hasta 1978 cuando aparece otra red similar, la conocida Transpac francesa.
La historia es realmente emocionante.
Macluskey cuenta que por aquellos años (finales de los 60) se comenzaron a implantar los primeros sistemas online en la banca española, los más interesados en aquellos años en toda la informática y comunicaciones en general y que fueron los que comenzaron a utilizar las primeras redes para conectas las sucursales con las centrales. Banesto fue el primer banco en disponer de sistemas conectados entre todas sus oficinas.
Desde la Telefónica de aquellos años comenzaron a trabajar en un sistema que permitiese de un modo fiable, rápido y barato este tipo de conexiones y, sin saberlo, llegaron a la misma solución en que la gente del MIT estaba trabajando para lo que sería ARPANET, los inicios de Internet, pero como era un proyecto secreto del gobierno norteamericano no se sabía nada: la comutación de paquetes.
Vale la pena que os leáis la historia, a veces aquí también innovamos
.
Igualmente recomiendo la serie completa de artículos “Historia de un viejo informático“, os dará un punto de vista que no tenemos los que nos dedicamos a esto hoy en día además de conocer la prehistoria de nuestra profesión desde un punto de vista más práctico que teórico.
» Leer más, comentarios, etc...
Picando Código
FLISOL 2009 - Festival Latinoamericano de Instalación de Software Libre
Abril 18th, 2009 - [Enlace local]
Hoy falta una semana para la edición 2009 del FLISOL. El próximo 25 de abril más de 200 ciudades de Latinoamérica organizan simultáneamente un festival para instalar y difundir el software libre.

FLISOL 2009
El Festival Latinoamericano de Instalación de Software Libre (FLISoL) es el evento de difusión de Software Libre más grande en Latinoamérica. Se realiza desde el año 2005 y su principal objetivo es promover el uso del software libre, dando a conocer al público en general su filosofía, alcances, avances y desarrollo.
Para tal fin, las diversas comunidades locales de software libre (en cada país, en cada ciudad/localidad), organizan simultáneamente eventos en los que se instala, de manera gratuita y totalmente legal, software libre en las computadoras que llevan los asistentes. Además, en forma paralela, se ofrecen charlas, ponencias y talleres, sobre temáticas locales, nacionales y latinoamericanas en torno al Software Libre, en toda su gama de expresiones: artística, académica, empresarial y social.
En Uruguay se realizan instancias del FLISOL en las ciudades de Montevideo, Río Branco, Salto, Maldonado (donde el intendente resolvió declararlo de Interés Departamental), Carmelo, Tacuarembó, Paysandú y Florida.
Visiten el sitio de FLISOL para conocer conocer las charlas y el software libre que habrá disponible en su ciudad. Generalmente se distribuyen sistemas operativos libres (GNU/Linux, OpenSolaris, etc.), juegos de alta calidad, y software libre para Windows.
Todo parece indicar que este año voy a visitar la torre de las telecomunicaciones de Antel para asistir al FLISOL en Montevideo. El evento se transmitirá a todo el mundo a partir de las 12:00 desde el siguiente URL:
http://giss.tv:8000/flisol_mvd.ogg
Entre los temas interesantes que se van a dar en las conferencias se encuentran un par de Ceibal Jam y programación, una presentación (supongo) de Ceibal Chess, “BSD Sistemas Operativos Libres Alternativos”, una presentación de Python por parte de Marcelo Ramos, y más. Revisen el sitio del FLISOl para ver el detalle de las charlas en su ciudad.
Autor poster: Patricio Maciel (daleduro)
Licencia: CC BY-SA 3.0 Unported
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
Postmortem: estimaciones y creación del sprint backlog
Abril 18th, 2009 - [Enlace local]
Estamos cerrando el último proyecto, una aplicación de gestión de datos con múltiples perfiles que controlan el trabajo y la información introducida por los demás. Acaba de entrar en explotación con bastante éxito: ni un error en los cuatro primeros días de uso, fundamentales porque corresponden con una primera fase que tiene un plazo límite. A partir de ahora, mantenimiento correctivo y algo de evolutivo.
Es un buen momento para comenzar el postmortem y analizar los errores cometidos.
Hemos usado Scrum como metodología, y la conclusión es que nos ha aportado tan poco como cualquier otra metodología que hubiésemos usado, pero al menos no ha molestado. No creo que nos haya aportado un auténtico valor, pero creo que estamos en el buen camino. El gran reto que teníamos para el desarrollo del proyecto era el uso de una pila de desarrollo nueva para casi todos, y contra eso no hay metodología que valga.
El product backlog se hizo a partir de las reuniones de contacto con los usuarios y de los primeros documentos de prototipado y requisitos que nos pasaron. Hasta ahí, bien, no es un artefacto que tenga mayor complicación.
Para estimar el product backlog hicimos planning poker con el equipo, tras haber contado de qué iba el proyecto. A todas luces la estimación era muy optimista, y se cumplió aquello de que los técnicos son positivos y que los gestores son pesimistas. Sin que sirva de precedente, los gestores tenían razón. Sin embargo, creo que si el mismo equipo volviese a comenzar el proyecto sí cumpliría las estimaciones que salieron de esa reunión. La experiencia en la tecnología y una mejor gestión de los requisitos habrían hecho que se hubiese podido implementar en los tiempos dichos.
Creo que nuestro gran error desde el punto de vista de la metodología fue la creación del sprint backlog. Lo hizo una persona (yo, como Scrum Master). Gran equivocación. Lo debe hacer el equipo en conjunto. El equipo careció de una visión global del proyecto, lo cual no trajo más que problemas:
- Se adquirieron tareas en el orden incorrecto.
- No se sabía qué era común y qué no, así que era más difícil organizarse para la reutilización.
- "Marchas atras" por mala comprensión de las tareas.
- Funcionalmente se depende del criterio de una única persona.
- La estimación de las tareas habría sido más acertada con un mejor conocimiento del problema.
- ...
- No es una tarea trivial, y es poco tolerante a errores. No pasa nada si haces mal un campo en una pagina, pero un error en el modelo de entidades puede tener consecuencias bastante dramáticas. Hacerlo exige un conocimiento profundo de los requisitos.
- Una equivocación de una persona puede tener un desagradable efecto de malentendidos de los requisitos en cadena.
- No es fácil compartimentar inicialmente para que la gente pueda trabajar independientemente.
- El product backlog lo hará el Scrum Master como esta vez, antes de la primera reunión (tampoco tiene sentido movilizar a más personas para él).
- En el sprint meeting el sprint backlog se hará entre todos los miembros del equipo. En vez de llevar a la reunión el sprint backlog prefabricado, leerlo, y estimar a partir de esa lectura, se generará durante ella, y tras la creación de cada tarea se hará la estimación de la misma. Sí, nos llevará mucho más tiempo, pero no será perdido, sino invertido.
- En caso de tratarse de una aplicación de gestión, probablemente durante el propio sprint planning se hará un modelo de entidades (entidades del sistema y su relación entre ellas, sin necesidad de entrar a nivel de propiedad). Algo muy básico, pero que permita tener un punto de arranque común y afianzar los requisitos. Eso sí, me mantengo en la opinión de que con Hibernate ya debemos trabajar en términos de entidades y no de tablas.
» Leer más, comentarios, etc...
Blog de Julio César Pérez Arques
Tipos de programador
Abril 17th, 2009 - [Enlace local]
Me gusta simplificar las cosas. Es algo que no puedo evitar, cúanto más simple es algo, más perfecto me parece. Por eso el otro día cuando leía a Jeff Atwood exponiendo los 8 tipos de programador que según él existen, no pude evitar pensar ¡¿8 tipos para algo tan sencillo?! ¿¿8??
Me vino a la cabeza uno de mis antiguos posts donde hablaba de cómo valorar a los miembros de un equipo. Pero esto es diferente, son tipos de programador. Así que intenté borrar el post de Jeff de mi mente, sobretodo la parte de hacerse famoso... y llegué a la conclusión de que sólo existen 3 tipos de programador:
- El primer tipo sería el programador que es capaz de aprender por sí mismo.
- El segundo tipo sería el programador que es capaz de aprender con la ayuda de otros.
- El tercer tipo es aquel que no es capaz de aprender ni por sí mismo ni por los demás.
Es así de sencillo. Actualmente nuestro mundo vive una evolución imparable y un programador debe vivir en un estado de contínuo aprendizaje que le permita reinventarse a sí mismo en caso necesario.
Por aprendizaje no me refiero a memorizar por memorizar. Aprender implica descubrir y comprender nuevos conceptos para ser capaz de relacionarlos con conocimientos previos de forma coherente. El conocimiento se aumenta con conocimiento.
El primer tipo es un programador superior porque no depende de nadie. Es capaz de buscar, encontrar y aprovechar las fuentes de conocimiento que necesita por sí mismo. Su propio código es una de ellas porque tiene un potente espiritu crítico. Pero sobretodo tiene una vocación y un talento natural. Disfruta realmente programando, resolviendo problemas y experimentando.
El segundo tipo es un programador que tiene la inteligencia necesaria para convertirse en un excelente profesional. Todo dependerá de su actitud, porque aunque es capaz de diferenciar entre lo bien y lo mal hecho, debe esforzarse en aprovechar las oportunidades que se le presenten para aprender. Principalmente, gracias a sus compañeros, pero también un libro, un artículo en internet o el código fuente de un proyecto open-source que utiliza.
El tercer tipo es un programador cuyas acciones no tienen un porqué. No razona porque no aprende, sólo memoriza una parte. Va a lo fácil, a sobrevivir. Necesita constante soporte y supervisión. Hoy hace bien una cosa y mañana la misma la hace mal. Su código es fuente de la mayoría de bugs totales. Daña la moral del equipo. Y a la larga, resta más que suma.
En definitiva -insisto- el programador capaz de aprender por sí mismo es superior, el que es capaz de aprender con la ayuda de otros es brillante y el que no es capaz de aprender ni por sí mismo ni con ayuda de otros es inútil.