Mientras leía artículos para decantarme por un editor, topé con esta frase que me encantó: “My mind continues to wander back to the days of using FlashDevelop, but I must push forward. Mac OS is my home now.” Así que la hice mía y decidí probar Flash Builder primero y FDT después.

Adobe FB lo descarté en poco rato. Conozco sus bondades para trabajar en Flex (obviamente) o proyectos ActionScript, pero realmente no está pensado para trabajar con Flash Professional: la integración es nula.

Con FDT tenía bastantes esperanzas ya que mucha gente habla maravillas, pero a las 3 horas lo tuve descartado también. Aunque tiene algo más de integración con Flash, me pareció muy complejo la forma de “enlanzarlo”, teniendo que crear una configuración específica para cada proyecto Flash, los Core Library, que copies una carpeta de clases en tu proyecto y no las reconozca hasta que hagas un “Add to classpath” explícito… Me agotó encontrar un “problema” cada 5 minutos y pasar 20 en Google para entender qué pasaba (con suerte!). E incluso a la hora de picar código, no me sentía del todo cómodo.

Así que visto lo visto, para mis necesidades, FlashDevelop sigue siendo la mejor opción:

• por su autocompletado y code hinting (el más potente de largo). Prácticamente no hace falta ni memorizar las variables: si tienes _planeta_azul y escribes “az” ya te ofrece la opción correcta
• por Ctrl+Shift+1, que te crea funciones parametrizadas, variables de clases, getters/setters …
• por los snippets
• por la cantidad de atajos básicos de los que no puedo prescindir (duplicar linea, intercambiar linea, comentar bloques, etc)
• por su configuración mínima
• por su perfecta integración con Flash
• porque es gratis

Y muy importante, que al contrario de FB y FDT, que están concebidos para trabajar con proyectos enteros, FlashDevelop sirve perfectamente para programar/editar clases sueltas (cosa que yo hago muchísimo).

Soy consciente que algunas de las cosas que he listado las hacen igual o mejor los otros programas, y estoy convencido de que FDT es un magnífico editor, pero al final es un tema de compatibilidad: con el IDE de Flash y conmigo :)

Así que volviendo a la frase del principio, Mac es ahora mi casa, pero voy a hacer un cuartito para un programa Windows. Hoy mismo publicaré un post explicando cómo lo tengo montado yo.

Update: ayer no me dio tiempo porque he seguido trabajando en el workflow entre Flash y FlashDevelop. Ahora sí que sí lo tengo a medida :) Espero contarlo en unas horas…

9 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2010

No ha sido una decisión fácil, porque por la mitad de 1600 leuros te puedes comprar un Dell cojonudo, porque creía que no necesitaba un portátil sino un sobremesa, porque ya tengo una pantalla de 22 pulgadas y descartaba el iMac,  porque lo encargué un día antes de la salida de Windows 7, porque me encanta FlashDevelop, Tortoise, LiveWriter…

A favor jugaba tener a mis propios mac-evangelizadores, Cay y Vicente, las ganas de aprender a moverme por Mac OS (no había tocado nada de nada), querer probar las maravillas que todo el mundo cuenta y este post de Joan Garnet, que acabó de darme el empujoncito ;)

Y desde el primer momento se aprecia qué supone tener un Mac: el packaging ya te hace sentir que estás manipulando un artículo de clase,  los acabados son preciosistas, el teclado perfecto, el trackpad exquisito… Baste decir que antes de sacarlo de la caja ya tenía a varios compañeros a mi alrededor (alguno más expectante que yo!), que me tiraron fotos y que esa tarde me felicitaron como unas 15 personas (más que en mi cumpleaños!) xD

Y bueno, del sistema operativo no voy a descubrir nada nuevo porque soy el último en llegar, pero como resumen decir que a las pocas horas ya sabía que había acertado con la decisión. Todavía me extrañan varias cosas y echo en falta algún funcionamiento/programa de Windows, pero las mil y una características compensan sobradamente. Cuando pase un buen tiempo vendré a contar mis experiencias desde el punto de vista de programador flash.

12 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2009

Para ponernos en situación: vamos a asumir que cuando hablamos de código fuente hay una parte que corresponde puramente al encargo, y en muchos proyectos hay otra parte de “valor añadido” (porque se está utilizando un framework propio, unas librerías muy complejas, una clase que facilita muchísimo x tarea, etc). Entiendo que con la primera no hay problema, porque al fin y al cabo te pagan por eso, y es en el segundo caso donde sabe mal “regalar” nuestro trabajo. A partir de aquí pienso todo el rato en situaciones con este “código de valor añadido”.

