ivanmosquera.net » software

Ikuspro es libre.

admin — Mon, 26 Jul 2010 18:52:06 +0000

Ikuspro es el proyecto de fín de carrera que hice en su día en el que aprendí un montón de cosas sin las cuales no se me habría ocurrido empezar el proyecto PFA.

En su día ya comenté un poco de qué iba el tema . Tras eso la cosa terminó en que el proyecto obtuvo matrícula de honor.

A rasgos generales aprendí lo siguiente y por tanto ahora que está liberado puede que sirva a alguien para indagar en estos aspectos:

Implementación de un framework MVC para Swing usando genericidad.
Diseño de interfaces gráficas Swing con soporte para persistencia.
Buenas prácticas Swing: integración con los OS más utilizados, no recarga del hilo de eventos usando workers etc…
Programación concurrente en Java, diseño productor-consumidor.
Separación de una aplicación en dos partes comunicadas mediante sincronización de hilos.
Implementación con ANTLR de un intérprete de un subconjunto de ANSI-C que se comunica con el GUI mediante mensajes XML.
Comunicación entre procesos mediante un API XML.
Dibujado en Canvas con Java2D e integración del mismo con el GUI.

Lo cierto es que fue bastante divertido. Me consta que en EUITI tienen pensado utilizarlo en laboratorios y la idea es que otros alumnos extiendan Ikuspro con nuevas funcionalidades e incluso con nuevos intérpretes.

Gracias a Mikel Villamañe por confiar en mí para implementar la idea.

A continuación el material que usé en la defensa, un pantallazo y el enlace al repositorio en mi github.

Presentacion pfc

View more presentations from ivmos.

Repositorio en GITHUB: http://github.com/ivmos/Ikuspro

Doctest en PHP

admin — Thu, 18 Mar 2010 21:03:55 +0000

Dana prefiere Haskell

Doctest es un módulo de Python que permite incluir tests en los comentarios (en los llamados docstring para ser exactos). Pues bien, existe una implementación para PHP en PEAR.

Para desarrollos rápidos (o ágiles que se dice últimamente), Doctest representa una buena forma de escribir tests debido a que utilizar otras herramientas típicas como PHPUnit o Simpletest requiere una metodología de primero escribir los tests y luego implementar, que está muy bien pero la curva de aprendizaje no es despreciable y tiene más sentido en proyectos de cierto recorrido. En realidad los doctest no se suelen considerar una alternativa a los tests unitarios sino una opción más centrada en la documentación y más sencilla aunque menos potente.

Instalamos la herramienta vía PEAR:

user@computer:$ pear install -f Testing_DocTest

A continuación un ejemplo de un doctest en php.

El doctest se incluye entre unas etiquetas . La salida esperada para que el test sea satisfactorio se escribe tras “// expects:”.





 





/**


 * 



 * mostrarNumeros(3);


 *


 * // expects:


 * //0


 * //11


 * //222


 * //3333


 * 


 *  


 **/


function mostrarNumeros($num) {


   for($i=0;$i<=$num;$i++) {


      for($j=0;$j<=$i;$j++) {


         echo $i;


      }


      echo "\n";


   }


}



Para ejecutar los tests :

user@computer:$ phpdt numeros.php.


Dará como resultado:

user@computer:$ Processing /tmp/numeros.php
[PASS]  function mostrarNumeros

Total time    : 0.0253 sec.
Passed tests  : 1
Skipped tests : 0
Failed tests  : 0


El doctest se suele incluir en la misma cabecera de comentario de phpdoc pero lo he omitido para que quede más claro lo necesario estrictamente para Doctest.
Doctest por defecto sólo considerará que el test ha sido satisfactorio si la salida del script es exactamente la misma que la salida que hemos escrito como esperada pero ¿y si queremos un comportamiento algo más flexible ?
Para ello podemos usar flags que alteren el comportamiento:

NORMALIZE_WHITESPACE: se ignoran los espacios en blanco.
CASE_INSENSITIVE:  ignorar mayúsculas/minúsculas
SKIP: ignorar el test
ELLIPSIS: permitir utilizar el comodín [...]. Útil para los casos en que parte de la salida es variable

A continuación un ejemplo que usa un flag de ELLIPSIS. También sirve para ver que podemos incluir varios tests en la misma cabecera.



 





/** 


 * 



 * // Usamos ELLIPSIS porque hay una parte de la salida que no podemos predecir


 *


 * // flags: ELLIPSIS


 * echo testString();


 * // expects:


 * // Lo siguiente no se puede predecir [...].


 *


 * 


 *


 * 



 * // Este es el mismo test pero lo hacemos para ver que podemos dividir la salida con \


 *


 * // flags: ELLIPSIS


 * echo testString();


 * // expects:


 * // Lo siguiente \


 * // no se puede \


 * // predecir [...].


 *


 * 


 *


 */


function testString()


{


    return sprintf(‘Lo siguiente no se puede predecir %s’, microtime());


}



