Comunidad y proyectos de código abierto

Participar en un proyecto de código abierto es similar a cuando empezamos en un nuevo empleo o debemos trabajar en algún viejo software de la organización: Un montón de código que alguien más escribió; sabemos que hace algo pero no el cómo; los requerimientos (issues, bugs) pueden o no ser claros; etc. Por encima de todos los tecnicismos (ver las pruebas, la documentación, el código, debug, etc.) acudimos a la interacción con el otro: ¿Venga, usted sabe qué hace este servicio? Este dialogo puede verse afectado por las dinámicas y las herramientas que se emplean terminando así en la frustración y deserción de nuevos ayudantes en el proyecto.

Hace unos días que empecé como aprendiz en el programa de mentores de F#  para contribuir en proyectos de código abierto. Una iniciativa bastante interesante y una experiencia positiva para maestros y principiantes, creo. Alan, mi mentor, y quien ya ha escrito sobre este proceso pensó que lo mejor sería programar en pareja: una llamada y compartir pantallas. Lo que considero una estrategia acertada para ayudar a los contribuidores novatos a involucrarse y mantenerse motivados en estos proyectos con un plus de red social y construcción de comunidad. Alguien que ya conoce algo sobre el proyecto en particular, y sobre las dinámicas y herramientas usadas en general puede orientar a los interesados no a manera de tutorial en blog, video o webcast sino como un dialogo de saberes más personal y constructivo que leer los comentarios y ver el avatar del otro.

Participar de procesos como este y con estrategias como esta son enriquecedoras en varios aspectos, en mi caso particular, por ejemplo, darme cuenta de lo oxidado que está mi inglés conversacional, no lo practico mucho y creo que puede convertirse en un dolor de cabeza. La barrera del idioma hace más grande la timidez y aunque la combata con brownies cósmicos al postre la conversación no va igual. Pero esto no debe ser visto como un problema sino una oportunidad para mejorar, somos personas con intereses en común en un proceso comunitario en el que los obstáculos solo pueden terminar empoderando a los individuos.

En mi opinión, participar en proyectos de código abierto es más que escribir código y hacer pull requests, es una construcción comunitaria en la que, además de hacer un producto de software, se crea comunidad: individuos e interacciones.

Anuncios
Comunidad y proyectos de código abierto

Sobre los técnicos en programación de software y los pegadores de ladrillos

Con este son ya diez los años que llevo escribiendo código. Diez años no son nada. Los años los inventamos nosotros, pero ¿y el tiempo? ¿y la muerte?. 10 es un signo, pero ¿y el número? ¿y las matemáticas? Debido a ese extraño valor simbólico que damos al aniversario reflexioné sobre algunos momentos clave en este primer decenio. Empecé por el técnico laboral en programación de software y no tardé en fijar mi atención en lo malo que había sido, o al menos, en lo mal orientado que estuvo. Ahora dudo de la dificultad de comunicación entre industria y academia, ahora creo que en la instrucción de estos técnicos se refleja, no lo malo, si no lo poco que se entiende este oficio desde el mismo mercado laboral.

Una vez un amigo me contó, exaltado, que un dirigente de una organización se había referido a su equipo de desarrollo como pegadores de ladrillos -no recuerdo haciendo referencia a qué pero ahora no es importante- y cómo él había refutado esa posición y defendido al gremio de las punzantes opiniones de un insípido dirigente que levitaba con el poder de su cargo. Lo relevante de su relato no es la posible tensión ideológica en la comparación de los oficios pues el capitalismo no distingue eso, lo interesante es la analogía misma con el gremio de la construcción pero no al nivel de los respetados arquitectos y las complicadas arquitecturas, sino al nivel de los obreros, los maestros y sus ayudantes.

