lunes, marzo 21, 2011

Aplicar lo nuevo lleva su tiempo

Uno de los “problemas” que he encontrado al querer aplicar técnicas, usar librerías, frameworks, lenguajes, etcétera. De los que he leído e incluso usado en algún pet Project. Es que al momento de querer aplicarlo en algún proyecto real, este tienen fechas de entrega a muy corto plazo y por lo tanto lo más “seguro”, para cumplir con esas fechas de entrega, es haciéndolo utilizando lo ya conocido y probado en proyectos anteriores.

No es común que el cliente nos pida alguna aplicación y nos de el tiempo necesario para aprender la tecnología a usar. Primero porque desea el sistema lo más rápido posible y segundo porque no quiere cubrir el costo del tiempo invertido en aprender lo nuevo. Cuando al final el recibe el mismo sistema, no importando la tecnología o técnicas usadas en el desarrollo.

Pude ser que esta necesidad sea mas del desarrollador, ya que es él el que trabaja directamente con la tecnología (ya sea framework,lenguaje de programación, etc).

Para poder aplicar/implementar algo nuevo en un proyecto real requiere de un esfuerzo adicional al que se necesitaría para aplicar lo que ya se conoce. Todo, por fácil que sea, tiene su curva de aprendizaje, sus ventajas y sus desventajas y debes de haberte encontrado con algunas de ellas antes de poder usarlo en producción, para que así sepas como resolver lo posibles problemas que se presenten.

Pero entonces. ¿Como puedo aplicar o usar lo nuevo en los proyectos de mi trabajo, si nunca tengo el tiempo necesario? Algo que he tenido que hacer al querer aplicar algo nuevo en proyectos del trabajo es primero practicar por fuera en proyectos personales (a.k.a. pet projects) la tecnología/técnica que me interesa y en una oportunidad que se presente proponer el uso de tal tecnología o técnica. Esta propuesta procuro hacerla mostrando algo ya funcionando (un demo funcional), para convencer de las bondades que tiene utilizar lo nuevo.

Esto requiere dedicarle tiempo extra al trabajo, porque lo aprendido en pet projects lleva su tiempo aplicarlo en proyectos reales. Puede incluso llegar a ser frustrante tardar en realizar algo sencillo que usando lo que ya conocemos lo haríamos en minutos; pero a la larga es aun más frustrante (por lo menos para mi) el trabajar con técnicas/tecnologías viejas, con las que no puedo lograr lo que se que es posible realizar con algo nuevo.

De no dedicarle tiempo por mi cuenta a practicar lo que quiero usar, la decisión de usar algo diferente correría totalmente a cargo de alguien más, ya sea el cliente, jefe o algún programador más que hiciera la sugerencia. Para algunos eso no es problema, esperar que a el jefe/cliente se le ocurra intentar algo nuevo (a veces hasta que ya no es tan nuevo, incluso ya viejo); pero para mi conocer y no aplicarlo no es divertido.

Entonces: Si quiero usar algo nuevo tengo que proponerlo, lo mejor seria hacerlo mostrando avances donde puedan verse las ventajas. Esto requiere algunas veces dedicar algo de mi propio tiempo para aprender las nuevas tecnologías y así poder convencer a los clientes/jefes que estamos listos para usar la tecnología/técnica nueva, porque el cliente no quiere pagar la curva de aprendizaje.

lunes, marzo 14, 2011

La practica hace al maestro

Hace unos días tuve la oportunidad de dar una capacitación (en el .Net Framework) a unos compañeros de trabajo que acaban de egresar de la universidad y que aun no tienen experiencia laboral. Algo común entre ellos era la falta de practica al momento de empezar a escribir código. Podían entender fácilmente el ejemplo escrito por mi, pero no les era igual de fácil escribir código propio.

Me di cuenta que algunos tomaban varias notas en papel sobre lo que íbamos haciendo, en lugar de ponerse a practicar. Esto me hizo pensar que el aprender (y mejorar) a programar debe de hacerse de la misma forma en la que se aprenden las matemáticas. No basta con saber los procedimientos para resolver un problema, es necesario practicar las operaciones con varios ejercicios para poder dominar el tema (y resolver los problemas mas rápido y fácil).

Cuando aprendemos a sumar, restar, multiplicar, dividir, etcétera. La parte de tomar notas es muy poca, la mayor parte del aprendizaje se da al practicar. Lo mismo pasa con la ortografía, no es solo conociendo las reglas, es con la practica constante como aprendemos a escribir mejor y cometer menos faltas de ortografía (como reconocer las palabras que llevan acento).

También se podría comparar con el aprender un segundo idioma, llega un momento en que puedes entenderlo casi perfectamente pero para poder hablarlo correctamente se necesita de practica, equivocarte constantemente hasta que puedas darte cuenta que algo no suena bien y busques una mejor forma de expresarlo. Y si dejas de practícar puede ser que algunas palabras se te olviden aunque no tuvieras ningún problema en entenderla si alguien mas la dice.