Para mí, casi siempre se debe entregar el código fuente. Sino se hace así, el cliente está encadenado. ¿Qué le impediría luego al desarrollador pedir cantidades desorbitadas por cualquier cambio? En caso de que al cliente no le interese trabajar con el autor original, debe tener la posibilidad de modificar él mismo el programa o pasárselo a terceras personas. Obviamente habrá excepciones, por ejemplo desarrollos muy complejos donde se entra en un sistema de licencias para explotación.

Si el cliente puede (y debería) exigir los archivos, el programador también puede pedir una cantidad mayor. En el primer comentario del post original se lee “para entregarse los fuentes, tiene que haber mucho dinero encima”, y me consta que hay muchísima gente de la misma opinión. Si un programador tiene el derecho de pedir mucho dinero, obviamente el cliente tiene el derecho de preguntar qué está comprando:

• ¿una clase propia para validar un mail? ¿un gestor entero de contenidos?
• ¿y qué calidad tiene el código fuente? ¿tipo Grant Skinner o tipo estudiante de segundo curso?
• ¿está el código 100% libre de bugs?
• ¿es fácil de implementar? ¿es fácil de extender?
• antes de que yo ponga encima de la mesa el dinero ¿me vas dejar investigar a ver si merece la pena?
• y más allá del código en sí… ¿me puedes asegurar que es imprescindible utilizar ese código que aumenta tanto el presupuesto?

Intento ilustrar las preguntas anteriores con un par de ejemplos:

1) Yo como “contratista”, hago un encargo a un freelance que me pasa un presupuesto muy elevado porque incluye el código fuente de un motor de tweens que ha desarrollado durante 2 años. Habiendo librerías gratuitas tan buenas como GTween o TweenLite, me niego a pagar el coste (seguramente nadie lo haría)

Ahora lo hacemos extensible, por ejemplo, a un conjunto de Expresiones Regulares. El freelance se ha currado una librería durante meses con decenas de ellas, y piensa que el cliente podrá aprovecharse de ello para otros proyectos. Yo dudo si pagarlo, porque considero se pueden encontrar en google de manera más o menos fácil.

Y lo hacemos extensible a un algoritmo que se ha inventando Yugop para deformar imágenes y que no se consigue en ningún lado y blablabla y yo lo pago encantado.

¿Qué marca el límite sobre lo que es fácil de conseguir y lo que no? ¿qué es reutilizable y qué no? ¿qué es único y qué no? Y más importante, ¿tienen nuestros clientes un nivel de conocimientos suficiente para tratar estas cuestiones?

2) Un cliente me contrata para un proyecto. Decido utilizar mi package de utilidades, que simplifica un montón de tareas y me permitirá hacer el trabajo en 5 días. El cliente se niega a pagarme el código, así que yo rehago el presupuesto sin incluir mis “utils”, lo voy a hacer todo de cero. Esto significa que en vez de 5 estaré 10 días y que doblo el presu final. Para el cliente no soy competitivo y se busca otra alternativa.

Son sólo dos ejemplos, pero a mí personalmente me responden muchas cuestiones. Y aún más, vamos a alejarnos un poquito de la perspectiva flash, por ejemplo pensando que hacemos un site en html+css+php, ¿no entregas todo? ¿el programador php teme que utilicen sus clases? ¿que aprovechen el css para otro site?

Mi conclusión final es que como programador siempre voy a dar el código fuente, y como cliente no voy a trabajar con nadie que no lo entregue. Y no voy a exigir más dinero al darlo, y no voy a pagar más si me lo dan. Para mí la gracia del negocio está en el valor que aporta el programador. Si trabajo con una persona que me resuelve cualquier problema, si puede aplicar cambios sin estar 4 días, si al pedir un cambio de funcionalidad no tiene que tirar media web abajo porque la implementó con patrones, si el código está perfectamente documentado… eso sí que no me importa pagarlo.  Y por contra, si el presupuesto es muy justo, pues se puede avisar de que se programará “rápido” (que no mal), que será más difícil de extender, poco modulable, etc.

Y en cuanto a nuestro trabajo de “valor añadido”, pues seamos listos. Si no se le quiere dar un plus al cliente, pues no metamos el package entero, simplemente las funciones/clases imprescindibles; si se utiliza un módulo que se puede reutilizar para otros proyectos, pues se crea un biblioteca de clases (swc); si paga las horas justísimas, pues no se comenta el código por falta de tiempo; etcétera etcétera.

