Dando la chapa

Cual Tomate versión friki, hoy va a haber polémica: ¿Extender MovieClip? No, gracias:

• Si extiendes de MovieClip no puedes extender de nada más, en Flash no hay herencia múltiple (o casi).
• MovieClip es una clase dinámica, por lo que te cargas toda la validación de variables al compilar. Es decir, si tienes una clase con una propiedad que se llama “wadus” y luego intentas acceder a ella con algo como “wauds”, el compilador NO canta. Esos errores me han hecho perder *muchas* horas absurdamente.. Actualizado, ver Extender de MovieClip. Su envainamiento, gracias.
• Instanciar clases que extienden de MovieClip es raro ya que no puedes hacer un new, tienes que crear las instancias con attachMovie.

Así que lo que hago normalmente es crear un MovieClip y pasárselo a las clases para que “trabajen” sobre el, incluso para las clases de objetos gráficos (como ComboBox o TextArea). Eso se llama formalmente composición.

Lo que también es cierto es que esta es una pelea que siempre que sale levanta bastante polémica entre frikis gafotas que al final acaban mentando a la biblia y sus apóstoles. Para mi es algo bastante más pragmático, la verdad. Para más puntos de vista y debate, podéis echarle un ojo a este hilo de ASNativos.

Y ya que estoy, aprovecho para meter la puntilla del IDE de Flash. No descubro nada si digo que su compilador es digamos… umm.. ¿malo? Pero ya sé querido diseñador y/o flojeras que no quieres venir al lado oscuro, que tu amas a tu IDE por encima de todas las cosas. Ok, no problemo. Pero échale un ojo a FLASC (FlashIDE + MTASC). Te vas a ahorrar muchos problemas.

Ánimo con el lunes

Hace poco se ha hecho famoso el menú de apagado de Windows Vista porque a Joel Spolsky no le hace mucha gracia. Poco después el autor contaba la historia en The Windows Shutdown crapfest. Lo que me ha llamado la atención es el inmenso proceso que va desde que algo se quiere implementar en Windows hasta que llega al usuario final. Modificar ese menú de apagado le llevó un año al autor. Más de 40 personas repartidas en varios equipos opinaban sobre el menú. En fin, una montaña de burocracia a-con-go-jan-te.

Pero ¿podría ser de otra forma?

No soy ningún campeón en la gestión de equipos, pero parece bastante evidente que cuanto más grande es la organización más capas y capas de gestión se tienen que añadir. Estamos hablando de programadores, diseñadores, gente de usabilidad, testing, jefes de proyectos y probablemente hasta los de la limpieza tengan algo que decir.

Por lo que comenta este hombre, el repositorio de código de Windows está formado por nodos, desde el centro (la parte que realmente _es_ Windows en un momento dado) hasta la periferia que es donde pequeños equipos van desarrollando. El desarrollo es de fuera a dentro, y este hombre estaba a 4 nodos de distancia de la rama principal. Una modificación suya tardaba entre 1 y 3 meses en llegar al centro, ya que tiene que ir escalando todas esas ramas, se supone que pasando controles de calidad y tal.

Aunque parezca un dinosaurio (probablemente lo sea) me sigue pareciando difícil organizar la cosa de otro modo. A no ser que vayas a un modelo completamente descentralizado…. umm… déjame pensar… ¿Como Linux? Sin intentar hacer demagogia, parece mucho más racional partir las tareas en equipos mucho más pequeños y manejables, incluso en distintas organizaciones. Está claro que la gente del entorno gráfico (GNome, KDE) no puede hacer mucho sin el equipo del núcleo y que están condenados a entenderse, pero parece que es mucho más fácil de gestionar.

En fin, el día que termine de leerme The Cathedral & the Bazaar, comentaré más sobre el tema.

Más discusión:

No te compliques
El autor del menú de apagado de Vista responde

Ya van una cuantas veces que tengo que escribir una guía de estilo para AS2. Dejo por aquí unos apuntes:

• No usar _root sino es absolutamente necesario*.
• No usar variables globales sino es absolutamente necesario*.
• No picar a fuego NINGUNA URL a ningún recurso. Usar un xml de configuración o FlashVars.
• Usar el prefijo “fv_” para todas las FlashVars, así se reconocen fácilmente en el código.
• No dejar traces por el código, sólo añaden ruido a la consola de log. Dejar sólo trazas de error.
• NO extender de MovieClip, utilizar composición en su lugar**.
• Declarar el tipo de TODAS las variables.
• Declarar el tipo devuelto por TODOS los métodos. Usar Void sino devuelve nada.
• Compilar con -strict en MTASC siempre que sea posible*.
• Trata de que sólo haya un return por método*.
• Intenta que todos los métodos y variables posibles sean privados. Pasar de privado a público es fácil. De público a privado se puede convertir en un infierno.
• Para ayudar a los demás a leer tú código:
• Delimita físicamente una zona de la clase como pública y otra como privada. Así es mucho más fácil ver qué métodos se pueden utilizar (API) y cuáles no.
• Utiliza la tabulación de una forma constante y coherente.
• Finaliza todas las líneas con “;”.
• Las líneas en blanco son gratis. Por favor, utilízalas.
• En el código comenta el “por qué” y no el “qué”:
• var res:Number = a + b // el resultado es a+b. MAL
• var comienzoIndice:Number = 1 // el indice empieza en uno por xxx razón. BIEN

* Hay muy pocas veces en las que sea absolutamente necesario. Repito: ¡muy pocas!
** Pronto en sus pantallas mi gran chapa sobre por qué no extender de MovieClip.

