Dando la chapa

Supongo que debido a la magia de los trackbacks Enrique Place (PHP Senior) se pasó por aquí a comentar mi post sobre su post sobre frameworks propios. Volvemos a estar en desacuerdo :)

No tiene sentido seguir re-inventando la rueda, para aprender ya tienes el propio framework [externo] y los proyectos que puedes construir arriba de ellos, sin tener que seguir lidiando con programación artesanal y errores típicos de la falta de experiencia.

Si quieres aprender, nadie te impide que te hagas un framework, pero si quieres ser profesional y te dedicas a proyectos comerciales concretos, no será muy buena decisión optar por un framework no probado.

De todas los razonamientos que me vienen a la cabeza para rebatir empiezo por el que me parece más contundente:

Dime qué framework usas y dime qué hubiera pasado si su creador hubiera leído tu post y seguido tu consejo a rajatabla.

RoR, Django, Spring, Struts, CakePHP, CodeIgniter… todos esos frameworks no llevan ahí por los siglos de los siglos. En algún momento alguien miró lo que tenía disponible, no encontró lo que buscaba y dió el paso.

En lo que sí estoy de acuerdo es en que los frameworks abiertos son mucho más potentes que los cerrados. Muchos frikis ven más que uno (o dos o los que haya en una empresa).

A título personal te comento, si has tenido que hacer 3 frameworks, es que ninguno han sido lo suficientemente “frameworks” (herramientas genéricas) como para seguir construyendo y mejorando a continuación de cada proyecto.

Voy a comentar aquí mis 3 frameworks no para tirar de currículum sino porque creo que son buenos ejemplos.

** PRISA, año 2004. Para los que no lo sepan, PRISA basa toda su arquitectura PHP en un framework propio basado en PEAR. Como les había dado buen resultado querían algo parecido para hacer aplicaciones Flash. A ello que nos pusimos. Miramos las poquísimas opciones disponibles en aquella época y vimos que no había nada que se adaptara lo suficiente a los requisitos (bastante peculiares, por cierto). Estuvimos 2 semanas haciendo pequeñas pruebas y esquemas sin tirar prácticamente una línea de codigo. Si tuviera que hacerlo hoy le daría una oportunidad a GAIA.

Por desgracia no puedo asegurar que lo sigan utilizando ya que yo me fui a los 6 meses cuando terminé el proyecto.

** CTAD, año 2006. Los requisitos era un framework libre y que fuera compatible con player 6 ya que tenía que funcionar para aplicaciones de escritorio y dispositivos móviles. No había (ni hay) ninguno disponible. A día de hoy hay cerca de 30 aplicaciones utilizándolo. Como digo algunas son aplicaciones de escritorio, otras aplicaciones para móviles, otras sencillas actividades educativas. Todas tiran del mismo framework. A mi me gustaría liberarlo porque creo que vale la pena, otra cosa es lo que piensa mi jefe sobre “que la competencia se aproveche”.

** ZCode, año 2008. Harto de hacer frameworks para los demás, hago el mio y lo libero. Al próximo sitio que vaya ya no empiezo desde 0.

En los 3 casos creo que las decisiones han sido correctas. Hemos mirado lo que había en el mercado y no hemos encontrado nada que se ajustara lo suficiente. Algo que por ejemplo no he hecho con PHP ya que no que tengo el nivel necesario. En PHP uso CodeIgniter.

Así que yo sigo en las mías, hay sitio para los frameworks propios y framework propio no significa “casero” o “poco profesional”. Vamos, ni mucho menos.

Salud!

Vaya, vaya. Leo en PHP Senior:

Si por cualquier razón la respuesta es “tenemos un framework propio”, mal pinta la cosa. De hecho, hasta me atrevería a ser radical y decir que es hora de huir de ahí como del demonio. A 2008, el mundo del software no necesita otro framework casero realizado por mentes privilegiadas

Vamos a ver si yo le encuentro sentido a picar un framework propio a ese 1% de situaciones :)

Utilizar un framework desarrollado por otros es bastante útil, completamente cierto. Por varias razones: seguramente lo haya hecho gente más lista que tú, lo han revisado muchas más personas y lo han usado en muchas más situaciones por lo que es mucho menos probable que haya bugs…

