Control Freak...

Que es controlar? Controlar es verificar que lo que se esta haciendo actualmente es lo que en realidad se queria hacer de la manera correcta.

Por que es importante? Porque es la unica forma de asegurarnos que lo que se esta haciendo actualmente es correcto.


Foto por germanium


Muchas personas subestiman la importancia del control en los procesos. Personas que asumen que lo que se esta haciendo esta bien. No hay espacio para feedback ni para mejoras.
El control es algo que debemos llevar en cada tarea que hagamos en nuestra vida. Sea que desarrollemos software y controlemos que el sistema funciona correctamente, que los requerimientos esten de acuerdo a las necesidades de nuestro cliente, etc. o sea que estemos cocinando unas galletas en el horno y el control nos permitira asegurarnos que no se esten quemando...


Foto por applesticker

De que sirve en un proceso que existan reglas o procedimientos sino hay nadie que controle que se esten cumpliendo esas reglas? El control hace respetar lo establecido y nos ayuda a enfrentarnos a posibles problemas para buscar soluciones...

Pero.... de que nos sirve saber que algo no se esta haciendo bien si no estamos haciendo algo para corregirlo. El tener control en un proceso por tenerlo de nada sirve. El control debe ser respaldado, debe tener consecuencias cuando se incumple lo establecido. El control va de la mano con acciones preventivas o correctivas.

No dejemos entonces el control de lado y si estamos teniendo control en nuestros proyectos, pues apliquemos acciones a aquellas tareas o personas que se esten saliendo de lo establecido. Sera la unica manera de asegurar nos de entregar un producto de calidad.

No es solamente el dinero

Por ahi de 1943 Abraham Maslow expuso una teoria donde presentaba una piramide con distintos niveles de necesidades de los seres humanos.

Foto por Wikipedia

Los primeros cuatro niveles son niveles de necesidades de deficit osea que pueden ser cubiertas por uno mismo o por otras personas, el ultimo nivel es enfocado en la autorealizacion de la persona.

El primer nivel nos habla de las necesidades fisiologicas, osea las mas basicas: respiracion, alimentacion, descanso, higiene, etc. Buenas instalaciones, lugar limpio, buena luz, temperatura adecuada. Aqui existen factores pasivos que si no se tienen no influyen o no va a mejorar la motivacion de las personas, pero si no se tienen afectan verdaderamente la motivacion de las personas. Un ejemplo de ello es la limpieza en los servicios sanitarios: si estan limpios nadie se emociona, es algo normal... pero si estan sucios la gente no se siente comoda, reclama, exige, se molesta...


El segundo nivel menciona necesidades de seguridad: fisica, economica, etc. La estabilidad de la empresa, la transparencia en el estado de la misma, salario justo, beneficios, etc

El tercer nivel nos habla de afiliacion y afecto: cuan comprometido me siento con la empresa? me siento parte con mis companeros? tengo la camiseta de mi equipo puesta? Soy parte del equipo de la empresa o soy solo un empleado que cumple un horario? Trabajamos como un equipo en realidad o solo como un grupo de personas reunidas en un mismo lugar?

El cuarto nivel son las necesidades de estima: como nos ven las demas personas: obtenemos respeto, reconocimiento, estatus, autoridad de parte de nuestros colegas o somos ignorados, despreciados o menospreciados? y como nos sentimos nosotros mismos: tengo confianza, tengo la experiencia necesaria, tengo el conocimiento?

El ultimo nivel se basa en la autorealizacion de la persona: hasta donde puede llegar esa persona? como puede ser motivada? de verdad soy de provecho en la organizacion? cual es mi proposito dentro de la organizacion? demuestro inteligencia emocional? como mejoro para el bien de los demas? Es algo continuo, es algo que debe salir de la persona misma. Si se cumplen los niveles anteriores, es muy factible que este nivel pueda ser llenado.

Ya ven la satisfaccion de un empleado no se traduce en solamente un cheque o pago que se le haga cada 15 dias o cada mes. Es una serie de elementos que van a afectar la manera en que el empleado sea motivado o no vaya a reaccionar ante el trabajo.

- "Pero si se le paga al empleado para que haga bien su trabajo...."

Si, pero eso no significa que no tenga otras necesidades, que no este pensando en que no tiene para comprar comida, que el bienestar de su familia no sea importante, que su aporte a la organizacion no sea reconocido, que no tenga seguridad de por cuanto tiempo va a tener empleo, etc, etc. Al final de cuentas son personas y con necesidades.

