Implementando Flex2 en el “Mundo Enterprise” - III (uniendo java y flex)

7 02 2007

No hay mucho que contar, pero lo poco que hay es significativo. Resulta que estoy planteando una infraestructura en la cual un server Jboss 4 con webServices programados en java interactúan con la base de datos. Los mismos son consumidos mediante Flex. El tema es que si uno está trabajando en ambas plataformas, por ejemplo, programando los webservices y testeándolos por frontend, hay que tener el Flex Builder y el Eclipse(de la distro que uses) funcionando al mismo tiempo. Esto representa una sobrecarga para el equipo, más si el Jboss y el MySQL se encuentran “levantados” para probar las cosas.

Lea el resto »



Implementando Flex2 en el “Mundo Enterprise” - II

6 02 2007

Flex 2 no es SOA, no se puede implementar SOA solo con flex 2. Consumir webservices con flex2 no implica que estes implementando SOA. En esta nueva entraga de la serie “Implementando Flex2…etc” explico por que.
Lea el resto »



Implementando Flex2 en el “Mundo Enterprise” - I

4 02 2007

flex2.pngEn el lugar donde estoy trabajando actualmente estoy involucrado en un proyecto muy interesante, cuyo objetivo es crear un plan de trabajo en el cual se definan herramientas y metodologías para realizar aplicaciones web “Enterprise”, es decir, aplicaciones seguras, destinadas a manejar algún aspecto del negocio de la empresa para la cual se construyen.

Con “manejar algún aspecto del negocio”, me refiero a que manejan dinero en forma de stock, en forma de servicios, o, llegado el caso, en forma de dinero ;-) .

Lo que acabo de mencionar dio origen a la serie de artículos “flex2 en el mundo enterprise” los cuales serán una bitácora de lo que se irá implementando y de las consideraciones y experiencias con que nos vayamos encontrando.
Lea el resto »



¿Para que sirve un blog?

22 01 2007

¿Para que sirve un blog? Es una pregunta que ronda las mentes de muchos, incluso en la de los que tenemos uno. Para muchos, obtener un blog es algo incluso mas trivial que obtener un teléfono celular, hay numerosos sitios de Internet que ofrecen este servicio de forma gratuita a sus afiliados, por lo que tener un blog propio puede tomar, a lo sumo, 10 minutos. Para otros, los más perfeccionistas o los que no se llevan bien con la tecnología, este tiempo puede dispararse a la hora de personalizarlo para que se vea y se sienta de la forma que a uno lo convenza, o simplemente porque lo piensan muy bien antes de presionar “siguiente, siguiente, siguiente”.
Lea el resto »



Conocer la tecnología no alcanza para hacer sistemas

10 01 2007

Estaba pensando por que demonios escribir software es tan difícil. Digo que es difícil porque hasta los supuestos expertos tienen un alto porcentaje de fracasar en entregar software estable, facil de usar, documentado y a tiempo.

Para que se den una idea, el 60% de los proyectos(en general, no solo de software) fracasan, todos hablan de eso en publicaciones como peopleware y varios artículos de intertet, solo hay que preguntarle al tío google para tener un puñado de ejemplos. De hecho, es el argumento de venta de Microsoft Project.

Por mas años de experiencia que uno tenga, por caras que sean las herramientas, por mas experiencia que el personal tenga sobre las herramientas, parece imposible hacer que un sistema nuevo salga bien “de una”. ¿Como puede ser que, teniendo gente que conoce perfectamente la tecnología con la que está trabajando y, no pueda hacerse un sistema que cumpla con las expectativas del cliente al primer intento? Ni hablar de tener un porcentaje de fracasos del 60%!. Y todo esto solo teniendo en cuenta proyectos en los que se decide no continuar. ¿Que hay de los sistemas que son construidos pero nunca son utilizados porque se descubre que representan un estorbo para el procesos que se deseaba agilizar?

Parece una locura que, en una civilización con una fuerte dependencia por el software, no seamos capaces de dominar completamente la construcción de este. La respuesta reside en el hecho de que los sistemas son hechos y usados por personas, por lo tanto, están sujetos a la mecánica de las relaciones humanas y, por ser el producto de un dialogo entre dos o mas grupos humanos, son especialmente vulnerables a la falta de comunicación entre las partes.

Por lo anterior, llegamos a la conclusión que aparece como punta de lanza del libro peopleware:

“Los factores que causan el fracaso de proyectos informáticos son de índole sociológico, no tecnológico.”

La complejidad del software reside en la especificación, diseño y testeo de la construcción conceptual, no en decidir como se llamaran las funciones y variables, el formato de los comentarios o la plataforma que se utilizará(aunque esto último no es tan trivial como suena en lo que acabo de decir).

¿En que cambia que una aplicación este hecha en .NET, Java, RUBY o .TXT si no se comprende cual es el objetivo que persigue y que necesidades trata de satisfacer?

El profesional en sistemas debería poner igual énfasis en conocer la herramienta en la que se está especializando que en dominar el arte de la comunicación. Tomemos como ejemplo a Linux. El famoso Sistema Operativo open source no sería lo que es si Linus Torvalds no hubiera sido capas de transmitir sus ideas en un por escrito, convocando a la cantidad de personas que convocó para participar del desarrollo.

Estudios realizados indican que dos de las habilidades más importantes que buscan las personas encargadas de contrataciones son las técnicas de comunicación oral y las aptitudes interpersonales(Goleman, 1998, pp 12-13). Aun en campos tan técnicos como la ingeniería, 72% de los encargados de seleccionar personal indicó que la facilidad de palabra era un factor muy importante(Darling y Dannels, 2003, p. 12).

Es importante indicar que por “técnicas de comunicación oral” o se esta hablando de pararse frente a un auditorio para protagonizar un monologo. También consiste en aprender a escuchar y a almacenar los datos que resultan de las entrevistas con el cliente. Es decir, aprender a tomar apuntes.
¡Cuan importante es esto!. Aprender a hacer cuadros sinópticos, plasmar taquigráficamente los requerimientos, características del workflow…en fin, toda la voluminosa cantidad de detalles que puede llegar a contener un sistema. A veces, un buen diagrama puede resultar mas esclarecedor que todo un cuaderno lleno de palabras.

Estas disciplinas no son mas complicadas que aprender cualquier lenguaje que ande dando vueltas por ahí, y los considero herramientas esenciales a la hora de encarar el análisis de un sistema para llevarlo al código.

Para más información acerca de los componentes sociológicos del desarrollo de los proyectos aconsejo leer el libro titulado peopleware, de donde tomé varias de las reflexiones expuestas aquí. Material valioso puede sacarse también del libro ¡Comunicate!
, también disponible en castellano.