Empezando con AS3

Mi aportación:

Para programadores de AS 2.0:
enlace

Para programadores en general:
Introducción: enlace
Nociones básicas: enlace

Avanzados:
Expresiones regulares 1: enlace
Expresiones regulares 2: enlace

En general en cristalab.com hay mucho contenido, yo sólo destaco los que me han resultado más interesantes

Me apunto:

Introducciones a AS3 sencillitas para empezar: tips y overview.

Librerias para Flickr, Delicious, etc: en los labs.

Bastante avanzado sobre rendimiento y el nuevo Garbage Collector. Ojo que en la misma pagina tiene segunda y tercera parte.

Y luego el tag AS3 en delicious, para saber lo que otra gente cree interesante.

Y tenia uno sobre AS3 por linea de comandos (solo con el SDK) pero no lo encuentro, creo que esta en casa, ya lo mandare.

Animo!

Imprescindibles los tips de senocular en Kirupa:

http://www.kirupa.com/forum/showthread.php?t=223798

Yo me he comprado este libro action script 3.0 para desarrolladores flash, pero no me esta resultando tan fluido como el de Colin de AS 2.0....

Aqui otro que se apunta al AS3 y me va bien todo lo que podais poner, por cierto que estoy esperando el de coolin Moock en castellano ¿Sabeis para cuando? mientras tanto me han recomendado el de AS3 coock-book ¿Alguien lo ha leido/consultado? ¿que tal esta?

Pues yo lo que he visto es que el CoockBook es más una referencia que una guia, expone problemas y soluciones concretos, pero no ofrece una curva de aprendizaje lineal y ejercicios de práctica como los de Colin. A mi me gusta más el segundo.

Fifty reasons ActionScript 3 kicks ass by Grant Skinner

Muchas gracias por el enlace msanchez. Esta de lujo.

Por cierto Hartum: Creo que el de Moock en castellano ya esta a la venta, la verdad. Vamos, al menos juraria haberlo visto en alguna libreria.

msanchez

Fifty reasons ActionScript 3 kicks ass by Grant Skinner

eRNieB

Por cierto Hartum: Creo que el de Moock en castellano ya esta a la venta, la verdad. Vamos, al menos juraria haberlo visto en alguna libreria.

Hey erni ;)

El que él dice también es de Moock.
El problema es que el que se ha publicado en España como "para desarrolladores Flash" es en realidad prácticamente calcado al "Cookbook" inglés (mismo animal en portada y creo q todo exactamente ¡ salvo el primer capítulo xD).

Creo que el que Hartum reclama es el básico. El que aquí es "Essentials", como el de AS2.

¿Voy bien encaminado?

Que buenos links msanchez (y demás foreros). Gracias.

He entrado en un bucle infinito viendo las 50 patadas en el pompis:
"ya era hora, que bueno, ya era hora, que bueno, ya era hora, ..." :D

ozke

Creo que el que Hartum reclama es el básico. El que aquí es "Essentials", como el de AS2.

¿Voy bien encaminado?

Ese mismo!!

Ah! ¡Ostis! :)

Yo pensaba que el que habia salido a la venta era el Essentials. Es decir que es el "Cookbook": pues no tenia ni puñetera idea. :( Estaba convencido de que era el otro.

Pido disculpas... Me temo, entonces, que habra que esperar. ;)

ozke

Hey erni ;)

El que él dice también es de Moock.
El problema es que el que se ha publicado en España como "para desarrolladores Flash" es en realidad prácticamente calcado al "Cookbook" inglés (mismo animal en portada y creo q todo exactamente ¡ salvo el primer capítulo xD).

Creo que el que Hartum reclama es el básico. El que aquí es "Essentials", como el de AS2.

¿Voy bien encaminado?

Algunos colegas de curro hemos abierto un blog con ejemplos y demás material para Flex y AS3 que creo os puede resultar interesante. Podéis visitarlo en http://blog.coconnut.com

Se agradece Caracool... :)

A ver si nos ponemos manos a la obra. Asi a primera vista, si que parece interesante, si.

Caracool

