Comentarios Dispersos

Tengo varios años leyendo y subscrito a blogs. Los leo principalmente a través de FeedDeemon (que se conecta a Google Reader) y desde mi teléfono. Por lo que no tengo que necesariamente visitar el sitio para leer el artículo. Aun así hago clic en el link de algunas entradas para leer el articulo desde el sitio del autor y así ver los comentarios.

Los comentarios enriquecen el contenido, la idea que el autor quiere expresar. Pueden aportar otra perspectiva que complementa o que incluso invalida la sugerencia del autor. Si sólo leyera el articulo sin los comentarios, me quedaría con la perspectiva del autor sin conocer las otras opiniones.

Es por eso que últimamente me he puesto a pensar en el fenómeno de la “descentralización” de los comentarios. En ocasiones algunos buenos comentarios (opiniones) se pierden en twitter como respuestas a quien compartió el link. Lo mismo ocurre cuando el artículo se comparte en otras redes sociales. Puede haber buenos comentarios en las entradas que comparten el link que no necesariamente los puede leer el autor o algún lector del artículo.

Por otro lado, entiendo que hay ocasiones que los comentarios pueden llegar a ser tantos que (por falta de tiempo) sólo quisiera leer los comentarios de las personas que conozco. Cómo cuando en las redes sociales, un amigo comparte un link y los demás (amigos) comentamos sobre eso en la red social.

En lo personal me gusta que comenten directamente en la entrada del blog, porque así los comentarios persisten junto con el artículo y ayudan a mejorarlo. Es por eso que los invito a comentar directamente en los artículos.

Los grupos de usuarios son un pasatiempo

Uno de los primeros grupos de usuarios que conocí de cerca fue el de la comunidad .net Tijuana. Antes había escuchado del grupo de usuarios de Linux; pero nunca me acerque a ellos. Recuerdo que sentí que era algo en lo que todo desarrollador profesional debería participar. Por eso mismo empecé a asistir a las reuniones mensuales a las que tenia oportunidad y sobre todo a los eventos grandes que la comunidad organizaba.

Por ese mismo tiempo comencé a suscribirme a varios blogs y sitios que trataban sobre el desarrollo de software. Noté que varios de los temas, que trataban en las reuniones de la comunidad, eran presentaciones que ya había conocido a través de esos sitios que seguía. Aun así me gustaba participar en las reuniones e invitaba a colegas a asistir. Me preocupaba que otros sintieran que no les aportaba algo nuevo una presentación que quizás podían ver en línea. Decidí participar dentro de la comunidad presentando, tratando de cambiar las presentaciones de PowerPoint por presentaciones con código. Por lo menos de esa forma verían un ejemplo practico, en código, del tema. Algo distinto a la presentación en línea que pudieran encontrar.

Organizando otros eventos trataba (y aun trato) de atraer a más desarrolladores profesionales para que formen parte de la comunidad. Noté que por más esfuerzos, la respuesta de los profesionales es la misma. Sí hay gente nueva; pero hay mucho profesional que no le importa pertenecer a un grupo de usuarios. Llegué a pensar que lo que necesitaban era conocer el beneficio que es ir a aprender de otros colegas y hacer mejor su trabajo. Una vez que lo vieran iban a asistir.

Me di cuenta que en lugar de buscar la razón por la cual alguien no participa en la comunidad, debía buscar la razón por la que las personas sí participan. Recordé que yo no necesito la comunidad para ser mejor desarrollador. Me gusta asistir aunque el tema ya lo conozca. No voy con la única intención de aprender más. Voy por el gusto de estar ahí conviviendo con personas que tienen el mismo interés por la tecnología.

Hace tiempo a la comunidad de Tijuana .Net Microsoft la apoyaba con regalos. Recuerdo que tenían rifas al final de cada reunión, había un tesorero y toda la cosa. Ahora que he estado más involucrado en la comunidad, noté y supe que Microsoft ya no apoyaba al grupo. Aun así en las reuniones sigue habiendo soda y galletas. Gabriel Flores los lleva, se toma la molestia de ir a comprar con su dinero sólo porque le gusta organizar las reuniones, le gusta la comunidad. No lo hace porque Microsoft le dará premios.