Si la salida esperada para un test es demasiado grande podemos utilizar “expects-file:” en lugar de “expects :”. El ejemplo de mostrarNumeros quedaría así con expects-file:



 





/**


 * 



 * mostrarNumeros(3);


 *


 * // expects-file: mostrarNumeros.txt


 *


 * 


 * 


 **/


function mostrarNumeros($num) {


   for($i=0;$i<=$num;$i++) {


      for($j=0;$j<=$i;$j++) {


         echo $i;


      }


      echo "\n";


   }


}



En el fichero mostrarNumeros.txt incluiremos la salida en bruto, es decir, sin comentar.
Existe también la posibilidad de incluir todo el test en un fichero externo:



 


 * 



 * // test-file: tests/test1.doctest


 * 


 



Por último, existe la posibilidad de insertar cierto código a interpretar antes que todo lo demás. Esto es útil para establecer variables de entorno o para simular una petición HTTP.



 


/**                                                             


 * This is a file level test.


 *


 * 



 * // setup:


 * // $_ENV['OSTYPE'] = ‘linux’;


 * echo OS_TYPE;


 * // expects:


 * // linux


 * 


 */


define(‘OS_TYPE’, $_ENV[‘OSTYPE’]);


 



Como conclusión, los doctest son una pequeña joya de Python que por suerte ha sido portada también a PHP. Permite incrustar los pequeños scripts que probablemente ya haces para probar tus clases y te obliga a ver tus clases desde el punto de vista del usuario de las mismas, de modo que te ayudará a pensar en si la encapsulación es correcta, en si tiene demasiadas dependencias, en si hace demasiadas cosas etc.. Sirve como complemento a los tests unitarios pero también como iniciación a la escritura de tests.
Se suele decir que el código fácil de testear es propio de un software bien diseñado.
Enlaces:
http://code.google.com/p/testing-doctest/

http://pear.php.net/package/Testing_DocTest

http://en.wikipedia.org/wiki/Doctest

Para ver más ejemplos de uso, lo mejor es ver el fichero de pruebas de Testing-DocTest, disponible en el repositorio:

http://svn.php.net/repository/pear/packages/Testing_DocTest/trunk/tests/test1.php



Las referencias en PHP: qué son y el porqué de no usarlas
admin — Sat, 13 Feb 2010 17:17:45 +0000
elefante
Según un estudio reciente, PHP es actualmente el tercer lenguaje de programación más popular.  Puede sorprender teniendo en cuenta los buenos comentarios que han recibido durante años lenguajes como Ruby y que se daba por seguro el retroceso de PHP.  Yo creo que esto es debido a que la gente que está detrás de PHP ha sabido adaptarse a las nuevas tendencias y responder a tiempo. Dos ejemplos muy significativos:

PHP5
Zend Framework (y otros)



La comunidad “phpera” lejos de quedarse parada ante el adelantamiento por la derecha que parecía que les iba a hacer Ruby/Python/etc han mejorado el lenguaje increíblemente hasta el punto que el diseño OO de PHP tiene poco que envidiar a Java. Me imagino a los desarrolladores allá por el 2003 diciéndo “Dicen que PHP4 no es enterprise-ready, que su OO da asco, vale, tienen razón.”. Y de ahí salió PHP5, miras la lista de cambios entre PHP4 y PHP5, y resulta increíble que sólo les separe un número de versión.  Algo parecido se puede decir de “Zend Framework”: “Ruby on Rails mola mucho, un killer app, hagamos algo parecido”. Y acabó surgiendo Zend Framework, un excelente framework MVC con “total” cobertura de test unitarios y completamente modular. Además, surgieron muchos otros framework que rivalizan con ZF, el “oficial”, creando una competencia absolutamente sana. Se trata de ejemplos como CakePHP, Symfony o CodeIgniter. El último episodio donde se ha demostrado este pragmatismo de los phperos ha sido dejar Zend_Entity y pasar a adoptar el ORM supuestamente de la competencia : Doctrine. Esto contrasta con la gente de Perl que ha dedicado la mayor parte de sus esfuerzos a crear una máquina virtual, académicamente muy interesante pero en la práctica ¿Hay nuevos usuarios de Perl existiendo PHP, Python y Ruby?.
Vale, a estas alturas te estarás preguntando a qué viene el título de esta entrada. Pues bien, todo esto de la actitud pragmática, los grandes avances etc. está muy bien pero existe un problema en PHP si bien en mi opinión es un mal menor: se trata de mantener la compatibilidad hacia atrás. No sólo un mal menor sino además un mal necesario que permite que los desarrolladores vayan adaptándose a los nuevos cambios progresivamente. La opción contraria podría resultar crítica para muchos usuarios, hay pocos casos donde ha sido necesario ese caso extremo, me viene a la cabeza VisualBasic 6 y poco más.
PHP es un lenguaje que empezó con objetivos mucho más modestos, seguramente Rasmus Lerdof ni en sus sueños más húmedos se imaginó que su herramienta evolucionaría hasta soportar sitios de la escala de Facebook. La política en PHP ha sido ir corrigiendo cosas y manteniendo compatibilidad hacia atrás avisando al desarrollador de las malas prácticas mediante warnings. En esta entrada hablaré de porqué no se debe utilizar a día de hoy referencias en PHP.
¿Qué son las referencias? “&”
Las referencias de PHP se parecen en esencia a las referencias (que no punteros) de C++. Son algo parecido a los enlaces duros de UNIX. Se han utilizado mucho en PHP debido a que en PHP4 el diseño OO era bastante distinto.  En POO se trabaja con referencias de objetos en lugar de con los datos directamente debido a que la idea es mandar mensajes a los objetos y que ellos mismos sean los encargados de modificar su propio estado, y para eso basta la referencia del objeto para mandarle mensajes, difícilmente vas a necesitar acceder al objeto en sí mismo.

