Dando la chapa

Estas cosas pasan hasta en las mejores familias. Un día llegas a la oficina y te dicen que tu aplicación va sobre un servidor Windows. ¡Maldición! Pero bueno, tú piensas: “¡eh! Si yo hago Flash, a mi casi me da igual quién sirva los archivos”. Bueno, pues casi. En Windows IIS necesitas autorizar específicamente que quieres servir archivos FLV:

Windows 2003 Server does not stream FLV videos

Lo digo porque habrá que habilitar los nuevos formatos de vídeo:

New File Extensions and MIME Types

¡Salud!

¡Y es que no me sale un título más corto! A ver, se trata de que cada vez que subas algo al repositorio el cliente de SVN que utilices escriba en tus archivos el número de la revisión y/o más cosas.

Aquí va el mini-tuto para TortoiseSVN:

• Bajarte una copia limpia del repositorio
• Botón derecho sobre la carpeta o archivo > TortoiseSVN > Properties > Add
• Seleccionar del combo o añadir “svn:keywords”, sin comillas. Como valor “LastChangedDate LastChangedRevision LastChangedBy”. Puedes mirar la lista con todas las propiedades posibles.

Ahora te vas a tu código y pones esto donde quieras:

$LastChangedRevision$
$LastChangedBy$
$LastChangedDate$

Cada vez que subas una nueva versión al repositorio, tu cliente de SVN se encargará de actualizar esos valores donde los hayas utilizado y luego subir la nueva versión. ¡Voilá!

¿Y para qué todo esto? Pues lo primero ayuda a ver de forma clara y rápida a qué revisión pertenece un archivo. Luego esa información va en la documentación si usas cualquiera de los sistemas automáticos. Pero lo que a mi me han pedido es que al hacer click con el botón derecho en las propiedades de un swf en Windows, aparezca esa información por algún lado. Y eso ya no es tan sencillo.

Por un lado tenemos que el formato swf acepta cierta información metadata. Desde el IDE puedes añadir título y descripción al editar las propiedades de la película. El problema es que incluso haciendo eso, el Explorador de Windows no lo pilla. Así que lo que me he planteado es hacer una pequeña aplicación con AIR o SWHX a la que se le pase por parámetros el swf en cuestión y agregarla al menú “Enviar A” del explorador.

Pero claro, normalmente un swf es un conjunto de clases, así que no sería tan sencillo como mostrar la revisión de una de ellas. Entonces ¿qué mostramos? Pues tiene toda la pinta que la última etiqueta para el archivo swf. El problema es que, que yo sepa, etiquetar en SVN no es *tan* sencillo como en CVS. Estaría encantado si alguien me mandara un tuto “Etiquetar en SVN para torpes”.

No sé, no lo tengo claro. Más o menos tengo la idea de lo que necesito pero no lo veo 100% seguro. ¿Alguien que se anime a discutirlo?

Efectivamente, y como ya amenazaba, parece que a principios del año que viene, se va poder ofrecer contenido con DRM en Flash:

Flash Video DRM Roundup

Parece que Adobe va a ofrecer 2 tipos de DRM: content integrity y identity-based licensing. El primero impide por ejemplo eliminar los anuncios de una película, el segundo decide quién ve qué.

Además se van a meter en jaleos con Flash Media Rights Management Server, un servidor para validar el acceso a los FLVs.

Yo de verdad que no le acabo de ver la ventaja para Adobe como empresa tecnológica. Significa una inversión en desarrollo importante, no sólo dentro del player sino con el nuevo servidor, hacerlo todo multiplataforma, mantenerlo… mucho trabajo. ¿Y qué gana? ¿No es Flash ya el estándar de facto para ver vídeo en la web? ¿Será para seguir siéndolo?

Me preocupa cómo afectará esto a Red5 y compañía. Por lo que parece, se avecinan cambios importantes en el formato FLV para permitir el DRM.

En fin, no me gusta. Cada vez veo el player más grande, queriendo abarcar demasiado, sin resolver problemas mucho más básicos… Me recuerda a Are Features The Enemy? Creo que Adobe está demasiado enfocada a añadir nuevas características simplemente porque parece que quiere vender a toda costa.

Como comentaba a la vuelta de vacaciones, acabo de publicar un nuevo artículo:

Flash para Barrapunteros como tú

Todo empezó porque en una discusión en Barrapunto, un montón de usuarios seguían con la idea de que Flash no es más que una mierda de tecnología, ¡además privativa! (Qué poco se oía eso de Java, aunque la FSF lo tenía claro). Todos dando caña que si las intros, que si accesibilidad, bla, bla, bla. Al final tengo la sensación de que miraron Flash en la versión 5 y no han vuelto a actualizarse.

Bueno, pues este es mi aporte para que puedan trollear a partir de ahora con conocimiento de causa :)

Tengo la sensación de que si tiene un poco de repercusión me van a llover toñas en el sentido de que algo se me habrá pasado o no será del todo correcto y de ahí tirarán a matar, pero estoy preparado. Sé que es una buena chapa, pero estaría genial si le pudierais echar un ojo para detectar posibles errores de bulto, aunque creo y espero que no haya.

Y como último favor, ¿puede alguno de los presentes menear y/o enviar esto a Barrapunto?. Lo haría yo mismo, pero me iban a llover los negativos por spam, así que mejor si lo hace otro. Enlazad el artículo directamente, no el blog. O protestarán por spam también :D

¡Salud!

pd: ¡Cómo mola tachar cosas de la TODO list!