Algunos colegas de curro hemos abierto un blog con ejemplos y demás material para Flex y AS3 que creo os puede resultar interesante. Podéis visitarlo en http://blog.coconnut.com

'Actionscript 3.0 para desarolladores Flash' no es de Collin Moock...
http://www.agapea.com/ActionScript-3-0-para-desarrolladores-Flash-n659547i.htm
sino pondría su nombre en autores...

ivanv

'Actionscript 3.0 para desarolladores Flash' no es de Collin Moock...
http://www.agapea.com/ActionScript-3-0-para-desarrolladores-Flash-n659547i.htm
sino pondría su nombre en autores...

Si, antes me he equivocado en eso. En cualquier caso... precisamente por no ser el de Moock es el Cookbook y no el Essentials como comentaba. :)

Bueno, a ver si retomo el tema.

Q editor debería usar? (Q usais vosotros?)
- Flash CS3 IDE
- Flex 2 SDK
- FDT
- otro

Básicamente quiero ponerme lo antes posible con AS3 y m molaria 2 cosas:
1) Q los miles de imports se hagan de forma automatica
2) Autocomplementado de codigo como con SEPY + o -
3) Es posible exportar ctrl+intro? (pijada)

Gracias por adelantado :)

FDT > sólo si te gusta Eclipse y pagas la licencia.
FlashDevelop > va bien, y tiene un "auto-import" que yo por cierto deshabilito. Sólo Win ¬¬
Flash IDE > Nunca mais : )

Pq lo tienes desabilitado?

Pues yo el IDE del Flash CS3 como los valientes (o tontos! pero principalmente como los vagos que les da pereza aprenderse otro programa o ir cambiendo entre 2). Eso si, lo inteto tunear un poco con Comandos y tiro mucho de "shortcuts" (cuanta gente sabe que si haces ctrl+f+n se te crea "function(){}?").

ozke

Pq lo tienes desabilitado?

Pues un poco por manía. El otro poco es que juntado con el autocompletar tan agresivo que tiene, acababa importando clases sin darme cuenta.

Y para finalizar, un poco de histeria que paso a relatar aunque alguno diga que parezco Rainman contando cartas. Tengo la manía de importar las clases en cierto orden, me ayuda a ver rápidamente qué estoy utilizando.

- Primero todos los imports de clases de terceros. Por ejemplo XPath, GDispatcher y similares
- Luego todas mis clases que NO son del proyecto. Me refiero a clases comunes, normalmente las guardo en Utils.*
- Por último, todas las clases pertenecientes al proyecto en el que estoy currando.

Evidentemente hay una línea en blanco entre cada una de esas "zonas".

Por cierto, hay 346 letras en este post.

: D

Con el garbage collector de AS3 (o más concretamente, de Flash player 9) ya he tenido algún que otro "roce". Como dice el artículo que citas, la limpieza de las instancias que se han borrado se produce en un futuro próximo, o lejano, pero incierto :-)).
He desarrollado un pequeño juego de puzzle en Flex y creo las piezas con la clase Bitmap, que permite copiar en memoria trozos de una imagen cargada. Cuando genero un nuevo puzzle elimino las piezas del anterior y, en teoría, las piezas antiguas deben desaparecer y liberar la memoria que ocupaban.
El puzzle ( y todo el código fuente, realizado en Flex) lo podéis encontrar aqui:

http://blog.coconnut.com/source/jel/puzzle/

Para comprobar cómo actúa el garbage collector de FP9 basta abrir el Administrador de tareas de Windows (Control Alt Supr) y mostrar la pestaña Rendimiento, a la vez que se van generando puzzles (pulsa el botón "Jugar" de la aplicacion). Verás cómo la memoria no se libera casi nunca cuando pulsas el botón Jugar (es en este momento cuando se eliminan, en teoría, las antiguas piezas), y puede ocurrir que generes varios puzzles sin que el garbage collector libere memoria.
Debería existir alguna forma de "forzar" la limpieza de memoria, sobre todo en aquellas aplicaciones que hacen un uso intensivo de ellas ;-).

