Bitácora de Vuelo

Hace rato me pasaba que cuando recibía llamadas en el celular, en la mayoría (no todos) de los casos me mostraba el número que me llamaba, pero no el contacto correspondiente (teniendo cargado ese número en mi lista de contactos, claro).

El otro día me pasó nuevamente, y me quejé públicamente, y me sugirieron que podía ser por la forma en que estaba anotado el número.

Yo había pensado en eso, pero como a los números los tenía cargado "bien" (entendiéndose por "bien" a lo que indica el PFNN), pensé que era otra cosa. Pero en ese hilo de Twitter me sugirieron una forma de anotar el número, que a priori no tiene sentido porque tenía números "de marcado" (como el 15, o el +, que no forman realmente parte del número), pero decían que funcionaba.

Hice varios experimentos y en efecto, para que el teléfono me reconociera el número entrante, tenía que escribirlo de formas particulares. Probé casi todo, y al final declaré ganador a los formatos +54 9 PFNN (para celulares) y +54 PFNN (para el resto), siendo PFNN el número "real sin detalles de marcado", y esos obviamente para numeración de Argentina.

Con ese formato tengo las ventajas de que el teléfono me reconoce el contacto del número entrante, y que al mismo tiempo yo puedo usar ese número para llamar al contacto, estando dentro o afuera del país.

¿El problema? Obvio que no iba a corregir todos mis contactos a mano. Como los contactos del teléfono los tengo en una cuenta de Google, decidí hacer un pequeño script que lo haga automáticamente, no sin cierto pesar porque las APIs de Google dejan mucho que desear.

Bah, no es que las APIs en sí sean malas. A veces son complicadas o rebuscadas, pero no más. El inconveniente es que son muchas, van cambiando con el tiempo, y la mayoría de la documentación es pobre, está desactualizada, tienen ejemplos que no funcionan, etc.

Pero me puse, y luego de revisar mil páginas, pelearme un poco, leer código fuente, probar distintas alternativas, y eso, terminé haciendo este programín que efectivamente baja toda la info de mis contactos, procesa los números de teléfono, y cuando corresponde los vuelve a grabar en la nube.

Péguenle una mirada al código ese, y pruébenlo con el cuidado correspondiente, pero debería funcionar. Les dejo algunos consejos con respecto a esta API de contactos en particular, por si quieren hacer algo parecido...

Antes que nada, vayan a esta versión, que ya autentica con OAuth, porque la forma vieja (con usuario y clave) ya está apagada. Van a tener que crear un proyecto, y poner los client_id y client_secret correspondientes en el script, luego la primera vez que lo ejecuten van a tener que darle permisos a través del navegador (es bastante automático, no tienen que hacer nada raro), y las próximas veces va a reusar esos permisos.

Tengan en cuenta que ese permiso es en función del scope que elijan (sólo lectura, que es una buena forma de empezar teniendo la seguridad que no van a romper nada, o lectura/escritura). Si autentican con un scope y luego lo cambian, borren el auth_info.dat así el script autentica nuevamente con el scope cambiado.

Entonces, les decía que la API está descripta acá, pero está contada de forma más genérica acá. Ojo que faltan ejemplos de Python, y lo que muestra de "Protocolo" y de "Java" no se corresponden entre sí.

En ese sentido me sirvió mucho esta referencia de la API a nivel Python. Y ojo con los ejemplos que hay por ahí, incluso los más oficiales y actualizados que encontré tenían errores en los imports o en las funciones que llamaban.

En fin. Si van a hacer algo parecido, arranquen del programa que ya dejé andando, y modifiquen desde ahí. Que les aproveche.

Finalmente, luego de mucho tiempo, me fui de gVim, el Vim integrado a interfaz gráfica con base en Gnome.

Me funcionaba, y lo usaba a diario, todo el tiempo, pero me pasó varias veces que quería mejorar algo, modernizarlo, agregarle un plugin tal, toquetearlo en algo puntual, y me trababa. Es que el proyecto no estaba del todo activo y había quedado un poco antiguo. Además ahora estoy basado en KDE, y era medio a contramano seguir instalando mucho de Gnome solo para gVim.

Y ahora me liberé, dejé el pasado, me renové, soy un hombre nuevo.

Ahora soy un feliz usuario de Neovim. Basicamente un Vim modernizado, con muchos defaults pensados correctamente para este siglo, con un desarrollo activo, y la mar en coche. Si quieren profundizar en qué (y qué no) es neovim, pueden leer sobre su visión acá. Gracias Fisa por insistirme varias veces en hacer el cambio.

