Sergio Gago

Un interesante artículo de restrospector que dice que los mejores gamers son los mejores desarrolladores. Que aunque muy discutible, a uno le da cierta confianza! (pasará también que los mejores desarrolladores son los mejores gamers?)

Hago una traducción libre:

Gamers	Developers
Tienen que aprender los comandos básicos de un montón de juegos	Tienen que ser capaces de aprender una burrada de herramientas y sintaxis diferentes para conseguir sus objetivos.
Normalmente empiezan observando detenidamente los puzzles y obstáculos todo lo cuidadosa y detenidamente posible (N del T: Depende el gamer y el juego )	Tienen que comprender y aprender los problemas y requisitosdados para ser capaces de resolverlos sin problemas
Aman la cacería para ser capaces de resolver el problema…. completar la misión… coordinar esa combinación perfecta con los compañeros de clan en una batalla masiva…	Mejorar para ser el guru que consigue lo imposible y sorprende a sus compañeros… para conseguir mayores victorias en armonía con su equipo.
Desean cualquier ventaja posible para ser, SIMPLEMENTE MEJORES QUE CUALQUIER OTRO.	No se quedarán atrás con lo que ya saben mientras los demás se actualizan con lo nuevo y mejor.

Mejoras en la traducción, díganlo!

Esta entrada tiene dos motivos, por un lado presentar enseñaros una presentación de Bob Martin, y por otro, presentar InfoQ, una web para desarrolladores repleta de buenas presentaciones, como ésta de Los principios del diseño ágil orientado a objetos. Hay una buena colección de presentaciones, algunas acompañadas con sus transparencias que van cambiando conforme avanza el tema. Peeeeero, en inglés.
Y la otra parte es la presentación vinculada: La gestión de la dependencia, mal utilizada, es frágil, inelástica, no reutilizable, y muy rígida. En esta presentación, Bob Martin nos presenta sus principios del desarrollo ágil, en una presentación bastante divertida para los que sepáis suficiente inglés. Como decía Bertrand Meyer: “Los módulos deben ser abiertos a la extensión pero cerrados a la modificación”, a lo que amplía Bob, la clave está en la abstracción.

Desde que conocí la metodología de programación extrema hace unos años, me di cuenta de que estaba hecha para la Web. Aunque inicialmente estuviera pensada para cualquier tipo de desarrollo (sobre todo Java), realmente encaja a la perfección con un proceso de desarrollo Web normal.

La XP es uno de los muchos procesos ágiles que hay ahora mismo disponibles, y que se basa fundamentalmente en olvidarse de que no podemos adelantarnos a los cambios de requisitos, y a que los clientes siempre serán aleatorios y caóticos. De modo que nos propone varias pautas a seguir a la hora de gestionar nuestro proyecto. Copio los epígrafes del artículo en la wikipedia, adaptándolos a un desarrollo web medio – grande.

• Desarrollo iterativo e incremental: El desarrollo en espiral evolucionado. No podemos presentar directamente la imágen a un cliente, o a unos usuarios. Aquí entra la labor de bocetado, prototipado, pruebas de usabilidad, etc. Poco a poco vamos aumentando fidelidad a los prototipos hasta que desarrollamos la lógica de negocio completamente (donde el cliente ya pinta poco). Y como decía hace unos días: Da igual que tu algoritmo sea el mejor y más eficiente… si es feo, al cliente no le va a gustar!
  Y respecto a incremental, el hecho de ir añadiendo módulos, o funcinoalidades hace que el desarrollo sea menos caótico, algo nada nuevo dentro del desarrollo Web.

• Pruebas unitarias continuas. Hoy en día con Firebug, esto es más fácil que nunca. A la hora de desarrollar la GUI, trabajar con los efectos JS y el CSS (sobre todo con librerías), cada vez que vamos al navegador y pulsamos F5 para comprobar los efectos del último hack incluido no estamos haciendo más que pruerbas unitarias. Esto inicialmente estaba pensado para JUnit, y para la preparación de los casos de prueba de las clases antes de la programación de las mismas. Esto también lo podemos hacer en la lógica de negocio de nuestras clases. De hecho una técnica para fidelizar al 100% los prototipos es desarrollar toda la lógica de presentación apuntando a clases de prueba, que en lugar de sacar los datos de una capa de acceso a datos, tiene un contenido dummy (arrays escritos a pelo en una clase PHP). De esta forma, la interfaz da la impresión de estar terminada, pero realmente no hay nada por debajo.

