SVN + Git, una manera de combinarlos y ser feliz.

SVN y Git provienen de dos modelos distintos de control de versiones: el centralizado y el distribuido, en la práctica son similares, sin embargo existen marcadas diferencias que hacen que la elección de cuál usar en un proyecto, dependen de varios factores.

Ventajas y desventajas del modelo centralizado

• Luce mas simple
• Existen muchas herramientas para trabajar con repositorios centralizados, ya que llevan mas años y fueron muy difundidos
• Muchas IDEs tienen soporte completo
• No pueden haber commits offline
• Dificultades para trabajar con branchs
• Dificultades para trabajar en equipos grandes.

Ventajas y desventajas del modelo distribuido

• Modelo simple de colaboración
• Permite trabajar offline
• La instalación es sencilla y hay muchos servicios de hosting
• Copia completa del repositorio en cada clon
• Todo el trabajo casi es local.
• Tiene flujo de trabajo mas complejo, sobre todo en equipos grande, y con diferentes permisos por usuario.
• Una curva de aprendizaje mas grande

Diferencias principales:

El modo de guardar la historia: Para SVN la historia de un proyecto nunca cambia, sin embargo Git permite modificar commits anteriores usando por ejemplo: git rebase. A pesar de que puedan haber maneras de editar el mensaje de un commit en SVN, esto requiere permisos de administrador, algo que no es recomendable si hay que darle permisos de administrador con equipos de trabajo grande.

Estructura del directorio: Para SVN se deben tener carpetas distintas para trunk, branches, y tags, en Git todo esta en una sola carpeta y Git se encarga de ocultar el master, branches y tags.

Subproyectos: Un subproyecto permite compartir código o módulos entre proyectos, para SVN se usa el svn-external y en git existen los Git submodels, comparten el mismo concepto pero el uso y el flujo de trabajo es el mismo.

Este artículo de Github amplia esta breve explicación de las diferencias: https://help.github.com/articles/what-are-the-differences-between-svn-and-git

¿Por qué combinar SVN y Git? Mi caso de éxito

Hay casos específicos en los cuales su combinación de verdad que resuelve muchos problemas, sobre todo aprovechando que el uso de Git para ramas locales es fantástico.

Actualmente trabajo en Belatrix y por motivos de contrato con el cliente (confidencialidad), no puedo mencionar detalles, nombres, mucho menos información privada del proyecto, sin embargo puedo explicar el flujo de trabajo que usamos y que se puede replicar en otros proyectos.

Mi cliente es una compañía multinacional que tiene un producto muy bueno de banca móvil, completamente configurable y adaptable a los sistemas bancarios actuales, lo que hace que tenga a su vez miles de clientes (entidades financieras) que usan su producto y por lo tanto al final el producto que ayudamos a construir es usado por millones de personas alrededor del mundo,  para lograr y mantener ese éxito tan grande que están teniendo ahora, se necesitan muchas personas involucradas en el desarrollo del producto, decenas de desarrolladores usando los mismos repositorios, las mismas ramas, con diferentes permisos de acceso y demás. Mi cliente ha elegido SVN como gestor de sus repositorios, por diversas razones técnicamente justificables.

A pesar de que la tendencia se da hacia modelos distribuidos de control de versiones (Git y Mercurial en su mayoría), el uso de SVN sigue siendo masivo en muchas empresas y proyectos.

En este proyecto Belatrix lleva aproximadamente 4 años y nuestro equipo en particular lleva un año y medio aproximadamente, al principio mi equipo empezó a utilizar git-svn para manejar ramas locales y funcionaba muy bien, el cliente tenia una rama principal, una rama para el proyecto, una rama para el modulo que estábamos desarrollando, y nosotros gracias a git-svn teníamos ramas para lo que queramos: bugs, User Stories, improvements, cleanups y encontramos un flujo de trabajo muy bueno y simple de mantener.

