viernes, 14 de diciembre de 2007

Interaccion de Flex con datos externos

Empiezo este tema hablando lo negativo... Flex no tiene acceso directo a bases de datos.

Y la respuesta inicial de muchos:

Como???? Entonces de que me va a servir a mi o a mis clientes, si lo más importante de sus aplicaciones es la información, que generalmente se guarda en una Base de Datos??? Mejor me quedo con mi lenguaje web que me permite conectarme con la base de datos desde la misma página que esta cargando el usuario (por que para muchos esa es la mejor manera de hacerlo...)
Si Flex no tiene acceso directo a base de datos, como entonces puedo acceder a mi informacion?

Funcionalidad Flex

Flex fue hecho para funcionar como una interfaz de interacción de un usuario con un determinado sistema. Razón suficiente para preocuparse en brindarle al programador los recursos necesarios para realizar una experiencia totalmente distinta a la de sitios con el tradicional HTML.

Ahora, lógicamente que para interactuar con un sistema, se debe de tratar con datos. La datos es lo más importante en un sistema y de que sirve interactuar con alguien si no le responde a uno nada...? Se hace necesario el uso de un Backend que se encargue de manipular la informacion y transmitirla a la aplicación en Flex.

Ocupo programar en algún lenguaje especial para que funcion esto?

El acceso a datos desde Flex es totalmente independiente del lenguaje en que se programe en el backend. Puede hacerse en Java, Cold Fusion, PHP, Ruby, .NEt, lo que usted se imagine ya que provee varias maneras distintas de accesar la información.

Métodos Básicos

HTTPService: Permite acceder a la un archivo "hosteado" en un servidor. Se puede acceder a información en el mismo servidor o en otro. Esto permite realizar peticiones tipo REST a un servidor, ya que permite el envio de Parametros en el request, pero además permite la manipulación del resultado que esa página produzca... todo por medio de llamadas asincrónimas. Permite no solo la invocación a HTML plano, sino tambien a archivos generados dinámicamente en PHP, JSP, ASP, etc, devolviendo estos el resultado en la forma en que quieran y que el programador pueda interpretar más facilmente. Lo general es devolver el resultado en formato XML. El Actionscript 3 provee una forma muuuuuuy sencilla de manipular el XML (E4X), pero eso se merece otro post aparte

Ejemplo:

<mx:httpservice id="httpLogin" destination="http://127.0.0.1/login.php" result="resultHandler(event)" fault="faultHandler(event)">

</mx:httpservice>

Esto es:
id ==> Nombre con que se manejara el servicio en el MXML y en el Actionscript
destination ==> Direccion del recurso que se quiere accesar. Puede ser incluso un archivo XML directamente
result ==> nombre de la función en actionscript que se encargara de manipular la información que devolver el script login.php (en este ejemplo)
fault ==> nombre de la función en actionscript que se encargara en caso de que el llamado falle, de hacer lo que el programador desee (mostrar mensaje o lo que sea)

Todavía no hemos invocado a la pagina, solo tenemos la definicion del servicio... Esta definicion se puede hacer tambien por actionscript.

Continuamos con el ejemplo:

<mx:script>
<!--[CDATA[
//Funcion que invocara el servicio
public function invocarLogin():void {
//Uso de Token
var call:AsyncToken = MyService.send();
//Hasta aqui se hace la invocacion a la página
call.marker = "login";
}
//Manejo de resultado
private function resultHandler(event:ResultEvent):void {
var call:object = event.token
if (call.marker == "login") {
//manipular informacion a través de: event.result;
trace(event.result) //imprime el resultado enviao por la pagina
}
}
//Manejo en caso de falla
private function faultHandler(event:FaultEvent):void {
Alert.show(event.fault);
}
]]-->
</mx:script>

<mx:remoteobject id="ro_tasklist" destination="TasklistService" result="onROResult(event)" fault="onROFault(event)" showbusycursor="true">
</mx:remoteobject>
Precaución: Al igual que con Ajax y con otras aplicaciones que se ejecutan en el cliente, el acceso a recursos que se encuentren en un servidor distinto al en que se descarga la aplicación flex, esta prohibido. Las reglas para acceso a recursos de un proveedor externo están restringidos por motivos de seguridad. Sin embargo una manera de evitar este problema, es utilizando un "proxy". Por ejemplo (un poco cavernicola...) tengo mi aplicacion flex en miserver.com que lee los feeds de un RSS localizado en CNN.com, puedo crear un archivo en mi servidor (el proxy) php, jsp, asp, o lo que quiera que se encargue de leer el contenido en CNN.com y se lo devuelva a mi flex...