He decir que estas son mis normas actuales y que no siempre han sido las mismas. Aunque he que reconocer con el tiempo cada vez cambian menos .

Se admiten comentarios y propuestas alternativas, por supuesto.

¡Salud!

pd: si no haces las cosas como yo, te odio : )

Does Writing Code Matter?

One of the biggest issues I see is developers getting caught up in the code. Spending countless hours making a function perfect or building features which show off the latest technology. Now you have to write code to be in the software business. It has to be high quality code that isn’t filled with bugs or is insecure. However, the best code in the world is meaningless if nobody knows about your product. Code is meaningless if the IRS comes and throws you in jail because you didn’t do your taxes. Code is meaningless if you get sued because you didn’t bother having a software license created by a lawyer.

Most of the famous-ish programmers I respect have actually made their impact on me through writing, and it’s usually just prose, with maybe a little code interspersed

What I am proposing is that we spend less time coding and more time developing skills in other areas that complement our coding skills. Become a better writer. Become a better speaker. Improve your personal skills. Participate in the community. Try to spend some time talking to people instead of the compiler.

Es un poco triste, pero tiene pinta de ser verdad. ¿Cuántos genios desconocidos habrá por el mundo que no conocemos simplemente porque no tienen unas mínimas dotes de comunicación? ¿Son los cracks de la programación mundial menos cracks como programadores de lo que pensamos y símplemente buenos oradores?

Sucking Less Every Year

I’ve often thought that sucking less every year is how humble programmers improve. You should be unhappy with code you wrote a year ago. If you aren’t, that means either A) you haven’t learned anything in a year, B) your code can’t be improved, or C) you never revisit old code. All of these are the kiss of death for software developers.

La verdad es que mirando el código que hacía el año pasado realmente apesta, lo cual indica que he mejorado :) Bueno, bueno, tampoco apesta tanto. Lo que sí que he mejorado brutalmente es el flujo de trabajo, dar el salto a MTASC y SWFMill ha sido lo mejor con diferencia. Este último año he aprendido un montón de muchas cosas, sobre todo de trabajar con dispositivos móviles, de herramientas libres para Flash, algo de Ruby… no me puedo quejar. Para el año que viene quiero saber haXe, ActionScript3 y Linux.

Si podéis/queréis echad un ojo a este otro post que se autoenlaza, que también es una perla:

Your employer can’t force you to be a good programmer; a lot of times your employer isn’t even in a position to judge whether you’re good. If you want to be great, you’re responsible for making yourself great. It’s a matter of your personal character.

Isn’t the world of development blogs, an amazing fountain of seemingly endless knowledge– also incredibly humbling? There are so many people, many of them giants in the field, who are far smarter and just plain better than I will ever be. But it’s not our job to be better than anyone; we just need to be better than we were a year ago.

Y tú qué ¿apestas menos que el año pasado pero más que el que viene?

Hace unos días Joan Garnet puso un post sobre fuentes para programar, y la verdad es que se agradece cambiarla de vez en cuando, como que tu código de siempre parece otro. Echadle un ojo a éstas que son gratis.

• Si trabajas con SEPY la puedes cambiar en Tools > Preferences > Fonts and colors.
• Si curras con FlashDevelop, tienes que ir al directorio de instalación de FlashDevelop, luego a /settings/ScintillaNET.xml, y ahí busca “default-font”.
• Y si picas con otro IDE… pues ya sabrás cómo hacerlo :)

Con este post voy a inaugurar una sección nueva:

MOLARÍA QUE TE CAGAS

Básicamente trataré de agrupar en estos posts cosas que me gustaría que no fueran como son. Dando por supuestas las clásicas “que no haya hambre en el mundo”, “que no haya George Bush en el mundo”, “que Roberto Carlos se vaya del Madrid YA”, etc, etc.

Para empezar he elegido el siguiente tema:

Programar las cosas que usas

Ejemplos:

• Móvil: no utilizo nunca la mitad de las funciones y las que utilizo no están donde yo las quiero
• Microondas: suena cuando termina la cuenta atrás, y a las 7.30 am me mo-les-ta. Como poco debería ser una opción programable: ¿quiere que suene sí o no?
• Menú interactivo de la tele digital: básicamente lo mismo que el móvil. Me hacen dar 50 clicks para las opciones que más uso. Hay opciones que nunca uso y problablemente no usaré
• Mando a distancia de la tele/vídeo/lo que sea: aunque se trate de hardware, estaría igual de bien poder quitarle la mitad de los botones. ¿Alguien se acuerda del mando a distancia aquel de Sony que por un lado tenía mogollón de botones y por el otro sólo los ultra-básicos? Qué bueno era. Ahora no lo encuentro en Google, si alguien lo hace que que lo deje en los comentarios, ¿ok?
• Cajero automático: Idem que el móvil. Eso sin contar con lo que le cuesta ofrecer la posibilidad de hacer dos operaciones distintas seguidas
• Etc, etc.

¿No molaría que te cagas poder reprogramar todo este tipo de aplicaciones que utilizamos a diario para que se adaptaran a nosotros?

Y digo yo, ¿para qué validar en cliente si la validación en servidor siempre hay que hacerla? ¿No estamos duplicando el código y la lógica de la aplicación? ¿Para ahorrar un par de llamadas al servidor? Eso sin contar con que hacer validación accesible en cliente no es nada fácil.

El caso, no digo que no sea útil en algún momento, ¿pero alguien me da buenas razones para hacerlo de forma intensiva?

Gracias