La estructura de un proyecto: ejemplo Encuentro

Python — Jueves 23 de Mayo de 2013, 18:43


Un tema que se ha visto varias veces, tanto en la lista de PyAr como en la vida real, es que los desarrolladores que no estuvieron involucrados en proyectos grandes, o que sólo estuvieron metidos en uno o dos sistemas (más allá el tamaño), no saben muy bien qué estructura, o qué forma, darle a un proyecto nuevo.

Es totalmente comprensible. La estructura a tener depende de muchos factores: de la complejidad del proyecto, de cuan listo lo deja uno para empaquetarlo, de la prolijidad del desarrollador, etc.

Lo notable es que (en mi experiencia) el proyecto aunque nazca pequeño, siempre conviene que esté ordenado. Y que la forma de ordenarlo, qué estructura darle, cambia en función de las necesidades (como decía arriba) pero que siempre es bueno tener alguna.

En función de todo esto es que paso a contarles qué estructura tiene hoy Encuentro. No es la mejor del mundo, pero es la que a mí me funciona en este y otros proyectos. Y es una buena base como para que alguien que no tiene idea sepa para qué lado ir ordenando los tantos.

El código en sí lo pueden ver acá o si tienen instalado bazaar pueden hacer bzr branch lp:encuentro y exploran el código de forma local.

Bueno, a los bifes.


El código "útil" en sí

Tenemos dos archivos y varios directorios...

- test: Este es un script que básicamente ejecuta todas las comprobaciones que necesitamos para asegurarnos que el proyecto está "verde". En el caso de encuentro, corre las pruebas de unidad (las que están en el directorio tests, ver abajo), luego corre un verificador estático de código genérico (pylint) y finalmente otro verificador puntual para pep 8.

- version.txt: La versión del programa. La tengo separada sólo por consistencia: me gusta que esté en un sólo lado así es la misma para todos los que la necesitan (setup.py, para mostrarlo al arrancar, o cuando el usuario pide info del programa, etc).

- bin/: Aquí (normalmente) hay un sólo archivo, con el nombre del proyecto: encuentro. Este es el script de inicio, el que arranca todo el sistema ya sea cuando lo ejecutamos desde el proyecto mismo, desde un tarball descomprimido, e incluso es el que va a parar a /usr/bin cuando se instala. Este es el único que es ejecutable, el resto del sistema son sólo módulos.

- encuentro/: Es el directorio principal del proyecto (por eso el nombre). Acá tenemos todo el código "de producción" del proyecto, con su estructura interna. Por lo pronto, en este mismo directorio están todos los módulos que tienen que ver con el funcionamiento interno de Encuentro.

- encuentro/ui/: Aquí tenemos todo el código que necesitamos para armar la Interfaz del Usuario del programa. También tiene que ver con el funcionamiento interno de Encuentro, pero es sólo el manejo de la interfaz. La separación de qué va aquí o qué va directamente en encuentro/ a veces es complicada.

- encuentro/ui/media/: Todas las imágenes, audios, etc, que necesitamos para que funcione la UI en sí.

- encuentro/logos/: También imágenes, pero que se usan como identificación del programa en sí. Aunque algunas se usan en la parte de UI, están todas acá porque también se usan en otros contextos (por ejemplo, en la instalación del paquete).

- tests/: Los tests de unidad del proyecto, normalmente un montón de archivos cuyo nombre arranca con "test_" pero también pueden haber otros (módulos o no) para dar soporte a las pruebas.


Otros directorios

Estos son directorios puntuales que tengo para Encuentro. Algunos se repiten con otros proyectos, otros no.

- qtreactor: El módulo de integración entre Qt (el framework de interfaz gráfica que estoy usando) y Twisted (una biblioteca asincrónica que uso para trabajar con la red).

- server: Cuando le decimos al programa "local" de Encuentro que actualice los episodios, se baja algunos archivos comprimidos de mi server, con toda la metadata. Estos archivos comprimidos se generan una vez al día a partir de los sitios webs de Encuentro, Conectate, BACUA, etc. El código para realizar todo esto está en este directorio.

- web: Todos los archivos necesarios para montar el sitio web del proyecto.