Y obviamente, lo expuesto aquí es mi opinión. Cada uno es libre de valorar su trabajo y sus horas como quiera. Al final, como cada proyecto, cada cliente y cada programador es un mundo, se convierte en una ecuación de infinitas posibilidades. Por eso, se piense como se piense, lo importante es dejarlo todo por escrito desde el principio.

13 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2009

Por cierto, sino fuera programador creo que me gustaría trabajar maquetando. Los css tienen un rollito puzzle-lógico que me mola mucho…

Bueno, el próximo post relacionado con código. Lo juro :p

4 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2009

A principios de 2009 pasé a ocupar el puesto de director técnico en mi agencia. En parte fue un formalismo, ya que venía encargándome de la mayoría de tareas asociadas a ese rol, pero por otro lado me obligó a tener un conocimiento global de todos los proyectos, a implicarme mucho más en la gestión de recursos, en la supervisión de externos, a consolidar el equipo técnico, etc. Así que para poder llevar todo esto a buen puerto (dentro de lo que cabe xD) tuve que renunciar a estar en los proyectos como programador. Al principio pensé que sería cosa de unas pocas semanas, pero al final he estado como medio año sin tocar una linea de código (que se dice pronto). Esto se tradujo en un abandono del blog: es difícil escribir sobre una temática cuando no estás en el día a día, no surgen  buenas ideas para los posts… y no tenía ni tiempo ni ganas para liarme con experimentos.

La segunda parte de la historia es que en julio me metí en un gran proyecto no sólo en la planificiación y dirección, sino también programando. A parte de disfrutar, puedo decir que es uno de los desarrollos en los que más he aprendido. Esto se ha traducido en ganas de volver a escribir y de compartir conocimientos.  Así que, tras unas reparadoras vacaciones, todos estos elementos dan como resultado que a partir de ya retomo el blog :)

Siempre es agradable volver.

9 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2009

De todas las grandes cosas que me ha aportado el blog la mejor ha sido (como ya me vaticinó un amigo) la posibilidad que he tenido de conocer a muchísima gente interesante, y la peor, el escaso tiempo del que dispongo algunas temporadas para escribir.

Y como no, dar las gracias de corazón a toda esa gente que siempre ha tenido un minuto para dejarme unas palabras: no os imagináis lo mucho que ayuda a tirar hacia adelante.

Un año después, seguimos.

12 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2008

En marzo de 2004 me sumé al proyecto Mahou en Herraiz&Soto, y la web corría a 15 fps. Nueve meses después lanzamos una nueva versión del site que lo hacía a 25 (supongo que los diseñadores y animadores meterían mucha presión).

Durante el 2005 y parte del 2006 todas las películas que trabajábamos en la agencia solían correr a 25 frames, pero luego un compañero empezó a utilizar como cifra mágica el 31, ya que había oído el rumor que las películas a 21 y 31 funcionaban mucho más optimizadas. Recuerdo que me parecía completamente absurdo, pero el resto de gente fue pasándose a los 31, menos yo, que me pasé a los 30 (pa chulo yo xDD)

21,31… el framerate mágico

Durante algunos años el Flash Player funcionó rematadamente mal en Mac debido a un bug del sistema operativo (los temporizadores eran imprecisos y los cálculos se resentían disminuyendo el framerate). Resultó que un framerate de +1 ayudaba a cuadrar las operaciones y el rendimiento del Player se asemejaba entonces al que tenía en Windows.
Lo gracioso fue que este error fue subsanado con el Flash Player 6, pero el rumor del “número mágico” continuó extendiéndose.

En el 2007 ya me había bajado del burro y utilizaba 31 frames en todos mis proyectos. Sólo con la salida del Player 9 y AS3, con su gran incremento de rendimiento, me decidí a cambiarlo. Así pues, para mi primera aventura en AS3 utilicé 60 fps. Era un site que combinaba mucha animación y programación, y la verdad es que me decepcionó un poco porque en el navegador, a pesar de verse más o menos fluido, caía muchísimos frames. Con tanto bombo que le habían dado a la AVM2 creí que rendiría mejor.

Después de esto volví a los 31 y hasta el día de hoy todo lo hago con este valor. Considero que una peli que funciona entre 25 y 30 frames es ideal, y ya en algún artículo he apuntado que al correr un swf en el navegador suele caer 2 o 3 frames, así que 31 menos la pérdida da un muy buen resultado.