Muchos barrios de la ciudad han sido levantados por sus habitantes, levantando desde la maleza que cubría los terrenos. En la construcción de una vivienda participaba más de una familia donde algún familiar era o conocía a un maestro, también vecino de estos porque todos apenas llegaban. Entre muchos maestros dieron cara e identidad a barrios enteros con la práctica de su saber popular, ajustándolos a las necesidades reales de sus habitantes, es decir, ellos mismos, la comunidad. Para llegar a ser maestro de obra se empieza por ayudante, en ocasiones de algún familiar, ayudando, por ejemplo, a subir y bajar material y escombro; a mezclar; pegar ladrillos; etc. Saber cómo levantar una casa es algo que el ayudante aprenderá en un número indeterminado de construcciones y con un número indeterminado de maestros.

Related image

Viendo el pensum del técnico en programación de software en las páginas de varias instituciones se evidencia el mismo error: se espera que en dos años de instrucción el sujeto sepa lenguajes de programación, bases de datos, dispositivos móviles y hasta “Desarrollar aplicaciones complejas utilizando bases de datos”. Plantear un programa así es desconocer las necesidades de la industria, aún muy joven en el país. La orientación que se debe dar a un técnico en programación de software es similar a la de los ayudantes de construcción.

Los maestros de los que hablo aquí no recibieron una y otra vez, en distintos niveles académicos, la instrucción y la practica de cómo hacer una casa. Primero se aprende cuanto pesa un bulto de arena, cuanto esfuerzo cuesta moverlo. Se acude tanto a la ceremonia de la praxis que cuando el ayudante es ya un maestro sabrá, con un movimiento rápido del metro, cuantos viajes de arena necesita para iniciar una obra.

Es más útil para el equipo contar con alguien que sepa automatizar tareas con, por ejemplo, bash o que domine git a estos técnicos que saben hacer un crud. El perfil de nuestros técnicos, como el de un ayudante de construcción, debe ser el de un facilitador para el equipo, con dominio de varias herramientas. Alguien que tiene lista la mezcla de arena y cemento cuando empieza la construcción.

Introducir un perfil como este, un automatizador entrenado para que los programadores no se ocupen, por ejemplo, de un script de compilación y despliegue automático en la industria sacudiría a más de un equipo de programadores e ingenieros obsoletos que, por estar pensando si mejor en blanco o en negro, siguen compilando en la máquina del único cuyo usuario tiene acceso al servidor que también tiene instalado Visual Studio, por si es necesario… Ese es el estado de nuestros equipos de desarrollo. Por eso, no es de extrañar que demanden de la academia lo que no necesitan: más jóvenes que arrastren y suelten botones en una pantalla.

Es común que las discusiones sean del orden de si microservicios o monolítico, ¿y nosql? ¿si redis? ¿y el performance? pero nunca una sobre una estrategia de integración continua consensuada, y como se desconoce, obvio, nadie sabe implementarlo.

La instrucción de estos técnicos es mucho más sencilla, es realmente una instrucción de técnica, de repetición, como una kata, se usa una y otra vez la herramienta hasta que se domina. Conociendo, por ejemplo, un sistema de control de versiones, lo que es un compilador y sabiendo hacer un script de compilación, entonces si pensamos en escribir código, en aprender un estilo ya sea en la practica o en un siguiente nivel académico.

En el desarrollo de software le hemos puesto etiquetas a situaciones comunes con la construcción: el segundo piso de una casa lo nombraríamos feature y a un piso desnivelado le diríamos bug. Conocer e identificar estos artefactos, saber, por ejemplo, qué es y cómo se redacta una historia de usuario en determinadas herramientas facilitará la integración de los técnicos en el equipo, para esto no es necesario saber qué es el polimorfismo, solo distinguir una situación y usar una herramienta para documentarlo. Es necesaria la comunicación: son más los equipos que fallan por sus individuos e interacciones que por las herramientas y los procesos.

Ser productivo en un lenguaje de programación es fácil, pero solucionar problemas reales construyendo un producto de software no lo es tanto. Para esto es necesario participar en varios proyectos, en varios equipos, conocer e ir creando un estilo propio, un estilo definido por las necesidades y restricciones propias de las organizaciones y las verticales de negocio en las que hemos intervenido.

Nuestro oficio no es el de científicos de la computación, aunque obvio que hay ciencia en esto como en saber levantar las columnas de una vivienda. Hay que bajar la programación de software al servicio de la practica y elevar su enseñanza a ciencia, como la ciencia que existe en enseñar a alguien a construir una casa.

