viernes, febrero 18, 2011

La idea de nuestro propio “Framework”

Creo que muchos de los desarrolladores hemos tenido la idea e incluso iniciado el desarrollo alguna vez de nuestro propio “Framework” para generar aplicaciones. No veo malo el escribir otro Framework. Pero muchas veces solo terminan limitándose, haciendo lo fácil mas fácil y lo difícil casi imposible, poco flexibles. Se vuelven una carga que mantener. Algo con lo que los desarrolladores no están muy entusiasmados en trabajar, porque prefieren usar algo nuevo.
He notado que esos pequeños Frameworks tienen algunas características en común (esta no es una receta, solo son unos de los problemas comunes que he visto en esos pequeños frameworks privados):
No se conocen los frameworks existentes: Lo más seguro es que ya exista algo que hace lo que se quiere lograr. Puede que se trate de un problema resuelto. Quizás lo mejor sea contribuir a un proyecto open source existente, agregando las características que se necesitan. Si la idea es hacer lo mismo que ya hace otro Framework, debe haber una razón más fuerte que el solo no tomarse la molestia de aprender a trabajar con los existentes.
No tienen un proyecto real donde usarlo: Sin una aplicación real donde probar los conceptos es difícil que se le atine a lo que realmente se necesita en un proyecto real. Puede tomarse en cuenta la experiencia de proyectos anteriores. Aun así creo que uno de los riesgos que se corre al no tener un proyecto donde probarlo es agregar características que no se necesitan u omitir las necesarias.
No son de código abierto (Open Source): Varios de estos pequeños frameworks son para uso exclusivo de quien lo desarrollo y a veces no quieren mostrarle el código a nadie fuera de la empresa, como si alguien les fuera a robar la idea y teniendo el secreto ya nadie necesitaría (contrataría) del autor del framework. Cuando en realidad es todo lo contrario, Al liberar el código de la librería/framework ayuda a que el código tenga mas ojos; y mas ojos pueden ayudar a que el proyecto sea mejor. Además de que es una buena oportunidad de que el autor se de a conocer en la comunidad (publicidad) y que la comunidad se beneficie de esto, ambas partes ganan, pero sobre todo código.
No conocen la teoría: Conocer la teoría para que la practica tenga mas sentido. Cuando el proyecto tiene buenas bases teóricas logra ser mas consistente en la manera como esta desarrollado y tanto la mantenebilidad, como su extensibilidad generalmente logran ser mayor.
Quieren abarcar mucho: El no tener un objetivo claro o un problema concreto el cual se quiere resolver termina generando una gran cantidad de código que nadie quiere usar.
El desarrollo de un framework es una buena actividad para ser un mejor desarrollador, es algo que se debe intentar (más si es en un proyecto open source). La innovación puede ocurrir. Si conociendo las soluciones existentes se cree necesitar una opción mas, pues adelante.

viernes, febrero 11, 2011

Comunicación con messenger en la oficina

Ahora que volví a trabajar desde la oficina, con compañeros de trabajo (antes trabajaba desde mi casa) he notado que mucha de la comunicación entre los desarrolladores, incluso con la administración, se da a través del messenger e incluso por redes sociales como twitter y facebook (aunque por estas la comunicación es mas informal). Es algo que ya venia haciendo, pero pensé que era porque no estaba físicamente ahí con ellos.

Al principio no me gustaba tanto y prefería levantarme e ir al lugar de los demás. Empece a notar que era de los pocos que hacia eso y sentía que estaba distrayendo a la persona que con la estaba hablando y a los de su alrededor.

Ahora uso mas el messenger (mensajero en español) para hablar con mis compañeros (aunque estén a lado mio) y he notado que tiene algunos beneficios que explico a continuación.

Debido a que somos muchos personas trabajando en la oficina, es casi imposible que a todos nos guste la misma música; por eso el uso de audífonos es algo común. Esto hace que al escuchar música (con los audífonos) logres cierta concentración hacia la computadora. El problema con una interrupción en persona es que obliga a "desconectarse" para poder atenderla. En cambio si la interrupción es a través del mensajero; entonces se puede atrasar un poco, no "desconectarte" en ese momento y después atender el mensaje cuando se tenga oportunidad. Incluso aunque se atienda el mensaje de inmediato, el no tener que poner en pausa la música y quitarte los audífonos para responder, logra que se pierda menos la concentración de lo que se esta haciendo.

Esto me hace pensar que si toda la comunicación se da a través de medios electrónicos, entonces ¿por que no trabajamos todos desde nuestras casas? Con las herramientas actuales de comunicación fácil podríamos todos trabajar desde casa; pero el problema es que no todos pueden. Hay para quienes trabajar desde casa implica muchas distracciones en persona, o simplemente se distraen por otras cosas, etc.

Extraño los días en que todo el equipo trabajaba escuchando la misma música (o sin música), cuando no había necesidad de audífonos. Y hablábamos sin necesidad del mensajero, pero ahora veo las ventajas y me parece una buena idea, porque hay quienes en la oficina no lo usan para hablar entre ellos y distraen a los demás con sus discusiones técnicas.

jueves, febrero 03, 2011

Desarrollo Web Arrastrando y Soltando

Hace unos días necesitaba realizar una aplicación web en muy poco tiempo. Debía mostrar un demo en un día; así que decidí olvidarme de las buenas practicas por un día y (usando ASP.NET WebForms) empezar a arrastrar y soltar componentes a mi página. Diseñando las paginas de captura y lectura (Grids) sin ver el markup que VisualStudio me iba generando.

Tenia mucho tiempo sin trabajar en Design View, pero no tenia tiempo de ponerme a editar el markup a mano. Una vez creadas las páginas (a la drag and drop) usando el ratón empece a conectar mis GridViews y DropDownsLists usando LinqDataSources. Todo esto con la ayuda de wizards, en algunas consultas utilice views definidas en la base de datos (MS SQL Server) también con la ayuda de diseñadores, no use SQL para definir mis views. (Creo que tenia años sin usar Views y menos de usar el query designer).

No pudieron faltar los lugares donde necesite algo de código y para ello LinqToSql me ayudo a realizar las consultas y/o actualizaciones a la base de datos. Como no tenia mucho tiempo y el código era poco opté por escribirlo directamente en los event handlers (button_click, etc). Donde el código crecía un poco entonces sí agregaba una clase para no tener métodos muy largos.

Al final el demo se pudo terminar en un día y la aplicación estaba lista para usarse en un semana. El haber podido entregar una aplicación en una semana me ha hecho reconsiderar mi opinión sobre el desarrollo web hecho arrastrando y soltando.

Se que el problema vendrá con el mantenimiento. Precisamente esta es una de las razones por las que deje de hacer desarrollo arrastrando y soltando; Pero el poco código que escribí es facil de mantener (al menos así lo veo ahora) y si despues necesito algo mas complejo podria refactorizarlo y apoyarme en pruebas unitarias para eso.

No se... me puso a pensar que tal vez si hubiera seguido las buenas practicas (TDD) quizas no hubiera terminado a tiempo y por lo tanto el proyecto se hubiera perdido.

Con esto no quiero decir que de ahora en adelante puro drag en drop (veremos como nos va con las nuevas features). Solo quise compartir mi experiencia en un proyecto pequeño y rápido del cual me sentí bien del código entregado y del poco tiempo que nos tomo hacerlo (Aunque fuera a la Drag and Drop) .