Pero la gran sorpresa que no me llevé con el Player 9 me la he llevado con el 10: no sólo no pierde frames sino que llega a marcar alguno de más y todo. He probado todo tipo de experimentos, y algunos que consumen muchos recursos y en el navegador bajaban hasta 24/25, ahora se quedan tranquilamente oscilando entre 31/32.

Han sido muchas las veces que he abierto un proyecto en Flash y he pensado “¿Qué framerate utilizo?”, y por más años que pasen parece ser que esta pregunta seguirá ahí.

Y tú, ¿tienes alguna preferencia a la hora de elegir framerate?

6 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2008

Oye… ¿por qué te pones en plan vendedor?
Porque necesitamos programadores.

¿Y qué tipo de programadores?
Pues del tipo que leen este blog: amantes de Flash y ActionScript.

¿Para qué puesto?
Lo mejor es que no necesitamos cubrir un puesto específico, sino varios.

Vaa, ponme algún ejemplo.
Ok! Eres un genio de ActionScript, estupendo. Nos mandas currículum.

- Vaya… así que te encargas de arquitecturas web, tocas bases de datos, trabajas con remoting… ¿qué te parecería liderar un site desde cero para Camper?

- O tú, que dominas ajax, oop en php, xml… ¿te verías capaz de ejercer de director técnico en la cuenta de BMW?

- Vaya, lo tuyo es la programación creativa. Tus ideas te preceden. Pues en Ikea o Casio está el listón muy alto… pero prueba a sorprendernos.

Hombre, yo a este nivel no, pero estoy aprendiendo Tweener y puedo hacer algún banner…
Pues sintiéndolo mucho, esta vez no será. Buscamos a gente senior, que esté curtida en mil batallas, que sepa trabajar en equipo y liderar proyectos. Una liga para mayores.

Pues no tengo mucha experiencia en grandes proyectos, pero tengo mucho que decir…
Está bien, Yugop también tuvo 20 años, y nosotros no rechazamos los desafíos. Veamos ese potencial.

Yo es que ya tengo un buen puesto en una agencia. Cambiar por cambiar…
Normal: eres bueno, tienes buen puesto. Pero si esto te está despertando una mínima inquietud, ¿por qué no hablamos? Deja que te cuente lo que se avecina aquí. Quizá se disipen las dudas… Además, cambiar de agencia está de moda!

Pinta bastante interesante…
Genial. Tráete tus ganas, tu experiencia, tu forma de trabajar. Habrá otros que harán lo mismo que tú, y entre todos vamos a marcar el camino a seguir. Si eres de los que tienen mucho que aportar, te aseguro que no hay mejor momento para subirse al carro.

No digas más. ¿Qué hago ahora?
¿Pues por qué no empiezas por enviarme un mail a dani(arroba)herraizsoto(punto)com? Cuéntame algo de ti, pásame tu curriculum, enséñame muchos links… Seguro que esto es el comienzo de algo interesante.

4 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2008

Si a esto le sumo que entre semana no puedo dedicarle muchas horas, el resultado es que publico unos 4 post al mes.

Así que pensando en maneras que me permitan escribir de forma más continuada y sin tanta “preparación”, he acabado añadiendo tres nuevas secciones al blog: Reviews, Trabajos y Utilidades (todavía no aparecen en el menú de categorías ya que no tienen ningún post asociado). Aunque los nombres son descriptivos, aquí va un pequeño resumen de lo que encontraréis.

Reviews

Aunque me tiro la mayor parte del día leyendo en el monitor, podría decirse que soy un buen consumidor de libros. De aquellos que vaya leyendo (normalmente entorno a ActionScript) y considere oportunos, escribiré una entrada más o menos detallada.

Pero los reviews no se centrarán únicamente en libros, sino que también lo haré sobre aquellos artículos que vaya viendo en la blogosfera y me llamen sobremanera la atención. No me dedicaré a poner un post tipo “Pepito habla de los eventos aquí, ves a verlo”, sino que se tratará más de análisis y crítica.

Review viene a ser en castellano una Reseña, pero la verdad es que el nombre en inglés me gusta mucho más y se entiende mejor en el mundillo tecnológico.

Trabajos

Cuando empecé el blog no era mi intención poner trabajos que hago en mi empresa, pero pensándolo mejor no está de más compartir esta parte, y a final de año me servirá para hacer una valoración y ver si estoy satisfecho con lo que he ido sacando.

