v3.2

Quiero escribir este post para agradecer a todas aquellas personas que me hicieron notar su aprecio, estima y cariño hacia mi persona, es complicado encontrar las palabras apropiadas para agradecer tantas muestras de estima y consideración. Muchas gracias a todos.

En especial quiero agradecer a mi familia que siempre está conmigo apoyándome, a mi linda esposa que organizó una bonita cena y se encargó de que el día fuera genial (te amo Auro).

Empiezo el camino hacia la siguiente versión muy animado de algunos cambios que estoy haciendo en el campo personal, sobre todo en mi salud, espero que muy pronto se den cuenta de ello y también en el campo laboral, también ya habran noticias.

Nuevamente muchas gracias a todos 🙂

p.d:

A photo posted by Sergio Infante (@neosergio) on May 4, 2016 at 8:17am PDT

 

 

Anuncios

Lenguaje de programación vs Framework de desarrollo, ¿Cuál se debe aprender primero?

Últimamente hay una moda en crecimiento por el uso de librerías y frameworks que faciliten el desarrollo de software y reduzcan considerablemente el tiempo y esfuerzo empleados, sin embargo a la vez que este crecimiento tiene sus ventajas, también se ve una reducción en la calidad de código. Hace unos meses leí una pregunta en una lista de correos sobre Django, la pregunta era: ¿Se puede hacer operaciones matemáticas en Django?, quedé con un gigantesco WTF en la mente. Al principio pensé que debía ser un error o que quizás se refería a algo más con plantillas o algo así, me quede pensando como carajos no pregunto ¿Cómo se hacen operaciones matemáticas con Python?, puesto que Django sólo es un framework el lenguaje es Python, continué leyendo el hilo y se trataba de un error de novatos, el que escribió la pregunta estaba sumando una variable simple con un diccionario por lo que recuerdo. Pero esta pregunta es solo una de las tantas que se pueden leer en tuits, foros y demás, como consecuencia de no haber aprendido primero el lenguaje de programación y luego el framework. Mi hipótesis es que estos “nuevos programadores” que producen en su gran parte código basura y proyectos insostenibles en el tiempo son el producto de tanto humo generado por cursos online con instructores inexpertos que no tienen proyectos reales en su historial, por tanto mentor y guru que usan hangouts para seguir vendiendo lo que sabe a duras penas. El uso de frameworks sin el conocimiento sólido del lenguaje de programación hace que la experiencia sea mas difícil debido a que se incurren en errores simples, incluso de sintaxis en muchos casos. He compilado de acuerdo a mi experiencia una serie de consejos que pueden ayudarle a cualquier programador a tener mejores resultados con cualquier framework y producir con ellos mejores resultados.

Sugerencias para aprender a usar frameworks y no producir proyectos basura en corto tiempo

  1. Si no sabes ningún lenguaje de programación, empieza a revisar o participar de iniciativas como code.org o program.ar
  2. Antes de aprender un nuevo framework, asegúrate de saber lo mínimo indispensable del lenguaje de programación (variables, condicionales, funciones, clases, repeticiones), y dedícale al menos unas tres horas a la semana a aprender algo nuevo del lenguaje en sí, alguna particularidad, o también a entender alguna característica en particular.
  3. Antes de embarcarte con un proyecto para un cliente real, intenta hacer un proyecto personal que te permita explorar y aprovechar las ventajas del framework, revisa artículos o foros para elegir las ventajas más resaltantes y en base a ella genera un proyecto para que experimentes de primera mano esas ventajas.
  4. Acompaña tu proceso de aprendizaje con buenos libros que incrementarán tu calidad de código como: The Pragmatic Programmer, Clean Code, Code complete, The Passionate Programmer, entre otros.
  5. Adquiere libros que te ayuden a mejorar tu trabajo con el framework en particular, libros que recopilan las buenas prácticas del propio framework.
  6. Participa resolviendo dudas en stackoverflow, eso te dará otro tipo de perspectiva, ayudar a resolver dudas amplia mucho la visión como desarrollador de software.
  7. Cuando sientas te sientas que ya llevas mucho tiempo desarrollando con ese framework y sientes un poco de rutina, es momento de aprender un nuevo framework, siempre sal del entorno de confort.

Si quieres agregar algo a esta lista o tienes una opinión diferente déjala en los comentarios.