- windows: Imágenes, configuraciones, y explicaciones necesarias para armar el .exe en Windows y luego armar con eso el instalador final que se distribuye.


Otros archivos

Estos son otros archivos que no tienen demasiada relación entre sí, pero que son importantes en distintos momentos de la vida del proyecto:

- AUTHORS, COPYING: Info legal: cuales son las personas que participaron del proyecto, y la licencia del mismo.

- LEEME.txt, README.txt, AYUDA.txt: Textos de ayuda para la persona que llega por primera vez al proyecto (viéndolo desde los archivos fuente). Está en dos idiomas, pero como Encuentro es inherentemente para personas que hablan castellano, el LEEME es el que tiene la info posta.

- anuncio.txt, pasos_release.txt: Recordatorios y textos preparados para mí (o para el que haga la release del proyecto... que vengo siendo siempre yo, :p).

- pylintrc: Un archivo de configuración para el verificador estático de código que mencionaba arriba.

- setup.py, MANIFEST.in: Script principal de empaquetamiento e instalación, más un archivo que podríamos decir de configuración del mismo.

- encuentro.desktop, source_encuentro.py: Dos archivitos necesarios en sistemas Debian/Ubuntu (al menos). El primero le pasa al sistema info para poner el programa en el menú del usuario, y el otro es usado en caso de que el programa crashee, para informar automáticamente del problema.


Actualizaciones

Python — Martes 23 de Abril de 2013, 11:37


Estos días hice dos releases rápidos.

El primero fue de LauncherPosta, porque resulta que en Ubuntu Raring crasheaba mal. O sea, no tiraba un traceback: crasheaba.

¿Lo peor? Es un problema de la librería PyGtk, de cómo está implementado para Gtk 3. ¿Lo peor más peor de todos los peores? Es por diseño, y les parece bien que crashee a la mierda en lugar de tirar un traceback decente (miren el bug que abrí y lo que me respondieron).

En fin, esto refuerza lo que les decía que Gtk3 me gustaba menos y menos y me estoy pasando a Qt.

BTW, de LauncherPosta liberé la versión 1.0, con el casi único cambio de soportar mejor el toqueteo de la configuración del systray bajo Unity (un pedazo de código que luego les compartiré más separadamente).

El segundo release fue de Enjuewemela.

Hace rato que no sacaba una versión del jueguito. Es que aunque le había hecho un montón de correcciones, había un gran feature que estaba esperando: el replayer.

¿Qué es el replayer? Es un modo de ejecución de Enjuewemela que le decís que te reproduzca un juego anterior (le tenés que pasar el log que generó la jugada), y podés ir viendo exactamente el juego que hiciste, avanzando y retrocediendo con las flechas. Esto más que nada lo hice porque era necesario para poder detectar algunos crashes raros, y porque era divertido de hacer, :)

Los cambios más interesantes para esta versión 0.5, aparte de la habilidad de "re-jugar un log", son:

- Alienta cuando hay múltiples coincidencias
- Cambia el tablero cuando cambia de nivel
- Múltiple fondos
- Correcto manejo de los highscores
- Otras pequeñas mejoras y un montón de correcciones.

La verdad es que estoy un poco harto de Enjuewemela. Hay que ponerle un montón de laburo para "hacerlo más lindo" al juego, y la verdad es que "hacerlo lindo" no es algo que me divierta.

Así que creo que sacaré un gran último feature, y luego creo que lo paso a mantenimiento, porque tengo otros proyectos bastante más interesantes para empujar.

Ya los comentaré por este mismo canal. Stay tuned.


Migrando Encuentro a PyQt

Python — Miércoles 17 de Abril de 2013, 17:59


Este no es un post sobre Encuentro precisamente, sino sobre la experiencia de migrar Encuentro a Qt.

O, mejor dicho, a PyQt. ¿Qué es PyQt? Sencillo: una capa de unión para poder usar Qt desde Python. ¿Y qué es Qt? Qt es una biblioteca multiplataforma para desarrollar aplicaciones con interfaz gráfica. En otras palabras, una biblioteca para hacer las ventanas, botones, y todo eso que arma la interfaz gráfica de un programa de escritorio.