RemoteObject: Mi favorito....este es definitivamentelo que hizo que me enamorara del Flex. Es totalmente RPC (remote procedure calls). Funciona en palabras simples asi:
Se tiene un backend creado en X lenguaje, en servidor se tiene una configuración especial para ese lenguaje y el Flex a través de esa configuración puede acceder a los métodos de las clases definidas en la configuración, pasando objetos como parametros y recibiendo objetos como resultados (literalmente objetos, nada de XML ni eso). Esto a través del protocolo AMF, que lo que haces serializar los objetos y mandarlos sea al servidor o al cliente para su respectiva deserialiazación y manipulación. El AMF serializa estos objetos en formato binario, osea es mucho más rápido (mucho más y sino lo cree, corra este ejemplo de James Ward: http://www.jamesward.org/blazebench/) y los manda encapsulados y comprimidos en un metodo POST por http (no teniendo problemas con proxies ni firewalls). No tienen que ser solamente un objeto a la vez, puede enviar colecciones de objetos (Arrays, listas, etc)
Algo bueno es que acaba de ser abierto por Adobe, lo que permitirá que otras personas intenten mejorarlo o darle nuevas aplicaciones...
RemoteObject es asincronimo tambien y hay que manejar tambien el Resultado o la Falla como en el HTTP Service.
Inicialmente funcionaban solamente con Java y ColdFusion (adobe provee librerias para configurar los servicios) sin embargo ya existen las librerias necesarias para configurar en otros lenguajes, ejemplo PHP --> amfphp, Ruby --> rubyamf, WEBORB, AMF.NET --> .NET entre otros.
Ejemplo:

Suponga que tenga una aplicación que tiene un metodo para crear usuarios llamado creaUsuario y que recibe un parametro de tipo Usuario (una clase) con nombre, username y password.

En actionscript, define su clase llamada Usuario también, con las propiedades nombre, username y password, esta clase es un mapeo de la clase Usuario en el server.
Algo asi:

package com.sitio.clases
{
//RemoteClass especifica a que clase en el server va a asemejarse esta. Apunta al mismo folder donde se encuentra la clase pero en el server.
[RemoteClass (alias="com.sitio.clases.Usuario")]
public class Usuario
{
public var nombre:String;
public var username:String;
public var password:String;
}
}

En el MXML (o en Actionscript tambien) se definira el RemoteObject

<mx:remoteobject id="ro_usuario" destination="ServicioEnServidor" result="resultHandler(event)" fault="faultHandler(event)" showbusycursor="true">
</mx:remoteobject>

Esto es:
id ==> Nombre con que se manejara el servicio en el MXML y en el Actionscript
destination ==> Nombre del Servicio o Clase que se configuro en el servidor para ser accesado por el Flex
result ==> nombre de la función en actionscript que se encargara de manipular la información que devolvera el método
fault ==> nombre de la función en actionscript que se encargara en caso de que el llamado falle, de hacer lo que el programador desee (mostrar mensaje o lo que sea)
showBusyCursor ==> Muestra un cursor con un relojito, mientras se hace el request...mas estetico que otra cosa

Todavía no hemos invocado al metodo, solo tenemos la definicion del remote object... Esta definicion se puede hacer tambien por actionscript.
Además en su aplicacion tiene un boton, que cuando sera presionado invocara a una funcion que preprara el usuario e invocara el metodo en el server:

<mx:button label="Add Item" id="submit" click="enviarForm()"/>

El Script:
<mx:script>
<!--[CDATA[
//Funcion que invocara el servicio, ejecutada cuando se apreta boton
public function enviarForm():void {
//Creacion de un objeto en AS3 de tipo usuario, que sera transmitido al server
var usuario:User = new Usuario();
usuario.nombre = "Mi Nombre";
usuario.username = "username";
usuario.password = "password";
//Uso de Token
var call:AsyncToken = ro_usuario.creaUsuario(usuario);
//Hasta aqui se hace la invocacion al metodo, pasandose de parametro el usuario creado
call.marker = "crearusuario";
}
//Manejo de resultado
private function resultHandler(event:ResultEvent):void {
var call:object = event.token
if (call.marker == "crearusuario") {
//manipular informacion a través de: event.result;
trace(event.result) //imprime el resultado del metodo
}
}
//Manejo en caso de falla
private function faultHandler(event:FaultEvent):void {
Alert.show(event.fault);
}
]]-->
</mx:script>

De verdad.. si está pensando en iniciar una aplicación en Flex con acceso a datos en el servidor, considere seriamente esta opción pues es mucho más facil que las demás...

WEBService: Permite acceder a información por medio de SOAP. Utiliza la especificación WSDL 1.1. Este método en realidad no lo he usado. Sin embargo está disponible y funciona igualmente con llamadas asincrónimas, haciendo que el programador maneje las funciones de resultado y de falla igual como el HTTP Service. Existen ya varias aplicaciones que utilizan de este medio, por ejemplo Yahoo ofrece varios de sus servicios para desarrolladores en Flex por medio de Web Services, como en los mapas o el clima: http://developer.yahoo.com/flash/astra-webapis/ (ellos "wrappean" los llamados a los servicios desde sus librerías)

Esto por ahora en cuanto a interaccion con datos...
Saludos

martes, 11 de diciembre de 2007

Japón, nuestro segundo barrio

Sin duda alguna las agencias de publicidad están empezando a reconocer la influencia del internet.
Debido a la participación de Boca Juniors en el mundial de Japón, Nike sacó una campaña que se llama "Japón, nuestro segundo barrio" y como forma de exponer su campaña decidieron cambiarle la cara completa a la página web del diario Ole en Argentina (no sé si lo hicieron con otros) que es un períodico totalmente deportivo.
Todos los titulares de las noticias fueron puestos en Japonés (o quiero pensar que se tomaron la molestia de traducirlos en verdad, aunque estoy casi seguro que sí)
A continuación un screenshot... me parece una idea genial y una excelente forma de mercadear a través del internet, ojala otras personas vean esto, agarren ideas de genios como los que están detrás de esto...

lunes, 10 de diciembre de 2007

Llamadas Asincrónicas

Tecnologías como Flex, Ajax, .NET entre otras, hacen uso de lo que se conoce como comunicación asincrónica. Esto es: llamadas a un cierto servicio en las cuales no sabemos cuando se recibirá la respuesta. Hay mucho factores que pueden modificar el tiempo de respuesta de un servicio, como puede ser la carga en el server, bandwidth del cliente, entre otros...
En comunicaciones sincronizadas, la aplicación no continuará trabajando hasta que reciba una respuesta a la petición hecha, en una aplicación asincrónica no.
Pensando en este ambiente, planteo la siguiente situación que se puede presentar en cualquier tecnología asincrónima:

Se tienen dos botones, que se conectan a un mismo servicio (archivo XML, un script PHP, ASP, JSP, un webservice o lo que sea) pero que hacen distintas funciones, se presiona uno primero y medio segundo después el segundo... En la forma en que se programa asincrónimamente, no sabemos cual respuesta va a llegar primero, puede ser la del segundo boton y después la respuesta del primero. Si nos ponemos a programar y pensar "sincronizadamente", esperaríamos la primer respuesta y luego la segunda y esto puede ocasionar problemas en nuestras aplicaciones ya que si el orden es distinto la forma en que se manejará la respuesta variará el procesamiento de la respuesta recibida y por lo tanto el funcionamiento normal de la aplicación.

Solución en Flex

El AsyncToken es una clase usada para manejar llamadas asincronicas... Es aplicable con lo que se conoce como el ACT Pattern o Asyncronous Completition Token. Este patrón se encarga de procesar la acción indicada a la respuesta recibida a una llamada asincrónima. Esto quiere decir que la llamada realizada por el boton 2, no procesara la acción a la respuesta del llamado del botón 1 aunque llegase primero... sino solamente la que esta relacionada con su llamada.

Las funciones principales del AsyncToken son agregar información que puede ser util para identificar la llamada... y permitir definir quien se encargara de procesar los resultados(y sus fallas en caso que hayan).

Como ejemplo para el primer caso que mencione antes (identificacion de quien hizo una llamada), al trabajar asincronimamente no sabemos cuando iremos a recibir el resultado, en el ejemplo anterior de los botones que se conectan a un mismo remote object pero hacen distintas funciones, se presiona el primero e inmediatamente el segundo.. como va a saber el Result Handler cual de los dos llamados fue invocado? El ASyncToken nos permite agregar cierta informacion que permitira marcar cada llamada y asi se sabra como procesar cada
informacion.... Este token sera agregado al llamado, así que cuando se reciba información el token va a ir pegado con el evento resultado.
Por ejemplo (muy basico) utilizando una "bandera" en el token, que se llamará marker:

//Ejecutado cuando se presiona Boton 1.
private function llamada1():void{
var token:AsyncToken = remote_object.agregarUsuario(instancia_usuario);
token.marker= "agregarUsuario";
}

//Ejecutado cuando se presiona Boton 2.
private function llamada2():void{
var token:AsyncToken = remote_object.modificarUsuario(instancia_usuario);
token.marker= "modificarUsuario";
}

private function resultHandler(event:ResultEvent):void{
var token:Object = event.token;//se carga desde el evento, el token que se instanció en cada función
if(token.marker == "agregarUsuario"){

//codigo para manipular resultado cuando se agrega usuario

}else if(token.marker == "modificarUsuario"){

//Codigo para manipular resultado de modificar usuario...

}
}

Ya en Cairngorm especificamente, en el delegate se utiliza esta funcionalidad, ya que permite asignar quien se encargara de procesar los resultados de una llamada a servicio externo. Generalmente en la comunidad de flex, se le encarga esa responsabilidad a los comandos, por eso los comandos con llamados a datos externos (remote objects, web services o http services) generalmente implementan la interfaz IResponder, que expone los servicios: result(en caso de resultado satisfactorio) y fault (en caso de error). Lo que permite concretamente el asynctoken en este caso, es asignar a otra clase el manejo de los resultados que se vayan a recibir, ej desde un delegate:

var call:AsyncToken = service.agregarUsuario(instancia_usuario);
call.addResponder(responder);

En este caso, quien manejara los resultados del metodo agregar usuario, no sera el delegate, sino el objeto Responder, que será un objeto de un tipo de Clase que implemente IResponder (como mencione antes) y que generalmente es el command, aunque se puede hacer aun en otra clase, para "favorecer la composicion sobre la herencia", pero eso es tema de otro topic...

Así de sencillo, lo bueno es que por la arquitectura de servicios que tiene el Flex, esta misma solución es aplicable a Web Services, HTTP Services y Remote Objects.
Saludos

viernes, 23 de noviembre de 2007

Flex Básico

Si busca una manera rápida para entrarle al Flex, le adjunto algunos puntos básicos para poder iniciar sin temor en la herramienta.
  1. Flex cuenta con un Ambiente de Desarrollo muy avanzado, llamado Flex Builder el cual está basado en el IDE Eclipse Un IDE ideado por IBM y que posteriormente puso a disposición de la comunidad en general. Esto ha permitido un desarrollo acelerado de la herramienta, teniendo a disposición múltiples plug-ins para distintas tareas. Este IDE es principalmente utilizado por programadores en JAVA, sin embargo puede ser adaptado para otros lenguajes. En lo personal me gusta más este IDE para Java que otros que he intentado, por ejemplo Netbeans. Adobe logró coger la estructura principal del eclipse y aplicarla a las necesidades que tenían para el desarrollo en Flex, una herramienta intuitiva para desarrollo de interfaces gráficas, compilación desde el mismo IDE, auto-complete del código, etc...
  2. Si no cuenta con dinero para el Flex Builder (que por cierto le bajaron su precio) o es de esos programadores que les gusta la línea de comando, Adobe le permite bajar gratuitamente el compilador de Flex, donde desde la linea de comandos (mxmlc) puede compilar sus archivos creados en notepad sin ningún problema (aparte de la creación de su codigo desde notepad por supuesto =p ). Solo para recordar, la clase principal debe estar en paquete sin nombre algo asi package {...
  3. El código fuente del Flex Framework esta disponible y abierto para ser bajado, leído o si es muy bicho, pues modificado. Aparte de permitir la extensión de los componentes del framework y la herencia por sustitución o por extensión.
  4. Existen dos maneras de desarrollar en Flex, por medio de Actionscript puro (con archivos .as) y por medio del MXML (archivos .mxml). El primero por medio de clases y paquetes con funciones. El segundo es un lenguaje de etiquetas (si...como el XML) el cuál es usado principalmente para la creación gráfica de las interfaces. Si ocupa hacer una interfaz gráfica lo recomendado es hacerlo por aquí. Si ocupa extender componentes o controles ya disponibles en el framework o crear componentes compuestos (los cuales son grupos de componentes dentro de otros, pueden ser dentro de un contenedor por ejemplo) lo ideal es hacerlo por MXML. Si ya ocupa crear un componente muy detallado y muy específico, lo recomendado es hacerlo en Actionscript. Por cierto, los archivos MXML, son convertidos posteriormente en Actionscript para ser compilado posteriormente en un .SWF (se dice suif)
  5. Dentro del MXML se puede tener código de Actionscript (dentro las etiquetas script) aunque esto no es recíproco.
  6. Prácticamente todos los objetos creados en Actionscript se pueden introducir al MXML por medio de etiquetas (markups) o desde el codigo AS3.
  7. Existen ya una serie de componentes gráficos muy interesantes y avanzados con los cuales se pueden hacer las aplicaciones, esto quiere decir que no hay que inventar la rueda... Recalco: son componentes bastante avanzados, no tan rígidos como los de Swing en Java por ejemplo.
  8. Se puede hacer uso de CSS, para tus componentes, incluso Adobe puso a disposición un Style Explorer de los componentes donde puedes escoger un componente y cambiarle sus atributos para posteriormente copiar el respectivo código CSS. Esto es bastante útil cuando se quieren tener "themes" o temas en tu aplicación o hacer diseños más avanzados.
  9. Existen múltiples contenedores para los controles. El principal es el Application. Sin embargo dentro de ese se pueden agregar contenedores para distribuir mejor los controles. Existen dentro de los contenedores distintos "layouts" o formas en la que se distribuyen los componentes, ejemplo, verticalmente: componentes uno encima de otro, horizontalmente: si... ya saben como, esta tambien el absoluto: donde se define con X y Y donde se quiere poner cada componente.
Esto sería por ahora... espero poder poner algunos puntos más posteriormente....
Termino con una frase que leí ayer y que me parece una certeza: "Lo que Natura non da, Salamanca non presta", refiriendose a la Universidad de Salamanca, una de las primeras universidades en el mundo... aquí mi interpretación: "se tiene o no se tiene (inteligencia, talento, lo que sea que sea necesario) para cumplir con una tarea... nadie puede poner eso en uno"

sábado, 10 de noviembre de 2007

Notas acerca de Cairngorm

Debo de admitir que después de muchos años, cuando ingrese al mundo de Flex, me pareció como un nuevo inicio para quitar vicios de mi programación en Java.
Uno de esos era la dependencia a ciertos frameworks como struts, spring, hibernate, etc. No es que los frameworks sean malos de hecho casi todo lo que hacemos, lo hacemos basados en un framework, pero algunas veces cuando se plantea un problema por resolver muchas veces se piensa directamente en como resolverlo para y con X o Y framework, en lugar de buscar resolver el problema de la mejor manera aunque no haga uso de un framework...
Cuando empecé a adentrarme en Flex, empecé a encontrarme con la palabra Cairngorm muy frecuentemente y como estaba siendo utilizado por bastantes desarrolladores de Flex. El Cairngorm según Adobe es una micro arquitectura y al mismo tiempo un framework. Es un conjunto de patrones de diseño que han sido recolectados a través de varios años.
Por bastante tiempo estuve en negación, no quise estudiar ni adentrarme en Cairngorm, hasta que después de varios meses, en un proyecto sencillo, pero que necesitaba otro tipo de solución a la que estaba empleando normalmente, decidí probarlo.
La verdad me arrepiento de no haberlo usado antes, muchas de las cosas que hice antes, se hubiesen podido resolver de una mejor manera haciendo uso del framework... ayudando a resolver muchos problemas de arquitectura, forzándote a usar algunos de los patrones de diseño.
En realidad es bastante complicado y no es algo que se aprende de la noche a la mañana, se necesita mucha experiencia para agarrarle el ritmo, pero cuando empiezas a entender el funcionamiento aún más de lo que entiendes la sintaxis o forma de implementación, cambiará la manera en que se pueden resolver ciertas RIAs, se buscará arquitecturas donde se busque reducir el acoplamiento, delegar en otras clases, programación a la Interface, uso de Singletons(de por si la aplicación es un cliente, una sola persona la usara...), etc, etc..
A continuación algunos conceptos básicos que mi primer experiencia con Cairngorm ha brindado, estoy seguro que no son todos y talvez no los entienda 100%, pero espero aprender muchos más y que le sirva a alguno que quiera iniciar con esto.

Va más o menos así: Componente --> Patron (es) q implementa --> Descripción

Eventos --> Observer --> Extienden la clase CairngormEvent y son utilizados para notificar a un controlador cuando hay una interacción de un usuario en la que se deba ejecutar algún proceso o comando
Commands --> Command Pattern --> Implementan la interfase Command, forzando a tener un método que se llama Execute, que recibe un evento de parámetro. Aquí es donde se realizaría la acción, sea comunicarse con un server o cualquier cosa que se quiera realizar, la lógica del negocio.
ModelLocator --> Singleton --> Mantiene una copia de toda la información que se maneja del dominio de la aplicación y la pone disponible a las demás "vistas" por medio de binding u otros métodos de setteo. No tiene gran lógica, solo una colección de los datos que se utilizan a través de la aplicación.
FrontController --> FrontController, Singleton --> Se instancia al inicio de la aplicacion y su tarea es registrar los distintos eventos que puedan suceder y los comandos o acciones que se quieran ejecutar en respuesta a esos eventos, desde un solo lugar. Es el que controla los hilos del juego...
Delegates --> Business Delegate --> Se encarga de realizar la comunicación y manejar las respuestas con un servidor (en caso que se ocupe realizar)
Service Locator --> Singleton --> Permite accesar a los distintos servicio de interacción con servidores que se tengan, sean servicios HTTP, acceso a WebServices, Remote Objects, etc... de una manera centralizada y sin tener que declararlos muchas veces, pues están declarados en un solo lugar.

Cairngorm no será la solución para todos los problemas, pero definitivamente hace que uno cambie la manera de pensar en como resolverlos. Igual que con todos los frameworks, "Úsese con cuidado y moderacion", no sea que se piense en como resolver el problema con X Framework, pero ni si quiera se entienda como resolverlo...
Para un verdadero entendimiento de la arquitectura y funcionamiento del Cairngorm, no dejen de visitar este diagrama. De verdad aclara el entendimiento.

PS: De verdad.. visiten el diagrama para que puedan entenderlo bien!

viernes, 9 de noviembre de 2007

Algunos conceptos basicos del ActionScript 3

El ActionScript3 es un lenguaje muy potente. De todas las versiones de actionscript, esta es la que me parece más de verdad (sin querer ofender a nadie...) Talvez por venir del lado de Java uno espera encontrarse con algo más maduro y la verdad eso ha pasado con el AS3. Pretendo ir mostrando algunas cosillas que me han ido llamando la atención en este camino.... Aquí hay una muy buena comparación entre el Actionscript 3 y Java si quiere profundizar más.

Algunos conceptos básicos:
En AS3, no existe la herencia múltiple (como en java), solo se permite heredar de una clase directamente. Sin embargo se permite la implementación de múltiples interfaces a la vez.

Las interfaces si pueden heredar de multiples interfaces a la vez.

Cada clase debe estar dentro de un paquete masomenos algo así:

package mi.paquete{

public class miClase{

}

}


No existen metodos o clases abstractas, como se conocen en java. Se pueden tener metodos sin cuerpo dentro de las clases, sin embargo no se obliga a las subclases su implementacion, solamente se podría documentar que el método se debe implementar o hacer uso de las interfaces, que si obligan a implementacion del método.


Ciclos

AS3 cuenta con los mismos ciclos que la mayoría de lenguajes. Sin embargo añade en esta version un ciclo que es muy útil y es el for each...
Se utiliza cuando se tienen una colección de objetos dentro de un Array o ArrayCollection y te permite navegar por la lista completa haciendo él la asignación automáticamente.
Ej:
Suponiendo una coleccion de objetos llamada "objetos" - todos de tipo MiObjeto

var obj:MiObjeto;
for each(obj in objetos){
trace (obj.nombre);
}

la variable obj va tomando un valor de acuerdo a como se va avanzando en la coleccion.
Esto tambien es bueno, ya que muchos programadores tienen la mala costumbre de crear nuevos objetos dentro del ciclo algo como:

for (var i:int=0; i < objetos.lenght ;i++){
var obj:MiObjeto = objetos.get(i);
trace (obj.nombre);
}

Esto lo que hace es ir añadiendo nuevos objetos a memoria y una vez que estos dejan de ser "accesibles" por el resto de la aplicacion, quedan como candidatos para ser recolectados por el Garbage Collector del virtual machine. Talvez se piense que no hay problema si son 10, 20 objetos disponibles para ser recogidos... pero cuando son 100, 1000, 2000 o mas? El performance de la aplicación puede bajar en caso que al GC se le ocurra correr.

Tipos

AS3 es un lenguaje estricto(con tipos definidos) y a la vez dinamico (que se puede alterar ciertas clases añadiendo nuevas variables y tipos en el camino).

Hay tres tipos distintos de Tipos: Null, void y Object.
Null y void tienen un simple valor: null o undefined.
Object puede contener todas los tipos de clases que se definan, pues es la super clase de todas las cases...

Sin embargo es una buena práctica ser lo más apegados a la definición de tipos(modo estricto), por dos razones principales:
1. El performance de la aplicación es mejor, ya que somos específicos con el compilador para decirle que hacer y no tener él que inventar que hacer.
2. Hay menos posibilidades de equivocarse, se permite al compilador ayudarte a comprobar si se esta otorgando a las clases la información que se quiere y no llamando a metodos o atributos que no existen.

Para hacer esa definicion se hace:
var variable:tipo = valor;

El tipo debe contener: nombres de clases u interfaces o el simbolo *, que indica que es una variable sin tipo osea q puede recibir cualquier tipo de informacion que se quiera, sin que se genere un error.

Para verificar si un objeto es de un tipo especifico, se puede realizar de la siguiente manera:

if(objeto is MiObjeto){
trace(objecto.nombre);
}else if(objeto is MiObjeto2){
trace("Es de tipo 2"+objeto);
}

El proceso de casting esta muy ligado con el polimorfismo y la herencia. Es un proceso que nos permite convertir un objeto de un tipo especifico a otro tipo.
Supongase que se tiene un clase que se llama Vehículo, de ahí descienden carro y moto.
Podemos hacer un UpCasting para pasar un objeto de tipo Moto como un objeto de tipo Vehículo. Osea de una subclase a una superclase.
Esto se haria masomenos asi:

var moto:Moto = new Moto();
var vehiculo:Vehiculo = moto as Vehiculo;
o
var vehiculo:Vehiculo = Vehiculo(moto);

El método para pasar de una super clase a una subclase (downcasting), es parecido:
var honda:Vehiculo = new Moto();
var moto:Moto = honda as Moto;
o
var moto:Moto = Moto(honda);

Sin embargo con el downcasting, existe el riesgo que se quiera hacer a una clase que no es subclase... por ejemplo castear de vehiculo a un objeto de tipo perro, que no tienen relación. Por eso es importante usar "is" como metodo de comprobacion, ej:
if(honda is Moto){
var moto:Moto = honda as Moto;
}

Namespaces

Como en XML, definen un area de acción que permite tener varias miembros con un mismo nombre, sin que existan conflictos entre otras clases, por ejemplo que se herede de componentes ya hechos y que no exista conflictos entre las nuevas definiciones y las echas en el componente previamente o para definir mismas funciones pero para distintos ambitos.

Se declaran asi:
Dentro de un paquete:
package mis.clases{
public namespace uno;
public namespace dos;
}

Luego desde una clase se importan:

import mis.clases.*;

y se utilizan desde la clase:

package mis.clases{
public class MiClase{
uno static function holaMundo():void{
trace('Hola Mundo desde namespace uno');
}
dos static function holaMundo():void{
trace('Hola Mundo desde namespace uno');
}
}
}

Y para accesar las funciones de MiClase, desde el cliente se usa la palabra "use"
Ejm:
...
use uno;
use dos;
...
MiClase.uno::holaMundo(); //Imprime: Hola Mundo desde namespace uno
MiClase.dos::holaMundo(); //Imprime: Hola Mundo desde namespace dos

lunes, 22 de octubre de 2007

Por qué tan tarde?

Hace poco uno de mis blogueros favoritos, Yakov Fain escribió un artículo muy interesante acerca del porqué trabajamos más tiempo del debido. Yakov llegó a varias conclusiones pero las que más me llamaron la atención fueron:
  1. Falta de Capacidad Técnica o quedarse tiempo extra para compensar el atraso durante el día
  2. Un bono prometido por trabajar extra
  3. Ser un trabajo-adicto
También podría agregar en lo personal, el hecho de una mala organización donde las tareas no estén bien distribuidas y te toque hacer las de Soyla...
En lo personal, definitivamente no lo hago para recibir un bono, primero porqué es muy factible que el tal no ocurra, segundo porque comparto el sentir de Yakov que al hacer la division del total del bono recibido entre las horas extras me va a dar un monto muuuuuy bajo por cada hora extra laborada.
Trabajo-adicto... que dificil, la verdad en un tiempo de mi vida pude haber sido uno de estos... no se si eso se quita o si con el tiempo uno aprende a valorar cosas más importantes como Dios, la familia y otras tantas cosas lindas que esta vida tiene y deja de lado un poco el querer quedarse como ratón de biblioteca todas las noches tratando hacer más y mejores cosas.
Sin embargo... pensar en un informático que no tenga cierto necesidad de quedarse unas horas más en las noches estudiando, leyendo, "alimentandose" en el área tecnica es bastante dificil, a no ser que el mismo no tenga pasión por su trabajo o no le importe quedarse atrás en las distintas áreas de este mundo tan cambiante. Si uno se descuida unos meses, sin actualizarce, sin ir esa milla extra para aprender nuevas cosas, para leer códigos, artículos y opiniones de otras personas, va a llegar un momento donde lamentablemente vas a tener pocas posibilidades de avanzar en el mercado y ahí no solo está en juego tu nombre, sino el alimento de tu familia.
Es debido a esta importancia de estar actualizados que he estado pensando, aunado con la primera razón expuesta arriba y debido también a un proyecto en el que estoy trabajando en este momento que puedo decir en estos días que mi razón para trabajar hasta tarde en estos días es una combinación de "deseo de aprender más" con "falta de capacidad técnica" que tienen que tratarse para poder cumplir con lo establecido con el proyecto. En parte me alegra que no sea por el simple motivo de quedarme "lampareando" o simplemente navegando... ni que no tenga otras cosas que hacer... sino que exista en mí la necesidad de reconocer mis faltas técnicas y tratar de llenarlas para que en este caso el proyecto actual o alguno futuro salgan de la mejor manera y mi conciencia pueda descansar tranquila (además de la experiencia recibida), de todas formas el primer paso para vencer los problemas es reconociendolos cierto?
Estoy actualmente trabajando en un proyecto con Spring, Hibernate y Struts. Spring y Hibernate ya los había usado antes con muy buenos resultados. Eso del ORM es una gran ventaja para el programador, aunque a veces me pone a pensar que se gasta más tiempo configurando y comprobando que todo este bien que lo que se necesitaría para crear un simple query. Y el Spring y su inyección de dependencia es totalmente delicioso. La reducción de acoplamiento y dependencia que se logra es maravillosa. También con Struts había trabajado. No fue una mala experiencia la verdad, sin embargo como framework para MVC nunca fue de mi total agrado (y hablando con otros mucho más bichos que yo, tienen el mismo sentir).
Sin embargo, lo extra que traía este proyecto es la utilización del framework MVC de Spring. Mismo principios pero distintas formas de implementarse y ahí es donde me ha tomado más tiempo últimamente. He tenido que leer, investigar, practicar, probar, arreglar, etc. La verdad ha sido por vagabundería mía, ya que hace un año o más habia comprado un libro donde trataba de este tema y siempre me decía que lo leería luego... y ese luego fue hasta el momento en que me pusieron una fecha de entrega. Talvez si lo hubiere hecho antes hubiese estado preparado para aplicar los conceptos necesarios.
Sin embargo, la experiencia con Spring MVC ha sido muy grata, mucho más que con el Struts definitivamente. Me encanta el hecho de poder inyectar los beans definidos en el Application Context de Spring dentro de mis controladores (mvC). También poder tener varios tipos de controladores e inyectarles validadores, vistas, etc. todo desde un archivo externo y sin tener nada ligado en código. Puedo utilizar varios tipos de vistas, hacer uso de los recursos ya implementados previamente en Spring sin hacer nada extraordinario. Esto hace más factible cumplir con algunos principios de la POO como: Programar a una Interfaz (o superclase) y Favorecer la Composición en lugar de la herencia.
Definitivamente en esto de la informática, el que se queda dormido o el que dice "luego" se va a quedar atrasado y cada día van a salir mejores programadores con más ganas de hacer y aprender más. Muchachos que no les importa no tener novia ni esposa, porque su computadora llena ese vacio. Personas con más ambición y ganas de triunfar y que no les va a importar dejar sin trabajo a cualquiera, con tal de superarse. En uno queda el deseo de superarse, no solo por el orgullo propio, que admito influye un poco de motivación en mi y estoy seguro que en la mayoría, sino por el sustento propio y el de su familia en un futuro.
Ahora preguntese, porque te quedás tan tarde trabajando?

domingo, 14 de octubre de 2007

Qué tan bueno es el Ajax...?

Como dijo Carlos Zumbado en la última reunión del Grupo de Usuarios de Flash en Costa Rica: "Ajax funciona excelentemente para limpiar baños y lavatorios... :-)"
Ya en lo serio, AJAX ha ganado mucha fama ultimamente y en lo personal pienso que debido a la gran cantidad de desarrolladores o diseñadores que por ver un nombre en una revista piensan que será la Panacea para todos sus proyectos.
Si bien es cierto se han desarrollado cosas muy interesantes como los mapas de Google, Google Suggest y mi favorito: Gmail que tienen sus interfaces completamente basadas en la funcionalidad que provee AJAX, no funcionan completamente bien con todos los browsers. Ejemplo de eso es la funcionalidad de Gmail en Safari, que es completamente reducida para los usuarios del browser de la Mac (o por lo menos en la mia...aunque usando Safari en Win tampoco funciona)
Veamos un poco del transfondo de AJAX: su nombre viene de Asynchronous JavaScript and XML y su mayor fortaleza es la de poder intercambiar informacion con un servidor desde un codigo en Javascript sin tener que refrescar la pagina y sin que el cliente se de cuenta, haciendo que la experiencia que viva el cliente sea en tiempo real. Todo esto por medio del objeto XMLHttpRequest que es el encargado de realizar el intercambio de informacion entre la aplicacion y el servidor y como dije anteriormente sin refrescar la página completamente.
El Ajax en sí no es ningún lenguaje de programación definido, sino una serie de tecnicas (como el llamado de XML dinamico, DHTML, etc) y que utiliza el "lenguaje" Javascript, que en lo personal no me agrada mucho por varias razones entre las que puedo citar que no es compilado sino interpretado, no es fuerte con los tipos de datos, no hay un estándar de definición como con otros lenguajes, etc.
Como programador en ambiente web he escuchado y he experimentado que muchas veces como cierto código de Javascript funciona bien para X browser, pero no funcione igual para Y browser. Y eso - que a mi gusto es la mayor debilidad de esta tecnología- es debido a que los distintos fabricantes de browsers no han podido ponerse de acuerdo y formalizar un API de objetos y funciones accesibles al programador, que esté estandarizado e implementado en todos los browsers y que faciliten al programador el desarrollo de codigos sin tener que preocuparse si funcionara en cada uno de los browsers o no.
Este mismo problema se presenta a la hora de trabajar con AJAX. Siempre se presentaran problemas de funcionamiento entre las distintas plataformas que obligan al programador
escribir mas lineas de codigo para validar el tipo de browser y revisar si un metodo existe o no existe para un browser especifico.
Parece que el equipo de trabajo de Google pasó por este problema y decidió hacerle la vida más facil, sobre todo a los programadores de JAVA. Lanzó hace unos varios meses un Toolkit con un API con métodos y controles o widgets, que ofrece a los desarrolladores familiarizados con Java, la escritura de algún codigo en java y posteriormente su traducción al javascript y la correcta validación para que corra en la mayoría de browsers. Desde clases de java, se hara la creación de los distintos widgets o controles y su respectiva interacción con el cliente. Tambien se harán el llamado a recursos del servidor, que en un principio serán logrados por RCP y que posteriormente serán traducidos por el mismo toolkit al javascript listo para ser usado.
Su integracion con los IDEs mas usados como Eclipse es sencilla y permite probar las aplicaciones de dos formas, desde el IDE o en desde un browser con un mecanismo que levanta la aplicacion como si fuera una verdadera aplicación web hosteada en un servidor web.
Lo mas interesante de todo, es que el Toolkit al final generará codigo javascript que podrá ser utilizado (según dicen) en cualquier browser, sin necesidad de que el desarrollador meta mano en ello ni se reviente la cabeza en buscar metodos que sean utilizables y aceptados por todos los browsers porque el toolkit lo hara automaticamente.
Para los no "javeros", existen muchos otras herramientas que facilitan el uso del Ajax sin necesidad de usar el Toolkit de Google y sin saber Java, entre ellos Backbase que por cierto ya he usado y ofrece algunas cosas interesantes.
Sin embargo queda en mi la duda de que tan bueno será todo esto... Las aplicaciones desarrolladas, especialmente por Google son fantásticas pero aún queda algo en mí que no me permite aceptar esta tendencia al 100%, porque aunque es muy útil (porque verdaderamente lo es...) no es tan fácil de desarrollar como se quisiera.
En cambio, hace unos meses ingrese al mundo del Flex de Adobe, y aunque no soy un experto como algunos que hay por aquí (y Dios sabe que quisiera llegar al nivel de ellos) lo poco que he visto y que he aprendido y utilizado ha hecho que me entren de nuevo las ganas de programar...
Ya estaba cansado de aplicaciones WEB planas, cansado de añadir y añadir capas y capas entre las aplicaciones, cansado de crear aplicaciones en el server o herramientas de desktop en el super rígido Swing y mucho más de las aplicaciones de líneas de comando.
Flex vino a traerme buenos recuerdos de mi época con Visual Basic 6.0, el manejo de eventos, añadir botones, imagenes a un formulario, integrar eventos con objetos, dibujar una pantalla en un papel y que la gente te diga si le gusta o no... Además cuenta con un gran lenguaje para programar en el, como lo es el Actionscript 3.0 que ya es un lenguaje robusto, bien orientado a objetos, con excelente manejo del XML, expresiones regulares y cuanta cosa uno se pueda imaginar en un lenguaje de verdad, este lo tiene. Además se integra excelente con el MXML (para diseño más fácil de la parte gráfica) y el Flex es open source, lo cual permite meterse hasta lo mas profundo del lenguaje, ver definiciones y hasta si se es muy bicho modificarlo...
Otras cosas que me gustan son: el IDE para desarrollo está basado en Eclipse, lo cual es un plus si se es un desarrollador en Java que ha utilizado el IDE ya que estas completamente familiarizado. También el llamado de procedimientos remotos, por medio de Remote Objects, Data Services, Web Services o Servicios tipo Rest. Esto último es demasiado útil, sobretodo si se desarrolla un backend en el lenguaje favorito (en mi caso Java, pero sirve con PHP, Cold Fusion y hasta .Net) y el front-end es una aplicación fresa y dinámica en Flex y sobre todo eso y para rematar, las aplicaciones corren sobre el Flash player, algo estandarizado, no andan varias versiones del player hechas por distintas empresas por ahi y que implementen ciertos métodos en unas y otros en otras. Es algo más estable y serio, además que la penetración del Flash Player es demasiado alta, casi en un 93% de las computadoras del mundo...
Pero a pesar de todo lo que el Flex pueda proveer o lo que AJAX pueda ofrecer, lo más importante para el desarrollo de un buen sitio web, no será el lenguaje en que se implemente (aunque definitivamente ayudará), sino el diseño(y no me refiero solo al diseño gráfico) que se haga previamente. Como dice Alan Cooper en su libro About Face 3.0, "diseñar un producto que vaya a cumplir con las metas del usuario final, ni más cosas ni menos cosas..." (palabras más, palabras menos)

jueves, 20 de septiembre de 2007

Mexico...


Mexico lindo y querido...
Esta semana fui con mi esposa, mi hermano y mi cuñada al hermoso país de Mexico...
La verdad ibamos con mucho temor acerca de la seguridad del país. A Dios gracias no sucedio ningún problema de asaltos, robos en hotel o cualquier otra cosa que nos imaginasemos... de hecho las únicas veces que nos robaron algo, fue enfrente nuestro y con nuestra propia aprobación.
Estos mexicanos saben como cambiarte los precios en un abrir y cerrar de ojos y aún así hacer que uno ni se dé cuenta... y si se da, no decir nada..
El país como tal, lo encontramos bastante polarizado politicamente. Asistimos al grito de independencia en el Zocalo con casi 200 mil personas y había alguien gritando desde una plataforma cosas contra el presidente en turno y pidiendo a la gente que se fuera... Ahí si tuvimos temor ya que no sabíamos como iba a reaccionar la gente... Gracias a Dios no paso a mas.
Fuimos a las piramides de Teotihuacan, algo verdaderamente impresionante...
Tambien fuimos a la ciudad de Taxco (se dice Tasco) donde la plata es la mayor fuente de ingreso. Entrar ahí fue como retroceder 100 años, una ciudad sin señales de alto ni anuncios, totalmente colonial y con calles para un solo carro... Cuenta la ciudad con un templo llamado Santa Prisca. Si tienen tiempo de ver la historia no será un desperdicio. Fue una experiencia muy bonita.
También fuimos a Acapulco, puerto famoso principalmente - para nosotros - por el episodio del Chavo en Acapulco y una pelicula de Cantinflas que fue firmada ahi... El Tratar de ingresar al area pública de la playa de Acapulco es como echarle maíz a las gallinas, te rodean muchisimas personas y te ofrecen servicios de todo tipo: masajes, refrescos, 'chelas', adornos y hasta sillas... mejor quedarse en la zona privada del hotel o en la piscina. La ciudad es bonita, tranquila y la gente muy amigable, como en casi todos los lugares donde fuimos, aunque si hay que decir que los servicios al turista no son de lo mejor, como que hace falta iniciativa o algo.
Luego de Acapulco subimos al DF de nuevo y de ahi de vuelta a tiquicia... la verdad quede en lo personal con una actitud muy distinta acerca del país.
Me encanto su patriotismo, su felicidad de celebrar su independencia, sus desfiles y banderas en cada esquina y negocio al que entrará... Mucha nostalgia de saber que en mi país ya no queda casi nada de eso. La verdad en mucho participamos nosotros al dejar de lado un poco de este patriotismo que es tan simple como poner una bandera en la casa. El tico solo se hace tico cuando hay partidos de la sele y listo. Para lo demás no se preocupa por su país ni por su sociedad, solamente cuando le sucede algo.
Si, Mexico tiene mucha pobreza; si, hay mucha criminalidad; si no es el país perfecto y si, de vez en cuando nos caen mal los mexicanos (sobre todo en lo que es de futbol), pero ellos tienen algo que aman y que tratan de cuidar y pasar a sus hijos de generación en generación. Cuanto anhelaria que eso también se tuviera acá, aunque creo que ya es muy tarde para eso no podemos dejar de intentarlo...