Hace meses inicié el grupo de usuarios de JavaScript y al ser el organizador tengo que pagar el dominio, crear el sitio y pues me toca comprar las sodas. Al principio sentía que no debería de pagarlas yo, que eran las empresas las que debían pagar por esos gastos ya que estábamos dando un servicio a los profesionales. Aunque no es mucho gasto, pensaba que estaba haciendo algo mal por tener que pagar las sodas de mi cartera.

Hasta que entendí que las comunidades son un pasatiempo y como todo pasatiempo cuesta, no se busca beneficio de un hobby, sólo se hace por el gusto de hacerlo. A veces es difícil darse cuenta, ya que se trata de lo mismo que hago en mi trabajo y por eso sentía que no tenia que pagar por hacerlo. Ahora que veo la organización de la comunidad como un pasatiempo (y no necesariamente como algo de beneficio para mi trabajo; aunque me ha ayudado) disfruto más de las reuniones. Los gastos no me pesan porque sé que son para el pasatiempo que disfruto. Entiendo por que algunos desarrolladores profesionales no asisten y nunca asistirán a las reuniones, simplemente es un pasatiempo que no compartimos.

Comunidades de Profesionales

En Tijuana, donde vivo, hay varios grupos de usuarios (comunidades de desarrolladores de software). Son organizados sin fines de lucro, con el fin de compartir el conocimiento entre colegas.

Algo que he notado, en algunas de estas comunidades, es la falta de participación de los desarrolladores. En varias reuniones de los diferentes grupos se ve a las mismas personas participando, ya sea como presentador o asistente. Hay ocasiones que las reuniones son organizadas en escuelas y es entonces cuando se ve una gran asistencia; pero principalmente formada por estudiantes. ¿Por qué no asisten más profesionales a las reuniones?

Una razón puede ser que no les gusta el horario. O es muy temprano y por lo tanto es en hora de trabajo o es tarde y prefieren ir a casa a descansar que tener que esperar a que sea la hora de la reunión. Parece que el horario “ideal” es justo saliendo del trabajo y no es el mismo para todos.

No saben que existe la comunidad. Si no saben que el grupo de usuarios existe y que se reúnen cada cierto tiempo, es casi imposible que asistan. Para remediar esto necesitamos mayor difusión, quizás no solo en las redes sociales sino acercándose, como comunidad, a las empresas. Las empresas pueden ver beneficio en las reuniones y ayudar en la difusión entre su personal.

Otro factor puede ser el nivel de los temas. Es difícil poder complacer a todos en esto. Para algunos un tema puede ser muy avanzado y no poder seguir la sesión por ello; para otros puede ser demasiado básico y sentir que la reunión no le aporta ningún beneficio (por no aprender algo nuevo). Lo que se podría hacer es presentar los temas en más de una reunión y tratar de cubrir un nivel en cada una. Por ejemplo: Tecnología X introducción, intermedio y avanzado. Esto no será posible para todos los temas; y para los que sí, será difícil contar con la disponibilidad del ponente.

Al igual que el nivel de los temas. Es difícil tratar un tema sobre el cual la mayoría se sienta identificado. A veces son sobre tecnología nueva y no les aporta conocimiento necesario para ser mejores en su trabajo actual. O el caso contrario, cuando se tratan tecnologías viejas que ya no utilizan en sus proyectos.

El factor principal sobre la falta de participación de desarrolladores profesionales es que no ven un beneficio en asistir o exponer en los grupos de usuarios. Los beneficios personales que se pueden obtener dependen de cada quien. El beneficio colectivo que se busca es el de compartir el conocimiento, experiencias y pasar un buen rato con gente que tiene intereses en común (la comunidad).

¿Cómo vas?

En ocasiones, me ha tocado trabajar con clientes que constantemente están preguntando sobre el avance de alguna característica que (prácticamente) se acaba de solicitar. No se refieren al progreso del proyecto o algún modulo, sino a la tarea individual que puede tomar unas cuantas horas solamente.