Empleados motivados son empleados que van a hacer mas de lo que se les solicita, un empleado motivado no es solo el que recibe mucho dinero sino el que siente que su trabajo cubre la mayor cantidad de sus necesidades.

Por cierto... motivar a un empleado no es solamente darle un aumento. El humano es insaciable y despues de 3 meses va a querer mas aumento. Si usted hace eso va a estar alimentando un monstruo que va a ir creciendo. Mejor dediquese a satisfacer esa area en conjunto con otras mas que son importantes tambien

Flash Catalyst y Flash Builder

Esta semana se hizo publico el release de las versiones beta de Flash Catalyst y de Flash Builder (antiguo Flex Builder) que viene con Gumbo, la version 4 el Framework de Flex.
Para bajar el beta de Catalyst pueden hacerlo desde aquí. Mas info aquí
Se encuentra en versiones para windows y mac.
Para el Flash Builder (y Flex 4) mas info aquí y para bajarlo aquí.

La importancia del Feedback y las pruebas

Recientemente escribi sobre la importancia de recibir feedback en nuestra profesion de infomaticos.
No voy a extenderme mucho al tema, mucho ya lo dije en el post anterior sin embargo hoy quiero hablar un poco sobre la importancia de hacer pruebas y como se relaciona con el feedback.
Veran, las pruebas que hagamos (me gusta usar Fluint para flex y ultimamente estoy probando con Flex Unit 4 - version alpha en este momento) son una forma de feedback para nuestras aplicaciones y para nosotros mismos.
Cuando hagamos cambios grandes o refactoty en nuestro codigo y ejecutemos las pruebas que hayamos realizado sabremos sabremos si los cambios realizados por nosotros han afectado el comportamiento correcto de nuestra aplicacion. Eso tambien es feedback.
Cuando durante el fin de seman un companero de trabajo cambie algo en su codigo y lleguemos el lunes y nada funcione... podemos correr nuestras pruebas y darnos cuenta que es lo que fallo y encontrar la solucion de forma mas rapida (ademas de poder culparlo :o) ). Eso tambien es feedback.
Soy partidario del TDD (Test Driven Development) y reconozco la importancia de las pruebas, como forma de feedback y de asegurar una mejor calidad en mi desarrollo, pero tambien reconozco que a veces el tiempo no alcanza o el cliente no entiende la importancia de estas pruebas. Por eso es necesario ser prudente a la hora de escoger que probar y que no. Como decia una abuela mia "Ni mucho que queme al santo ni tan poco que no lo alumbre". Repito Nada malo con probar, pero tambien ser concientes de nuestros tiempos ya que no siempre tendremos el suficiente tiempo para probar todo.
Mis secciones favoritas para probar, son las que estan en constante cambio y que son criticas:
logica de negocio, acceso a datos (servicios remotos o a base de datos en AIR).
Componentes y vistas me gusta probarlos separados, aislarlos en una aplicacion aparte y probar su funcionamientos, estilos, etc. Eso me provee Feedback. Me gusta aislar las vistas que haga y sus interacciones basicas y proveerlas a quien sea que este a cargo de esa vista, sea el disenador grafico o el encargado del proyecto o cliente del mismo. Que jueguen con la vista por separado en lugar de tener que cargar toda la aplicacion y gastar mas tiempo en proveerme feedback, eso lo pueden hacer en otro momento. Existen herramientas para probar la interfaz como Flex Monkey y Selenium que permite grabar interacciones y ejecutarlas automaticamente. Tambien son validas.
Flex Unit 4 Alpha viene con muchas mejoras y cosas nuevas, verdaderamente lo recomiendo! Aqui mas info

Creando APIs en Actionscript