Debemos reconocer en los procesos de aprendizaje de oficios milenarios, como el de la construcción, aspectos y técnicas que nos pueden ser útiles. Este es un oficio joven aún y ya nos hablan de un deficit de programadores. Tal vez es el momento preciso para replantear entre academia e industria lo que significa para una sociedad como la nuestra los programadores de software.

Sobre los técnicos en programación de software y los pegadores de ladrillos

Tercer año como MVP – Autoevaluación

Ayer recibí, con la misma sorpresa que la primera vez, el correo que me notificaba que estaría vinculado un año más al programa Microsoft Most Valuable Professional, por mis aportes en el área de Visual C#.

Recuerdo con agrado cuando inicié en este mundo de las comunidades de usuarios: compartir conocimientos, dejar que mi código fuera empleado y criticado, aportar soluciones a problemas planteados en foros sin esperar nada a cambio, bueno, nada más allá de aprender siempre un poco más. Así fue como llego el primer reconocimiento que me brindó Microsoft, y del que por supuesto, hablé en este blog.

Un año más tarde, en abril de 2012, ¡recibí el MVP!  un galardón por el que no se debe trabajar, pero con el que muchos sueñan (sé que suena raro y trataré de explicar el punto en esta entrada) y ya, tres años más tarde, luego de algunas experiencias e interacciones con más humanos, de forma virtual y no virtual tengo una opinión diferente de lo que significa ser un MVP.

Más allá de la “hermosa estatuilla hecha de un material que parece cristal pero no lo es ¹” el MVP brinda la posibilidad, créanme o no, de aportar un grano de arena en el futuro de un producto en concreto, y es quizá esto lo que más me gusta del programa, porqué para cambiar el futuro de algo se debe ser un verdadero experto en la materia, esto implica: conocer el pasado del producto, trabajar con el, identificar las cagadas que los equipos de producto comenten, pensar en la mejor forma de hacerlo. Una vez se reúnen estos criterios, entonces si decir con argumentos validos que x o y esta mal y merece una revisión. Y no solo los MVP (“expertos en la materia”) tenemos esta voz! Microsoft tiene abiertos muchos canales para entregar feedback valioso, feedback que puede convertirte en un MVP.

Partiendo de este punto, lo que más me gusta es entregar feedback a partir de mis experiencias, en mi caso con Visual C#. Estas experiencias no tienen que estar sujetas solo a productos del fabricante (creo que este es el peor error). Lo mejor que se puede hacer, desde mi humilde punto de vista, es compararnos con otras comunidades. Esta comparación, en mi caso, parte de tratar de ser un desarrollador poliglota, tratando de conocer lo mejor de distintos lenguajes de programación, de distintas plataformas y pensando en como mejoraría C# con esto.

Pero si pongo en una balanza el feedback que entrego contra otras muchas cosas que hago, es claro que no es por este motivo que recibo el galardón. Soy muy joven aun, y mucha de la poca experiencia que tengo no la he obtenido directamente en las empresas en las que he trabajo, porque pese a que hay retos, no se coparan, en cantidad, con los problemas que me llegan de las comunidades de usuarios, amigos (virtuales o no) y foros! Entonces empieza un trabajo desinteresado (¡Esto es una farsa! yo siempre espero agrandar mi capital intelectual, ya sea repasando algo que ya sé o aprendiendo algo nuevo) para solucionar un problema a algún buen samaritano que este en aprietos. De ahí vienen entonces varios artículos del blog (No son mentiras cuando digo: “Un amigo me escribió”).

El “espíritu investigativo” motiva siempre a estar viendo lo nuevo, compararlo con la que ya se tiene, intentar tomar lo mejor de varios mundos por un método deductivo, de ahí que sea un inconforme early adopter y siempre tenga tema para hablar en eventos de varias comunidades y defender o no lo que creo que ésta bien.

Estos dos últimos puntos, son de pronto, los que me han llevado a hacerme con este galardón, me encanta aprender y compartir lo que sé, últimamente no creo mucho en las universidades (menos en las de mi país) y me gusta mucho ser un inter didacta!De ahí, que para mi, el MVP sea una sorpresa, pues siento que premian mis propias ganas de aprender con el efecto colateral de la colaboración a comunidades de usuarios.