Actualización: Cambié la imagen del post, ya que Symfony estaba mal escrito, gracias @mario21ic por notarlo.

Happy coding 🙂

Politeismo técnologico

Hay muchas religiones en la actualidad y a sus fieles se los llaman: Pythoneros, Javeros, PHPeros, Raileros, Javascripteros, PuntoNeteros y cualquier otra forma de llamar a un programador que le gusta y usa el mayor tiempo un lenguaje de programación, cada programador en algún momento se ha visto tentado a defender con todo a su alcance a el lenguaje de programación favorito, y es muy común encontrarse con batallas épicas y discusiones acaloradas en las listas de correo.

Yo hasta hace unos tres años era del tipo: “yo solo uso estos lenguajes nada mas y no me jodan” (PHP, Python, C++ y Javascript) y también del tipo “Yo sólo uso GNU/Linux o cualquier otro tipo UNIX o BSD y el resto de sistemas operativos sólo sirven para jugar”.

Pero hace tres años decidí alternar mi manera de trabajar (freelance) con un trabajo a tiempo completo dedicado a construir software, fue una decisión difícil, involucraba mudarme de ciudad (con lo tedioso que pueden ser las mudanzas), vivir lejos de la familia, tener un horario de oficina (con las reglas de oficina, algo que para un freelancer puede ser bastante incomodo), sin embargo la oportunidad de trabajar con clientes importantes de USA era un gran motivante,  el apoyo de mi esposa fue fundamental en esto y así decidimos dar el paso.

Este cambio hizo ampliar mi visión, me hizo entender finalmente que en la industria del software a gran escala lo que interesa por encima de la forma como se hacen las cosas y las herramientas que se usan, están los resultados, que el software libre y el opensource son buenos pero que son mejores si se integran con el software propietario, es mejor la armonía tecnológica que estar limitando la creatividad porque el software que usas no se adapta a lo que necesitas.

No me arrepiento de mi pasado radical, el de solamente usar cosas abiertas y libres, aprendí de eso, aprendí a defender y sustentar mis opiniones con fundamento técnico, aprendí mucho al enfrentarme a los que defendían el software propietario y que no conocían internamente su funcionamiento, aprendí a buscar siempre el porque de las cosas, la única diferencia es que ahora, si debo usar software privativo o desarrollar software privativo, pues ya no soy radical, le doy una oportunidad, analizo que opción se acomoda a mi forma de trabajar y elijo la que me hace más productivo.

A partir de ahora en este blog no sólo postearé cosas sobre software libre y opensource, también postearé cosas sobre software privativo, no al nivel de volverme fanático de una u otra tecnología, sino tratando de ser lo más objetivo posible, siempre poniendo por delante los resultados y la productividad.

Seguiré contribuyendo al software libre y opensource como lo he venido haciendo hasta ahora, para mi es más efectivo contribuir con código, creando o solucionando bugs, que tener peleas eternas en las listas de correo, o redes sociales, que al final no producen valor, y muchos menos perteneciendo a comunidades o asociaciones que lo único que buscan es vivir de los eventos y actividades para su beneficio personal, pero que no tienen forma de sustentar (cuantitativamente) sus aportes y sólo están a la espera de conseguir un buen “contacto”.

Lo que aprendí, escribiendo para Maestros del Web

Hace dos años tuve la iniciativa de hacer un curso en español sobre Django, uno que me permitiera plasmar lo que aprendí como programador, mi intención de colaborar con la comunidad de programadores y mi experiencia como profesor universitario, me contacté con @cvander y el resultado fue un tremendo éxito, mucha gente escribiéndome al día, cientos de correos electrónicos con muchas consultas, realmente logre mi propósito, el acercar Django a la comunidad hispana a través de Maestros del Web, fue una experiencia estupenda.

Luego de hacer el curso y que se publicará empezaron a aparecer muchos cursos que eran parecidos al mío, en video, audio y con otros ejemplos, en un momento me llego a molestar pues simplemente a veces copiaban el curso le cambiaban el nombre y lo publicaban, pero luego comprendí que es normal que eso suceda y que por el contrario de molestarme lo empecé a tomar como un agradecimiento.

Sin embargo como siempre hay gente que llego a pensar que tenia el derecho de exigirme que les de soporte, que solucione sus errores de codificación, que su trabajo dependía de ello y obviamente lo pedían de mala manera, hay gente que no lee, simplemente copia y pega el código y cree haber aprendido, o incluso gente que tuvo errores simples con sintaxis de python y que insistía en que yo corrija su código.