Recientemente he tenido en mis ratos libres la mania de bajar API's para Actionscript 3 de diferentes servicios que hay por ahi, como Digg, Twitter, Facebook, Salesforce, etc para probarlos, jugar con ellos y hacer alguna aplicacion sencilla con ellos aunque nunca vaya a ser utilizada.
Esto me divierte en realidad y mas importante me ayuda a ver codigo de otras personas, maneras de pensar y de implementar. Creo que es una experiencia enriquecedora. Muchos desarrolladores piensan que ver el codigo de otros es malo, es bajo, es denigrante. Honestamente creo que no! Primero yo escojo de quien veo el codigo y la mayoria de personas que hacen estos APIs son mucho mas competentes que yo! Ademas es una manera de aprender de mejorar y de desarollar mejor. Un claro ejemplo es el acceso que tenemos al framework de Flex. Si algo puedo decir de mi actual trabajo y de los dos maestros de Flex con los que trabajo es que se conocen ese framework de arriba a abajo. De ahi que puedan hacer las cosas que hacen.
Bueno siguiendo con mi fascinacion tan geek de las ultimas semanas, me he puesto a pensar en que requisitos son necesarios para construir un API en ActionScript.

Primero pensemos para que necesitamos realizar un API. Un API es utilizado para ofrecer una serie de servicios que puedan ser invocados por otras aplicaciones con el fin de ejecutar una accion. No es lo mismo que un framework. El API debe ser claro, sencillo y definido. Mejor si esta documentado. Mejor aun si tiene ejemplos. El API debe ser facil de usar, intuitivo y tener todo lo que nuestros futuros clientes vayan a ocupar para interactuar con nuestra plataforma. Incluyendo objetos definidos por nosotros mapeando la informacion de nuestros servicios.

Segundo analicemos la forma en que vamos a entregar nuestra informacion. Aqui desde dos perspectivas distintas:
a) Como se accedera a la informacion que se quiere facilitar (ya pensando en algo mas "fisico"). Esto incluye como se haran los llamados a nuestros servicios: REST Services? Web Services? Remoting? External Calls (como tiene el API de Facebook)? Todo esto debe ser transparente para el usuario de nuestro API. Si acaso lo mas es la opcion de escoger que tipo de canal usar para comunicarse con nuestros servicios, pero la implementacion y demas no debe ser de importancia para el.
b) La forma en que entregaremos la informacion recolectada de nuestros servicios. Si recibimos XML, no podemos pasarle simplemente XML al cliente y dejar que el piense que va a hacer con esa informacion (tecnicamente si podemos, pero no debemos :) ). La creacion de objetos que mapeen nuestro servicio hace que nuestro API sea mas facil de usar.

Tercero consideremos en la naturaleza Asincronima de nuestra plataforma. Cuando hacemos una invocacion a un servicio externo sea por WebService, Remoting o simple REST Services no sabemos cuando vamos a recibir la informacion de vuelta. Esto hace que nuestros APIs no sean tan facil de usar cuando invocamos servicios remotos como hacer:

var misUsuarios:ArrayCollection = miAPI.cargarUsuarios(); //ESTO NO FUNCIONA!!

El metodo cargarUsuarios puede demorar un tiempo (incluso has segundos) en devolvernos esta informacion, asi que la asignacion a mis usuarios no va a ser correcta.

Soluciones:
a) Una forma de hacerlo es pasarle al metodo el arraycollection que queremos cargar y cuando se reciba la informacion se carguen los resultados en esa variable pasada como parametro. Recordemos que nuestros objetos en AS3 se pasan por referencia y no por valor, asi que los cambios que hagamos al objeto pasado por parametro, se reflejaran en nuestro objeto original (a menos que se haga una copia del mismo. En lo personal la siento como valida, pero no es aplicable en todas las ocasiones. A veces ocupamos darnos cuenta cuando algo fue procesado y eso se logra a traves de eventos.

b) Otra forma de hacerlo es atraves del uso de eventos. Cuando nuestra funcion recibe el resultado, esta manda un evento indicando que fue recibido. Anadiendo un event listener a ese evento, podemos procesar esa informacion desde donde queramos. Algo importante es aislar cada llamada o cada proceso de datos por aparte, para que cada llamada despache un solo evento, en lugar de estar llamando handlers de otras locaciones por eventos que se invocan con otros propositos. Por supuesto es importante recordar el removeEventListener una vez que es ejecutado un event handler que no se ocupa tener mas y poner las referencias como weak, pero igual si no se aislan las llamadas pueden crear conflictos.

Esta practica es seguida en el API para Facebook, a continuacion parte del codigo de uno de sus ejemplos:

var call:AddComment = new AddComment(story_id, body);
call.addEventListener(FacebookEvent.COMPLETE, onAddComment);
facebook.post(call);