• Programación por parejas: Esta es la parte que más me gusta, y que aunque parezca mentira realmente funciona. Mientras uno codifica, el otro va diseñando y realizando pruebas, preparando la codificación y comprobando lo que va haciendo el otro. Cuando hay un error que se nos atasca no hay nada mejor que pedir a alguein que lo eche un vistazo, y la programación por parejas va un poco por ahi. En el mundo del desarrollo Web es común hacer esto en parejas de diseñador gráfico – maquetador, o programador – analista, pero la idea es que haya cuatro ojos mirando el mismo monitor.

• Frecuente interacción del equipo de programación con el cliente. De hecho, el método propone que haya un miembro de la empresa cliente en el equipo de desarrollo. Esto es bastante inviable en el 99% de los casos, pero lo que si se puede hacer es un constante trabajo de pruebas y mejoras continuas. De nuevo, volvemos al prototipado y las pruebas con el cliente. Desde diagramas de casos de uso que sean entendibles, hasta documentación (no técnica), pasando, claro, por reuniones de seguimiento y de pruebas, documentadas y en acta.

• Corrección de todos los errores. Lo ideal es que cada “entrega” o “hito” no dure más de una semana. Cuanto más cortos mucho mejor, pues se genera menos ruido o caos en el código general. Y una filosofía que pocos apliacan. No se añaden funcionalidades hasta que se han solventado todos los errores de las existentes. En Web esto es muy importante. No nos sirve de nada implementar un mashup de google maps en nuestra aplicación, si la página no se ve bien en firefox!

• Refactorización del código. Aunque depende mucho del sistema que usemos (Java con struts y JSP, PHP, Ruby on Rails….), es importante refactorizar el código para aumentar la escalabilidad y el mantenimiento. En prácticamente todos los desarrollos informáticos acabas utilizando más librerías o implementando más funciones de las que necesitas. Muchas veces haces código duplicado, y otras podrías haber usado algún patrón de diseño para mejorar el código y hacerlo más claro. Lo idea es que cada iteración de la aplicación sufra una refactorización total, por supuesto sin modificar las funcionalidades. ¿Qué implica esto en el D. Web? Separar los CSS por tipo de presentación y módulo, juntar los JS de funciones similares, o separar los que no tengan nada que ver, buscar herencias y polimorfismos en el código e implementarlos, etc… Aquí la diferencia se nos dará en clarificación de código, y tiempo de carga (pasar de cargar código javascript de 80kb a cargar 30kb).

• Propiedad del código compartida: Todo el código es de todos y cualqueira puede modificar cualquier parte. Aquí estoy de acuerdo sólo si usas un buen control de versiones. Pero en los desarrollos Web es más común que un pequeño cambio afecte a toda la aplicación, de forma que se hace necesario que todos los desarrolladores conozcan todo el código y estén capacitados para modificarlo.

• Simplicidad en el código. Esto está claro, pero ampliarlo a simplicidad en la interfaz, en el diseño (no solo gráfico, sino de la aplicación), y por supuesto, cumplir con estándares y validaciones.

En general es útil cuando los equipos no son muy grandes (no más de 8 personas), y cuando son ágiles. La consultora tradicional tendrá muchos problemas para adaptarse. Sin embargo el equipo de jóvenes desarrolladores de una start-up, lo tendrán como el modelo ideal. Ergo concluyo: La programación extrema puede ser el mejor paradigma de programación para la creación de start-ups.

Más info en la web de difusión del extreme programming.

He leido en Sentido Web esta entrada que habla de PHP Maker , una herramienta que no conocía, y que me de haberlo hecho me habría ahorrado unas cuantas horas de trabajo.

A la hora de desarrollar aplicaciones web, en la parte de acceso a datos suelo implementar dos modelos diferentes, uno basado en consultas, y otro basado en “maestros”. Aunque no es nada nuevo, trataré de explicarlo un poco.

• Servicio de consultas:
  Sería una parte de la capa de acceso a datos que gestiona todas las consultas necesarias para ofrecer información a la lógica de negocio. Búsquedas concretas, ordenaciones, extracción de información de tablas diferentes en función de variables determinadas, etc… Id est: “Quiero ver los últimos 10 posts del usuario X en la categoría K”. Esa consulta implica varias tablas, y parámetros que nos ha pedido el usuario de antemano.
• Servicio de maestros:
  En ocasiones es necesario obtener toda la tupla de información de un registro, para cualquiera de las modificaciones básicas (CRUD – Create, Retrieve, Update, Delete, es decir: Crear, Obtener, Actualizar, Modificar registros). En esas ocasiones con un identificador nos puede valer para obtener toda esa tupla.
  Pues bien, este servicio hace unas labores tan concretas y tan optimizables, que tiene sentido separarlas en un servicio aparte, y que sea la lógica de negocio y el acceso a datos el que decida qué usar en cada momento.