En los últimos meses he estado recibiendo varios correos con supuestos errores que tiene la guía y que dicen que es malo, sin darse cuenta tal y como esta escrito que la versión que use es la 1.4 y obviamente va a fallar con las nuevas versiones del framework, hay tanta mala onda en esos correos que simplemente me canse de contestarlos, y aquí viene la pregunta que me hizo @shinjiDev

Y pues de verdad que lo intente, escribí algunos capítulos con la versión 1.5, luego no pude concluirlo, mi situación laboral cambio, llegaron mas responsabilidades a mi vida profesional, lo retomé, actualicé y escribí algunos capítulos con la versión 1.6 y nuevamente llegaron mas responsabilidades profesionales, hice un último intento por actualizar lo poco que había escrito para la 1.6.5 y ahora lo veo ya innecesario porque la 1.7 está por salir y realmente no quiero dar falsas esperanzas a aquellos que me siguen escribiendo y pidiendo que actualice la guía, se necesita un gran esfuerzo para cumplir con publicar semanalmente y con una calidad aceptable y capturas de pantalla, con código entendible y depurado sin mencionar que se debe publicar gratis, y lo que vendrá luego ayudar a muchos a solucionar los problemas que puedan tener, a asesorar y a responder correos a los que no leen del todo.

Así que por ahora, pienso aprovechar que esta por salir la 1.7 y refactorizar la estructura de la guía, sacar una nueva versión o porque no convertirlo en un libro, esta vez pienso usar Leanpub me parece una buena opción.

Todo este contexto me ha permitido aprender y dar estos consejos si alguna vez se animan a publicar un curso o guía técnica:

  • Debes tener una estructura ya planificada antes de escribir la primera palabra de la guía, eso te dará una visión general del producto final y te permitirá organizar tus ideas.
  • Debes de tener fechas fijas de publicación, y por lo menos listos dos capítulos para no fallar con la fecha, eso le da seriedad a tu publicación
  • Usa un repositorio de código si va a haber ejemplos, usar tags y branchs son muy buenas ideas.
  • No escribas código en el post, menos uses etiquetas especiales, tienden a desordenarse, algunos lo copiaran sin leer o entender y te lloverán los emails pidiendo ayuda, y la mayoría de errores serán porque copiaron mal, en lugar de ello usa el repositorio o capturas de pantalla con indicaciones (usa skitch)
  • Escribe claramente, si es posible en mayúsculas, que no te haces responsable de dar soporte o asesoría personalizada, créeme te ahorraras problemas y malos entendidos, sobre todo evitaras conflictos con gente que cree que todo es gratis y que hasta te pueden llegar a insultar e inmerecidamente llamarte estafador.
  • Escribir una guía técnica es un estupendo ejercicio del cual puedes mejorar tus habilidades de comunicación.
  • Acompañar la guía técnica con videos puede resolver muchas dudas y evitar que tengas que responder muchos correos con las mismas explicaciones.
  • Separa un tiempo a la semana para responder correos, y comentarios y no te excedas de ese tiempo, sino se convertirá en una pesadilla y algo más de que preocuparse.
  • Intenta escribir porque también, encontraras a estupendas personas que compartirán contigo ideas y puedes armar una buena red de contactos y generar comunidad.

Empezaré a trabajar desde ahora en la nueva versión de esta guía, que espero que se convierta en un libro.

Actualización: Aquí está disponible el PDF del Curso de Django en Maestros del web

Actualización 29/01/2017: Hace varias semanas atras he recibido varios email y mensajes para poder actualizar al menos en parte el proyecto en github con una versión mas reciente del framework, aún me sigo sorprendiendo que despues de 5 años muchos sigan tomando el curso como base para aprender Django, asi que me tome un tiempo para poder actualizar los archivos principales, asi que ahora hay una nueva versión del proyecto en github compatible con Django 1.10.5.

Fue un buen 0x7DD