En PHP4, la implementación OO hacía que fuera necesario utilizar el operador referencia para hacer POO ya que de lo contrario estabas copiando objetos.  También hay que tener en cuenta que hasta hace relativamente poco no se programaba OO en PHP por lo que se asumía que al igual que en C, si quieres trabajar con una estructura de datos muy grande, lo suyo es pasarlo por referencia y así evitar la copia. Esto me lleva a explicar un hecho poco conocido de PHP.
copy-on-write
La práctica de usar paso por referencia por motivos de optimización es equivocada actualmente debido a que PHP hace copy-on-write. Esto consiste en que PHP cuando se pasa por valor (casi siempre), no hace una copia de la variable desde el principio sino que trabajará en realidad con la referencia y hará una copia sólo en el momento en que detecte que vas a intentar modificar. Es decir, tú como programador feliz, estás en el ámbito de la función y con un parámetro por valor, y parece que estás trabajando desde el principio con una copia con lo cual si la estructura de datos es muy grande te puedes ver tentado a pasar por referencia pero es un error debido a que PHP internamente no hace la copia hasta que sea realmente necesario. Vale, pero puedes estar pensando: ¡ pero es que precisamente mi función va a modificar esa estructura y mucho así que se va a hacer esa costosa copia! Bien, el problema subyacente es que no se está pensando suficientemente a lo OO sino más bien proceduralmente.  En PHP5 el modelo de objetos está rediseñado de modo que los objetos se trabajan con referencias como en Java, por lo que deja de ser necesario utilizar el operador referencia para hacer POO. Esto supone que el operador ‘=’ en la práctica es como si copiara sólo para los tipos primitivos mientras que para los objetos copia la referencia. Esta suele ser la típica explicación pero en realidad es errónea, lo cierto es que esta misma mala explicación también se suele dar en Java como simplificación. Lo que ocurre en realidad es que en PHP5 no trabajas con el objeto directamente, trabajas con su referencia, de modo que cuando pasas el objeto por valor, como mucho estarás provocando (copy-on-write) la copia de la referencia pero no del objeto. Si quieres una copia física del objeto lo que necesitarás es clonar el objeto (clone). Puedes utilizar el operador de referencia con objetos también pero resulta innecesario.
Vamos a ver más en profundidad cómo trabaja el intérprete de PHP las variables.

user@computer:$ apt-get source php5-cli.


La estructura de datos que almacena una variable en PHP se llama “zval_struct” (zval entre amigos).  Un “zval” tiene los siguientes campos:

tipo (el tipo de la variable)
valor (el valor de la variable)
is_ref (flag que indica si la variable es una referencia &)
refcount (contador del número de símbolos que apuntan a este zval)

La estructura está definida en zend.h:



struct _zval_struct {


/* Variable information */


zvalue_value value;             /* value */


zend_uint refcount;


zend_uchar type;        /* active type */


zend_uchar is_ref;


};



Un zvalue_value puede ser muchas cosas. Ahí reside la magia del tipado de php. Tenemos en la misma estructura de datos las distintas posibilidades, tanto tipos primitivos como objetos, en Ikuspro realicé una implementación similar sólo que la genericidad de Java facilita mucho las cosas. Los objetos no se almacenan en esta estructura sino que únicamente se guarda el puntero (en PHP-5).



typedef union _zvalue_value {


        long lval;                                      /* long value */


        double dval;                            /* double value */


        struct {


                char *val;


                int len;


        } str;


        HashTable *ht;                          /* hash table value */


        zend_object_value obj;


} zvalue_value;



En PHP4 probablemente el diseño era distinto de manera que en el valor iba directamente el objeto de manera que era necesario usar continuamente el operador referencia para hacer programación orientada a objetos correctamente.
Un zend_object_value es lo siguiente (zend_types.h):



typedef struct _zend_object_value {


        zend_object_handle handle;


        zend_object_handlers *handlers;


} zend_object_value;