Entonces, este PHP Maker, nos sirve para generar automaticamente scripts de acceso a datos a partir de una base de datos, y por lo tanto nos ahorra mucho trabajo.
Para ser sinceros, no lo he probado en mis propias carnes, pero tiene muy buena pinta. Y en la misma página ofrecen XMLMaker, o ASPMaker, que prometen soluciones del estilo. Merece la pena probarlo!

A la hora de desarrollar una Web, es cierto que usar frameworks es una ayuda muy interesante. Anieto, ya escribió hace unos meses sobre los más usados.
Quizá el problema puede estar en que unos te dan unas facilidades que no te dan otros, y por supuesto, mezclarlos es una muy mala idea. Además, la actual, si se puede llamar “guerra de frameworks”, provoca que cada vez tengan más funcionalidades, y por lo tanto más peso. De forma que si lo quieres solo para una cosa concreta, o te buscas un snippet de código concreto, o rebajas manualmente la librería.

En coder battery, dan una lista de razones muy adecuada sobre porqué usar frameworks, que intentaré resumir.

• Te permite programar más rápidamente.
• Te ahorra trabajo
• Da consistencia a tu código.
• Te ayuda a escribir mejor código y más ordenado.
• Te permite usar lo último en herramientas técnicas
• Te da soporte gratuito
• Te permite tener un ejército de programadores para ti.
• Te permite separar presentación de negocio.
• Puedes tener la documentación lista.
• Es más multiplataforma
• Mejor acceso a la capa de datos del que podrías hacer tu.
• Mejora la seguridad de tu aplicación

Bien, estas afirmaciones, lo cierto es que tienen muchas caras. Empezando porque hay que sopesar el tiempo de aprendizaje que requiere una librería, o la elección de la más apropiada (usaré prototype o jQuery?), por no hablar de efectos espectaculares que nos dejan asombrados, pero que requieren cantidades inmensas de código.

Aumenta el peso de nuestra aplicación, y, cuidado, como tengamos errores o incompatibilidades con el resto de nuestro código, prepárense para analizar el código línea a línea a ver dónde carajo está el fallo (gracias! firebug!).

Y depende que frameworks, tendrás mejor o peor soporte, las herramientas serán mejores o peores, o tienen una documentación maso menos útil.

“In the other hand” , tenemos este artículo en inglés de Andy Smith: Why frameworks suck, muy interesante de leer, aunque un poco denso.

Me quedo con una frase:

If building an application with libraries is playing football with your buddies, building an application on a large framework is playing football in the NFL. You may get money, attention and busty cheerleaders, but what was a game about throwing a ball and doing your damndest to make your best friend eat mud becomes a game about offsides, holding and television breaks; it’s just not fun anymore.

Si desarrollar una aplicación con librerías es como jugar al futbol (americano) con tus colegas, desarrollar una aplicaión con un gran framework es como jugar en la NFL (liga de futbol americano). Puedes conseguir dinero, atención y animadoras “pechugonas”, pero lo que fué un juego de tirar una pelota y hacer todo lo posible para que tu mejor amigo caiga sobre el barro, se ha convertido en algo lateral, de participación y televisión; ya no es divertido… (traducción libre y muy mejorable).
Y la conclusión, al final de su artículo:

Frameworks suck because they are an avatar of enterprise, frameworks suck because they take away your freedom, frameworks suck because they build walls between coders, frameworks suck because they make you fit your project to the toolset rather than the toolset to the project, and frameworks suck because they take the fun out of programming, long live the library.

Los frameworks apestan porque son la representación empresarial, porque te quitan libertad, porque levantan muros entre programadores, porque hacen que tengas que cambiar tu proyecto a la herramienta en lugar de la herramienta al proyecto, y porque le quitan la diversión a la programación, larga vida a las librerías!.

Sin duda, la clave está en el término medio. Ni son la panacea para cualquier proyecto, ni debemos dejarlos de lado. En parte estoy de acuerdo en que en ocasiones adaptamos nuestro proyecto a una herramienta, cuando debería ser al revés, de modo que ahi entra la inteligencia y experiencia del analista, que sopesa los riesgos y las ventajas de usar un framework y los acepta y asume.

Vosotros, ¿que framework utilizáis? ¿Qué dificultades os habéis encontrado a la hora de implementar alguno?