onAddComment Va a encargarse de utilizar la informacion recibida como se quiera, puesto que ya esta informacion viene procesada y convertida en el tipo de dato que se quiere todo esto cuando se despache el evento de Complete.

c) Otra forma de hacerlo, es aislando el resultado de la funcion invocada y que ella se encargue de manejar el resultado. Esto es como lo que hacen con el API de Digg . Esto es delegar la llamada y el procesamienta del resultado y posterior conversion a objetos normales a un objeto que es devuelto por nuestra funcion invocada. Por ejemplo:

Del API de DIGG

public static function getUser(user:*):UserResponse
{
var request:URLRequest = new URLRequest(getUserURL(user));
return load(request, new UserResponse()) as UserResponse;
}

Esta clase devuelve un UserResponse, que hereda de la clase Response que a su vez es la que hace el llamado al servicio y delega en UserResponse el procesamiento y conversion del resultado en un objeto utilizable en la aplicacion y no simple XML.

Como ven, enfoques distintos, pero el mismo principio aislar la invocacion para que pueda ser tratada como una llamada distinta.

Espero esto pueda ayudar a otras personas que tengan que crear APIs para servicios externos para AS3 o que anden buscando como ingresar a esto de APIs y servicios externos y que puedan de este humilde texto encontrar algo que les ayude
Disfruten...

Some thoughts about Offshore companies in Latin America

I've been reading lately some posts from Geoff Sowrey, Technology Director of the Hangar, Critical Mass for Latin America. He's been writing about how difficult its to start a new company in a different country with different culture, language, timezones, etc.
I really feel his pain, having worked in different companies where we either used or provided services in that way.
For me this is a critical topic that needs more discussion if we really want to have to more companies moving to Latin America; and no just moving but having success.
You see, Latin America's (LA) culture is totally different from North America. Ambitions, goals and priorities as well and if companies moving to LA are not aware of these differences they are going to suffer a lot.
And I'm not talking only about hiring services from companies in other country; I'm talking about moving and creating new companies. That's takes of course more responsibilities and challenges.
Here are some thoughts:

• Leaders HAVE to reproduce leaders, once you invest time teaching the RIGHT people how/when things need to be done they should be able to guide other people and groups and share the load of responsibility. Of course if the cycle goes on, they should be able to reproduce and have a company that runs by itself.

• Learning curve, for both sides of the story: you need to learn how people work in Latin America and they need to learn how you guys want things done; but eventually both sides are going to have to give up a little. You can't expect to have a warehouse full of robots programmed to work as you want, as they can't expect that they are going to receive a paycheck just for the sake of being physically present every day in an office.

• Good resources are very important. Sadly that's the hardest thing to find. But I wonder, are companies from outside really hiring the best (and willing to pay more $$ for them) or they are just hiring people just for the sake of getting people... Hiring people "just in case we get more projects" is one of the biggest errors a company could make. That will create an awful "comfort zone" and that's going to affect the performance of the people waiting for action and the people around them. I've seen this happening before. It is sad, lot of people earning their salary but without enough technical knowledge, no ambition, no will to learn and sadly that affects others. Would it be better to have less (but good or very good) people, even if you have to spend more money but at least you know they understand you, they know what you need and they really feel part of the company? Of course a lot of these companies go to other countries to save money, but if they really don't invest in the right people at the end of the road they are going to spend more money and loose more clients.
  

• Getting people to feel part of the company. Sadly Latin America is full of this: "I'm just working for a gringo that is getting rich". And that's something that needs to be changed as soon as possible. They SHOULD say: "I'm working for a GREAT company. I'm making this startup grow. I've been working really hard til midnight but we have the best project and the client is so happy, they are willing to get more things done so there should be no problem with my pay check..." Too emotional? Maybe, but that's the way every employee should feel about the company they work at. How to do this you say?? It should be part of the culture of the company. It starts having great team leads, people with passion, people that could inject that passion to others. It starts with making people feel proud of what they are doing... what about having a section in the company's web site with pictures of the employees, how they work hard? What about having a blog mentioning successful projects and the people that were involved in them? They need to feel damn proud of what they are doing so that they can give the best of them. Again too emotional?? maybe yes... but for some people that emotion is very important and could mean a big change of attitude towards the company, the client and the work they do. They won't feel they are just working for a "gringo", they will feel they are doing this for themselves and their country.
  