Por lo que he leido yo en Moock no puedes forzar que se limpie el garbage collector y será el propio player cuando vea que se está consumiendo mucha memoria quien tomará la iniciativa de borralo.

Eso en teoría implica que no deberíamos preocuparnos por no tener control sobre el garbage... pero claro eso solo en teoría.

tpmmds, al margen de que esté consumiendo mas memoria, ¿tu has visto que el rendimiento se vea afectado de cara a la experiencia de usuario (en caida de fps por ejemplo)?

Sobre lo de forzar el GC mr Grant Skinner debe tener soplones en Adobe, mirad lo que cuenta en Resource Management 3:

<fieldset>This trick can be really handy for exploring Garbage Collection, and testing your applications during development, but it should never be deployed in production code because it can wreak havoc with processor load. It is also officially unsupported, so you cannot rely on it to work in updated versions of the player.</fieldset>

<code>try {
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
} catch (e:*) {}
// the GC will perform a full mark/sweep on the second call.</code>

Y si se puede hacer, por qué no lo permite Adobe de forma oficial? Pues yo diría que su filosofía es:

- Tú programa sin memory leaks.
- Nuestro GC sabe muy bien lo que hacer y hará su trabajo.
- No tenemos bugs : )

Si yo tuviera que utilizar esto, lo encapsularía dentro de un método estático, algo como:

<code>class GCUtils{

public static function ForceGC():Void{
// codigo
}

}</code>

Lo digo porque al ser código no oficial, si manyana deja de funcionar o si pasa a oficial, no hay que andar buscando por todo el código, sólo hay que modificarlo en una clase.

Salud!

Zárate

<div class="quote">
ozke

<blockquote>Pq lo tienes desabilitado?</blockquote>
</div>

Pues un poco por manía. El otro poco es que juntado con el autocompletar tan agresivo que tiene, acababa importando clases sin darme cuenta.

Y para finalizar, un poco de histeria que paso a relatar aunque alguno diga que parezco Rainman contando cartas. Tengo la manía de importar las clases en cierto orden, me ayuda a ver rápidamente qué estoy utilizando.

- Primero todos los imports de clases de terceros. Por ejemplo XPath, GDispatcher y similares
- Luego todas mis clases que NO son del proyecto. Me refiero a clases comunes, normalmente las guardo en Utils.*
- Por último, todas las clases pertenecientes al proyecto en el que estoy currando.

Evidentemente hay una línea en blanco entre cada una de esas "zonas".

Por cierto, hay 346 letras en este post.

: D

No me parece nada raro tío.
Lo único es que mi orden es:
- "Normales"
- "Generales propias"
- "Del proyecto"

Lo de poner las letras del post ya si q me parece friki por eso jajaja

Con la cantidad de memoria que tienen los ordenadores actuales me parece correcto que el GC la amortice, y no la limpie ni continua ni inmediatamente. Recuerdo mi Olivetti "portátil" con 640Kb de memoria. Quizás alguien debería recuperar el término "optimización del código" mejor que estar testeando System.TotalMemory.

El problema real es si al usuario le afecta o no esta limpieza aleatoria, como, cuando y porqué. Es así?

Por otro lado no he visto nunca un código entero sin bugs, o inmejorable, así que esa crítica a Adobe no me parece tan razonable como otras. Sobretodo cuando a demasiados programadores lamentablemente les importa poco que un ordenador se quede colgado por una aplicación mal programada ("mientras sea bonita..."). Los "dead lines" tienen gran parte de la culpa. :D Así que, les das libertad total o intentas proteger el entorno de programación?

El código perfecto es como el crimen perfecto, todos hablan de él pero nadie sabe como es realmente :)

PD: npi de cuantas letras tiene este post :D ni de su interés o utilidad.

Flex Builder: AS3, MXML, debugger, autoimport, autocompletion, memory &amp; performance profiler (versión pro), vista de diseño, editor CSS...

http://www.onflex.org/ted/2007/09/flex-3-beta-2-code-debug-profiler.php
http://www.onflex.org/ted/2007/09/flex-3-beta-2-design-tools-learning.php
http://www.onflex.org/ted/2007/09/flex-3beta-2-crud-wizard-for-aspnet-php.php