Iba a escribir un artículo pidiendo disculpas por tener esto tan “abandonado”, pero he pensado que podía matar dos pájaros de un tiro, y publicar de paso uno de los artículos que tenía pendientes en la parrilla de borradores.

Tampoco hay mucho comentar, simplemente un enlace que desde que lo vi, se ha convertido en una gran fuente de información. Localhost80.
No recuerdo desde donde conseguí el enlace, pero recomiendo una navegación ardua por el sitio, es muy interesante. Desde PHP hasta SEO, pasando por usabilidad, manejo de errores 404, Ajax, startups, etc…
Pues eso:
http://localhost80.com/

API o Application Programming Interface no deja de ser, ni más ni menos, que una herramienta que nos ayuda a programar.

No me gusta linkar a otros artículos sin añadir algo de mi cosecha, completarlo o comentarlo, pero en este caso haré una excencpción ya que no se puede decir nada nuevo…

Desde aNieto2K: Las APIs que te harán rico

• Google Maps API [URL]
• Geonames.org [URL]
• OpenID [URL]
• MediaWiki API [URL]
• YouTube API [URL]
• Technorati API [URL]
• LastFM [URL]
• Del.icio.us [URL]
• FeedBurner [URL]
• Flickr [URL]
• Amazon E-Commerce Service [URL]

En el siguiente artículo de las herramientas de trabajo necesarias / útiles en el desarrollo Web, entraremos en la ingeniería del software y el lenguaje de modelado.

¿Qué es esto?

El UML o Lenguaje de Modelado Unificado, no es más que un convenido de diagramas y símbolos utilizados (supuestamente) por la comunidad de analistas y desarrolladores informáticos, con el fin de utilizar un lenguaje común en el desarrolo de software de cualquier índole. Está preparado para el desarrollo orientado a objetos, y así, sus diagramas más importantes son:

• Diagrama de clases
• Diagrama de componentes
• Diagrama de objetos
• Diagrama de despliegue
• Diagrama de casos de uso
• Diagrama de estados
• Diagrama de secuencia

Aunque ya anda ciruclando la especificación 2.0, que introduce nuevos diagramas y mejores (o complejidades) no es usada de forma general, y de hecho, aún existe discusión sobre si es adecuada para el proceso de diseño.El caso es que a la hora de iniciar la fase de diseño de un software determinado, es imprescindible tener un diagrama de clases muy bien pensado, después de haber compartido con el cliente un diagrama de casos de uso, de forma que las dos partes estén de acuerdo en qué es lo que se va a hacer.

Existen multitud de herramientas en el mercado, la mayoría bastante caras, como Rational Rose, mi preferida es el Poseidon for UML de gentleware.

Basado en Java, y recientemente preparado para UML2, permite hacer todos los tipos de diagramas de la especificación, así como crear la documentación y después, generar código, lo cual resulta un ahorro muy significante de tiempo (no tener que escribir todos los ficheros y las declaraciones de atributos y métodos…)

Hace relativamente poco han abierto una versión gratuita para proyectos de código libre, lo cual hace que ahora sea más usado, aunque si queremos más, podemos optar por la versión PRO, que integra una gran cantidad de posibilidades.

Gentleware además, provee del Apollo, para los desarrolladores de eclipse que quieren que sus modelos estén siempre actualizados, y si no usas Eclipse, siempre puedes usar la función de ingeniería inversa, que en general, funciona bastante bien, y nos da los diagramas desde el código.

Algunas imágenes:

(Más capturas)

Y la respuesta a un amigo que me pregunta… ¿Porque no usar visio, o las autoformas del Word?

Sencillamente, si yo creo una clase en el diagrama de clases, y le pongo los atributos y los métodos, cuando diseño el diagrama de iteración, ya me da el solito los métodos y los atributos que va a necesitar, y si todo lo he hecho correctamente, me generará un código fuente muy limpio y preparado para ser rellenado. Eso, las autoformas del Word… no lo hacen…

Otros sobre herramientas de trabajo…
Diseño de BD – DB Designer
Diagrama de Gantt – Gantt Project

El año pasado hice una pequeña presentación de unos 20 minutos sobre qué es Ajax, destinada a gente con cierto conocimiento técnico en programación orientada a internet y hoy, haciendo limpieza la he recuperado.

Dado que a mi me gusta que mis presentaciones sean simplemente hilos conductores y no el propio contenido, verla por si misma es poco informativa o, como mucho una curiosidad, amén de estar ya un poco obsoleta en algunas partes y de mezclar muchas cosas que realmente solo tocaba de pasada en la presentación.

En fin, por si a alguien le interesa la tenéis a continuación en pdf

Presentacion ajax