Traté un par de veces usar Neovim en el pasado, pero enseguida me chocaba con una limitación de uso bastante específica. Es que Neovim (como el Vim "pelado") cuando los ejecutás desde la terminal te usan esa terminal para su interfaz. A mi NO me gusta eso, yo estoy en la terminal manejando un proyecto o yendo de acá para allá, y en el momento en que abro un archivo, NO quiero que me ocupe esa terminal, sino que se abra en una nueva ventana. Y tiene que ser una nueva ventana, no una nueva pestaña, porque yo quiero poder ver varios archivos al mismo tiempo (y me es importante la ubicación espacial de las distintas ventanas).

Entonces busqué y probé varias "interfaces gráficas para nvim" pero con todas tenía algún problema (fue una exploración poco prolija, no tengo buen feedback para darles en este punto). Así y todo, com Neovim se corre en una terminal, pensé en que cada vez que abra un archivo disparar una terminal nueva con Neovim ahí adentro. Y medio lo solucioné haciendo que vi sea un alias de "abrir una ventana nueva con una consola ahí adentro que me ejecutara nvim editando el archivo que especifiqué", aunque esto me llevó un tiempo porque intenté hacerlo con konsole (de nuevo, KDE) pero crasheaba casi siempre luego de cerrar el editor (!): lo terminé haciendo con gnome-console, que andaba mejor... no me gustó del todo, pero andaba lo suficientemente bien.

Pero en su momento nunca terminé de pasar a Neovim porque me trabé con tratar de hacerle andar flake8, el analizador estático de código Python que yo tengo integrado en gVim, funcionalidad que considero indispensable en el día a día. Por una cosa u otra, no tuve tiempo de seguir probando, y lo abandoné.

Luego vino la PyCon 2019, y Fisa dio una lightning talk sobre su famosa configuración para Vim, mencionó que instalar todo era sencillo, y yo me decidí a probarlo. Además volví a pegarle una mirada a ver qué GUI encontraba y me choqué con neovim-qt que funcionó super piola.

Hoy puedo decir que me convertí. Pero el camino no fue sencillo.

Por lo pronto, la instalación de Neovim y neovim-qt es bastante a mano, porque son proyectos muy nuevos y prefiero usar las últimas versiones disponibles. Para Neovim lo que hice fue bajar la appimage de neovim, hacerla ejecutable y moverla/renombrarla a /usr/local/bin/nvim. Y para neovim-qt cloné el proyecto, lo buildeé (instrucciones en el README), y copié el ejecutable a /usr/local/bin/.

Después arranqué con la config de Fisa y empecé a entenderla y agregarle los detalles que yo necesitaba. Luego la cantidad de cambios creció. En un momento me dí cuenta que en algunos casos me resultaba lento y al debuguear era por plugins que no me interesaban, entonces decidí realizar una limpieza de todo lo que no quería. Al final terminé forkeando el proyecto y ahora tengo esta config.

Entonces, luego de instalar Neovim y neovim-qt, todo lo que hago es llevar (o symlinkear) los archivos init.vim y ginit.vim de ese proyecto-config mío a ~/.config/nvim/, abrir un editor y esperar que la magia que armó Fisa instale todos los plugines y deje todo pipícucú.

Y vualá.

Como frutilla del postre, les cuento que con Fisa armamos un grupo de Telegram para ayuda de Vim en español. Que lo disfruten.

¡Disclaimer! Esta es mi explicación fundamentada de por qué me parece bien el lenguaje inclusivo, por qué lo uso, y por qué uso la forma que uso.

Es la razón por la que YO lo uso, no intento convencerles a ustedes, cada une habla como quiere :) No intenta ser una justificación de si el lenguaje inclusivo es bueno o no, sólo lo que me convenció a usarlo.

Si quieren leer más sobre el tema les dejo este artículo de El Gato y La Caja, mejor escrito y con el tema mejor analizado que en este mi texto.

Entonces.

A mí siempre me hizo ruido el tema de generalizar al masculino. Aprendimos que era lo correcto, un montón de señores a sueldo de la corona española dicen que está bien, pero siempre me molestó en algún rincón de mi cerebro.

En verdad no tiene sentido generalizar a masculino. Desde un punto de visto puramente técnico, si uno diseñara el lenguaje desde cero, no tiene sentido generalizar al masculino.

Como ejercicio, imaginemos un grupo de personas esperando el colectivo, pasa un auto que pisa un charco y salpica todo.

Si ese grupo fuesen diez mujeres, diríamos "las mojó un auto que salpicó", denotando que son todas mujeres. Si ese grupo fuesen diez hombres diríamos "los mojó un auto que salpicó", implicando que son hombres. Hasta acá todo bien (o no, pero luego llegaremos al no binarismo, sigan conmigo por favor).