Con esa descripciones no tendríamos diferencia entre PyQt/Qt y PyGtk/Gtk, que es lo que usaba Encuentro hasta ahora. Entonces, ¿por qué migrar?

Son varias las razones... pero principalmente porque empaquetar PyGtk en un .exe es un dolor de muelas, y eso llevó a que la última versión que corre en windows es la que no funciona porque cambió todo el backend web (cuando los videos pasaron de ser hosteados por Encuentro a estar en Conectate). En otras palabras: la última versión de Encuentro que corre en windows no sirve para nada, y básicamente es culpa de Gtk.

Otras razón de menor importancia es que no me gustó como Gtk evoluciona. El futuro del framework es Gtk3, y ya estuve tirando código para usarlo, y lo que usé me gustó menos que Gtk2, así que me pareció un buen momento de cambiar. Finalmente, es una buena excusa para aprender Qt, ;)

Qt

En fin. La migración ya está terminada, pude hacer en Qt todo lo que tenía que hacer en función de la interfaz de Encuentro. ¿Qué me pareció? Bueno, las sensaciones son varias.

Me gustó Qt, mucho más cuadradito, más pytónico especialmente en la versión 4 que es la que yo estoy usando. Aunque la mayoría del código es muy similar, hay varias cosas que son más sencillas que en Gtk, aunque no todas, y hay bordes que limar.

(En este punto quiero aclarar que en ningún punto usé Qt Creator, el constructor gráfico de interfaces, sino que hice todo todo a mano, lo cual me permitió meterme bien adentro del framework y aprender mucho de su estructura subyacente.)

Un ejemplo de borde sencillo: no se puede saber si una señal está conectada o no. Entonces, por ejemplo, yo tengo un botón que muta de función, y a veces tiene que tener una señal conectada, y a veces otra (para que al hacer click haga una cosa u otra; en particular en el contexto de Encuentro: que el botón dispare la descarga del episodio, o la reproducción). Cuando el contexto cambia y se hace la revisión del estado del botón, no puedo decirle que desconecte cualquier señal que tenga, o preguntar qué señal tiene y desconectarla, tengo que (a mano) guardar en algún lado la señal que había conectado antes para desconectarla y conectar la nueva que corresponda.

Un ejemplo de algo complicado de hacer en Qt (que en Gtk es trivial): QTreeWidget no soporta HTML en el texto. Esto es, la habilidad de insertar tags para cambiar el tipo de texto (en el caso de Encuentro, yo lo necesito para resaltar en amarillo el fondo de las letras que coinciden con lo que el usuario ingresó en el campo de filtrar). Finalmente lo pude hacer, adaptando un ejemplo que Roberto Alsina encontró en la web, pero lo hace más lento, le agrega pequeños glitches que aunque no me joden, no deberían estar, y me mete a mí código oscurísimo que no es ni cerca de fácil de debuguear.

Por último, la integración con Twisted no es trivial. Hay cosas que en Encuentro están hechas con Twisted que podrían hacerse con herramientas más propias de Qt, sí, pero en este caso de migración, ya estaban hechas en Twisted y mi idea era aprovecharlas. Pero tuve que meter en el proyecto todo un módulo de integración y levantar la aplicación y cerrarla de una manera no trivial (y que me costó tiempo y sudor hacer que funcione correctamente, especialmente la parte de cerrar la aplicación, porque tuve que apagar los hilos de Twisted a mano).

La conclusión es que Qt me gustó bastante, y aunque extraño algunas cositas de Gtk, seguramente mis nuevos proyectos estarán usando PyQt.


El tutorial de Python 3 en español

Python — Sábado 02 de Marzo de 2013, 10:56


Finalmente terminé de armar todo para liberar al mundo la versión traducida al español del tutorial de Python 3.

Realmente había terminado de traducirlo hace un par de semanas. Pero (aunque la generación del HTML fue bastante directo), generar el PDF me trajo bastante problemas.

Por un lado, el PDF generado por inkscape para los headers bonitos que tenemos es incorrecto en algunos detalles, así que tuve que meter un hack en el proyecto pdfrw para evitar que explote con ese problema. Luego habían problemas con páginas en blanco al final de capítulos que tuvieran footnotes, así que metí un workaround en rst2pdf para que reportlab no la cague al generar el PDF. Y dos o tres detalles más, pero menores (gracias Roberto Alsina por toda la ayuda en este bardo). Todos los parches (para poder reproducir la generación de algo copado) están en el README del proyecto.