El handle es un ID único de entre ese tipo concreto de objetos (no global). El tipo del objeto y su funcionalidad está en esta otra estructura que es encuentra en una tabla. Desde zend_object_value vemos que se apunta con handlers en la entrada adecuada.



typedef struct _zend_object_handlers {


        zend_object_add_ref_t                    add_ref;


        zend_object_del_ref_t                    del_ref;


        zend_object_delete_obj_t                 delete_obj;


        zend_object_clone_obj_t                  clone_obj;


        zend_object_read_property_t              read_property;


        zend_object_write_property_              write_property;


        zend_object_get_property_ptr_t           get_property_ptr;


        zend_object_get_property_zval_ptr_t      get_property_zval_ptr;


        zend_object_get_t                        get;


        zend_object_set_t                        set;


        zend_object_has_property_t               has_property;


        zend_object_unset_property_t             unset_property;


        zend_object_get_properties_t             get_properties;


        zend_object_get_method_t                 get_method;


        zend_object_call_method_t                call_method;


        zend_object_get_constructor_t            get_constructor;


        zend_object_get_class_entry_t            get_class_entry;


        zend_object_get_class_name_t             get_class_name;


        zend_object_compare_t                    compare_objects;


} zend_object_handlers;



Los símbolos (nombres de variables) que apuntan a un zval se guardan en una tabla de símbolos. Normalmente solemos hablar de variables locales, variables globales, ámbitos de variables… Bien, de lo que se trata es que tenemos una tabla de símbolos por ámbito y en PHP el ámbito está unido a las funciones o métodos. En C por ejemplo, es diferente y los ámbitos van unidos a los bloques directamente de modo que tenemos tablas de símbolos por bloques.  Por ejemplo en PHP tenemos:



 


$a = "hola/";


echo $a;


{


          $a = "jaja/";


          echo $a;


}


echo $a;



El resultado será “hola/jaja/jaja/”
En C:



#include 


main() {


 


char *a = "hola/";


printf("%s",a);


 


{


char *a = "jaja/";


printf("%s",a);


}


 


printf("%s",a);


 


}



El resultado es “hola/jaja/hola/”.
Si te parece un detalle de importancia echa un vistazo a este código:



 





$a = "Hola";


echo $a;


 


if ($a == "Hola") {


        $b = "Adios";


}


echo $b;



Este código en C no tiene sentido.
Podemos ver los zval con xdebug_debug_zval

user@computer:$ apt-get install php5-xdebug


Veamos un ejemplo:



 





 


$a = "Hola";


xdebug_debug_zval(‘a’);


$b = 2;


xdebug_debug_zval(‘b’);


$obj = new stdClass();


$obj->atrib1 = "foo";


$obj->atrib2 = "bar";


xdebug_debug_zval(‘obj’);


$obj2 = $obj;


xdebug_debug_zval(‘obj2′);


$obj3 = &$obj;


xdebug_debug_zval(‘obj3′);



El resultado es:
a: (refcount=1, is_ref=0)='Hola'
b: (refcount=1, is_ref=0)=2
obj: (refcount=1, is_ref=0)=class stdClass { public $atrib1 = (refcount=1, is_ref=0)='foo'; public $atrib2 = (refcount=1, is_ref=0)='bar' }
obj2: (refcount=2, is_ref=0)=class stdClass { public $atrib1 = (refcount=1, is_ref=0)='foo'; public $atrib2 = (refcount=1, is_ref=0)='bar' }
obj3: (refcount=2, is_ref=1)=class stdClass { public $atrib1 = (refcount=1, is_ref=0)='foo'; public $atrib2 = (refcount=1, is_ref=0)='bar' }
Como puedes ver el único con is_ref=1 es la variable referencia. Un zval se elmina cuando refcount pasa a ser cero y esas referencias van desaparenciendo a medida que se van resolviendo los ámbitos. Es decir, si hemos creado un zval dentro de una función (localmente) tendremos en principio símbolos pertenecientes a la tabla de símbolos de esa función. Al terminar la función ese zval pasará a tener 0 de refcount y por tanto se podrá liberar. Se suele decir que la función unset() de php destruye objetos pero creo que eso no es cierto.  Un ejempo:



$orig = 4;


 


$a = $orig;


xdebug_debug_zval(‘a’);


$b = &$a;


xdebug_debug_zval(‘a’);


unset($a);


xdebug_debug_zval(‘b’);


echo $b ."\n";


$obj = new stdClass;


$obj->foo = "bar";


$obj2 = &$obj;


xdebug_debug_zval(‘obj’);


unset($obj);


xdebug_debug_zval(‘obj2′);


echo $obj2->foo ."\n";