Pero si ese grupo son nueve mujeres y un hombre, teóricamente deberíamos decir "los mojó un auto que salpicó". La simple aparición de un hombre en el grupo modifica la expresión y la deja igual que si fuesen todos hombres. Invisibiliza que en el grupo hay mujeres (¡que incluso son la mayoría!).

No tiene sentido. El tema es: ¿qué hacemos para hablar y escribir "mejor"?

Hace muchos años arrancó una movida de escribir con @. "L@s mojó un auto que salpicó". Aunque simpática, esa forma de escribir realmente es ilegible. El cerebro no lee "L-arroba-s", automáticamente convierte a esas tres letras en el artículo que el cerebro espera que tenga sentido con el resto de la frase, y en realidad leemos "Los". Además, es impronunciable si leemos el texto en voz alta. Sucede exactamente lo mismo con la x. "Lxs mojó un auto que salpicó". También ilegible e impronunciable, realmente.

Por eso me encantó cuando apareció la forma de deformar las palabras usando la e. "Les mojó un auto que salpicó". El cerebro ahora lee eso como "Les" y no se puede hacer el boludo, al punto que al principio y si no estamos acostumbrados molesta un poco (¡y está bien que moleste!). Y se puede hablar con la e, cartón lleno :)

La otra gran ventaja de esta forma de escribir es que dejamos de lado el binarismo hombre/mujer que implica escribir "Los/as mojó un auto que salpicó", indicando que son hombres o mujeres solamente, y no la multiplicidad de géneros que hay en realidad.

Por otro lado, tenemos que tener en cuenta que el lenguaje inclusivo lo podemos usar cuando hacemos referencia a un grupo de "géneros mezclados" (como los ejemplos anteriores) pero también cuando hacemos referencia a una persona pero queremos ser neutrales con respecto al género (ejemplo: "Le mojó un auto que salpicó", no "La" ni "Lo"), pero NO debemos usarlo para entidades que tengan un sólo género. Está mal decir "Conecté les parlantes al equipo de audio", porque el parlante como entidad tiene sólo género masculino, entonces ahí va "Conecté los parlantes al equipo de audio".

Habiendo dicho eso, demos una vuelta de rosca más: sí está bien usar el género neutro cuando pluralizamos entidades que, aunque individualmente tienen género definido, el grupo no. Ejemplo: "Saqué las puertas y los estantes al patio y les lavé con ganas"... acá el "las puertas" y "los estantes" están bien, porque esas entidades tienen su género bien definido, pero cuando hacemos referencia al grupo completo al final de la frase lo hacemos siendo neutros.

Para terminar, les dejo con algo que no tengo del todo resuelto: la neutralización de aquello que en alguna de sus formas (masculino o femenino) YA usa la e. Ejemplo: "Los atorrantes" es en masculino, "Las atorrantas" es en femenino, ¿cómo neutralizamos el género? Si vamos ciegamente a la e nos queda como el masculino, no estamos neutralizando nada. ¿"Estudiantos"? No sé.

Hace mucho tiempo que veníamos con ganas de cambiar el logo de Python Argentina.

Es que el que veníamos usando ya había cumplido su ciclo. Nació durante los primeros meses de Python Argentina, casi que "era una joda y quedó"; cuenta la leyenda que Pablo Ziliani lo diseño/armó de apuradas para algo que necesitábamos y después yo lo agarré y vectoricé, con lo cual pudimos escalarlo (hola bandera de PyAr) y después ya quedó y lo seguimos usando.

Nunca estuvo bueno a nivel de diseño gráfico. Más allá del diseño en sí (que a mi me gusta) el logo tiene sus serios problemas de construcción: cuando yo lo vectoricé le puse unos gradientes en las letras que muchas veces nos complicaron la vida en determinados casos de uso. Hasta estos días, incluso, a veces voy a imprimir algún cartel o similar, y el logo sale impreso raro (y no siempre "igual de raro").

En los últimos años hubieron varios intentos de que alguien de la comunidad armara un nuevo logo, pero nunca prosperó. Es difícil derribar algunos status quo.

El año pasado me harté y decidí empujar yo el cambio. Me pareció una buena oportunidad hacerlo durante el 2019, ya que PyAr cumplió 15 años, ¡era hora de tener una renovación visual!

Como tuvimos buena experiencia con el diseñador gráfico de la PyConAr 2018, Gastón Meza, decidí no sólo volver a utilizar sus servicios para la PyConAr 2019 sino también encargarle el diseño del nuevo logo de Python Argentina.