Problema
Por un lado, esto llega a ser cansado para el equipo. Es molesto que te pregunten una y otra vez lo mismo, más aun si el tiempo que te tomas en contestar hace que la tarea sencilla te tome un poco más (esto a su vez provoca más preguntas sobre el estatus). El “¿Cómo vas?” constante desmotiva porque pone bajo estrés al equipo, evitando la creatividad. No permite que busquen nuevas y mejores soluciones para los problemas que se tratan de resolver. Esto puede llevar a que crezca la deuda técnica del proyecto, que a la larga puede resultar en costo de tiempo y dinero.

Por otro lado, puede causar frustración en el cliente porque siente que no se avanza en lo que se necesita. Al estar preguntando contantemente sobre el avance del proyecto y recibiendo respuestas del tipo “vamos donde mismo”, puede llegar a sentirse un estancamiento en el progreso.

Posible causa
Pasa cuando el cliente no tiene experiencia en trabajar con un equipo de desarrollo y (quizás) siente que es una forma de tener el proyecto bajo control.

Soluciones
Para evitarlo la solución obvia es hablar con el cliente para que evite esas interrupciones constantes. Sin embargo, en ocasiones, no es posible y aun cuando se hace no siempre se logra un cambio duradero. Algo que he intentado en esas situaciones es el dar estimaciones pesimistas. Con la intención de reducir las expectativas sobre el tiempo de entrega de la característica y evitar el ansia de verla terminada. Se debe tener cuidado en no exagerar en el pesimismo, no queremos que el cliente se nos vaya.

Otra cosa que intento es no contestar inmediatamente para así evitar la interrupción y al mismo tiempo ir acostumbrando al cliente a que cada pregunta puede tomar su tiempo de respuesta.

Si la situación continúa, lo otro que he hecho es contestar lo mismo a varias preguntas consecutivas, incluso aunque ya haya un poco de avance, para tratar de no alimentar esa necesidad de estar conociendo el más mínimo avance de algo que no es crítico como dando a entender que “no por mucho madrugar amanece más temprano”.

Esto he hecho para que se reduzcan los “¿Cómo vas?”; pero aun así, de pronto, aparecen.

El 2012

Como ya va terminar el año, en lugar de escribir predicciones preferí hacer un resumen de las actividades y eventos en los que participé en este 2012.

Super Happy Dev House Tijuana
En Marzo participé en la organización del séptimo SHDH-TJ. Hubo buena asistencia, podríamos decir que el evento fue un éxito.

Hubo varios proyectos usando diferentes tecnologías; pero con algo en común. La mayoría (si no es que todos) eran Web así que tiempo después surgió tijuana.js

tijuana.js
En Abril publiqué el sitio tijuanajs.org. El grupo de usuario de javascript de Tijuana tuvo su primera reunión el último martes de Mayo y así cada ultimo martes de mes hasta Octubre, fueron 6 reuniones en este primer año. Esperamos seguir reuniéndonos en el 2013.

Tijuana.net
Participé como expositor en reuniones de la comunidad .net de Tijuana:

• R48: NuGet y jQuery
• R49: Webmatrix & jQuery
• R51: ASP.NET MVC 4

dev3cast
Fue un año más en que participé, junto con Gabriel Flores e invitados, en el dev3cast podcast. Los temas tratados en el 2012 fueron:

• SimpleMembership
• ¿A qué le tiras cuando sueñas programador?
• Convenciones de programación
• Entity Framework 5
• Errores de capa 8
• Windows Azure en la vida real
• programación en parejas
• Cuando se busca un nuevo programador
• Artesanía de Software
• Startup Weekend Tijuana
• Lo que se enseña en las escuelas
• MVC para los no iniciados
• SHDH Tijuana
• OData
• node.js
• backbone
• CoffeeScript y Jasmine
• TDD con Javascript
• NancyFx

CafeScript
Como puede verse, en los primeros episodios del año del dev3cast, hubo varios relacionados con JavaScript. De ahí surgió la idea de crear un podcast dedicado a JavaScript. Se unió Iván González al proyecto y así inicio CafeScript. Los episodios del año fueron:

• Episodio 0
• Un poco de historia de JavaScript
• Objetos en JavaScript
• Algunos conceptos
• JavaScript debe morir
• Jasmine
• Titanium SDK
• jQuery
• Malentendidos de JavaScript

Google Developers Group (GDG) Tijuana
Fui invitado a participar con el GDG como expositor del tema “Extensiones para Google Chrome”. Fue agradable participar en otras comunidades.

Universidad
El 2012 fue el año en que regresé a la Universidad; pero esta vez no como alumno sino como profesor. Impartiendo 2 Materias (Programación Visual y Desarrollo Web). Me gustó la experiencia, tanto que el siguiente cuatrimestre impartiré una materia más.

Vista
Por último, ya para terminar el año mi vista se canso. Al parecer el pasar mucho tiempo con la vista fija en la laptop (trabajo, proyectos extras, blogs, etc.) fue la causa de que tuviera problemas con uno de mis ojos. Eso provocó que me convirtiera en un “programador 4 ojos”.

Estas fueron algunas de las actividades en las que participé este 2012.

Convenciones de nombrado

¿Qué son?
Las convenciones de nombrado son un conjunto de reglas para nombrar identificadores (nombres de variables, clases, propiedades, funciones, etcétera) dentro de un lenguaje de programación. No son requeridas por el compilador o interprete para que el programa funcione, son un estilo en la forma de escribir el programa.

¿Por qué utilizar convenciones de nombrado? ¿Cuáles son las ventajas?
El utilizar una convención de nombrado dará al código un estilo consistente que ayuda a la lectura para el resto del equipo o incluso para el mismo desarrollador que lo escribió. Es fácil saber que esta pasando con sólo ver el estilo utilizado. Similar a como ocurre al leer un libro.  Algunos autores usan diferentes formatos a lo largo de los libros (itálica para ciertas partes del texto, recuadros con otro tipo de letra, etcétera) estos sirven para que el lector tenga un mejor contexto de lo que esta leyendo.

Denota cierta intención. Si la notación es consistente, a lo largo del programa, con sólo leer un fragmento del código podemos descubrir lo que se intenta (y como) lograr. El no seguir una convención puede requerir que el lector tenga que leer más del código para poder entender mejor el contexto y el objetivo de cada variable o procedimiento.

Muestra que él código fue escrito por un profesional, esto pareciera no ser importante; pero al momento de tener que mantener código de otras personas (o de uno mismo) es más agradable trabajar con código escrito de manera profesional.

¿Cuáles serían las desventajas?
La mayoría de las desventajas aparecen cuando se sigue una convención equivocada o "anticuada", sí, me refiero a la notación húngara.

¿Por qué no me gusta la notación húngara?
La Notación Húngara consiste en usar prefijos en el nombre de las variables, dependiendo del tipo. Esta notación la utilizaba en la escuela y en los primeros proyectos en los que participé saliendo de ella. Era común en lenguajes como Delphi y VisualBasic al momento de nombrar los componentes (controles) utilizados.

Algo que noté como desventaja era que tenía que recordar cual era el prefijo para la variable que iba a declarar. Por ejemplo, actualmente si voy a definir un botón para guardar cambios puedo llamarlo saveButton, con lo cual es claro ver que se trata de un botón para guardar; Pero con la notación húngara tenía que recordar cual era ese prefijo para los botones antes de poder nombrar mi variable btnSave. Esto se complicaba más entre menos común fuera el control a utilizar. Había ocasiones que perdía tiempo definiendo prefijos y después buscándolos para poder así nombrar variables y el código fuera consistente.

En otras ocasiones son totalmente innecesarios los prefijos y sólo sirven para meter ruido y hacer más difícil la lectura del código. Tomemos como ejemplo  el siguiente calculo:

Sin notación húngara
    item.amount =  unitPrice * quantity;

Con notación húngara
    oItem.fAmount = fUnitPrice * iQuantity;