Además, estoy con un par de desarrollos en AIR que me motivan mucho, y quizá más adelante pueda ir comentando sobre ellos.

Utilidades

Aquí englobaré programas, frameworks y clases que considero imprescindibles en mi día a día. En esta categoría compartiré también mis clases propias, por si fueran de utilidad a alguien.

Pronto empezaré a rellenar estas secciones, aunque intentaré no descuidar los artículos ni los experimentos :)
Y hablando de no descuidar, estoy a medias con la tercera parte de Jugando con pixels. Espero tenerlo acabado para finales de semana.

Nadie ha comentado, se el primero | Permalink | Add to del.icio.us

LLops Blog, 2008

Desde hace un par de días estoy trabajando en un banner que, por requisitos del cliente, tiene que estar publicado para Flash Player 8. En general, el desarrollo no es muy problemático, pero hay una tarea que requiere de una lógica algo más compleja.

Lo primero que quise hacer fue quitarme de en medio esta parte, y cómo lo importante era centrarme en el problema, me puse a picar código en AS3. En poco más de un día tenía solucionada dicha parte. Después de esto, he abierto un nuevo fla y me he puesto a programar el resto del banner y a migrar mis clases a AS2.

Pues bien, volver a AS2 está siendo una experiencia traumática. A pesar de llevar varios años programando en actionscript parezco un novato. Un breve resumen de las cosas que me están pasando…

Bienvenido al pasado 

Abro mi fla y me dispongo a declarar el Document Class. Ah, es verdad, que eso es de CS3. Pues nada, abro el panel de acciones y creo mi clase:

new Main();

Abro FlashDevelop y creo una nueva clase AS2. Al generarme la estructura el programa, recuerdo que el package no se define, sino que se pone junto a la clase. Creo mi constructor, una función init (con el Void en mayúscula, que gracioso) y un trace para probar, compilo y todo bien (“Excelente, Smithers”).

La siguiente tarea titánica es… definir un enterFrame en mi método init. Pues bien, para esto he estado varios minutos. Empiezo con addEventLi… no no, es verdad, esto es de AS3. Escribo lo siguiente:

this.onEnterFrame = enterFrame;

Defino una función enterFrame con un trace de prueba. Esta vez no va. Miro la documentación porque ya no estoy ni seguro que se escriba onEnterFrame. Pues sí, está bien escrito, y en la documentación también lo implementa en el this… En vez de asociarlo a una función pruebo directamente a definir la función dentro del método. Tampoco va. Pensemos…

Al final caigo que en AS2 la clase principal no extiende de nada, por tanto el this hace referencia a un Object, no a un MovieClip. Vuelvo al fla y en la creación de Main paso una referencia del escenario, lo recojo en el constructor como root y ya puedo asociar mis eventos a este clip.

Este ha sido el round 1. A partir de ahí me he encallado en cosas como:

• intentar hacer un scroll y no conseguirlo, hasta darme cuenta que utilizaba y en vez de _y.
• tener que almacenar en un botón una referencia de la clase para poder acceder a ella en los eventos onPress y onRelease (de esto me acordaba xD)
• volverme loco al no conseguir acceder a un MovieClip en mi clase!! Al cabo de unos minutos he visto que tenía un problema de ámbito y he recordado a mi viejo amigo el Delegate (que ni recordaba en que paquete se encontraba, y mira que lo he utilizado veces…)
• enterarme (por las malas claro) que el método hitTestPoint es de AS3, y tener que implementar manualmente un sistema de colisiones.
• tener que reescribir una clase que funcionaba a base de Timers, y comprobar lo limitado que es el setInterval.
• volver al attachMovie (noooooooooo!!!!)
• y alguna más que me dejo en el tintero.

En fin, que hace falta experiencias de este tipo para valorar más que nunca AS3. Después de unos 10 meses tocando únicamente AS3, he vuelto a descubrir lo maravilloso que es el “method closure“, la gestión de eventos y, en general, la forma de trabajar. Incluso cosas como el Timer, que al principio me pareció más engorroso que el setInterval, ahora lo he echado de menos.

Por suerte para mí se trata de un banner y estaré 3 o 4 días, pero no me quiero ni imaginar lo que tiene que ser empezar un proyecto medio-grande con AS2. Si en mi curro me “enchufan” uno me cambio de agencia. Avisados están.

3 comentarios | Permalink | Add to del.icio.us

LLops Blog, 2008