Ideas sueltas, cosas que sucedieron, anhelos, melancolías, nostalgias y alegrías, no en ese orden, tampoco cronológicamente. Fue un buen 2013.

  • Presentí que el 2013 sería un buen año para mi, afortunadamente no me equivoqué
  • No me sentí valorado en mi anterior trabajo, a pesar de ello aprendí mucho, me sentía bien por el equipo de personas en el proyecto, más que por la empresa, empecé a buscar algo mejor, lo encontré.
  • Dicte clases en una universidad, una que practica el catolicismo, pensé que sería buena idea y un buen lugar para continuar con mi vocación de docente, me equivoque, los problemas administrativos son muy graves, decidí dejarlo porque además quedaba muy lejos de casa.
  • Ingresé a dictar clases a uno de los institutos con mayor prestigio en Lima, al principio era motivador, había mucho que hacer, luego me di cuenta que eran esfuerzos en vano, no había libertad de cátedra, decidí no pelear más con los “docentes responsables de curso”.
  • Buscando un mejor trabajo, volví a las entrevistas de trabajo, ahora desde otra perspectiva, una con mayor confianza, deje de buscar la reputación de mi entrevistador, decidí ir al todo por el todo, fue una apuesta que rindió sus frutos.
  • Me ofrecieron una oportunidad laboral muy buena, justo lo que buscaba, una rama distinta a mi zona de confort, el desarrollo de aplicaciones móviles, tome el reto y fue una de las mejores decisiones que tome en este año.
  • Entre a trabajar a Belatrix, hasta ahora tiene el mejor entorno laboral en donde haya trabajado en Perú, mi equipo es fantástico, juntos estamos haciendo un producto que estará disponible en miles de dispositivos móviles, es fascinante saber que el trabajo de uno, esta siendo usado por miles y miles de personas, es difícil de transmitir esa alegría.
  • Me puse como meta, hacer que mis compañeros de equipo, que no habían usado GNU/Linux hasta ese entonces, lleguen acostumbrarse al punto que prefieran el sistema operativo por sobre todos, lo logre, fue una buena obra de activismo, demostré que GNU/Linux es una alternativa estupenda cuando se refiere a desarrollo en Android.
  • Salí de la Asociación Peruana de Software Libre, mis ideales ya no son los mismos de los que aún permanecen en ella, a mi punto de vista perdieron la visión en algún momento, hice todo lo que pude, di lo mejor que estaba a mi alcance, espero que puedan retomar el rumbo, a pesar de todo siguen siendo mis amigos.
  • Fui aceptado como Miembro de la Fundación GNOME, es una de las mayores satisfacciones que recibí en el año, quiero seguir dando mayor tiempo a la fundación y seguir contribuyendo al proyecto, espero que el 2014 pueda incrementar mis contribuciones.
  • Forme parte de un estupendo grupo en una revista digital sobre desarrollo de software y software libre, lamentablemente por motivos que escapan del control se tuvo que cerrar el proyecto, sin embargo la experiencia fue muy buena.
  • Seguí recibiendo emails, tweets, y diversos comentarios sobre el curso de Django que hice para maestros del web, a pesar de que tiene ya un buen tiempo, creo que sirvió de mucho, me atrevo a decir que muchos Djangeros nuevos son gracias a mi curso, este año espero continuar con maestros del web en otros proyectos.
  • El grado de magister aún se me escapa de las manos, no puedo encontrar la fórmula mágica para distribuir mejor mi tiempo, eso a veces me frustra.
  • Junto con mi esposa buscamos departamentos para poder mudarnos, el próximo año habrá una gran sorpresa y será el inicio de otra etapa en mi vida.
  • En el trabajo empecé a usar a diario OS X, en combinación con GNU/LInux para poder ser eficientes en el desarrollo móvil con Android y iOS, el equipo empezó compartiendo una mac mini, ahora todos los desarrolladores tienen una, tengo en mente escribir un artículo sobre mi experiencia usando ambos sistemas operativos a la vez, me gustan ambos, aunque mi corazón se sigue inclinando por GNU/Linux + GNOME para muchas actividades.
  • Pase de usar un móvil con Android a usar un móvil con iOS, la diferencia también merece un artículo, la conclusión adelantada: aún no encuentro un móvil con el cuál me quede contento.
  • Abandoné mi blog, por casi todo el año, es otra cosa más causada por mi falta de organización con el tiempo, una frustración más a la lista.
  • Este año hice nuevos amigos, gente muy interesante, pintoresca, carismática y además tengo la suerte de trabajar con ellos día a día.

Son algunas cosas que recuerdo a muy poco de terminar el 2013. con respecto a lo que se viene para el 2014, simplemente puedo decir que será mejor que este que ya esta terminando y que fue genial.