Pero ¿qué pasaría si todo el mundo pensara así? ¿qué pasaría si nadie se tirara a la arena? ¿que pasaría si nadie pensara que las cosas se pueden hacer mejor? Pues que no tendríamos Rails, no tendríamos CodeIgniter, etc, etc, etc…

Yo en mi caso no he picado un framework propio sino 3 :) En la mayoría de casos por requerimientos de los proyectos. Por ejemplo, el que tenemos en mi curro actual tenía que ser compatible hasta con player 6 y cuando miré los frameworks disponibles no encontré ninguno que se adaptara.

Dicho esto, desde que he descubierto CodeIgniter he desechado mi triste wanna-be framework en PHP. ¿Por qué? Pues porque como PHP no es mi fuerte, estaba claro que mejor ser usuario y no creador. Mejor beneficiarme del curro de gente que sabe mucho más que yo de PHP.

En lugar de deshechar tan rápidamente los frameworks propios hay que pensar un poco más, hay ocasiones en las que yo creo que es la mejor solución. Lo que nos lleva a la gran pregunta:

¿Cuándo picar y cuándo usar el código de los demás?

Sólo la experiencia te lo puede decir. ¿Y cómo pillar la experiencia? Picando un framework propio :) No lo digo en broma, yo creo que es un MUY buen ejercicio. No se tarda tanto en darse cuenta de que si lo que has picado es bueno o no.

Si lo puedes reutilizar fácilmente, si se pueden añadir nuevas funcionalidades sin tener que tocar muchas clases, si se puede utilizar para proyectos muy variados…. entonces lo has hecho bien. Si es todo lo contrario, échale un ojo a los frameworks que tengas a tu alrededor.

Así, a las malas, picar un framework propio es bueno aunque sea para saber que no lo tienes que hacer más. Es el clásico “no soy tan malo, por lo menos sirvo ejemplo de lo que no hay que hacer”.

+1 por reinventar la rueda con sentido.

Salud!

Yo más de una vez he sido criticadillo al pedir NO trabajar en 3-4 proyectos al mismo tiempo. Alguno ha sugerido que yo era poco menos que un niño protestón por decir algo como:

En lugar de darme 4 proyectos de 1 semana para 1 mes, dame 1 sólo proyecto por semana.

No eran exactamente 4 proyectos de una semana, pero es la idea. Pues no, aquí tienes los 4 a la vez, de los 4 tienes que atender mails, reuniones, testing, bugs,… yo eso no es que lo lleve bien o mal, es que simplemente mi rendimiento baja.

Bueno, recabemos otras opiniones: The Multi-Tasking Myth:

The study, carried out at the Institute of Psychiatry, found excessive use of technology reduced workers’ intelligence. Those distracted by incoming email and phone calls saw a 10-point fall in their IQ – more than twice that found in studies of the impact of smoking marijuana, said researchers.

Interesante también Holding a program in one’s head:

The danger of a distraction depends not on how long it is, but on how much it scrambles your brain. A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds.

Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don’t even start working on something hard.

Since there’s a fixed cost each time you start working on a program, it’s more efficient to work in a few long sessions than many short ones.

One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts. This works well for more parallelizable tasks, like fighting wars. For most of history a well-drilled army of professional soldiers could be counted on to beat an army of individual warriors, no matter how valorous. But having ideas is not very parallelizable. And that’s what programs are: ideas.

Personalmente no puedo estar más de acuerdo. Lo que a mi me gustaría es:

- Dame los requerimientos o los definimos juntos. Ponemos un plazo, ponle 2 semanas.
- No me hables de otra cosa en esas 2 semanas.
- 2 semanas después: aquí está el curro. Vamos a por la siguiente.

Pero eso nunca funciona así, claro. Por el medio siempre hay que arreglar un pequeño bug de otra aplicación, una reunión para un proyecto futuro, bla, bla, bla, distracciones. Y eso que yo curro sin messenger (la mayoría del tiempo) y sin el correo abierto.

Yo soy un asiduo usuario de “Recordar contraseña”. No es que me olvide mucho de las mías, lo que pasa es que las de los sitios que visito poco nunca me las aprendo.