También tuve que renovar el cómo presentábamos el tutorial, porque ahora tenemos el mismo para las versiones 2 y 3 de Python. Entonces ahora puse que la URL principal del tutorial apunte a un HTML muy bonito (gracias Rodrigo Bistolfi) que te deja elegir si querés ir qué versión del tutorial, tanto en Python 2 o 3, como en su formato: HTML o PDF. También reformulé la página del tutorial dentro del sitio de PyAr.

En fin. Disfruten y pásenlo.


El árbol fluorescente

Python — Lunes 25 de Febrero de 2013, 23:06


En otra edición de "cosas que hice hace tiempo y me resultaron útiles ahora", les presento un proyecto que nació hace cinco años y medio de una charla de PyAr.

Como explico en este post, para jugar un rato con un amigo hice un árbol Trie, que luego de algunas optimizaciones degeneró en algo que llamé "Fucked Trie".

Este árbol para guardar palabras y buscarlas por prefijo de forma muy muy rápida resultó ser lo que necesitaba en el laburo un par de semanas atrás, pero con un cambio: ahora cada palabra tenía que guardar cierta metadata (que luego se obtendría al buscar).

Entonces, agarré el código original, lo modifiqué un poco, y armé este proyecto nuevo que se llama Fluorescent Trie (porque Fucked quedaba muy fuerte para un proyecto, vissste).

Fluorescent trie

Características de este árbol:

- Está pensando para mantenerlo en memoria: ocupa poco, y carga rápido

- Las búsquedas son por prefijo: O sea, entrando con "foo" encuentra "foo" y todo lo que empieza por "foo". No encuentra "grafoo".

- Las búsquedas son extremadamente rápidas (en el orden de los 10-4 segundos).

- Cada palabra tiene un payload que puede ser cualquier cosa.

Si lo necesitan para algo, aprovechen.


CDPedia 0.8

Python — Lunes 21 de Enero de 2013, 19:30


Luego de bastante laburo las últimas semanas, estoy muy contento de anunciar (de mi parte y de Python Argentina) que está en la calle la versión 0.8 de CDPedia, un proyecto que permite acceder a la información de la Wikipedia en castellano sin necesidad de una conexión a Internet.  Se puede descargar libremente de la red y grabar a CDs, DVDs o memorias USB para repartirla sin restricciones.

La CDPedia funciona en cualquier computadora, ya sea que tenga Linux, MacOS o Windows como sistema operativo, y esta última versión incluye contenido de Wikipedia a Diciembre de 2012.

Para mayor información e instrucciones para la descarga, visitar la página del proyecto.

Logo


Esta versión trae las siguientes novedades:

  • Renovamos completamente la generación del ejecutable para Windows, se deberían tener muchísimos menos problemas para usar la CDPedia en ese entorno.
  • Al extraer las páginas de Wikipedia, se les hace un análisis para evitar los artículos vandalizados (en este caso, se baja una versión más antigua, pero correcta).
  • El servidor interno ahora es multiusuario, lo que simplifica enormemente instalar CDPedia en un servidor y que sea accedida desde distintos clientes.
  • Ahora se incluyen en los discos todas las páginas de las categorías, no sólo la primera.
  • Actualizamos el contenido a Diciembre 2012.
  • Varias mejoras a la hora de la generación de discos y tarballs, así como también en la calidad del código.

Si tenés discos disponibles, hacé algunas copias de CDPedia para regalar a tus familiares y amigos, a la biblioteca de tu barrio, o a la escuela de tus hijos. ¡Difundí CDPedia!


Regalo de fin de año: Encuentro 0.9

Python — Domingo 30 de Diciembre de 2012, 19:40


Y digo que es un regalo para las fiestas porque esta versión trae algunas cosas interesantes.

Por un lado, ¡hay un nuevo backend! Cuando actualicen los contenidos van a ver que pueden descargar programas del Banco Audiovisual de Contenidos Universales Argentino (gracias Gonzalo!),