En una sola línea de código se ve que tenemos ruido innecesario, en programas algo grandes el ruido que introducen los prefijos llega a ser muy molesto.
Las convenciones varían según el lenguaje
Es importante conocer la convención de nombrado utilizada (recomendada) para el lenguaje que estamos utilizando, estas varían de leguaje a lenguaje. Aun y que estemos usando varios lenguajes en un mismo proyecto las convenciones pueden (y deben) cambiar según el lenguaje en uso.

Por mi trabajo es común ver JavaScript, HTML, CSS (incluso SQL) escrito siguiendo convenciones de C# lo cual no creo que sea correcto (sin tomar en cuenta lo mucho que me molesta). En esos casos se esta desaprovechando las ventajas de usar una convención, se hace más complejo leer la intención del código.

Al final de lo que se trata es de poner atención en que el código sea fácil de leer y entender. Para esto debe ser escrito de una manera profesional, siguiendo las convenciones comunes para el lenguaje. Cuando el código no sigue la convención del lenguaje  es fácil dudar de la experiencia (profesionalismo) que tenía el desarrollador  en ese lenguaje en particular (al momento de escribirlo), por lo tanto se  tendría que revisar más código para saber si el código hace lo que suponemos y que  además que lo haga de la mejor manera.

MagmaRails 2012

Hace poco asistimos a magmarails. Este es el segundo año consecutivo que vamos, aunque el año pasado se suspendió el evento de 3 días que se tenia programado aun así se llevo a cabo un día de presentaciones con un ambiente muy bueno que decidimos volver este año. Además de que había la posibilidad de ganarnos un ipad por haber asistido en el 2011, este no fue un factor para decidirnos hacer el viaje; pero al final sí costeó.

Aunque no trabajamos con RubyOnRails, en nuestro trabajo actual, de cualquier forma me parece una buena conferencia para asistir y aquí algunas de las razones:

Presentaciones sobre personas, presentaciones no técnicas. Varias de las presentaciones hablaban de conceptos que se pueden aplicar a cualquier lenguaje y plataforma. Algunas hablaban de temas tales como el lugar de trabajo, la organización del equipo, como ser un mejor desarrollador, etc. Muchas de estas presentaciones hechas por personas que trabajan en empresas exitosas y con buen ambiente de trabajo.

Practicas aplicables a cualquier Framework/Lenguaje. Las presentaciones que fueron técnicas hablaban de practicas que son aplicables a la mayoría de las plataformas para realizar desarrollo web, cosas como DDD, diseño de APIs, FrontEnd, Backbone.js entre otras.

Todos podemos aprender de Ruby y RubyOnRails. Las presentaciones que si fueron más enfocadas a RubyOnRails fueron interesantes aunque no trabajemos con él. Considero que como desarrollador profesional debemos saber cuales son las opciones que tenemos para desarrollar. Quizás no ha detalle; pero sí de tal manera que cuando se presente un problema recordemos esa opción y entonces sí ver los detalles. Además de que en lo personal me parece muy interesante lo que pasa en el mundo de Ruby.

Amigos. En nuestra primera visitas hicimos buenos amigos allá en colima y esta era una buena oportunidad para ir a visitarlos otra vez (gracias Mario y Nizait por tratarnos tan bien, nos hicieron sentir como en casa).

Vacaciones. La conferencia fue en manzanillo así que aprovechamos para tener unas vacaciones algo geek.

Crowd Interactive. La conferencia no es organizada por una empresa que quiere venderte sus productos y/o herramientas de desarrollo. Es organizada por una empresa de desarrollo que esta interesada en formar comunidades de desarrolladores. Busca que se generé talento nacional. Creo que eso es algo que ayuda a que el ambiente sea muy agradable. En ningún momento sientes que te están vendiendo algo, solo esperan que te la pases muy bien, convivas con otros desarrolladores y que formes parte de la comunidad.

“Celebridades”. Otro de los atractivos de la conferencia es que asisten personas reconocidas, por su trabajo, dentro de la comunidad. Esta es una oportunidad para poder hablar con ellos en persona, hacer preguntas, convivir y aprender de lo que hacen. Te das cuenta que son personas accesibles y que están dispuesta a ayudarte.