La última que he “olvidado” es la del Backnetwork de Flash on the Beach. Pues nada, le doy fuerte a recordar contraseña y en un instante tengo un mail. Lo malo de ese mail es que me manda mi contraseña tal y como yo la puse, en texto plano. Malo, malo. ¿Por qué? Pues porque para que me la manden tal y como la puse seguramente la han tenido que almacenar sin encriptar*. Eso quiere decir que cualquier empleado con acceso a la base de datos de Backnetwork puede conocer mi contraseña.

En este caso me da igual porque nunca compartiría una contraseña importante, pero seguro que hay mucha gente que repite la misma en varios sitios.

Lo cierto es que almacenar la contraseña encriptada es algo fundamental pero complica el proceso de recuperación. Normalmente implica una de 2:

- El sistema elije aleatoriamente una nueva y te la manda.
- Se genera un link con un identificador tambien aleatorio a un formulario especial en el que puedes volver a elegir una nueva.

Desde luego la primera opción es más sencilla si algún día la tienes que programar. Lo que no puedes hacer en ningún caso es almacenar las contraseñas de tus usuarios en texto plano para TU comodidad como programador. Ni siquiera mandes las contraseñas de tus usuarios sin encriptar entre el cliente y el servidor, Joan Garnet puso un ejemplo bien clarito de cómo hacerlo.

Resumiendo:

Desconfia de los sitios que te mandan tu contraseña tal cual la escribiste

Y al hilo de contraseñas, 2 posts de Coding Horror: Rainbow Hash Cracking y You’re Probably Storing Passwords Incorrectly. El último sobre el flaco favor que Facebook hace a sus usuarios pidiéndoles sus datos (incluídas contraseñas) de
cuentas de Hotmal, GMail, etc. para facilitar así que encuentren a sus contactos. Me ha encantado esta imagen:

¡Salud!

* También han podido encriptarla con un sistema reversible, pero eso igualmente quiere decir que la clave y el método de encriptación están por algún lado en el código.

Voy a explicar un poco de qué va a ir mi conferencia en SubFlash.

La idea básica es que la mayoría de aplicaciones que hacemos realizan una serie de tareas comunes. A saber:

- Leer un xml de configuración
- Escuchar los eventos de Stage para ajustarse al tamaño disponible
- Leer variables que vengan por FlashVars
- etc.

Empezar las aplicaciones desde cero es un poco una pérdida de tiempo porque estamos solucionando problemas que ya hemos afrontado en el pasado. Hacer que todas nuestras películas Flash compartan un código común tiene las siguientes ventajas:

- Picar el código común una sóla vez. Don’t Repeat Yourself (DRY)
- Las aplicaciones son más sencillas de mantener. Cuando un error se arregla en la parte común automáticamente se arregla en todas las aplicaciones que lo usan.
- De la misma forma, agregar una mejora a todas las aplicaciones es muy sencillo ya que al agregarla a la parte común todas las películas lo heredan.
- Las aplicaciones son más sencillas de entender (y mantener) una vez que conocemos el código común. Además se comportan de una forma predecible.

¿Y muchos de estos problemas no se solucionarían utilizando un framework ya existente? Sí, pero aunque programar nuestro propio framework sea un poco reinventar la rueda, tiene ciertas ventajas como que se ajusta perfectamente a nuestras necesidades (no hace ni más ni menos de lo que queremos) o como que arreglar bugs o añadir funcionalidades es mucho más sencillo al ser nosotros los creadores del código.

Utilizar un framework de desarrollo es algo muy básico pero no suele ser la norma en el mundillo Flash. Desde luego hay gente utilizando frameworks (ARP, GAIA, etc.), pero yo diría que son la excepción.

En la conferencia empezaremos desde cero el desarrollo de un framework propio. La idea es ir escribiendo código, compilando e ir respondiendo las preguntas según vaya surgiendo. La ponencia será *muy* práctica. Vamos, que no llevo PowerPoint :D Y por el camino veremos MTASC, SWFMill, y las ventajas *prácticas* de algunos de los patrones de diseño. En fin, picar menos y mejor.

¡Espero que os guste!