• Processes are important, creation of standards, DOCUMENTED processes (say wiki, blog, paper, etc), something that lowers the bar for new people or people that don't not knowing exactly how to do things. Processes not only from a technical perspective, but company policies, etc. Zero tolerance for people having access to this documents and not following them. They should not be written in stone, but they should be clear and detailed for everyone. A lot of work yeah... but is going to save you a lot of work eventually.

• Promote ownership of projects (and/or clients), again make people feel proud, but more important RESPONSIBLE. Create teams (real teams, not groups of people in one office working on a random project), combination of people where you see they get along and more important get things done correctly. Specialize people in different skills, take advantage of people with special knowledge.

Programacion Modular - II Parte

Hace un tiempo escribi sobre los modulos en Flex y aun tengo algo que quisiera compartir y que aprendi hace poco.
Casi siempre cuando se crea un modulo, se extiende de la clase mx.modules.Module (si es en MXML) o de la clase ModuleBase si es en Actionscript.

Ahora, que hay en esa clase Module que la hace tan especial??

En si como tal, la clase no tiene nada especial mas que un metadata que vamos a revisar pronto. La clase Module extiende de "mx.core.LayoutContainer" que extiende a su vez de la clase "Container"; clase base de la mayoria de los componentes contenedores que utilizamos como Box (y sus decendientes: VBox, Hbox), Canvas, etc. Esto quiere decir que por si mismo el modulo nos permite agregarle componentes, como lo hariamos en otro componente contenedor.

Sigamos con el Module, si revisamos el codigo que viene el framework vemos lo siguiente en la clase:

package mx.modules
{

import mx.core.LayoutContainer;

[Frame(factoryClass="mx.core.FlexModuleFactory")]

Encontramos el metadata [Frame]

Sobre este metadata tenemos muy poca informacion, sin embargo es utilizada en otras clases del framework, como es el caso de la clase Application, que siempre utilizamos. Por ejemplo Application utiliza "mx.managers.SystemManager". Aunque siempre pensemos que la clase Application es la base de nuestra aplicacion, en realidad es SystemManager, es la primer clase que se ejecuta, se encarga de setear los eventos principales, cargar las librerias necesarias y pasar al siguiente frame, donde estaria nuestra aplicacion.

Las aplicaciones Flex tienen siempre 2 frames, el primero cuando se corre el preloader y se cargan los recursos necesarios de la aplicacion (RSL, etc) y el segundo donde se tiene la aplicacion en si. Este metadata nos permite especificar la creacion de un framework e indicarle cual clase debe ejecutarse en ese frame. En el caso del Module, le pedimos que ejecute la clase "mx.core.FlexModuleFactory", que si vamos a su codigo podemos entender lo siguiente:

• Implementa la interfaz "IFlexModuleFactory" al igual que SystemManager. Esta interfaz define dos metodos: create() e info() que nos devuelve la informacion necesaria para cada uno de los modulos.
• Extiende la clase "MovieClip" que es la unica que nos permite tener mas de un frame a la vez.
• Una vez que los recursos necesarios por el modulo son cargados la clase se encargara de pasar al siguiente cuadro, con nuestra aplicacion. Esto cuando este todo cargado. Algunas veces usando External RSL el tiempo de carga se alarga y esto es porque no pasara hasta el siguiente cuadro hasta que este todo cargado.
  

Ahora.. aparte de teoria en general que mas nos provee esto?? Pues haciendo uso del metadata "Frame" y de la clase "FlexModuleFactory" podemos crear a partir de componentes contenedores nuestros modulos con comportamiento especifico. Por ejemplo modulos que se comporten como TitleWindows, como Panels, etc. o incluso como algun componente contenedor que definamos nosotros; solamente ocupamos agregar el metadata

[Frame(factoryClass="mx.core.FlexModuleFactory")]

Esto es super util cuando queremos imitar un mismo estilo entre varios modulos, se crea un componente base, con el comportamiento y estilos repetidos a traves de la aplicacion y posteriormente en lugar de crear modulos basados en "Module" se crean basados en "ComponenteCustomizado"

Espero pueda servir de algo y ampliar un poco el conocimiento en este tema que podemos agregar nuevas cosas a nuestras aplicaciones de manera elegante y optima. El metada "Frame" podria tambien permitir agregar nueva funcionalidad si extendemoslas clases correctas.