Ahora bien, resulta muy motivante hacerse con el galardón, créanme, la estatuilla se ve muy bien en el escritorio o en la biblioteca. Y cada vez son más los amigos virtuales que llegan con la pregunta: “¿Como hago para ser MVP?” Y se ven cada día más y más blogs técnico-publicitarios con el único objetivo y meta clara de hacerse con un reconocimiento por parte del fabricante.

De ahí que se vean opiniones como esta:

image

No sé si sea realmente la puerta de entrada para obtener el reconocimiento, aunque es obvio que no serás un MVP en x si siempre hablas de y, pero lo que si es claro es que no es lo más sano para una comunidad de usuarios ni para ti, como profesional, ser “evangelistas gratuitos”, esto, créanme, debe venir por añadidura. Lo digo, porqué para decir que X es el mejor producto del mundo, se debe como mínimo tener algo contra que compararlo, se debe como mínimo reconocer que hay cosas que nos disgustan y queremos cambiar, se debe como mínimo tratar de ser un experto en lo que se habla. Entonces ahí si resulta muy fácil y natural escribir un articulo, dar una charla y defender un producto así no recibas nada a cambio.

Me gustó ver reacciones como las del colega aquí Latam, Chalalo:

image

No con esto abandonar los nuevos usuarios y miembros de comunidades. Creo que este sería el mejor skill, tener la experticia y el tacto para poder aportar con lo más básico y con lo más avanzado.

El cambio esta en nuestras manos, mejorar nuestra comunidad de usuarios (aportando así un grano de arena por mejorar la cultura del desarrollo de software en LATAM), despertar el espíritu investigativo y critico en pro de hacer mejor los productos que usamos. Esto solo se puede hacer de la forma difícil, ¡TRABAJANDO! ¡haciendo algo que ponga a prueba todos esas cosas que usamos día a día, y por que no, creando nuevas herramientas y marcos de trabajo! no reuniendo certificados que aportan siglas sin sentido a las portadas de las PPT o transcribiendo capítulos enteros de los libros que compramos.

Estos serán los puntos en los que me enfocaré este nuevo año como MVP de Visual C#.

Hasta el próximo post.

 

¹ – Tomado de la bio de Eduard Tomas en la web de gusenet.org

Tercer año como MVP – Autoevaluación

Me regreso a WordPress

Hace ya unos meses decidí comprar un dominio y hacer algo con este, no quise vincularlo con WordPress y no encontré nada mejor que escribir artículos de programación como los que llevo escribiendo aquí  hace ya más de un par de años. Así que escribí un muy pequeño blog engine con lo mínimo necesario para ser feliz y hacer un brain backup de ideas y aprendizajes personales.

image