A mi parecer bastante más completo en general que FDT 3, que ha tardado demasiado en ver la luz, y te lo dice uno que era defensor acérrimo del FDT para AS2

Llevo usando Flex Builder 2 desde enero, y la beta 2 de FB3 desde que salió, y no hacen más que mejorarlo.

En cuanto al garbage collector, hay que asegurarse que el número de referencias a los objetos que queremos eliminar sea cero, o que todas las referencias que quedan hacia él sean débiles (weak), sino no se borrarán nunca. Un tipo de referencias que no suele borrarse es el de los oyentes de eventos (listeners), por eso en ciertas ocasiones es recomendable usar una referencia débil al objeto que genera el evento, usando el último parámetro del addEventListener.

elSuricatoRojo

tpmmds, al margen de que esté consumiendo mas memoria, ¿tu has visto que el rendimiento se vea afectado de cara a la experiencia de usuario (en caida de fps por ejemplo)?

En la mayoría de aplicaciones no se va a notar, por eso Adobe no se ha tomado mucho interés en optimizar el GC. Pero aquellas que cargan en memoria mucho contenido gráfico sí pueden llegar a saturar el sistema. No es tan raro encontrar ordenadores con menos de 256KB de RAM, y esta cantidad de memoria se puede llenar ràpidamente con sólo poner a true el cacheAsBitmap de todos los movieClip que estemos utilizando.
Además, cuando aplicamos un filtro (como el sombreado, que tan popular se está haciendo últimamente: no hay interactivo en Flash que se precie que no lleve al menos un sombreado :-)), el sistema se encarga de poner cacheAsBitmap = true por nosotros.
Por otro lado, es que soy muy "perro", si hubiera recortado el bitmap antes de enmascarar cada pieza del puzzle, ocuparía menos RAM y ni me hubiera enterado de lo poco eficiente que es el GC ;-).
Por cierto, en aplicaciones que llevan vídeo Flv incorporado (que no lo leen o hacen streaming), también he notado una cierta tendencia al embotamiento de la RAM.
Un saludo.

Zárate

<code>try {
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
} catch (e:*) {}
// the GC will perform a full mark/sweep on the second call.</code>

Y si se puede hacer, por qué no lo permite Adobe de forma oficial? Pues yo diría que su filosofía es:

- Tú programa sin memory leaks.
- Nuestro GC sabe muy bien lo que hacer y hará su trabajo.
- No tenemos bugs : )

Da la impresión de ser un "hallazgo" de un programador, que probando un try/catch, escribió dos veces una conexión local y... sorpresa... descubrió que se lanzaba el GC. No he tenido tiempo de probarlo, pero será lo primero que haga cuando me siente delante de Flex (y no me refiero al colchón). Si realmente provoca una activación del GC, ¡¡¡bienvenido sea!!!, muchas gracias por la información.
Un saludo.

[quote="Athomix"]Con la cantidad de memoria que tienen los ordenadores actuales me parece correcto que el GC la amortice, y no la limpie ni continua ni inmediatamente. Recuerdo mi Olivetti "portátil" con 640Kb de memoria. Quizás alguien debería recuperar el término "optimización del código" mejor que estar testeando System.TotalMemory.

[quote]

El problema, creo, no está en optimizar, o depurar el código al máximo: el GC no va a eliminar toda aquella "basura" que nos hallamos ido olvidando ;-), ya que sólo "recolecta" aquello que nosotros previamente hallamos eliminado con código. Se me ocurre un caso, no demasiado rebuscado que puede saturar el "sistema más pintado":
Imaginemos una aplicación en forma de revista interactiva que muestre páginas con abundantes fotografías y vídeos Flv. Nuestro avezado programador no ha escatimado en líneas de código y elimina las instancias de todos los elementos gráficos de las páginas que ya ha visto el usuario. Si el GC se lanza cada minuto y limpia la RAM, os puedo asegurar que he visto "usuarios" capaces de verse un libro virtual entero en menos de 1 minuto.
Un saludo, y esto es hablar por no estar callado ;-)