El resultado es:
a: (refcount=2, is_ref=0)=4
a: (refcount=2, is_ref=1)=4
b: (refcount=1, is_ref=0)=4
4
obj: (refcount=2, is_ref=1)=class stdClass { public $foo = (refcount=1, is_ref=0)='bar' }
obj2: (refcount=1, is_ref=0)=class stdClass { public $foo = (refcount=1, is_ref=0)='bar' }
bar
Como podemos ver lo que hace unset en realidad es disminuir el número del contador.  Por último un ejemplo en el que pasamos la referencia de un objeto con lo cual hacemos que deje de apuntar a un objeto y pase a ser un string (tipo primitivo):



 





 


function lafuncion(stdClass &$obj) {


        $obj = "Sorpresa";


}


 


$a = new stdClass();


$a->foo = "bar";


xdebug_debug_zval(‘a’);


lafuncion(&$a);


xdebug_debug_zval(‘a’);



El resultado es:
a: (refcount=1, is_ref=0)=class stdClass { public $foo = (refcount=1, is_ref=0)='bar' }
a: (refcount=1, is_ref=0)='Sorpresa'
Como conclusión: no merece la pena trabajar con el operador referencia si estamos haciendo POO, lo único que vamos a conseguir es liar el código y provocar bugs, los punteros y referencias no están al nivel de abstracción que solemos manejar en nuestra vida diaria mientras que los objetos, atributos y métodos sí. Desgraciadamente existe mucho código “legacy” que hace uso intensivo de pasos por referencia, incluyendo algunas funciones de ordenación de PHP. Una opción para convertir esas funciones es sustituir los parámetros por referencia por un objeto stdClass que los encapsule pasado por valor.
Links:
Para escribir este post me he basado en el código citado del intérprete de PHP y en los siguientes enlaces. Si crees que he cometido algún error pon un comentario, estaré encantado en aprender:
http://php.net/manual/en/features.gc.refcounting-basics.php
http://schlueters.de/blog/archives/125-Do-not-use-PHP-references.html
http://blog.libssh2.org/index.php?/archives/51-Youre-being-lied-to..html



Desarrollo para Plataforma Flash en Linux: Minibuilder
admin — Sat, 26 Dec 2009 16:53:18 +0000
Desde hace un tiempo Adobe ya no desarrolla Flash/Flex Builder para Linux. Una alternativa libre prometedora que he encontrado es Minibuilder. Se trata de un editor que utiliza la tecnología Adobe Air.


flash platform
Veamos a continuación los pasos necesarios para desarrollar en Linux para plataforma Flash con esta herramienta:


1. Instalamos Adobe AIR : (Fuente:  http://www.sizlopedia.com/2008/04/06/how-to-install-adobe-air-on-ubuntu/ )

user@computer:$ wget http://airdownload.adobe.com/air/lin/download/1.5/AdobeAIRInstaller.bin



user@computer:$ chmod +x AdobeAIRInstaller.bin



user@computer:$ ./AdobeAIRInstaller.bin


Si aún habiendo instalado las dependencias tiene problemas para hacer funcionar Adobe AIR con 64 bits, con un error como el siguiente: Error loading the runtime (libnss3.so: wrong ELF class: ELFCLASS64)

Los pasos que le pueden faltar son:



$ cd /usr/lib32/

$sudo ln -s /emul/ia32-linux/usr/lib/libnss3.so .

$sudo ln -s /emul/ia32-linux/usr/lib/libssl3.so .

$sudo ln -s /emul/ia32-linux/usr/lib/libsmime3.so .

$sudo ln -s /emul/ia32-linux/usr/lib/libnspr4.so .

$sudo ln -s /emul/ia32-linux/usr/lib/libnssutil3.so.1d .

$sudo ln -s /emul/ia32-linux/usr/lib/libplc4.so.0d .

$sudo ln -s /emul/ia32-linux/usr/lib/libplds4.so .

$sudo ln -s /emul/ia32-linux/usr/lib/libplds4.so.0d libplds4.so.0d


2. Instalar Java

user@computer:$ apt-get install sun-java-jre


3. Instalar Flex 3.5 ( URL : http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3 )
Descomprimir en algún sitio
4. Descargar minibuilder: (URL :  http://minibuilder.googlecode.com/files/AirMiniBuilder-1.0-alpha-3.air )

user@computer:$ Adobe\ AIR\ Application\ Installer /$RUTA_ABSOLUTA/AirMiniBuilder-1.0-alpha-3.air


5. Tras la instalación de minibuilder, éste se iniciará. Veremos que nos pide ejecutar un tal MBCompiler, la ruta al script figurará en la última línea de la ventana.

En mi caso : /opt/AirMiniBuilder/share/MBCompiler/start

Supongo que Minibuilder no hace ese trabajo por nosotros debido a algún tipo de limitación del sandbox de Air.
Teniendo ejecutado MBCompiler podemos hacer click en “Check again” y desaparecerá la advertencia.

También tenemos que especificar la ruta  a flex en el cuadro “SDK Path”.
Y ya está. Ya podemos empezar a utilizar de Minibuilder. Empezaremos con un pequeño proyecto para el Flash Player.
Utilizamos la pestaña “Create New Project“:
Minibuilder
Elegimos:

Project target : “Flash Player AS3”
Vemos que soporta dos frameworks : Flex y AsWing. Nosotros por ahora sólo usaremos Flex.

Activamos “Add (some) Flex support”
Como project name lo que queramos, en mi caso “hola mundo”.
Ese texto inicial que veremos se trata de MXML, un lenguaje de marcado que facilita el uso del framework Flex.
Editor Minibuilder
Hacemos click en “Compile and Quickrun”. Veremos que tarda su tiempo en compilar el SWF, años luz de la rapidez de MTASC o Haxe.

No veremos nada cuando no debería ser así. Sospecho que puede ser porque mi distribución Linux utiliza SWFDEC por defecto en lugar del player de flash Adobe. El swf lo podemos encontrar en la carpeta bin-debug, con lo cual podremos ejecutarlo manualmente.
Veremos que aparecen unos botones (“AAA”,”BBB”…) es debido a que se está utilizando la clase “Application.as” predefinida por Minibuilder que incluye esos botones en tabs.
Ahora ya es cuestión de aprender Flex. Como pistas para alguien que venga de MTASC decir que las clases Flash que se solían utilizar anteriormente, en la documentación están en el API de Flash Player.
Así que para jugar por un lado tenemos los controles del framework Flex: http://livedocs.adobe.com/flex/3/html/help.html?content=controls_01.html y por otro lado tenemos el API de Flash Player, el cual ya nos resultará familiar al haberlo utilizado con MTASC , Haxe o Flash Studio:
http://livedocs.adobe.com/flex/3/html/help.html?content=Part3_Flash_Player_APIs_1.html
Podemos utilizar ambas cosas sin problemas. En el siguiente ejemplo, se utiliza NetStream y Netconnection en lugar del control VideoDisplay de Flex, pero eso no quita para que los botones a utilizar puedan ser controles Flex:
http://blog.flexexamples.com/2008/03/01/displaying-a-video-in-flex-using-the-netconnection-netstream-and-video-classes/
Vemos que en ese ejemplo el código Actionscript se encuentra incrustado en el MXML. No tiene porqué ser así y de hecho yo no creo que sea una buena práctica. El ejemplo de Minibuilder utiliza una clase independiente para el código (Application.as). De todos modos, ya hablaremos en otro post sobre buenas prácticas, patrones y otras librerías.
Entonces como conclusión. ¿Qué ofrece Minibuilder en cuanto a facilitar el desarrollo para plataforma Flash?
Resaltado y autocompletado AS3, así como compilación amigable de SWF incluyendo gestión de los namespaces.





    
        
    

    
        
        
            
            
        
    






Probando Haxe
admin — Mon, 02 Nov 2009 20:07:05 +0000
Haxe es el sucesor de MTASC, pero no se limita a tener como objetivo la tecnología flash sino que también genera Javascript, PHP y otros. Además, se acompaña de una máquina virtual, Neko, que le sirve para la ejecución en servidor. Yo personalmente creo que es un proyecto que está intentando abarcar demasiado pero hay varios puntos que me han animado a probarlo:

Las nuevas funcionalidades y rendimiento mejorado de AVM2 (máquina virtual en las últimas versiones de Flash).
El lenguaje de Haxe es mejor que ActionScript.
La posibilidad de portar aplicaciones flash a plataforma nativa fácilmente. Esto se está utilizando por ejemplo para aplicaciones iPhone.



A continuación los pasos necesarios para la instalación y un par de ejemplos de Haxe contra Flash y CPP usando el mismo código:

La instalación en Debian (testing) es sencilla:

user@computer:$ apt-get install haxe
apt-get install neko


Si no está disponible en tu distribución o se trata de versiones no actualizadas, una buena opción puede ser utilizar el instalador estándar de haxe para Linux y los siguientes pasos seguirán siendo los mismos.
Instalado Haxe y Neko, hacemos:

user@computer:$ mkdir -p /usr/lib/haxe/lib/
haxelib setup


Instalaremos hxcpp para hacer alguna prueba.

user@computer:$ haxelib install hxcpp


Instalamos el fichero de sintaxis de Haxe para Vim:

user@computer:$ wget http://tech.motion-twin.com/zip/haxe.vim && cp haxe.vim /usr/share/vim/vim72/syntax/


Añadimos lo siguiente en nuestro .vimrc

" Haxe

au BufNewFile,BufRead *.hx                setf haxe

Ya estamos listos para probar un “hola mundo”:


class Hola {

static function main() {

trace("Hola mundo");

}


Compilamos a  swf con

user@computer:$ haxe -swf9 salida.swf -main Hola


Podemos abrir el swf directamente con el navegador y deberíamos ver el trace. La función trace de Haxe se dibuja directamente, algo muy práctico la verdad.
Ahora vamos a compilar el mismo fichero a código nativo. Veremos que lo que hace Hxcpp es traducir nuestro fichero fuente en Haxe a código C++. Si falla es probable que sea porque nos falta algún paquete C++, podemos servirnos de apt-file para localizarlos.
Vemos que él mismo se encarga de invocar al compilador C++ con los parámetros adecuados así que nosotros obtenemos el resultado final simplemente con la línea de haxe.
El resultado estará en la carpeta “salida”. Ahí encontraremos nuestro ejecutable ELF (“Hola”) y las carpetas “include”, “obj” y “src”.

user@computer:$ ./Hola
Hola.hx:3: Hola mundo


Echamos un vistazo a las librerías de las que depende nuestro ejecutable:

user@computer:$ ldd Hola
linux-gate.so.1 =>  (0xb80d6000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb80ad000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb80a9000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7fb6000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7f90000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7f65000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7e06000)
/lib/ld-linux.so.2 (0xb80d7000)


Vemos que no depende de nada extraño, es decir, neko o similar.
Muy bien pero esto se queda un poco pobre tratándose de un simple trace así que vamos a probar algo más. Para ello necesitaremos instalar una librería más. Con Haxe podremos programar contra el API de Flash y generar CPP gracias al wrapper de SDL que implementa NME.

user@computer:$ haxelib install neash


Verás que él mismo baja de internet los ficheros necesarios y configura la instalación por lo que al parecer haxelib viene a ser algo parecido a CPAN o PEAR.
El código fuente del nuevo fichero que vamos a probar es el siguiente:



import flash.events.MouseEvent;


import flash.events.Event;


import flash.display.MovieClip;


 


class Prueba {


 


     private var mc: flash.display.MovieClip;


     private var square: flash.display.MovieClip;


     function new() {


         mc = flash.Lib.current;


         drawSquare(0xAFAFF0,50,50);


         mc.stage.addEventListener(MouseEvent.MOUSE_DOWN, onPress);


     }


 


     private function drawSquare(pColor:Int,pStartX:Int,pStartY:Int):Void {


         square = new MovieClip();


         square.graphics.beginFill (pColor);


         square.graphics.moveTo (pStartX,pStartY);


         square.graphics.lineTo (100,50);


         square.graphics.lineTo (100,100);


         square.graphics.lineTo (50,100);


         square.graphics.endFill ();


         mc.addChild(square);


 


     }


 


     static function main() {


        #if cpp


        neash.Lib.mOpenGL = true;


        neash.Lib.Init("Prueba",320,200);


        neash.Lib.SetBackgroundColour(0xFFFFFF);


        #end


        var prueba:Prueba = new Prueba();


        #if cpp


        neash.Lib.ShowFPS();


        neash.Lib.Run();


        #end


 


     }


 


     function onPress(event:MouseEvent) {


        trace("Yepa!!");


        square.x += 4;


     }


 


}



Al igual que antes, primero probamos con flash:

user@computer:$ haxe  -swf prueba.swf -swf-version 10 -main Prueba




Y ahora a código nativo:

user@computer:$ haxe -cpp salida_prueba --remap flash:neash -lib neash -main Prueba -cp /usr/lib/haxe/lib/neash/1,0,1/neash/


Vemos que en este caso ha sido necesario directiva de precompilación y decirle a haxe que sustituya las ocurrencias de flash por neash.
Por ahora la sensación que me da es que Haxe como plataforma open source para Flash ya es estable, pudiendo sustituir a MTASC perfectamente pero en cuanto a CPP la cosa puede estar demasiado verde como para cosas serias.



Ikuspro en beta
admin — Fri, 02 Oct 2009 17:57:07 +0000
Ikuspro es el nombre del software que he desarrollado para mi PFC.  Se trata de un simulador gráfico de programas.

La idea del proyecto es de mi director de PFC que es profesor del departamento de LSI de EUITI-BI e imparte clases de “Fundamentos de Informática” por lo que pensó que una herramienta de este tipo podría ser útil para quien se enfrenta por primera vez a la metodología de programación.

Con Ikuspro la ejecución de los programas se hace visual y gracias a ello se alivia un poco la sensación de abstracción que suele inspirar la programación. Es algo parecido a lo que ocurre con Logo, aquella tortuga que hacíamos mover por toda la pantalla sin darnos cuenta de que estábamos programando por primera vez.
De todos modos lo mejor es que ponga un ejemplo. Este código por ejemplo:

Como puedes ver este código es C.
Ikuspro en la versión actual incluye un intérprete de C que he desarrollado con el objetivo de que puedan funcionar los ejercicios utilizados en la asignatura de “Fundamentos de Informática”. Este ejemplo es muy sencillo para no recargar esta entrada pero el intérprete de C de Ikuspro es bastante más avanzado soportando funciones, arrays, condicionales, bucles e incluso punteros parcialmente.
Hablo del intérprete como algo independiente de Ikuspro ya que una parte interesante del proyecto es que Ikuspro está pensado en realidad como un simulador gráfico que se puede extender en el futuro con nuevos intérpretes para otros lenguajes sin mayor dificultad. Siendo un poco más técnicos, lo que hace Ikuspro es ejecutar el intérprete adecuado para el tipo de programa en un hilo independiente comunicándose ambos como productor-consumidor vía mensajes XML.
A continuación la simulación gráfica que genera Ikuspro al término de este programa y digo al término ya que con Ikuspro se va viendo la ejecución del programa línea a línea, en realidad como si de un debugger se tratara sólo que mucho más fácil y sobre todo didáctico para el usuario objetivo.

Además, Ikuspro también genera comentarios didácticos acerca de lo que va sucediéndo línea a línea y muestra la salida estándar del intérprete, que es fiel a lo esperable.

A continuación un pantallazo de Ikuspro donde puedes ver las diferentes partes y hacerte una idea del funcionamiento del mismo:

Enlace a imágen ampliada
Ikuspro está desarrollado enteramente en Java. El intérprete C que incorpora se ha desarrollado con ANTLR.
Por último, el título de esta entrada es “Ikuspro en beta” porque esta semana he terminado de realizar mis pruebas así que está listo para realizar pruebas con usuarios. Ikuspro actualmente está numerado como 0.9 en lugar de 1.0 para dar cabida a alguna idea interesante y factible que pueda surgir en las pruebas con usuarios.
Si has llegado a leer hasta aquí y te gustaría probar Ikuspro:
Página web provisional del proyecto Ikuspro



Editores UML gratuitos
admin — Wed, 22 Apr 2009 19:42:32 +0000
Aquí mantendré una lista comparativa de software gratuito para edición de diagramas UML. El prerrequisito para que el software sea incluido en la lista es la gratuidad excluyéndose licencias temporales y similares.

diagramas_uml

 

Además, daré especial importancia a los siguientes aspectos de modo que problemas relacionados con los mismos supondrán directamente una desventaja pero su cumplimiento no se mencionará como ventaja:

UML 2
Soporte como mínimo de los siguientes lenguajes de programación: Java, C#, Python.
Utilizable en cualquier tipo de proyecto, sea comercial o no por ejemplo.
Ingeniería inversa (capacidad de generar diagramas o modelos desde código fuente)
Binario disponible para Linux y Windows, de forma nativa o por ser multiplataforma.

Visual Paradigm Community Edition
http://www.visual-paradigm.com/product/vpuml/communityedition.jsp
Ventajas:

Buena integración con IDEs.
Incluye localización en castellano.
Muy personalizable.
Soporta muchos más lenguajes de programación.

Desventajas:

No permite su uso en proyectos comerciales e incluye marca de agua recordando este hecho.
Muestra muchas otras funcionalidades no disponibles como gancho para las versiones de pago.

ArgoUML
http://argouml.tigris.org/
Ventajas:

Es software libre.
Soporta PHP.

Desventajas:

UML 1.4

StarUML
http://staruml.sourceforge.net/en/
Ventajas:

Es software libre.
Muy personalizable.

Desventajas:

Problemas con la ingeniería inversa si hay caracteres locales, tildes por ejemplo.
Sin versión para Linux aunque puede funcionar con Wine. www.tadicho.com/?p=154

UMLET
http://www.umlet.com
Ventajas:

Es software libre.
Buena integración con Eclipse.
Permite edición sólo con texto (sin usar el ratón).

Desventajas:

Sin ingeniería inversa.

JUDE COMMUNITY
http://jude.change-vision.com/jude-web/product/community.html
Ventajas:

Buena personalización.

Desventajas:

Soporte incompleto UML 2

BOUML
http://bouml.free.fr/
Ventajas:

Muy rápido.
Soporte PHP.
Es software libre.
Ingeniería inversa por encima de la media.

Desventajas:

Muy poco intuitivo, curva aprendizaje grande.

Umbrello
http://uml.sourceforge.net/
Ventajas:

Es software libre.

Desventajas:

Sin binario actualizado para Windows.

www.websequencediagrams.com
http://www.websequencediagrams.com
Ventajas:

Muy ágil y cómodo, diferentes estilos de presentación.
Herramienta web, no requiere instalación.
Permite edición sólo con texto (sin usar el ratón).

Desventajas:

Herramienta web, necesitas estar conectado.
Sólo soporta diagramas de secuencia.

yuml.me
http://yuml.me/
Ventajas:

Herramienta web, no requiere instalación.
Muy ágil y cómodo.
Permite edición sólo con texto (sin usar el ratón).

Desventajas:

Herramienta web, necesitas estar conectado.
Ciertos problemas con caracteres locales.
No soporta diagramas de secuencia.

Nota: Websequencediagrams.com y yuml.me juntos sí que conforman una solución completa de UML. Lo que ocurre es que son proyectos distintos, diferentes autores, y por tanto no tiene sentido analizarlos en conjunto.