Por otro lado, rediseñamos la GUI en el último sprint. Ahora tenemos un sector a la derecha con la imagen del programa (gracias Diego!) y la descripción (más un botón de acción). Y también hay una cola de descargas, donde se muestra lo que se está descargando, lo que ya terminó (y cómo), y lo que está encolado para después.

Los programas terminados ahora se ponen de otro color, y son fáciles de filtrar porque hay un checkbox que hace que se muestren sólo esos.

También hay un mejor manejo de las cancelaciones, más logging, y otras pequeñas mejoras y correcciones.

Como siempre, las formas de instalarlo, toda la info, y etc, en la página del proyecto.
   
¡¡Feliz fin de año!!


Cortando mal

Python — Viernes 21 de Diciembre de 2012, 20:07


Una de las cosas que repito mucho en mi charla de Entendiendo Unicode es que "siempre, siempre, siempre, hay que procesar los textos estando en unicode, no en bytes, porque se pueden obtener resultados inesperados".

Acabo de encontrar un caso de estos. Lo interesante es que es un caso que no había visto nunca.

Estoy agregando a mi programa Encuentro un nuevo backend: BACUA. Bueno, ya casi está (gracias a la ayuda de Gonzalo Martinez), el tema es que había una página que tenía problemas de unicode. Me puse a investigar, y resulta que el problema es que se estaba decodificando con el encoding incorrecto.

Se intentaba decodificar con UTF-8, pero como fallaba, se decodificaba con otra cosa, y algunas palabras quedaban mal.

Empecé a ver en detalle, y resulta que la página está toda bien codificada en UTF-8, excepto una parte. La linea "molesta" es esta:

'          <h5 class="sinopsis_cat">Los Ludomatic, banda de m\xc3\xbasica infantil exitosa en los a\xc3\xb1os 80, se re\xc3\xbane luego de veinte a\xc3\xb1os para ver que sus vidas no son como lo hab\xc3\xadan imaginado tiempo atr\xc3\xa1s. Toni, Becca, Marco, Lupe y Ren\xc3 ...</h5><br/>\r\n'

Como pueden ver, está toda casi bien, en utf8... por ejemplo, dice "Los Ludomatic, banda de música", y ahí vemos que la "ú" está bien codificada en utf8 como 0xC3 0xBA. El problema está al final, en el último nombre. Seguramente debía decir "Toni, Becca, Marco, Lupe y René", pero está cortado (con el agregado de los tres puntos, para indicar continuación).

Y está cortado mal.

Obviamente, si los que generaron la página hubiesen procesado el texto como unicode, se hubiese cortado antes de la é o después de la é. Pero no, lo manejaron como bytes, donde la é codificada como utf8 es 0xC3 0xA9. Y por mala suerte el corte cayó en el medio de esos dos bytes. Y quedó el 0xC3 suelto, que no es utf8 válido.

Y bueno. Eso. Recuerden: Siempre hay que procesar los textos como Unicode.


Charlas repetidas

Python — Martes 04 de Diciembre de 2012, 18:51


Les comentaba en un post anterior que había vuelto a dar "Entendiendo Unicode" en las PyCones de Argentina y Venezuela. Charlando con alguien más de este tema, le decía que seguramente era la charla que más veces dí.

Bueno, no, este es el top 5 de todas las charlas que dí:

   13  Introducción a Python
   10  Entendiendo Unicode
    8  Python más rápido que C
    4  Python 3000
    3  Comunidad, anarquía y subversión

Se acumulan las repeticiones.

Y es algo natural, teniendo en cuenta que por año preparo casi siempre una charla nueva pero presento entre media docena y una docena de veces...


Nuevo Encuentro

Python — Martes 16 de Octubre de 2012, 18:11


No, este no es un post sobre un partido político. Sino que es el anuncio de que tenemos una nueva versión de Encuentro en la calle!

Encuentro es un simple programa que permite buscar, descargar y ver contenido del Canal Encuentro, Paka Paka, Educ.ar y otros.

Encuentro

La versión 0.8 trae los siguientes cambios con respecto a la versión anterior:

  • Soporte para múltiples fuentes de datos. Ahora también baja los episodios perdidos de la web de Encuentro.
  • Corregido el problema que hacía perder las actualizaciones cuando se reordenaba o filtraba (dando la impresión que los downloads se trababan).
  • Mejor uso de nombres y directorios al grabar los videos.
  • Otras pequeñas mejoras y correcciones.