Happy New Year 😉

La diferencia es la documentación

Existen muchas formas de desarrollar software y por supuesto muchas metodologías para hacerlo, cada una con sus ventajas y desventajas como muchas otras.

Sin embargo es muy frecuente leer y/o escuchar, la siguiente expresión: Lo único que cambia es la documentación (sobre todo cuando se habla de metodologías ágiles vs tradicionales).

Siendo objetivo, el proceso de documentación si cambia, pero es el proceso más no específicamente la documentación, la idea es ir produciendo documentación que agregue constantemente valor al cliente, y dejar de lado aquella documentación que no agregue valor y que por el contrario se convierta en un gasto o molestia mantenerlo.

¿Quién define que documentación produce o no produce valor?, pues es un tema más amplio y que da para un artículo aparte, lo que quiero resaltar con este título es que muchas veces la frase “la diferencia es la documentación” se usa en algunas ocasiones para disfrazar el desconocimiento y a veces el temor al cambio, existen muchas formas de hacer software, pero va mas allá del cambio en la documentación

Y esta confusión con respecto a las metodologías ágiles, no es exclusividad de ellas, pasa también con otras metodologías y es una excusa usada más de lo que se imagina.

Algo a tener en cuenta es que en el desarrollo de software no hay una formula secreta, “no hay balas de plata” que sean la solución a todos los problemas, y que sean las perfectas, sólo hay maneras y maneras de trabajar.

Entonces ¿Qué hacer para comprender una metodología de desarrollo de software?, y no asumir que solo es la documentación.

  • Comprender que la metodologías son recomendaciones
    que han funcionado para muchos, pero son sólo eso: recomendaciones, y no deben ser reglas a obedecer sin objetar.
  • Las metodologías se deben adaptar al equipo de trabajo, y es el equipo de trabajo que debe decidir como implementarlas, ver que funciona y que necesita mejorar.
  • Una metodología de desarrollo conocida puede servir como base para que el equipo de desarrollo elabore la propia, compartiendo algunos de sus principios.
  • No solamente basta leer la teoría sobre una metodología para entenderla, realmente se tiene que hacer lo posible por ponerla en práctica, hay mucha diferencia entre lo que se dice y como es realmente.
  • Buscar conferencias y charlas sobre metodologías de desarrollo es lo mismo que buscar la teoría, hay mucha diferencia cuando se aplica, así que mejor es buscar experiencias reales.
  • No buscar certificaciones en metodologías si realmente no se ha aplicado, las certificaciones en gran parte son un gran negocio, un profesional certificado, no necesariamente es eficiente y no necesariamente sabe aplicarlas.
  • Unirse a comunidades sobre metodologías de desarrollo de software puede ayudar a encontrar otros profesionales que comparten ideologías, puede ser un buen lugar para buscar nuevas ideas y formas de aplicación.
  • Busca artículos sobre experiencias reales en aplicación de la metodología que quieres usar, es posible que encuentres algunas recomendaciones de como aplicarlas efectivamente y algunos secretos.
  • Y por último publicar tus hallazgos, escribir y compartir lo que experimentaste es una buena manera de generar mayor conocimiento, muy recomendable que lo hagas.

Desarrollar software es una actividad apasionante, y encontrar la manera en la que puedes hacer mejor tu trabajo te llevará a construir tu propia metodología de desarrollo o una adaptación de alguna conocida, lo importante es que funcione para ti y tu equipo.

Happy Coding 🙂

Adios 11111011100

Ideas sueltas, cosas que sucedieron, anhelos, melancolías, nostalgias y alegrías, no en ese orden, tampoco cronológicamente.

  • Mejoré mi conocimiento en algunos lenguajes de programación, frameworks y herramientas, evolucioné.
  • Aprendí mucho más sobre la Ingeniería de Software en la práctica.
  • Aprendí mucho sobre metodología ágiles en la práctica.
  • Algún mes me pagaron menos de un sueldo básico, no fue fácil.
  • Jugué mucho con mi perrito, se llama Kernel.
  • Jugué con mis gatitos, la gata se llama micha, el gato no reconoce su nombre, le pongo uno diferente cada mes.
  • Aprendí nuevos lenguajes de programación
  • Me entregaron las fotos de mi boda, me reí de las fotos, las publiqué en FB

Continúa leyendo Adios 11111011100