miércoles, junio 29, 2011

Reunión 44 de Tijuana .Net Sobre Razor

Razor

El día de hoy estaré presentando en la reunión 44 de la comunidad el tema de Razor. Hablaremos de la sintaxis de razor usando WebMatrix en webpages y después un ejemplo de un blog usando razor en asp.net mvc en Visual Studio.

Los temas serán:

  • Code blocks
  • Syntax, encoding
  • Code expresions
  • Html Helpers en razor
  • Layout
  • Sections
  • Html helper en C#
  • EditorTemplates
  • Partial Views
  • Html.Action

Esperamos grabar la presentación y mostrarla aquí y en la página del evento.

viernes, junio 17, 2011

Adicción a la Refactorización

Siempre que trabajo en una nueva característica, para algún proyecto, modifico el código antes de entregarlo. Tratando de hacerlo más compacto y/o fácil de leer. Esto con la intención de mejorar la calidad del código.

También cuando necesito modificar cierta funcionalidad existente, cambio el código antes de implementar los cambios. Con la intención de entender mejor la funcionalidad actual y así dejar todo listo para realizar los cambios que se requieren implementar. Una vez hechos los cambios vuelvo a buscar áreas donde haya oportunidad de refactorizar…hasta ahí creo que todo va bien. El problema viene cuando se convierte en una especie de adicción.

Hay ocasiones que al trabajar en alguna característica determinada me encuentro con algún trozo de código “malo” que no esta relacionado con lo que estoy trabajando y aun así siento la necesidad de modificarlo. A veces logro aguantarme las ganas; pero otras veces simplemente no puedo evitarlo. También me pasa cuando algún compañero de trabajo me pregunta  algo especifico y al mostrarme el código quiero empezar a modificarlo, cuando ese no es el punto de la pregunta que me hicieron. Aunque estoy tratando de que el código sea mejor, puede convertirse en un problema.

A veces no se si lo hago por el proyecto o lo hago por mi. El código “malo” puede ser mucho, por lo tanto requiere algo de tiempo. Aunque hay herramientas que ayudan con la refactorización (ya sea como parte del IDE o como plugins), aun así es tiempo que le estoy quitando a tareas que el cliente espera y que están pendientes por realizar.

Estoy convencido de que La refactorización constante ayuda a la calidad del código, mantiene activo al proyecto, previene en cierta medida que el proyecto se vuelva legacy. Pero también debo aceptar que existe código que se puede mejorar y que esta bien (si funciona) dejarlo así como esta. Aunque sea difícil de vencer la tentación de mejorarlo. Es importante enfocarse en las tareas que le dan valor al usuario y en ocasiones la refactorización no da ese valor.

Como en todo lo demás: “Es bueno el uso; pero no el abuso”.

miércoles, junio 15, 2011

Motivación diaria

Hay días en los que siento que soy productivo y tengo muchas ganas de programar. En cambio hay otros en los que simplemente no tengo ganas, estoy frente a la computadora, pero no logro avanzar en las tareas pendientes. Tratando de encontrar cuales son los factores que influyen para estar motivado y ser productivo, identifique los siguientes:

Conocer el dominio del problema: Cuando ya se lo que tengo que hacer es más rápido ponerme a hacerlo. Cuando no conozco el beneficio o la razón de una característica del sistema donde estoy trabajando, o peor cuando no se exactamente que es lo que se supone que debe de hacer, mi productividad baja. Cuando se lo que se requiere, simplemente lo hago.

Comunicación constante: Esto va ligado al primer punto, para conocer el dominio del problema es necesaria una comunicación constante con el cliente. Cuando tengo dudas y el cliente tarda mucho en contestarlas o simplemente no lo hace, en algunos de esos casos simplemente no puedo avanzar, me desmotiva y se me quitan las ganas de trabajar en eso. También la comunicación entre los miembros del equipo me ayuda a mantenerme enfocado en lo que se quiere lograr, no me aburro ni busco algo con que entretenerme en el internet.