Pues el bueno de Grant Skinner y su equipo han sacado Spell Check Engine, un corrector ortográfico en AS3. No es ni mucho menos gratuito, pero viniendo de quien viene, para mi tiene el beneficio de la duda.

Pero me ha recordado que hace ya algún tiempo me pidieron algo semejante y les dije que yo encantado de desarrollar algo así, pero que si tenían el presupuesto para hacerlo. Por supuesto dijeron que no. Mi idea era tirar de Open Source, por supuesto. Resulta que Pidgin (cliente de mensajería para MSN, Yahoo, GTalk, antiguo GAIM) utiliza una librería de terceros para la corrección ortográfica: GNU Aspell.

Me imagino que Pidgin va llamando de forma transparente a Aspell para que le de la corrección, pero claro, lo primero que habría que hacer sería portar Aspell a AS3. Interesante proyecto, desde luego. Lástima de falta de mecenas…

¡Y es que hay que tener 1.000 ojos encima de los chiquillos! Para no alargarme mucho, resulta que por necesidades del guión queríamos pasar unas aplicaciones de player 7 a 8. Todo bastante bien hasta que unas en concreto dejan de funcionar completamente. El swf carga pero no va muy lejos. Empiezo a mirar, por aquí, por allí, pruebas, mirar código que no es mio… Resulta que compilando para player 7 todo bien, compilando para 8 natillas. Hasta que me da por preguntar al que las había hecho. Y me dice:

¡Claro hombre! Si es que estoy utilizando esa función no documentada del player 7, si compilas para 8 todo se jode.

Mírale que espabilao, programar AS2 en condiciones una mierda, pero utilizar funciones no documentadas todas las que sea necesario. Pues resulta que, para el que no lo sepa como yo, en el player 7 podías seleccionar un nodo de un xml así:

var xml:XML = new XML();
var node:XMLNode = xml["myID"];

Entonces seleccionas el nodo que tenga el atributo “id” = “myID”. Y claro, para el player 8 se cepillaron la gracia y la cambiaron por la oficial XML.idMap que cuando la he visto en la documentación me he quedado O_O porque anda que no habré pasado veces por allí y no la había visto.

Me pregunto si los problemas de rendimiento de Flash con los xmls largos no tienen algo que ver con esto porque ¿es automático el parseo del xml para generar el idMap o se generará la primera vez que se invoque? Hagan sus apuestas.

Moraleja 1: Cuando crees que sabes mucho de un lenguaje te encuentras con cositas como esta que te devuelven a la humilde realidad.
Moraleja 2: JAMÁS bases una aplicación en una función indocumentada o no oficial. Si lo haces (porque estás sordo o ciego y no has leído el aviso anterior) DEJA UN COMENTARIO GIGANTE EN EL CÓDIGO AVISANDO.

Joder.

:D

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!

Pues ahora que los Reyes se acercan, aquí va mi whislist para el futuro player 10:

- Componentes básicos incluidos en el player. Como ya explique aquí, me parece que Adobe debería primero hacer unos componentes decentes y segundo incluirlos en el player. Eso todavía permitiría a quien quisiera utilizar los suyos propios.
- Que funcione wmode o que lo quiten. No más infierno.
- Seamless tabbing. Es una parámetro del objeto HTML que permite que un objeto Flash entre en el ciclo de TABs normal del navegador sin tener que hacer click en el. A dia de hoy sólo funciona en IE y salió con el player 7…
- Fuentes compartidas oficiales, para evitar esto o sus derivados.
- Solucionar todos los bugs del player ANTES de añadir más complejidad.
- Igualar las versiones del player en TODAS las plataformas. Esto entiendo que es lo más complicado de todo, pero es que a día de hoy hay un player para PC, Win y Mac, otro para Pocket PC, otro para Flash Lite y el player de la PSP…

Si sacaran una versión del player arreglando todo aunque no añadieran nada molón yo estaría más que feliz.

Ha habido muchos dimes y diretes sobre si el iPhone muestra webs con Flash o no. La respuesta es NO:

iPhone Does Not Support Adobe Flash: the Facts

… por ahora:

Questions About Apple’s iPhone

QUESTION: If the iPhone’s Web browser is so good, why can’t it play video on Web sites I visit?

At launch, the iPhone version of the Safari browser is missing some plug-ins needed for playing common types of Web videos. The most important of these is the plug-in for Adobe’s Flash technology. Apple says it plans to add that plug-in through an early software update, which I am guessing will occur within the next couple of months. However, a separate program included on the iPhone can play a limited selection of videos from YouTube, and the phone can play videos you purchase from Apple’s iTunes store, and certain videos you create yourself.

Y el comando friki le manda recaditos a Apple en formato Apple:

Vía Aral.

Es que me quería morir. Atención al código en una clase que usa GDispatcher:

var ev:myEvent = new myEvent();
dispatchEvent(myEvent);

Por lo menos 1 hora tratando de averiguar por qué co@;;;$#s no llegaba el evento a la clase receptora. Venga leer y releer el código que compilaba perfectamente…. Hasta que me di cuenta. Igual es mejor esto:

var ev:myEvent = new myEvent();
dispatchEvent(ev);

El problema viene porque dispatchEvent es un método que GDispatcher “inyecta” en la clase emisora. Y en la clase emisora la función dispatchEvent normalmente sólo se declara así:

private var dispatchEvent:Function;

Por lo que puedes mandar lo que quieras que no hay error de validación…. Así que me estoy pensando algo para dejar de usar así GDispatcher. No me gusta! Viva la validación de tipos al compilar!