Pueden ver en la página las distintas formas de instalarlo según el sistema operativo. Recuerden revisar el archivo AYUDA.txt si tienen alguna duda de cómo usar el programa.

¡Que lo disfruten!


PyCamp 2012

Python — Jueves 12 de Julio de 2012, 22:26


A esta altura ya no voy a andar explicando qué es un PyCamp, ni todo lo copado que está. Fue repetido hasta el cansancio por mí en este blog y por otros en otros lados. Busquen.

Este año no fue la excepción, estuvo muy bueno, aunque distinto. Principalmente porque fue en Julio, e hizo mucho frío. Igual, eso no evitó que disfrutemos actividades al aire libre, pero creo que tendimos a salir un poco menos de la comodidad de la zona de trabajo.

Trabajando cerca del fuego

El viernes arrancó demasiado lento... la gente fue llegando tarde, y no tuvimos la reunión de selección de proyectos hasta justo antes del almuerzo, y luego de comer hicimos la votación y asignación de slots. Inmediatamente luego de eso me puse a jugar un poquitito con Spacecraft, un sistema donde se programan navecitas para que luego combatan entre ellas, tratando de darles la mayor "inteligencia" posible.

Estuve con eso hasta que arrancó otro tema que me interesaba mucho: Python en Android.  Arrancamos la sesión charlando sobre qué frameworks había, y ventajas y desventaja de cada uno. Finalmente, decidimos probar Kivy, un framewook crossplatform que compila Python para android y escritorio.

Instalarlo y hacerlo andar no fue trivial, pero tuvimos éxito con ejemplos que trae el framework y hacerlos andar en nuestros teléfonos, y la verdad es que quedamos maravillados con los resultados.  Lipe siguió luego trabajando con esto e hizo una "botonera de efectos" bastante piola.

A la noche nos hicimos un partidazo de Battlestar Galáctica, pero el sueño me venció y me fui a dormir antes de terminarlo :(

Jugando BSG

El sábado estuve con distintos temas chiquitos, lo más que hice fue trabajar en CDPedia, ultimando detalles que nos permitan hacer un dump actualizado. Charlamos y trabajamos bastante con Diego Mascialino, y creemos que en las próximas semanas ya podríamos estar liberando una nueva versión actualizada, :)

También estuvimos de compras, y hasta hubo un partidito de fútbol a la tarde. Después del asado de la cena volvimos a jugar a algo: esta vez, un "Settlers of Catan" pero holandés, que permite jugar hasta seis personas. Buenísimo!

El domingo arranqué duro y parejo con mi programa Encuentro. Yo lo había actualizado para que funcione con el nuevo portal Conectate, pero necesitaba pulir varios detalles tanto en el lado cliente como el servidor. Me ayudaron Diego, Humitos y Martín, y lo dejamos en mucho mejor estado que al principio del PyCamp.

A la tarde hubo un taller de malabares, dictado por Humitos, que estuvo genial. Yo me enganché un ratito, nada más (seguía a full con Encuentro), pero nos tiramos unas clavas entre tres, que nunca había hecho, e hice este videito para compartirles.

Para cerrar el día, luego de cenar, tuvimos reunión de PyAr. Esta vez fue alrededor de una gran fogata que armamos (en un lugar preparado para ello), y la verdad es que estuvo buenísima. Se hablaron de un montón de temas, principalmente de PyCamp, PyCon, y del lugar de PyAr en la sociedad. Pero no hay nada que discutirle: la fogata y estar todos reunidos alrededor de ella le dió un saborcito especial :)

Reunión de PyAr

El lunes, como todo último día, estuvo más relajado, y marcado por la despedidas de la gente que se iba a distintas horas. También se cerró el campeonato de ping pong, el cual fue facilmente ganado por David que es un profesional en el tema.

Yo le seguí metiendo laburo a Encuentro (ya está casi listo para el release tan esperado que lo vuelve a la vida), pero también me hice un ratito para charlar con Roberto sobre qué posibilidades hay de migrar mi blog a Nikola, y de ir a comprar honguitos a la champignonería que está a dos cuadras de donde estábamos nosotros.