Tareas cortas y bien definidas: Tener bien definidas las acciones concretas a realizar me permite concentrarme en esa acción, evitando la parálisis por análisis. Que las tareas sean cortas me ayuda a poder terminarlas en poco tiempo. Dándome una sensación de avance, la cual, me motiva a seguir avanzando en el proyecto.

Café: Hay días que lo más difícil es empezar. Una vez que inicio con las tareas, el resto no es tan difícil. Para iniciar con ganas un café por la mañana ha sido muy efectivo.  Hay ocasiones (generalmente después de comer) que no tengo ganas de programar y lo único que pienso es en la hora de la salida. Para esos casos una bebida energética me “vuelve a la vida”, después ni cuenta me doy cuando ya es hora de irme.

Evitar interrupciones: Una vez que ya inicié a programar es fácil enracharse. El problema con las interrupciones es que me quitan esa viada que llevaba y necesito volver a empezar (que es lo más difícil). Las interrupciones pueden ser tanto internas (por mi mismo) o externas (alguien más me interrumpe). Para las externas no hay mucho que pueda hacer; pero para las internas he notado que el escuchar música me ayuda a concentrarme en lo que estoy, sin tratar de ver que dice la gente en las redes sociales o ver alguna foto graciosa.

Evitar estrés: Una mente tranquila produce más, que una mente casada o frustrada. Algunas veces el trabajo no es como quisiera, ya sea por decisiones de los managers, trabajar con sistemas legacy, “clientes especiales”, etcétera. Aunque me quejo seguido por cosas así, trato de que no me afecte al momento escribir código. Y si me pongo a pensar en esas cosas mejor me voy a caminar un rato, para que se me pase o para hablarlo con alguien más. Para evitar el estrés también ayuda estar bien con la familia, dormir bien… o no dormir Guiño.

Bueno… estos son algunos de los factores que he notado ayudan a mantenerme contento trabajando, motivado y productivo.

jueves, junio 02, 2011

El ingles es parte de las mejores practicas

Hace algunos años leí un comentario que no me gustó mucho. Decía algo como que todos los buenos desarrolladores sabían ingles. No me gustó, creo principalmente, porque mi primer idioma no es el ingles. Ademas conozco a personas que no hablan ingles y que son muy capaces de desarrollar. Me pareció un poco arrogante el comentario. Sin embargo en ese momento recuerdo que no pude pensar en algún programador que no hablara ingles; pero pensé que se debía a que vivo en la frontera con los Estados Unidos (Tijuana) y aquí la mayoría habla (o por lo menos entiende) ingles.

Ahora, después de ya algún tiempo, me ha tocado conocer a colegas desarrolladores que no dominan el ingles y he visto como sus opciones para buscar información, sobre cualquier tema técnico, se ve limitada comparada con la cantidad de información que se puede encontrar en ingles. Esto es más notorio cuando se trata de tecnología o técnicas nuevas (tendencias).

La mayoría de la información técnica es generada en ingles, incluso cuando para quien la genera el ingles no es su primera lengua. Esto puede causar que por la falta de información, sobre algo nuevo por ejemplo, se pierda competitividad frente a otros desarrolladores que sí dominan el ingles y pueden usar la información a su favor (más en estos tiempos donde google es una herramienta muy usada en el desarrollo).

El saber ingles ayuda a tener más opciones para resolver problemas y eso (en mi opinión) te hace un mejor desarrollador. Ademas los lenguajes de programación y las APIs estan en ingles, conociendo el ingles se puede leer, escribir... por lo tanto entender y mantener el código con mayor facilidad.

Hay varios esfuerzos para tener información disponible en español, ya que es nuestro idioma (creo que este blog es parte de ese esfuerzo). Aun así, si se desea conocer las mejores practicas y como aplicarlas, el ingles debe de estar en esa lista.