Entonces me junté con Gastón y charlamos de cómo sería el proceso, que luego ejecuté: definimos (entre varias encuestas, más un proceso de curado manual y pensado) aquellas palabras que definieran conceptos claves de lo que es Python Argentina, y luego le pasamos esas palabras y explicamos esos conceptos a él, que lo trabajó y luego de algunas iteraciones terminó presentándonos el Manual de Identidad Gráfica de Python Argentina, cuya lectura recomiendo efusivamente.

Este es el resultado final, en una de sus versiones:

Obvio que a un montón de gente le pareció raro el logo, o el cambio, o la nueva imagen. Es así, los cambios siempre generan un poco de rechazo. Pero a otro montonazo de gente le encantó. Yo estoy contento.

Una de las ventajas de tener un laburo bien hecho y completo es que tenemos distintas alternativas listas para usar y pensadas, tanto de PyAr grupo como de la Asociación Civil, en versiones horizontal, vertical, a un sólo color y escala de grises.

Aproveché y metí todo ordenado en este directorio del repo de PyAr.

Pasó la PyCon Argentina 2019.

Realizada por segunda vez consecutiva en Buenos Aires, volvimos a pasar la marca de mil personas. Por la experiencia de otros años, se notó que el tercer día NO era sábado, donde hay mucha gente nueva que viene porque no pudo venir en la semana. En este caso la gente del viernes fue más o menos la misma que la del jueves. Sirve como aprendizaje: en el futuro tenemos que tratar que haya la mezcla "día de la semana y sábado".

Tampoco es que elegimos que sea de miércoles a viernes, fue la única opción que nos dejó el Centro Cultural General San Martín. Tuvimos otros detalles de organización al respecto que me obligó a salir corriendo a buscar proveedores para alquilar elementos que dábamos por hecho (teles, mesas) e incluso estuvimos el lunes anterior con Nico Sandoval todo el día resolviendo cuestiones allá: pegando cables al piso, comprando insumos, resolviendo conectividad, etc; un baile.

Los días de la conferencia en sí también tuvimos algunos detalles que tuvimos que resolver de emergencia, pero nada importante. Fuimos solucionando todo lo que se podía solucionar, y al final salió todo bárbaro.

Habían cosas que eran imposibles de corregir, sin embargo. Por ejemplo, los aires acondicionado de las salas C y D están para atrás. En la D se soportaba, pero en la C, que funcionaban dos de los tres, cuando se juntaba la gente hacía mucho calor. Por suerte las temperaturas de esos días fueron tranquilas, aunque la gente tomó más líquido que el año pasado (contratamos un 25% más de bidones para los dispensers, y se acabaron).

También faltaron un par de disertantes sin aviso, e incluso una de las keynotes nos canceló con menos de 24hs de anticipación, con lo que decidí cancelar ese espacio y no volverme loco tratando de suplantarla.

Algunas cosas funcionaron mucho mejor que el año pasado. Todo lo que fue internet (conexión y wifi) anduvo mucho mejor (contratamos extra a Fibertel para la conectividad y a un proveedor externo para el wifi), y el proyector de la sala AB no nos trajo tantos problemas como el año pasado (era otro, porque la disposición en esa sala fue otra).

Algo que repetimos fue darle a la gente un "subidón de azúcar" en el break de la tarde, con dos mesas en las que pusimos fruta y dulces. La gente se abalanzaba como si fuese el último chocolate del universo.

El último día dio su keynote Martín Sarsale. Me pareció muy buena, y mucha gente me comentó que le había encantado, así que estoy contento con esa elección. Esta es su presentación.

Después de Martín hablé yo sobre El futuro de Python Argentina donde no sólo mencioné que tenemos el PyCamp en Marzo y tiré la noticia que PyCon Ar 2020 se hace en Rosario, tipo Octubre o Noviembre, sino que también hablé un poco de la renovación necesaria que debemos tener en la gente empujando proyectos, el papel de la Asociación Civil como soporte a esa gente, y que los primeros 15 años del grupo nos trajeron hasta acá, pero que tienen que ponerse en el hombro los próximos 15.

Luego dar premios a preguntas sencillas, revolear regalitos, y antes de que la gente se fuera del todo, hacer la foto grupal.

Y de ahí a terminar de acomodar las cosas para liberar el centro cultural (parte del equipo había estado acomodando/organizando casi todo desde un par de horas antes), e irnos a tomar y comer algo para felicitarnos por lo bien que había salido todo :)

En las próximas semanas saldrán las fotos del evento e iremos subiendo al canal de Youtube de PyAr las charlas grabadas. Stay tuned.