Hace un tiempo que llevo pensando que las entrevistas de trabajo no son nada equitativas. Por normal general la empresa pregunta mucho más que el entrevistado. No digo que no sea justo que la empresa pregunte, digo que nosotros no solemos preguntar suficiente.

Así que hace un tiempo me escribí una lista de cosas que iba yo a preguntar en mi turno de la entrevista. Lo que pasa es que hace un par de días seguí un enlace al blog de mr Joel Spolsky en el que recopilaba una lista de 12 puntos sobre buen código. Y yo he pensado que se le puede aplicar a empresas: The Joel Test: 12 Steps to Better Code. Ojo que el post es del año 2.000 y es perfectamente válido a día de hoy:

1 – Control de versiones (CVS, SVN o lo que sea).

Esta es crítica. Si una empresa no usa control de versiones, malo, malo. Para mi no hay desarrollo de software mínimamente serio sin poder volver a una versión anterior, saber qué cambió de una versión a otra, saber quién hizo los cambios, etc.

2 – Tener listo el producto en un paso.

Esta es importante pero no tan crítica. Es decir, lleva razón en que tener una versión funcional de tu producto (cd, web, lo que sea) tiene que ser sencillo y en el menor número de pasos posibles. Evitar hacer cosas a mano y poco documentadas como cambiar rutas de desarrollo a producción y cosas por el estilo.

3- Daily builds

No creo que sea muy importante, especialmente para el desarrollo de aplicaciones Flash, pero la idea me gusta.

4 – Gestor de bugs

Ya sea GForge, Mantis, JIRA o uno propio. Es fundamental tener todos los bugs de una aplicación en el mismo sitio y no esparramados por vaya usted a saber cuántos mails. Además es importante relacionar una nueva versión en el repositorio con un bug corregido.

5 – Corregir viejos problemas ANTES de escribir nuevas funcionalidades

Realmente buen apunte, pero creo que pocas o muy pocas de las empresas en las que he trabajado hacen esto. Y la verdad es que es muy buena idea.

6 – Tener plazos actualizados

Y reales, añadiría yo. Es importante tener unos plazos y cumplirlos. Claro que para eso los plazos deben ser realistas.

7 – Tener una especificación

Y actualizarla al finalizar el proyecto, añado. Hace poco leía no sé dónde que el desarrollo de software era tan sencillo como caminar sobre el agua, fácil si tienes una base congelada. Aunque los de eXtreme Programming tienen otro punto de vista. Tanto si tienes un documento monolítico como si vas haciendo programación ágil, durante el desarrollo de un proyecto, siempre hay pequeñas modificaciones que DEBEN reflejarse en la especificación. Y nunca hay tiempo para hacerlo sobre la marcha, así que un día extra de documentación y desintoxicación* debería ser obligatorio.

8 – Un espacio tranquilo para los programadores

Fundamental. Hay millones de artículos sobre el tiempo que tarda una persona de media en empezar a producir de verdad cuando se pone con una tarea: aproximadamente 15 minutos. Así que si te interrumpen cada poco, echa cuentas.

9 – Buen equipamiento

Igual de fundamental. Si tu IDE favorito tarda 50 segundos en abrir, si compilar un proyecto es darle al botón e irte a por un café, si renderizar una escena es hacer click y mejor vete a comer, mal vamos. Últimamente me he hecho super fan de tener 2 monitores, aunque es algo que un bonito monitor de 24 pulgadas también puede solucionar :)

10 – Equipo de testing

Hay veces que los quieres matar, pero cuanto más errores encuentran los de testing, menos errores encuentran tus usuarios. Pero hay veces que los quieres matar, claro.

11 – ¿Hacen los candidatos una prueba de código durante la entrevista?

En principio no ha lugar, aunque sería interesante saber qué proceso de selección han pasado tus posibles futuros compañeros.

12 – Tests de usabilidad de pasillo

Es decir, pillar al primero que pillas y que no tiene nada que ver con el producto y hacer con el/ella una pequeña prueba de usabilidad. Supongo que las empresas profesionales de usabilidad tendrán algo que decir sobre si es válido o no, pero seguro que están de acuerdo en que mejor eso que nada. Me gusta.

Y como extra bonus yo agrego:

13 – ¿Tienes una librería de clases propia?
14 – ¿Tus proyectos de hace un año compilan sin problemas?
15 – ¿Inviertes en formación?

En fin, una chuleta compartida para la próxima vez que vaya a buscar curro.

* ¿No os pasa que al terminar un proyecto grande (digamos un par de meses) necesitáis un tiempo para meteros de lleno en otro? Ésa es la intoxicación con un proyecto. Algunos lo llaman estar hasta los cojones, pero bueno. El caso, aprovechar el tiempo de desintoxicación para actualizar la documentación me parece una buena idea. Para ti y para el proyecto.

Es algo que ya comentaba en lo que yo sé de al hilo de los eventos. Mucha gente que utiliza EventDispatcher lo hace de esta forma:

var event:Object = {type:"Wadus",value:5};
dispatchEvent(event);

Funcionar, funciona, claro. El problema es que la función que recibe el evento no sabe cuáles ni de qué tipo son los parámetros del objeto recibido. A mi me parece mucho mejor tener una clase para el evento y lanzar eventos de tipo conocido:

class WadusEvent{
public static var TYPE_LIT:String = "Wadus"
public var value:Number = 5;
public var type:String = ""
public function WadusEvent(_value:Number){
type = TYPE_LIT;
value = _value;
}
}

Y a la hora de lanzarlo:

var event:WadusEvent = new WadusEvent(5);
dispatchEvent(event);

De esa forma la función receptora sabe perfectamente las propiedades del objeto. Además tenemos validación de tipos a la hora de compilar.

Bueno, pues esto mismo piénsatelo SIEMPRE que te veas usando un objeto anónimo. Imagina que tu aplicación va de gestión de usuarios y que además lees la información de un xml. Normalmente tendrás que parsear el xml y crear un objeto por cada nodo. En lugar de hacer esto:

var worker:Object = {age:30,name:"Pepe"};

Te creas una clase:

class Worker{
public var age:Number = 0;
public var name:String = "";
public function Worker(_age:Number,_name:String){
age = _age;
name = _name;
}
}

Y luego creas instancias:

var worker:Worker = new Worker(30,"Pepe");

Al principio parece más trabajo, pero a la larga yo creo que trae muchos beneficios.

Y ya que pongo un poco de código, ¿alguien recomienda un plugin de WP para meter código? Más que nada porque lo que tengo ahora no respeta los espacios y apesta bastante.

Gracias!

Complexity happens. Simplicity, you have to strive for.

AMÉN

Simple is beautiful

Para escribir mi peyote sobre AS2 le he echado un ojo a un libro que tenía por aquí sobre AS2 y OOP. Y es alucinante la de veces que me he visto diciendo:

Aaaaaaaaanda, pues claro

Es decir, la de cosas que se supone que debería de saber (porque me he leí un libro), pero que realmente no aprendí. Las leería, las comprendería más o menos y las olvidaría a los 10 segundos de cerrar el libro. Errores que no tendría que haber cometido y que he cometido, a pesar de estar sobre aviso.

¡OJO! No estoy diciendo que leer libros sea un ejercicio inútil, estoy diciendo que releerlos cuando ya tienes cierta experiencia en el tema es MUY interesante.

Code Smell

• Large method – a method, function, or procedure that has grown too large.
• Large class – a class that has grown too large, see God object.
• Feature envy – a class that uses methods of another class excessively.
• Inappropriate intimacy – a class that has dependencies on implementation details of another class.
• Refused bequest – a class that overrides a method of a base class in such a way that the contract of the base class is not honored by derived class. See Liskov substitution principle.

Los dos primeras yo creo que son bastante fáciles de ver y de corregir. Normalmente no me gusta trabajar con clases de más de 300-400 líneas, aunque siempre hay excepciones claro.

Ahora, las otras no las veo tan claras… Por ejemplo feature envy. Quicir, si una clase utiliza mucho un método de otra… pues es lo que tiene ¿no? Para eso están los métodos públicos. Sobre las otras igual, me cuesta pensar en casos prácticos donde eso pase.

Aún así, yo creo que todos tenemos un 6 sentido para darnos cuenta de que algo no va bien en el código. Compilar, compila, pero huele. El problema está en encontrar qué es lo que huele y solucionarlo, claro.