Mientras escribía y publicaba unos pocos artículos en este nuevo sitio empezaba a echar de  menos muchas de las interacciones sociales que me ofrecía ofrece WordPress, estas interacciones van más allá de los simples comentarios en los artículos, pues en esto Disquis tiene todo lo que quería. Además de esto, el viejo blog siguió creciendo en seguidores, visitas, comentarios, amigos y solicitudes que pedían nuevo contenido :(.

Actualización

Así pues, desde la semana pasada me decidí a migrar los pocos artículos que publiqué en aquel nuevo blog a este, mi viejo y querido .wordpress.com. En total son unos 10 artículos de temas variados (¡DESARROLLO!) todos migrados en orden cronológico, es decir, con la fecha en que se habían publicado en el nuevo sitio y que ya se encuentran disponibles aquí.

Este blog esta estrenando template, un poco más “minimalista” que la anterior, sin imágenes ni contenido distractor en los lados… todo este contenido quedó en el final de la pagina.

Así que de ahora en más seguiré escribiendo todos mis artículos técnicos en este sitio y todo el contacto profesional y comercial en http://nicolocodev.com.  

Me regreso a WordPress

Xamarin y yo – Bienvenida

La semana pasada Miguel de Icaza anunció con esta publicación la posibilidad a los Microsoft MVPs de obtener una copia gratuita de Xamarin Business edition for iOS and Android y pues esta es una de esas oportunidades que no se puede dejar pasar, no solo por el hecho que sea gratis por ser MVP sino porque como dice Joseph Hill en el artículo que anuncia la oferta los MVPs somos criaturas con una relación simbiótica con el IDE (el mejor IDE creado por la humanidad) y podremos explotar muchas de las características del producto y contribuir con el proyecto sino es con código con algo que se valora mucho… dando feedback del producto.

Hasta aquí todo muy bonito, pero y ¿qué es Xamarin? y ¿por qué estoy tan emocionado?

Desarrollo para dispositivos móviles

Cuando conocí el concepto de desarrollo para dispositivos móviles lo conocí en la academia con Java, pequeñas formas y cosas no muy avanzadas, jamás hice algo que no fuera estrictamente académico.

Luego conocí los buenos Windows Mobile y el Compact Framework que para mí eran altamente competitivos en proyectos reales, en fin siempre estuve en el mercado sobre plataforma Microsoft mientras a su lado crecían los mercados de IOs y Android. Luego llegó el Windows Phone y redefinió un nuevo rumbo para Microsoft en el mercado sistemas operativos para dispositivos móviles, aprendieron mucho de todo lo vivido con Windows Mobile.

Nunca miré hacía otros lados porque mi trabajo no era apuntarle a estos dispositivos, cuando trabajé Windows Mobile era de forma corporativa, nada personal, pero no veía mucha fuerza (económica) allí, me pagaban solo por software a la medida y vivía feliz así. En cambio ahora vemos mucha fuerza con el mercado de las Apps y el tema de grandes capacidades de cómputo en pequeños dispositivos (tema por el que siempre se ha caracterizado IPhone por ejemplo).

Si quieres lanzarte por desarrollar para IPhone de entrada aprendes Objetive C (corríjanme si me equivoco) y si ingresas al mundo Android te encuentras con Java, aparte claro de sus SDKs correspondientes. Personalmente conocí en su tiempo alguito Java, Python, C y C++ llegando por ultimo al lenguaje y plataforma con la que trabajo y me consigo el dinero la para cerveza y la conexión a internet… mi amado C#! y es precisamente esto lo que viene a solucionarme Xamarin, la posibilidad de desarrollar aplicaciones nativas para IOs, Android y MAC con Visual C# y ahora con la posibilidad de trabajarlo con el IDE que más me gusta! ¿Desarrolladores altamente competitivos? ¿Dónde?

La nube esta lista.

Algo que siempre argumento en mis conferencias es que un backend solido es un factor determinante para el triunfo de muchas Apps (como muchas de las que me gustan) y si le sumo a esta oportunidad de desarrollo multiplataforma la posibilidad de todo el poder de Windows Azure Mobile Services? Las oportunidades son ilimitadas!

Ya basta Nicolás! Screenshots!

Realmente es un proyecto que me gusta mucho (y más ahora empapado del tema de las Apps) así que la emoción es inmensa y aquí van algunas fotografías de la instalación y de mi IDE para que se antojen.

Por ahora me dedicaré a jugar un poco con mi nuevo juguete y ya les estaré contando.

Hasta el próximo post.

Xamarin y yo – Bienvenida

Proyecto Euler: Descripción y problema 1

Hace ya un par de semanas vi a varios colegas de España planeando por twitter un juego de esos que tanto nos gustan, se trata del proyecto Euler, este consiste en avanzar en una carrea para resolver varios y muy divertidos juegos matemáticos con un lenguaje de programación, por ejemplo, el buen Eduard Tomas se ha lanzado por Scala, Juanma ha elegido Clojure y yo (que quería C# pero ya se lo había pedido Quique) volví a mis inicios con Python.

Cuando comencé con Python tenía 11 años y escribía pequeños algoritmos y la verdad que resulta realmente fácil de aprender y en mi opinión ofrece una sintaxis muy rica y muy funcional, así que me arriesgaré a hacer el upgrade a Python 3.3, aprender que tiene de nuevo y lanzarme a terminar esta carrera con este lenguaje.

Todos los que están “jugando” están dejando el código en el blog, y los que podamos hacer alarde de códigos realmente pequeños hasta en un tweet 😛

Ejercicio 1:

El primer problema del Proyecto Euler dice:

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1000.

Mi solución en Python es:

sum(range(0, 1000, 3)) + sum(range(0, 1000, 5))

Lo que hace el código es realmente sencillo, hace uso de range(start, stop, step) [step es un parámetro opcional e indica de cuanto en cuanto debe aumentar] y sum(), básicamente crea una colección que luego suma a través de la función SUM y sumo los resultados de los dos sum range.

Update:

Juanma me hizo caer en cuenta de un error por medio de un tweet, el ejercicio requiere de la operación de unión, teniéndolo presente puedo escribir algo como:

sum(set(range(0, 1000, 3)).union(range(0, 1000, 5)))

Aquí hago uso de un objeto set que empleo para poder usar la función unión y realizar la suma de los elementos.

Como ando tan ocupado, le sacaré tiempo en las noches como para distraerme un poco.

Si conocen mas formas y mas optimas de realizarlo no duden en comentar 🙂

 

Hasta el próximo post

Proyecto Euler: Descripción y problema 1

[Opinión] ¿Renderizado del lado del cliente o del lado del servidor? – Parte 2

Las reacciones de algunos colegas en mi Facebook por la entrada anterior no se hicieron esperar 😛 así que adelantare esta entrada comentando lo que pienso sobre este tema, pero como prometí en la entrada anterior, hablare un poco mejor del renderizado en el lado del cliente, porque no lo puedo negar, lo veo muy positivo… futurista pero positivo :P. Digo futurista (aunque ese futuro es AHORA) porque la tecnología ha avanzado mucho y HA REDUCIDO SUS COSTOS de una manera sorprendente, es decir, grandes capacidades de computo a precios muy cómodos. El costo y calidad de las conexiones a internet también ha mejorado mucho y por no hablar de dispositivos móviles que pese a su tamaño tienen ya procesadores de más de un 1Gh y con más de un core. Pero ¿en qué influyen todos estos factores sociales y económicos en nuestro mundo del desarrollo?… pues en que así como el “público” tenga la capacidad de cómputo, nosotros podremos seguir desarrollando productos increíbles que podrán ser usados por todas las personas de una población, o por lo menos por su gran mayoría. Con esto no pretendo decir, que de ahora en más pensemos que todas las personas deben tener maquinas como las nuestras de desarrollo, con 7 núcleos y 16 Gb de memoria 😛

Todo esto de los múltiples dispositivos y clientes que pueden estar necesitando acceder a nuestro sitio, esto ha obligado a dar un paso más en el desarrollo web, la necesidad de implementar una API publica para poder responder a todos los tipos de clientes y peticiones de una manera limpia con un solo endpoint. Sin embargo este servicio debe tener la autonomía de responder como sea debido a cada petición y de implementar una correcta negociación de contenido.

Con esto vemos hacia donde apunta el mercado, y hacia donde debemos tener la mirada, el desarrollo de webs increíbles con HTML5 y delegando responsabilidades que antes no podíamos a los clientes. No con esto podemos pretender desarrollar web de forma “irresponsable” muchas cosas aun no son estándar y no todos los navegadores tendrán el mismo rendimiento en este tipo de trabajos y procesando volúmenes de datos considerables.

Personalmente, en uno de los últimos proyectos en los que he trabajado tuve la oportunidad con WEB API, y aunque no soy front-end developer conocí varios frameworks y técnicas JavaScript para este trabajo, los resultados… muy positivos, era un entorno controlado de Web Privada donde conocía previamente todas las capacidades tecnológicas de mi cliente y pude desarrollar sin riesgos.

Bien, pues esta es mi opinión y experiencias sobre el tema.

Si tienes experiencias o comentarios sobre el tema, no dudes en comentar J

Hasta el próximo post

[Opinión] ¿Renderizado del lado del cliente o del lado del servidor? – Parte 2