Considero para que un desarrollador profesional pueda seguir superándose es importante leer, ya sea blog posts, artículos, código de algún proyecto de código abierto, screencasts, podcasts, en fin… consumir y producir contenido técnico. Pero algo que ayuda mucho a ser un mejor desarrollador es la practica constante, escribir muchas líneas de código, cometer errores y aprender de ellos (echando a perder se aprende). Así que además de leer y tomar notas es necesario practicar constantemente, porque (ya lo dice el viejo y conocido refrán) “la practica hace al maestro”.

sábado, marzo 12, 2011

NuGet Manejador de paquetes

Al trabajar en proyectos en .Net es común hacer uso de librerías de terceros, ya sean de código abierto e incluso de algunas con código propietario. Para usar estas librerías necesitaba ir al sitio de cada una de ellas y descargar la última versión (o la que necesitara) y descargar los archivos, después agregar una carpeta al nivel de mi archivo de solución de VisualStudio que acostumbraba llamarla “Lib” y ahí agregar los DLLs de terceros que usaría en mi solución.

Ahora con NuGet, el manejo de dependencias se simplifica. Lo primero que necesito es instalarlo, lo cual lo puedo hacer desde VisualStudio, usando el Extension Manager y buscando “NuGet”

extension_manager_nuget 

En algunas maquinas con esto fue suficiente, sin embrago (desconozco la razón) en una de mis maquina no pude instalarlo a través del extension manager. Lo que hice fue instalarlo desde nuget.org

nuget.org 

Una vez instalado se debe de reiniciar VisualStudio y aparece una nueva opción en el menú de Tools (Herramientas) y en el menú de View > Other Windows

tools

Con esto se puede abrir la consola de NuGet (se necesita tener instalado PowerShell 2.0) y descargar e instalar desde ahí los paquetes (librerías) que se necesiten para el proyecto actual.

nuget_console

En un proyecto en particular necesitaba instalar MSpec, para eso solo ejecuté en la consola de NuGet:

PM> Install-Package Machine.Specifications


NuGet se encargó del resto: descargar dlls, agregar referencias, etc. El único ajuste que tuve que hacer en mi manera de trabajar es que nuget usa una carpeta llamada “packages” en lugar de “lib” como yo lo hacia. Pero es un pequeño cambio que bien vale la pena para aprovechar lo que hace NuGet por mi.

martes, marzo 08, 2011

Al desarrollador le gusta desarrollar

Seguido leo (y escribo) comentarios, tweets, posts, etc sobre lo mal que la pasamos en ciertos proyectos en los que trabajamos. Aun y cuando lo que nos gusta hacer, como desarrolladores que somos, es desarrollar. ¿Entonces por qué es que surgen estas situaciones de descontento entre los desarrolladores?

Considero que parte del problema es la falta de decisión que se tiene sobre el curso de algún proyecto, la arquitectura, metodología, framework, (peor cuando nos toca usar el intento de framework que hizo alguien más), etc. Esto hace que el desarrollador se sienta como un code monkey, alguien que hace la talacha y no como alguien que desarrolla soluciones para las necesidades del cliente. No hay motivación.

Al participar en proyectos con diferentes empresas he notado que en los proyectos que he sufrido mas frustración, al trabajar en ellos, es cuando el cliente ya eligió que usar y peor cuando ya eligió el como hacerlo. Al iniciar o continuar el desarrollo del proyecto me encuentro con que la decisión del cliente no fue la mejor, muchas veces basada en las viejas formas de hacer las cosas o basado en la tecnología que un tercero le vendió. Esto hace que haya cierta frustración en el desarrollo del proyecto porque estoy en problemas por culpa de alguien más.

Este descontento también aparece cuando no se entienden bien las necesidades del cliente. Ya sea porque se trata de un sistema ya establecido y solo se pide que se corrijan algunos errores. Y no se quiere perder tiempo en explicarle al equipo la importancia de lo que hace el sistema. Esto hace que el desarrollador no sienta el proyecto como suyo y por lo tanto no sienta motivación para mejorarlo.

En cambio cuando se trabaja en proyectos donde el cliente explica, no solo las necesidades sino también las razones por las cuales es importante. Incluso que nos explique porque eligió la posible solución y el como. De una manera en la que el equipo pueda aportar y mejorar esa idea. Es cuando se siente una mayor motivación para trabajar en ese proyecto.

Hace poco grabamos un episodio de Dev3Cast y ahí nos comentaba Iván González sobre la importancia de la confianza en el equipo. Y la importancia de la opinión de todos los desarrolladores, incluso de aquellos que aun no tienen experiencia.

Esto puede ayudar a que el desarrollador sienta el proyecto como suyo y este dispuesto a dar un poco más de esfuerzo con tal de que se logre un mejor resultado, mientras hace lo que le gusta. Los managers deben de tomar ventaja de que al desarrollador le gusta desarrollar.