Para lograr esto usábamos git-svn (https://www.kernel.org/pub/software/scm/git/docs/git-svn.html), todo iba bien hasta que en el lado del SVN se empezó a usar svn-externals, a partir de entonces dejo de funcionar git-svn y si hubiéramos querido forzarlo, hubiéramos complicado el flujo de trabajo y probablemente hubiéramos aumentando las probabilidades a cometer errores.

Es aquí donde encontramos una forma simple de continuar con nuestro flujo de trabajo y este fue un par de cambios en el .gitignore, el flujo de trabajo es como el que describo a continuación:

• svn checkout <ruta_del_servidor_SVN>
• git init (en la carpeta donde se hizo el checkout)
• Agregar .svn/ al .gitignore (para que Git ignore a la carpeta principal del SVN, este es un paso muy importante, de no hacerlo correctamente todo el flujo fallará.)
• Agregar */.svn/ al .gitignore (para que Git ignore a multiples carpetas).
• Continuar el desarrollo con Git, creando ramas locales y usarlo como se acostumbra.
• Actualizar y mantener sincronizado el Git master antes de hacer un commit al SVN
• Los commits siempre van al Git master para evitar errores y desde el Git master se hacen los commits al SVN.
• Los updates desde el SVN siempre se hacen al Git master, de manera tal que el master siempre tiene una copia actualizada.

Si te sirve sienteté libre de comentar, sugerir una mejora para este flujo y compartirlo  🙂

 

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

@neosergio y por qué no actualizarla? =)

— Christian Palomares (@shinjiDev) August 1, 2014

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.

Patrones de interfaces de usuarios para móviles

Cuando se tiene una idea de una aplicación móvil o una interfaz especial para web móviles (no responsive, sino especificamente construida para movil, algo como los que tienen el subdominio m.ejemplo.com), empezamos a imaginar como debería lucir en el móvil, la distribución de componentes y otros detalles claves, que determinan el éxito o fracaso de una aplicación. Es en esos momentos en los cuales es ideal consultar galerías y patrones de interfaces, que presentan soluciones comunes a las que el usuario ya esta acostumbrado y que permite. Estas son las fuentes de inspiración que a mi parecer tienen la mayor cantidad de patrones:

pttrns.com

Especializada en patrones de interfaces de usuarios para iPhone y iPad, posee mas de 2000 patrones.

 androidpatterns.com

Esta más enfocado a patrones de interacción en interfaces de usuarios para Android.

mobiledesignpatterngallery.com

La galería relacionada al libro de Theresa Neil sobre patrones de diseño móvil de editorial O’Reilly, $9.99 como ebook para kindle que valen la pena.

 android.ux

Patrones de diseño para android, son diversos screenshots de interfaces existentes.

mobile-patterns.com

Diversos patrones de diseño para iPhone y Android

uiparade.com

Recursos visuales que se pueden descargar y también comprar, algunos muy creativos e innovadores, definitivamente gran fuente de inspiración

 inspired-ui.com

Ademas de tener patrones para iPhone y Android, también posee una categoría para iPad.

 

lovelyui.com

Es mas una colección de elementos visuales, pero que también valen de inspiración

 

cocoacontrols.com

Aqui puedes encontrar elementos visuales al igual que el anterior, pero orientados a iOS y OS X, incluyendo una clasificación por licencias.

 

 

 

Estas son algunos de los mejores recursos online que se pueden utilizar para buscar inspiración y patrones que funcionan.

Happy UI designing 😉

El poderoso tablero Kanban en la gestión de tareas

Uno de las metodologías con mayor difusión y aplicación en diversas áreas profesionales es Kanban para la gestión de tareas y trabajo en progreso, aquí un video si es que no estas muy al tanto de que es:

httpv://youtu.be/I-H-WXAX_oM

El tablero kanban es una herramienta que ayuda a implementar la metodología del mismo nombre en un proyecto, este tablero es una variación de lo que son las famosas tarjetas kanban, usadas en producción y almacenaje, que van adjuntadas al producto y van trasladándose etapa por etapa (aquí un ejemplo de las tarjetas):

Y aquí un video de como se usa las tarjetas Kanban en una línea de producción:

httpv://youtu.be/ZHxz_u-JkEk

Existen muchos tipos de tableros Kanban, que pueden tener columnas para diversos propósitos (pendientes, pruebas, desarrollo, pendientes de aprobación, realizadas, entre otras) y puede incluir subcolumnas, con diversos parámetros adicionales (capacidad máxima, prioridades, limitaciones, alertas) y cualquier otro tipo de indicador que permita hacer visible el trabajo en progreso.

Esta flexibilidad en el tablero kanban lo convierte en algo confuso al principio e incluso tedioso que puede convertirse en una resistencia al cambio sobre todo cuando se quiere utilizar por primera vez.

Cómo empezar a usar el tablero Kanban en pasos sencillos

• Empieza usando la versión más simple de todas: tres columnas, una para las tareas pendientes, otra para las que están en progreso y una tercera para las terminadas
• Es mejor empezar con un tablero físico, que se puede confeccionar con materiales sencillos: plumones, hojas, cintas. Puede ser de tamaño personal que pueda caber en tu escritorio, en una pizarra, o incluso en una ventana, para ello las tarjetas pueden ser esas notas adhesivas de colores.
• Si vas a empezar a usar en tus tareas personales o tareas de equipo concéntrate en poner todas las tareas pendientes, si durante el desarrollo de alguna tarea, se te viene a la mente alguna otra, inmediatamente agrégala a tu columna de pendientes.
• Ordena las tareas pendientes por prioridad, puedes usar colores si se te hace más simple o puedes ponerles algún numero en las esquinas que indique la prioridad.
• Cada vez que vas a iniciar con una tarea, coloca la nota en la columna de «En progreso», puedes aprovechar la nota para poner algunos criterios de aceptación, es decir que cosas debe cumplir la tarea para avanzar a la siguiente columna (en esta versión simple, que cosas tienen que cumplirse para considerar que la tarea esta concluida).
• Evita llenarte de tareas «en progreso», buscando siempre tener esta columna vacía, si es que una tarea pasa mucho tiempo en esa columna, indica que es una tarea que probablemente tenga que volver a la columna de pendientes o apresurarse en concluirla.
• Una vez concluida la tarea y haberte asegurado que todos los criterios para considerarla terminada se hayan cumplido, trasládala hacia la columna de concluidas, esto servirá para medir cuantas tareas ya fueron terminadas y visualizar tu progreso.
• Aprovecha las notas para llevar un registro del tiempo en que te demoro en terminar una tarea, eso te ayudará a evaluarte y buscar mejorar continuamente tus tiempos.
• No busques una herramienta informática para gestionar un tablero kanban, hasta que no tengas la costumbre de usarlo, no te servirá de nada tener una plataforma mas que atender si no estas acostumbrado al tablero, lo hará más complejo y lo abandonaras rápidamente, sin aprovechar su potencial.

Estas son mis recomendaciones para empezar a trabajar con el tablero Kanban, es importante notar de que este tablero no es excluyente y que puede ser usado con cualquier metodología de desarrollo o gestión de proyectos, incluso se puede utilizar para tareas del hogar o para tareas personales.

Nota: Si buscas una herramienta en línea para gestionar Kanban, hay muchas opciones de pago y gratuitas, elegir una para el trabajo en equipo dependerá del contexto, así que prefiero no hacerlo. Pero si se desea aplicar para contexto personal o pequeños proyectos no esta mal darle un vistazo a Trello que incluso tiene una aplicaciones para el smartphone.

Actualización: Este es un ejemplo de cómo se gestiona un tablero kanban, en un sprint de dos semanas, en un video de pocos segundos

https://vine.co/v/MahttLprp1D/embed/postcard

Happy task management 😉

Los principios ágiles

Al hablar de metodologías ágiles de desarrollo de software, lo primero que a muchos se le viene a la mente es el manifiesto ágil (para mi al puro estilo de Los Simpsons).

Pero a unos cuantos se les viene a la mente que este manifiesto se ve soportado por los principios, principios que a veces son difíciles de entender si es que no se han practicado o haber aplicado en situaciones reales.

He preparado el siguiente video con mis puntos de vista y mi experiencia con los principios ágiles (decidí hacer un video, porque un artículo me hubiera quedado muy largo).

httpv://youtu.be/91U_9qjvVbQ

Otro video muy interesante es el que preparo @pablitux vale la pena verlo.

httpv://youtu.be/V5LaKpjcgKQ

Y esta es la fuente oficial de los principios ágiles (en español): Principios del Manifiesto Ágil

Happy Coding 🙂

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 🙂

El mejor IDE

Hace unos días leía una pregunta en una lista de correos sobre python (cito la pregunta):

¿Cuál es el mejor IDE – GUI para Python ?

Y las respuestas obviamente eran los nombres de herramientas, decidí que era una buena oportunidad para escribir mi respuesta extendida, y mostrar mi punto de vista.

Para mi las preguntas de cual es el mejor IDE, denota que el que las hace es un programador junior o novato (que no esta mal que lo sea, por el contrario es muy bueno que quiera saber que herramientas usan los demás), un programador que esta en el proceso de aprendizaje o en camino a convertirse en experimentado o senior, para mi los experimentados nunca hacen esa pregunta porque ellos ya la saben (ya la encontraron) y aquí el porque.

Imaginemos que un cocinero novato quiere freír un huevo, esta aprendiendo a hacerlo, ¿valdría la pena que este cocinero se compre la mejor sartén de todos los modelos existentes ?. O imagina que quieres colocar un cuadro en la pared de tu sala, ¿sería adecuado que compres un martillo eléctrico costoso o bastaría con uno estándar y simple?. O tal vez un aprendiz de guitarra que esta aprendiendo algunos acordes, y sus primeras notas, aún no sabe círculos armónicos o nada de teoría musical,  ¿sería un buen consejo que se compre una guitarra fender stratocaster?

El punto al que quiero llegar es que las preguntas de cual es la mejor herramienta o tecnología, en si pueden llegar a no ser constructivas porqué la pregunta es muy genérica y va a provocar un enfrentamiento innecesario entre promotores y detractores de herramientas (flamewar), sin mencionar que es muy subjetiva la respuesta, para mi a esta pregunta le falta la parte importante de definir el propósito, la necesidad o incluso la experiencia del programador, no servirá de nada una IDE con muchas funcionalidades a un programador que aun no entiende su propósito y no puede valorarla realmente, la mejor herramienta siempre esta sujeta a las necesidades y a la forma de trabajo de quien la va a usar.

El mejor IDE para un programador siempre será aquel que cumpla con sus necesidades, que se adapte a el, y que le permita ser eficiente y productivo con su trabajo.

¿Cómo llegar a saber cuál es el mejor IDE, que se adapte a mí?

Aquí les dejo algunas recomendaciones que les pueden servir en la aventura de encontrar la mejor herramienta.

• Mejora tu habilidad con la tecnología o lenguaje de programación antes de ponerte a buscar cual es la mejor herramienta en la cual plasmar lo que sabes, (si eres un mal cocinero, de nada te servirá tener la mejor olla del mercado, si cocinas mal)
• Consigue una lista de los IDE disponibles para la tecnología deseada y prueba una a una durante por lo menos un par de semanas por cada IDE.
• Usa todas las extensiones y funcionalidades de cada IDE, algunas serán extrañas y a veces sin sentido, pero eso te permitirá saber las limitaciones de la herramienta y te llevará a descubrir interesantes procedimientos que pueden llevar a mejorar tu trabajo.
• Intenta llevar al límite al IDE, busca personalizarlo desde los colores de la interfaz hasta agregar código o incluso contribuir con el desarrollo del IDE en el caso de que sea open source.
• Busca videos tutoriales (youtube o cualquier otro servicio) sobre como usan el IDE otras personas, esta es una excelente manera de comparar tu trabajo y el de los demás, y así poder mejorar el tuyo con nuevas ideas.
• Busca charlas y/o videoconferencias sobre el IDE que estas usando (en esas dos semanas), te sorprenderás de lo que puedes encontrar.
• Lee blogs, revistas o sitios especializados similares a The Setup, busca inspiración en el trabajo de otros.
• Postea tus hallazgos, hay otras personas que les gustaría comparar tu forma de trabajar con la propia, así se genera conocimiento a través del intercambio de opiniones y hallazgos.

Al final encontrarás la mejor herramienta que se acomode a ti, de eso no hay duda.

Remember the message from Morpheus to Neo:

Neo, sooner or later you’re going to realize, just as I did, that there’s a difference between knowing the path, and walking the path.

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

Cinco años de aventura educativa y contando.

Es difícil recordar con detalle, lo que he vivido en estos 5 años (desde septiembre del 2007), sin embargo aún recuerdo mi primera clase modelo, lo cuidadoso que fuí para prepararla, recuerdo el primer curso que dicte, las primeras tareas que deje, los primeros exámenes que evalué, incluso a mis primeros alumnos, es imposible no sentir nostalgia por ello.

Siempre busque transmitir la pasión que siento por la programación y el desarrollo de software, y en busca de eso, decidí aprender a enseñar pero no de manera teórica, sino en la práctica, no estudié pedagogía como carrera, no tuve la oportunidad de llevar cursos de andragogía, muchos menos lleve cursos de educación virtual o cursos similares, quizás esto fue un descuido y algo muy arriesgado, debido a que no sabía nada sobre como enseñar eficientemente y esto podría representar un pésimo intento de enseñar, a pesar de ello me aventuré en ello, afortunadamente encontré el apoyo para iniciar mi experimento, y con mucho agrado puedo decir que hasta ahora todo ha salido bien.