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
sábado, 16 de mayo de 2009
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...
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...
martes, 14 de abril de 2009
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:
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.
lunes, 30 de marzo de 2009
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:
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:
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.
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.
[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.
jueves, 19 de marzo de 2009
It's all about feedback
It's all about Feedback
Recently Subway set the price of all their foot long sandwiches to $5 (any sandwich) which are great news specially in this tough times..
Now, how is this "important" event related with Software Development? Well for me this a big opportunity that Subway is missing to get to know their clients better since they don't register what kind of sandwich you buy. They don't really have an idea of what kind of sandwich sells better and which is not doing so well...
Many companies are willing to pay for marketing studies, surveys, etc. to get an opinion from their customers, what they like / don't like about their products, what could be improved, etc. and some companies don't take advantage of opportunities like this one to get that feedback from their clients.
Again... how is this related with software development? I believe the developer's best tool for software development is not a programming language, an IDE or what ever new geek stuff is out in the web. For me is feedback from your client, since it lets you make sure that you are doing exactly what they hired you to do.
This feedback will let you know what is the client thinking, are we doing exactly what he needs/wants?, is this field in that form actually required? is the user experience good and pleasant? are we saving all the information we need or are we missing anything? Do you really need this astronaut architecture for your simple image gallery...?
It's not about showing stuff just for the sake of showing something. It's about showing new stuff, new functionality, changes, new concepts, idea. Is trying to get the client (and perhaps the final users of the software) into the development cycle, getting comments, opinions, suggestions (after all - and hopefully - they will have a better idea than you of what they want/need)
How to do this? Constant builds, demo servers, make the application available for demoing as much as possible, screenshots, mockups, wireframes, isolate functionality and presenting it, continuous testing/integration, etc
And all of this, because is the client the one that requested your services and is the client the one that knows what kind of sandwich he wants. And when you see that the BMT sells better than the Turkey Breast sandwich you will try to repeat and improve the recipe every time...
Todo es Feedback
Recientemente la cadena de restaurantes Subway, puso todos sus sandwiches de un pie de largo a $5 (cualquiera de ellos) osea mucho mas barato de lo normal. Esto logicamente alegro el bolsillo de muchos de nosotros y pusieron la cadena de restaurantes como uno de los favoritos para la gente que almuerza afuera.
Ahora, que tiene que ver Subway con software, que es de lo que trata este blog? Pues me parece que la cadena o los restaurantes mismos estan perdiendo una valiosa oportunidad de conocer cuales son los sandwiches favoritos de sus clientes (no se registra que tipo de sandwich se compra) y al hacer esto no pueden utilizar ese feedback para mejorarlos, ponerlos en oferta, anunciarlos mas, etc...
Muchas empresas estan dispuestas a pagar por encuestas y estudios para saber cuales son los gustos/disgustos de sus clientes con su firma sin embargo otras no aprovechan oportunidades como estas para escuchar a su cliente.
Ahora... de nuevo que tiene que ver esto con Software? Pues como dice el titulo, todo es Feedback. La mejor herramienta de un desarrollador es el feedback que pueda recibir durante el desarrollo de la aplicacion. Es el feedback del cliente el que le indica si se esta yendo o no por el camino correcto, si esa pantalla tiene los datos correctos, si la tabla tiene los campos que verdaderamente necesita, etc.
Pero como hacer esto? Pues permitiendo al cliente y usuarios ver e interactuar con la aplicacion lo mas frecuentemente posible, tener dialogos con ellos, exponer screenshots o mockups, isolar funcionalidades y presentarlas por aparte, cualquier forma de interaccion que nos permita asegurarnos que el cliente esta siendo satisfecho con lo que vamos haciendo.
No se trata de ensenar cosas todos los dias a todas las horas aunque no se avance nada o este inestable. Se trata de meter al cliente (y usuarios finales si es posible) lo mas dentro del ciclo de desarrollo para asegurarnos que hacemos lo que ellos quieren/ocupan.
Este feedback nos ayudara a saber cuales son los "sandwiches" favoritos de nuestros clientes y cuando sepas que el Italian BMT vende mejor que el sandwich de pechuga de pavo, vas a intentar repetir y mejorar la receta...
Recently Subway set the price of all their foot long sandwiches to $5 (any sandwich) which are great news specially in this tough times..
Now, how is this "important" event related with Software Development? Well for me this a big opportunity that Subway is missing to get to know their clients better since they don't register what kind of sandwich you buy. They don't really have an idea of what kind of sandwich sells better and which is not doing so well...
Many companies are willing to pay for marketing studies, surveys, etc. to get an opinion from their customers, what they like / don't like about their products, what could be improved, etc. and some companies don't take advantage of opportunities like this one to get that feedback from their clients.
Again... how is this related with software development? I believe the developer's best tool for software development is not a programming language, an IDE or what ever new geek stuff is out in the web. For me is feedback from your client, since it lets you make sure that you are doing exactly what they hired you to do.
This feedback will let you know what is the client thinking, are we doing exactly what he needs/wants?, is this field in that form actually required? is the user experience good and pleasant? are we saving all the information we need or are we missing anything? Do you really need this astronaut architecture for your simple image gallery...?
It's not about showing stuff just for the sake of showing something. It's about showing new stuff, new functionality, changes, new concepts, idea. Is trying to get the client (and perhaps the final users of the software) into the development cycle, getting comments, opinions, suggestions (after all - and hopefully - they will have a better idea than you of what they want/need)
How to do this? Constant builds, demo servers, make the application available for demoing as much as possible, screenshots, mockups, wireframes, isolate functionality and presenting it, continuous testing/integration, etc
And all of this, because is the client the one that requested your services and is the client the one that knows what kind of sandwich he wants. And when you see that the BMT sells better than the Turkey Breast sandwich you will try to repeat and improve the recipe every time...
Todo es Feedback
Recientemente la cadena de restaurantes Subway, puso todos sus sandwiches de un pie de largo a $5 (cualquiera de ellos) osea mucho mas barato de lo normal. Esto logicamente alegro el bolsillo de muchos de nosotros y pusieron la cadena de restaurantes como uno de los favoritos para la gente que almuerza afuera.
Ahora, que tiene que ver Subway con software, que es de lo que trata este blog? Pues me parece que la cadena o los restaurantes mismos estan perdiendo una valiosa oportunidad de conocer cuales son los sandwiches favoritos de sus clientes (no se registra que tipo de sandwich se compra) y al hacer esto no pueden utilizar ese feedback para mejorarlos, ponerlos en oferta, anunciarlos mas, etc...
Muchas empresas estan dispuestas a pagar por encuestas y estudios para saber cuales son los gustos/disgustos de sus clientes con su firma sin embargo otras no aprovechan oportunidades como estas para escuchar a su cliente.
Ahora... de nuevo que tiene que ver esto con Software? Pues como dice el titulo, todo es Feedback. La mejor herramienta de un desarrollador es el feedback que pueda recibir durante el desarrollo de la aplicacion. Es el feedback del cliente el que le indica si se esta yendo o no por el camino correcto, si esa pantalla tiene los datos correctos, si la tabla tiene los campos que verdaderamente necesita, etc.
Pero como hacer esto? Pues permitiendo al cliente y usuarios ver e interactuar con la aplicacion lo mas frecuentemente posible, tener dialogos con ellos, exponer screenshots o mockups, isolar funcionalidades y presentarlas por aparte, cualquier forma de interaccion que nos permita asegurarnos que el cliente esta siendo satisfecho con lo que vamos haciendo.
No se trata de ensenar cosas todos los dias a todas las horas aunque no se avance nada o este inestable. Se trata de meter al cliente (y usuarios finales si es posible) lo mas dentro del ciclo de desarrollo para asegurarnos que hacemos lo que ellos quieren/ocupan.
Este feedback nos ayudara a saber cuales son los "sandwiches" favoritos de nuestros clientes y cuando sepas que el Italian BMT vende mejor que el sandwich de pechuga de pavo, vas a intentar repetir y mejorar la receta...
Binding / No Binding
Binding y no Binding...
Hace un tiempo escribi un post sobre binding y a continuacion muestro un ejemplo del uso del mismo.
Este ejercicio muestra la diferencia a la hora de actualizar objetos que usan binding y no.
Se tiene una clase que se llama Producto, con dos campos nombre y precio. Se cargan dentro de un ArrayCollection (que provee binding por si mismo) y se bindea el array collection a un datagrid. Cada vez que se selecciona un producto de la lista, se rellenan los campos de abajo con un objeto bindeado tambien. Al modificar dichos campos y apretar "Update", modificamos directamente el objeto seleccionado asi:
var prod:Product = products.getItemAt(grid.selectedIndex) as Product;
prod.name = namet.text;
prod.price = Number(price.text);
La aplicacion utilizando binding en la clase Product automaticamente nos refresca los campos modificados en el grid. La aplicacion que no utiliza binding al contrario se queda quieta... Si apretamos "reload" veremos los cambios aplicados.
Si en este mismo ejemplo, en lugar de actualizar el producto que esta dentro de la lista, crearamos una nueva instancia de un objeto Product y actualizaramos en el Array Collection con este nuevo objeto, el grid se modificaria automaticamente ya que el ArrayCollection provee binding por si mismo. Algo asi
var prod:Product = new Product();
prod.name = namet.text;
prod.price = Number(price.text);
products.setItemAt(prod, grid.selectedIndex);
El ejemplo trata de mostrar las diferencias entre ambos casos y la importancia de conocer cuando utilizar binding y cuando no.
Con Binding
Sin Binding
Codigo Aqui
Hace un tiempo escribi un post sobre binding y a continuacion muestro un ejemplo del uso del mismo.
Este ejercicio muestra la diferencia a la hora de actualizar objetos que usan binding y no.
Se tiene una clase que se llama Producto, con dos campos nombre y precio. Se cargan dentro de un ArrayCollection (que provee binding por si mismo) y se bindea el array collection a un datagrid. Cada vez que se selecciona un producto de la lista, se rellenan los campos de abajo con un objeto bindeado tambien. Al modificar dichos campos y apretar "Update", modificamos directamente el objeto seleccionado asi:
var prod:Product = products.getItemAt(grid.selectedIndex) as Product;
prod.name = namet.text;
prod.price = Number(price.text);
La aplicacion utilizando binding en la clase Product automaticamente nos refresca los campos modificados en el grid. La aplicacion que no utiliza binding al contrario se queda quieta... Si apretamos "reload" veremos los cambios aplicados.
Si en este mismo ejemplo, en lugar de actualizar el producto que esta dentro de la lista, crearamos una nueva instancia de un objeto Product y actualizaramos en el Array Collection con este nuevo objeto, el grid se modificaria automaticamente ya que el ArrayCollection provee binding por si mismo. Algo asi
var prod:Product = new Product();
prod.name = namet.text;
prod.price = Number(price.text);
products.setItemAt(prod, grid.selectedIndex);
El ejemplo trata de mostrar las diferencias entre ambos casos y la importancia de conocer cuando utilizar binding y cuando no.
Con Binding
Sin Binding
Codigo Aqui
martes, 10 de marzo de 2009
Degrafa Patterns
Update (2009-03-29): Download Code Here Example below
I've been trying to spend sometime learning Degrafa, a very nice declarative graphics framework for Flex.
I really like it and enjoy it. It is a very useful tool, specially because it lets you do in few lines very powerful graphic oriented tasks, like the one I just did below...
This pretty simple application allows you draw an icon in a grid, preview how the Icon will look in different sizes and then draw that icon into a canvas and display it as a pattern, that you can interact with since you are able to rotate it. All this using a some Bitmaps, BitmapData and the Surface, Rectangular and VectorFill objects from Degrafa with no hassle...
*Hopefully* I'll upload the code soon but this is a good example of how simple and powerful Degrafa is; for now feel free to try the final application...
Click here to run the application
BTW... did I mention Degrafa has a lot of examples and documentation on their site and that in fact it is an open source project?? :)
Suscribirse a:
Entradas (Atom)