Y luego, sí, la etapa de cierre. Ya quedando pocos, terminar de desarmar todo, limpiar, dejar ordenado, saludar a la gente que cuida el lugar, y partir en un viaje que pensamos que iba a ser más complicado (la "vuelta" de un fin de semana largo) pero que no estuvo tan mal.

Foto grupal

En fin. PyCamp. El evento que más me gusta del año.

(algunas fotos: acá, acá y acá)


Workshop para principiantes pre-PyCamp

Python — Sábado 19 de Mayo de 2012, 10:53


Siempre que hablamos de diversidad sale el tema de ayudar a principiantes, de bajar la barrera de entrada para que los chicos y chicas nuevas participen en proyectos de la comunidad.

PyCamp es uno de esos eventos en los que un principiante puede tomar velocidad y salir, en cuatro días, con una experiencia grosa, habiendo trabajado codo a codo con desarrolladores "seniors", y todo en un ambiente divertido. Más info sobre el PyCamp 2012 acá.

Pero hay que animarse a venir al PyCamp. Y se escucha muchas veces razones como las siguientes...

  • "Pero yo sé muy poco de Python, apenas estoy empezando"
  • "Me da vergüenza laburar con gente que sabe mucho"
  • "No conozco a nadie de los que van"
  • "No sé editar un wiki para colaborar con otros"
  • "¿Qué es bazaar, mercurial o git? ¿Cómo arranco?"
  • Etc.

Entonces, estuve pensando, y creo que lo mejor que puedo hacer para ayudar a la gente que está tan cerca de ir a algo tan groso como un PyCamp pero que no termina de animarse, es un workshop pre-PyCamp para "limar estos detalles".

¿Qué estructura tendría este Workshop? Lo estaba pensando en dos partes más bien separadas, una donde dejemos la computadora de cada uno lista para trabajar, y otra donde aprendamos las distintas herramientas...

- Set up:
    * Instalar Python
    * Instalar y preparar un editor de texto o IDE
    * Instalar sistemas de control de versiones
    * Hagamos un "Hola mundo"!

- Pequeñas gotas de conocimiento:
    * Intro a Python y más (~1 hora)
    * Trabajando con mercurial, git y bazaar (~1 hora)
    * Cómo usar un Wiki (~20 min)

La idea de la charla de Python es para nivelar conocimientos, y de los sistemas de control de versiones no es hacer comparaciones ni discutir cual es mejor: sólo mostrar los cinco comandos más comunes de cada uno que le permitan a una persona trabajar con un grupo que está usando ese control de versiones.

¿Cuando sería y dónde? Capital Federal, el jueves 5 de Julio. Al otro día arranca PyCamp en Verónica, y la mayor parte de los que vayan van a pasar por Capital Federal, así que "queda de paso"... sí, si vienen de lejos van a tener una noche más de hotel o hostel, pero seguro que lo podemos resolver a nivel comunidad (gente de PyAr que tiene un colchón de más en la casa, por ejemplo... y si al otro día también va a PyCamp, es un win win).  Creo que se puede hacer todo en una tarde (arrancar a las 14hs, terminar a las 19hs, e ir a tomar/comer algo entre todos).

¿Quienes pueden venir? Obviamente, gente que esté anotada al PyCamp. Pero si están tan indecisos de ir o no ir, me mandan un mail y vemos qué podemos hacer. Un detalle muy importante: por favor agreguen su nombre a la lista en este wiki si planean venir al workshop (para ver si juntamos gente interesada, y estimar cuantos seríamos). Obvio, si no saben o no pueden editar el wiki, me mandan un mail y yo los agrego.

Finalmente, acá es donde *yo* pido ayuda. Necesito:

  • Un lugar donde hacerlo... lugar para ~10 personas, con pizarrón, proyector, y servicios básicos (baño, agua para mate, etc).
  • Alguien que conozca git y mercurial para enseñar esa parte (o contármela a mí antes, aunque luego ese día no vaya).

Gracias por esta ayuda, coordinemos la misma también por privado.

Bueno, veremos si se puede hacer y cómo sale, me parece que es una idea piola...


Powered by LifeType