h1

5 Herramientas Opensource y 10 Frameworks de desarrollo que todo delivery engineer debería conocer (Parte I)

07/27/2007

[Tips + Tricks (Icon by Buuf)]

  Informática e Internet: Software Engineering

Un tema bastante espinoso a la hora de dimensionar una arquitectura es cómo la vamos a implementar, adicionalmente al qué hay que resolver. Tomando prestados los conceptos de ingeniería civil, es como saber con qué materiales vamos a construir (¿ladrillo, madera, monoblock, piedra?) y con qué herramientas podemos disponer (¿maquinaria automática, un ejército de albañiles?) a la hora de diseñar nuestra arquitectura final. Por otro lado, particularmente en esta industria siempre es deseable utilizar herramientas y frameworks opensource para minimizar los costos de producción y permanecer competitivos contra aquellas empresas que están casadas con alguna marca en particular: El ejemplo clásico es .NET, que obliga al arquitecto a utilizar toda la infraestructura, herramientas y componentes Microsoft e impide la flexibilidad que un JEE puede proporcionar. Claro que siendo justos, la suite de Visual Studio y herramientas relacionadas es excelente para construir aplicaciones .NET y al limitar las opciones permite arquitecturas más estables y homogéneas que las de JEE.

Tomando en consideración esto, y consultando con algunos conocidos acerca de sus propias preferencias, llegamos a la conclusión que hay ciertos frameworks y herramientas que adicionalmente a poder ser descargadas de manera libre desde la Internet, son muy útiles y facilitan los desarrollos disminuyendo el riesgo y la probabilidad de defectos durante la etapa de construcción:

Herramientas que pueden salvar a más de un proyecto

Para este punto, existen 5 herramientas indispensables para que cualquier desarrollador pueda sacar su chamba sin demasiada dificultad y el arquitecto que diseña la solución pueda preocuparse un poco más por el qué en vez del cómo. Esto es porque me he topado con quienes todavía utilizan vi o Notepad para desarrollar, y compilan a manita sus "proyectos" o utilizan un Excel para su Bug Tracking:

Herramienta:

Eclipse + Plug-ins (especialmente MyEclipse o Lomboz)

Tipo:

IDE

Desarrollado originalmente por IBM como un reemplazo de VisualAge for Java, posteriormente liberado como opensource, y actualmente en su versión 3.3, el Eclipse IDE es una de las herramientas de desarrollo más populares de la industria. Adicionalmente a facilitar la generación de proyectos, compilación y validación de sintaxis, la herramienta cuenta con toda una gama de plug-ins desarrollados por la comunidad Eclipse para extender su funcionalidad: desde permitir su uso para compilar en otros lenguajes como C o Python, hasta la generación automatizada de web services o la administración del ciclo de vida de nuestro proyecto. Algunos plug-ins tienen costo (como Lomboz o MyEclipse), pero ninguno pasa de los US$60, haciéndolos muy competitivos y especialmente útiles para proyectos de alta complejidad.

Herramienta:

SOAP UI

Tipo:

Testing de Web Services

Un problema al que me he enfrentado con relativa frecuencia es probar la funcionalidad de un http web service de manera rápida y eficiente. Parecía que para probar web services no desarrollados por nosotros era todavía peor: era necesario utilizar alguna herramienta o IDE para convertir el WSDL a objetos de java y generar un cliente. Con SOAP UI sólo basta proporcionar el URL del WSDL (o el path si es que ya lo tenemos de forma local) y ¡voila!: ya podemos hacer un request y validar el response en su formato SOAP XML. Y si nos queremos ver con iniciativa, podemos aplicar incluso pruebas de carga con este mismo request.

Herramienta:

WebLOAD

Tipo:

Pruebas de desempeño, carga y estrés

Hay algunas herramientas muy buenas en el mercado (me salta a la mente el WebServer Stress Tool), pero contar con una herramienta fácilmente configurable y opensource, existen pocas. Una de ellas es WebLOAD, originalmente desarrollada por Radview Software pero liberada como opensource más tarde. La ventaja principal: el script recording (o generación del camino de pantallas a seguir durante la prueba de estrés) es muy sencillo de aplicar. Adicionalmente pueden programarse pruebas y ver los resultados de manera muy puntual.

Herramienta:

SubVersioN + SVN Tortoise

Tipo:

Control de Versiones/Administración de la Configuración

En cualquier proyecto, por más pequeño que sea, se necesita un control de versiones: he sido testigo de desarrollos se realizan sin tal control, llegando al extremo de implementaciones con hasta 5,000 horas/hombre tiradas a la basura porque se batieron las versiones. Ahora bien, los repositorios más usados son Visual Source Safe de Microsoft y Concurrent Version System (CVS). Ambos con sus pros y contras, pero el que se está poniendo de moda es Subversion: Desarrollado por CollabNet, es el sustituto de CVS con una calidad de tal grado que es considerado como el mejor software standalone de administración de la configuración del software. Por otro lado, SVN Tortoise es un excelente cliente de subversion que está integrado al Windows shell, para aquellos que no somos adeptos a usar líneas de comando para usar el repositorio.

Herramienta:

Scarab y Bugzilla

Tipo:

Rastreo de incidencias (Bug Tracking)

Conforme aumenta la complejidad de un sistema y el número de personas que participan en él, así se reflejará el número de incidencias que surgirán. Desde el típico "la ortografía no ha sido revisada" hasta "¡al loguearme se cae el servidor de bases de datos!", los bugs reportados por el equipo de calidad o el mismo cliente deben ser documentados y se les debe llevar un correcto seguimiento: desde el descubrimiento del mismo hasta la liberación del fix correspondiente. Para ello hemos encontrado que los dos mejorcitos son Bugzilla (viejo pero de excelente usabilidad) y Scarab (más moderno, que incluso puede acoplarse a subversion).

La próxima semana continuaré con los frameworks, que seguramente la mayoría los conoce: Spring, Hibernate, Log4J y otros 7 que caen en la categoría de "indispensables" para la mayoría de los proyectos. Eso sí, como dijo mi antiguo maestro de la UDLA, el Dr. Gerardo Ayala: la neta del planeta no existe, y nada es la verdad de la vida. O lo que es lo mismo: como arquitectos lo peor que podemos hacer es adquirir el síndrome de la bala de plata.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: