Integrando aplicaciones y sobreviviendo a ello

- "Ya está listo! Dalé probá!!"
- Mmmmm... no amigo, no funciona!
- "Es en serio?? Si yo lo probé!"
- Si... pero no funciona! Te voy a enviar el log con el error para que lo revises.
- "Ok mandalo! Solo que voy saliendo, pero lo veo mañana a primera hora..."











Photo By Zach Klein


Y así termina otro día para el programador de front end, donde no pudo avanzar todo lo que quería y donde tendrá que atrasarse unas horas mas para poder terminar sus tareas.

Esta es una historia repetida diariamente para muchos programadores de clientes para internet, donde sus aplicaciones son apenas la interfaz de acceso para sus usuarios a servicios con bases de datos, servicios externos y demas aplicaciones que pueda tener un sitio corporativo.

Hablando con mi colega y amigo Ivan Alvarez - quien trabaja en la Bolsa Nacional de Valores en Mexico desarrollando aplicaciones financieras de ultima tecnología con Adobe Flex y Java en el lado del servidor - nos dimos cuenta que nuestros trabajos aunque son en areas totalmente distintas (yo trabajo para Scrapblog un sitio en Flex para crear tarjetas y manualidades digitales) enfrentamos estas mismas situaciones aunque estemos a miles de millas de distancia, con gente completamente distinta.


Photo by: http://www.lumaxart.com/

La integración de aplicaciones con clientes en Flex y código de servidor se puede convertir muchas veces en una tarea titánica y dolorosa. Sin embargo estamos convencidos que no debe ser así:

• Existen distintas formas para comunicarse: Webservices, Rest Services y Remote Objects.
• Los tres metodos son robustos, probados y comprobados.
  
• Para Remote Objects, existe un protocolo de comunicacion (para la serializacion y deserializacion de la informacion) definido por Adobe que es AMF3. Este protocolo es bastante rapido, comprimido y binario lo cual hace que la informacion se transmita mas rapido.
  
• Este protocolo ha sido implementado multiples veces para distintas plataformas, empezando con Java (BlazeDS, LifeCycle Data Services, Weborb, GraniteDS), .Net (Weborb, FluorineFx), Rails (Weborb, RubyAMF), PHP(Weborb, AMFPHP), entre otras. Esto quiere decir que puedes hacer tu backend en el lenguaje que quieras y utilizar esta implementación de AMF para comunicar tu aplicación Flex con el servidor de manera rapida, robusta y segura.

Con estos antecedentes, podemos decir que crear aplicaciones en Flex conectada a un servidor de aplicaciones con bases de datos o cualquier servicio que se ocupe es bastante sencillo. Sin embargo el problema que mas sufrimos es cuando tratamos de comunicarnos con los servicios expuestos por nuestro servidor. Generalmente hemos visto los siguientes problemas:

• Los servicios no estan correctamente configurados y por lo tanto es imposible a nuestras aplicaciones accesarlos.
• El nombre de los métodos no son los mismos que como se definió previamente (si es que tiene la suerte que le definan los nombres de sus servicios en algún lugar como un Wiki, email o un documento más oficial.
• La signatura de los métodos no es la misma que la que esta documentada (error muy parecido al anterior)
• El servicio no fue probado y sus métodos tiran excepciones cuando son llamados. Este es el mas común. Parece que nuestros amigos de backend nunca prueban, ya sea por Unit Testing o al menos ejecutar desde un cliente la invocacion al método. Esto tan simple, puede ayudarlos a ellos a darse cuenta mas tempranamente que hay errores y arreglarlos antes de decirnos que ya esta listos nuestros servicios.
• Problemas de serialización al enviar la información. Debemos recordar que hay una capa intermedia entre nuestra aplicacion cliente y nuestro servidor. Ese se va a encargar de convertir nuestra informacion y datos en terminos que nuestra contra parte pueda entender. Por ejemplo algunas implementaciones del AMF3 tienen problemas a la hora de serializar fechas (zonas de horario, 24 horas vrs 12 -AM/PM, etc), otras problemas a la hora de serializar numeros, las enumeraciones por ejemplo son estructuras que no todas las implementaciones soportan. Este tipo de problemas hacen que la integración sea mas lentas, es un constante hacer/probar/repetir.

Ahora, todo esto presentado anteriormente no quieredecir que no hay manera de solucionar esta situación:

• Documentacion de los servicios, métodos, parametros, valores de retorno,excepciones, etc. No tiene que ser una documentacion de 3 paginas por servicio. Lo minimo debe incluir eso que puse arriba. Muchos desarrolladores sienten pereza de hacer esta documentacion y ahi es donde empiezan los problemas.
• Uso de unidades de prueba (o algún tipo de prueba) en el código del servidor que sea ejecutado antes de "entregar" el código.
  
• Como dije anteriormente, existe una capa intermedia entre nuestro cliente y el servidor y ocupamos probar que esa capa funciona correctamente, por eso es bueno probar nuestros clientes y los respectivos llamados al servidor con utilidades como Flex Unit 4, Fluint, etc. Incluso algunas herramientas para llamados remotos (como Weborb) incluyen consolas para probar directamente estos servicios desde un ambiente creado en Flex.
• Investigar la herramienta que utilizamos y conocer cuales son problemas conocidos en las mismas. Investigar más del proceso de serialización esto nos ayudara a reconocer posibles problemas tempranamente.
• Aprender un poco como es el desarrollo en el lado del servidor. Si tienes ese conocimiento vas a tener un valor agregado en el mercado y ademas vas a conocer más del proceso y poder ayudar a detectar errores, sugerir formas de implementación, etc.
  
• Enseñar. Si tienes estos conocimientos de arriba, enseñar a otros desarrolladores sobre todo esto. Iniciar la chispa en ellos para que investiguen igual. Esto debe ser de conocimiento para la mayoría de personas en el proyecto.
  
• Cruzar los dedos y esperar que todo salga bien... :-P
  

Saludos!

Posts Relacionados

Integracion de Aplicaciones
Pruebas de Integracion
Llamadas Asincronimas
Interaccion con sistemas remotos

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.

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...

Codificador o Desarrollador...?

Semanas atras tuve una conversacion con un colega acerca de la diferencia entre un codificador y un desarrollador de software.
A mi gusto (mi opinion) es clara la diferencia, un excelente codificador (de los que hay muchos) son esos capaces de lograr cosas increibles, ganar concursos, hacer las cosas mas fuera de este mundo, rockstars... sin embargo a la hora de trabajar en equipo, seguir procesos, lineamientos, metodologias, se vuelve complicado y hasta imposible de trabajar con el. Excelente escritor de codigo!
Un buen desarrollador, me parece (mi opinion) que tiene mas implicito: aparte de ser un buen codificador debe tener buena comunicacion tanto verbal y escrita (de hecho se dice que el trabajo de un desarrollador incluye un 70% de su tiempo comunicandose, sea por codigo, escrito o verbalmente; sin embargo esto es en lo que menos nos preocupamos por mejorar), buen analisis y creatividad para resolver problemas, trabajo en equipo, ayudar a los otros, mejorar a las demas personas, aprender de otros, seguir procesos, estandares, agilidad y muchos atributos mas, que hacen que no sea la unica estrella de un equipo, sino que el equipo completo sea la estrella...
Opionion mia claro, pero en realidad cada dia quiero ser un excelente desarrollador...