Juanjo Conti: Mayo del 68

En la edición de hoy de Poetas leyendo a otros poetas Leo Pez lee Mayo del 68 de Eduardo Zotto.

En una competencia con el sonidista de la feria del libro, Pez lucha porque sus palabras se escuchen sobre la fuerza del jazz.

Juanjo Conti: Presentación de El puto infierno, de Gonzalo Geller

Hace un rato, en la planta alta de la estación Belgrano, durante la feria del libro, Gonzalo Geller presentó su más reciente novela: El puto infierno.

Hoy no pensaba ir a la feria, pero hice el esfuerzo de llegarme por dos razones:

  • Gonzalo es muy genereso con los autores que edita y siempre les organiza presentaciones de libros. Casi no hace presentaciones para los suyos.
  • Soy fan de una fracción de su obra, la fracción que yo denomino "Novelas con humor" ( ¡La re venganza!, Con el asado, no, El muy maldito, por nombrar algunas) y El puto infierno es la continuación de una de ellas. No me la quería perder.

En la presentación Gonzalo contó la genesis del proyecto y los distintos aspectos que lo moldearon así como una muy interesante teoría sobre el éxito del género "zombies". Luego siguienron 3 lecturas.

Con el asado, no: para abrir el apetito.

El punto infierno: el libro que nos reunió.

El imperio de los feos: el nuevo desopilante proyecto.

Manuel Kaufmann (Humitos): Red Libre

Viajar te abre la cabeza. Constantemente uno está conociendo personas, aprendiendo sobre otros estilos de vida y también entendiendo sus negocios para conseguir dinero y así poder seguir adelante con sus sueños.

También uno se encuentra con personas más estáticas, que trabajan fuerte en un mismo lugar todos los días para implementar una idea en particular en esa zona y así construir una red de contactos entre personas, brindar un servicio o mejorar algo existente, promover la cultura local y revolucionar todo lo que se pueda. Hay de todo. En todo el mundo y hasta en los lugares menos pensados.

La motivación

Durante el último tiempo conocí el proyecto mARTadero en Cochabamba, Bolivia en donde están construyendo un Barrio Hacker y que además aloja al HackLab Cochabamba. En este lugar aprendí muchísimas cosas, desde lo social hasta lo técnico y también su combinación. Su uso adecuado e inteligente de la tecnología. Todo esto, lo sume a mis ideas y empezó a gestarse algo...

Luego, llegamos a La Paz, Bolivia y conocimos a los chicos del r00thouse, un HackLab en el que actualmente están construyendo una Red Mesh desde cero y con muy poco conocimiento en el tema. Han estado estudiando muchísimo los últimos meses y lograron montar dos nodos: conectaron la Universidad con su propio HackLab. Con ellos hablamos sobre el impacto social que esto podría tener y cómo hacer que los servicios actuales sean más visibles. También les comenté todo lo que había aprendido en Cochabamba con la experiencia del Barrio Hacker y el HackLab. Agregué también un punto de vista más social y no tan técnico (que es lo que nos gusta y más fácil nos sale) para acercar la tecnología a las personas no-técnicas, facilitándoles su uso y su entendiemiento sobre las mismas. Así, entendiendo como funciona y su porqué, podrán decidir si les va a ser útil o no.

Hoy me levanté mirando el cerro Calvario en Copacabana, Bolivia y me puse a leer un libro que me prestó Facundo Batista en mi visita al #asadogeek 2015: "Redes inalámbricas en los países en desarrollo". Luego de leer unas 4 o 5 páginas, me hizo un cortocircuito dentro de mi cabeza y me llegó a mezclar todas estas experiencias que habíamos estado escuchando y llegué a un nuevo proyecto de "Red Libre".

La idea

Consiste en armar una red WiFi en las ciudades que visitemos con Argentina en Python y ofrecer diferentes servicios además de dar a conocer el proyecto. Notamos que la mayoría de los turistas que recorren la ciudad, en algún momento, están en busca de WiFi para conectarse con sus amigos, buscar lugares para comer, hoteles o turismo, conocer personas locales y demás. Eso nos pareció un buen punto de partida para dar a conocer, sin esfuerzo, lo que hacemos cotidianamente y así sumar más personas a esta locura.

Pero claro, ofrecer solo eso me parece que era poco y que podríamos sacarle mucho más provecho a una red WiFi. Es por eso que queremos, en principio, tener estos servicios disponibles de forma gratuita para quienes se conecten a esta red (en modo offline):

  • Nuestros blogs (el blog de humitos, Química & Nómada) [1]
  • Sitio web de Argentina en Python
  • CD-Pedia en su formato DVD
  • Chat mediante IRC / Bonjour o similar
  • Buscador de POIs mediante upoi.org
  • Maps.me, OSMAnd y sus correspondientes mapas

Todo esto de forma offline y disponible para todos los que puedan conectarse a la red. Una vez que los usuarios se conecten e ingresen google.com, por ejemplo, en vez de mostrarse el sitio de Google se les mostrará una página con una explicación detallada sobre el proyecto de Red Libre y los servicios que están disponible.

De esta forma, podrían chatear entre los que estén conectados y cercanos, conocerse entre ellos y juntarse a tomar una birra en el bar de al lado. Coordinar para ir a hacer una excursión juntos o lo que se les ocurra que cualquier comunicación pueda brindar. Leer sobre nosotros y nuestros blogs en caso de estar aburridos y tener que hacer tiempo a que salga su bus, leer diferentes artículos de Wikipedia sobre el lugar en el que se encuentran, conocer nuestros proyectos y sumarse a la causa, buscar un montón de información sobre lugares interesantes en la ciudad mediante OpenStreetMap y también llevarse esos datos en su celular para luego consultarlos en modo offline.

Suena interesante, ¿no?

¿Cómo montaríamos esto?

En todas las ciudades hay lugares que son muy transitados por turistas que están buscando donde alojarse, qué comer o bien conocer cuáles son las actividades de esa ciudad. Esos son lugares claves para montar esta red WiFi Libre y dar a conocer nuestros proyectos y también ofrecer un servicio gratuito y de utilidad (además, estaríamos dando a conocer varios proyectos de Software Libre que no son fáciles de acercar al público general). La idea es llegar a esos lugares en auto, conectar nuestro router WiFi (Ubiquiti) a la batería del auto junto con el servidor (RaspberryPi) y su disco externo con los datos. Esto hace que sea totalmente transportable y que podamos alcanzar cualquier lugar de la ciudad [2].

En el lugar que estacionemos el auto, podríamos poner la bandera de Argentina en Python, una mesa, sombrilla y sillas para dar a conocer lo que hacemos, entregar micro-tutoriales, difundir estas herramientas y ayudar a la gente a configurar/instalar las apps en sus celulares. También, si tenemos un evento pactado en esa ciudad, podríamos hacer difusión en este mismo lugar.

Conclusión

Creo que de esta forma estaríamos acercando un montón de servicios y utilidades a muchas personas sin quizás tener interacción alguna en primera instancia. Mostrando el Software Libre como alternativa a muchas herramientas cotidianas que usamos sin tener conciencia alguna sobre nuestros datos y llegar a charla más que interesantes.

Además de darnos una visibilidad más fuerte en la ciudad que nos encontramos y así poder conseguir ayuda y contactos para seguir adelante con nuestras locuras itinerantes :)

Al día de la fecha no tenemos el router WiFi Ubiquiti ni la RaspberryPi que necesitamos. Podés ayudarnos a tomar una decisión sobre qué modelo nos conviene comprar para obtener un mejor servicio, como así también económicamente para comprar estos dispositivos.

Nos encantaría leer/escuchar comentarios y sugerencias sobre qué otros servicios podríamos brindar en esta Red Libre y así acercar más información a usuarios pasajeros.

¡Muchas gracias!

[1] Podríamos tener muchos otros blog también aquí
[2] Incluso, en un futuro se podría disponer de una batería extra para no depender de llevar el auto a ese lugar

Facundo Batista: Magicicada: the evolution of file sync


I spent my first years in at Canonical working in the Ubuntu One project, particularly in what we always called "filesync": the pure file synchronization server (which was propietary at that time), the client, and the protocol (both always open source).

Then, the company didn't push the project anymore, I started to work on other areas, and eventually the project was cancelled. When they cancelled it, they made the promise of opensourcing the server, which will allow to anyone put the full stack to work and have their own personal filesync cloud.

Time passed by, and at some point I got instructions to put daily time on that opensourcing work. I've been working the whole day on this for several weeks, and even more weeks part time, massaging all the code and dependencies for the project to be public. Then the project was released.

Was the project easily usable for anyone to start syncing files? Not really, my goals when working in the project to make it available for everybody were:

  • use only dependencies and libraries from a standard Ubuntu Precise environment and from freely available code from Launchpad
  • "make test" to pass ok, which means that further development can be easily started
  • "make start-oauth" to start and work ok, which means that the server actually works and sync files

However, there's a lot to do for the service to be really used in a production environment where we can put our files and trust it, including but not limited to:

  • keep cleaning the project, lot of quirks and small weirdness to fix
  • make it to store files not in AWS but in the local filesystem
  • (after last item because some internal working reasons involving resumable upload that won't explain here) make it work in Trusty, or even in any modern (Ubuntu or not Ubuntu) environment
  • make it work nicely in a production environment (currently, for example, everytime it starts it uses a fresh database!)
  • simplify it: the server will not longer be used to hold a million users so features like use PostgreSQL in several shards are not worth it anymore
  • and several etceteras

Note that part of this work already started!! Naty Bidart and myself are working actively in some of those points.

Where? Well, with Natalia we already had the Magicicada Project, which was a GUI to interact with the client. So we forked the rest of the projects and naturally put them under that namespace.

So, the whole solution stack currently is:

  • Magicicada Server: the one that "lives in the cloud" and holds the files so all your clients can access them.
  • Magicicada Client: the application that runs in background in each of your computers, uploading/downloading new/changed files from/to the server.
  • Magicicada Protocol: a project with common code between client and server, particularly all the protocol implementation that allows them to talk each other.
  • Magicicada GUI: a small graphical utility that lets you interact and supervise what the client is doing in your computer.


Magicicada

All further work will be done in those projects. If you want to participate please suscribe to the mailing list or say hi in the IRC channel (#magicicada in Freenode). Also, you can file issues for any bug you find or new features/changes you want (be sure to choose the right project: server, client, protocol or gui).

If you're a bzr impaired developer, we have mirrors in GitHub (currently, only for the server, others will be added in the following weeks, ping us if you want any of these to happen sooner).

In any case, you may want to follow the Magicicada twitter account, where will be posting all kind of progress notifications.

Mariano Guerra: Quotes N+1

Some Quotes I had around and wanted to put somewhere.

Navigation implies state. Software that can be navigated is software in which the user can get lost. The more navigation, the more corners to get stuck in. The more manipulable state, the more ways to wander into a “bad mode.” State is the primary reason people fear computers—stateful things can be broken
Most of the time, a person sits down at her personal computer not to create, but to read, observe, study, explore, make cognitive connections, and ultimately come to an understanding. This person is not seeking to make her mark upon the world, but to rearrange her own neurons. The computer becomes a medium for asking questions, making comparisons, and drawing conclusions—that is, for learning.
Many types of context can be naturally expressed in some informative graphical domain, relieving the user from manipulating information-free general-purpose controls.
If the software properly infers as much as possible from history and the environment, it should be able to produce at least a reasonable starting point for the context model. Most of the user’s interaction will then consist of correcting (or confirming) the software’s predictions. This is generally less stressful than constructing the entire context from scratch.
Simplicity. “I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is make it so complicated that there are no obvious deficiencies.” C.A.R. Hoare, The Emperor’s Old Clothes Turing Award lecture (1980), p81. From a practical (and historical) standpoint, we can assume that no complex specification will be implemented exactly. This, in itself, is not a problem. However, multiple, decentralized implementations of a complex specification will be incorrect in different ways. A platform consisting of the union of all possible implementations is thus arbitrarily unreliable—the designer can have no assurance of what a recipient actually receives. For a platform to be reliable, it must either have a single implementation, or be so utterly simple that it can be implemented uniformly. If we assume a practical need for open, freely implementable standards, the only option is simplicity.*

All of our days are numbered, we cannot afford to be idle To act on a bad idea is better than to not act at all. Because the worth of an idea never becomes apparent until you do it.

—nick cave, 20000 days on earth

Mariano Guerra: Quotes N+1

Some Quotes I had around and wanted to put somewhere.

Navigation implies state. Software that can be navigated is software in which the user can get lost. The more navigation, the more corners to get stuck in. The more manipulable state, the more ways to wander into a “bad mode.” State is the primary reason people fear computers—stateful things can be broken
Most of the time, a person sits down at her personal computer not to create, but to read, observe, study, explore, make cognitive connections, and ultimately come to an understanding. This person is not seeking to make her mark upon the world, but to rearrange her own neurons. The computer becomes a medium for asking questions, making comparisons, and drawing conclusions—that is, for learning.
Many types of context can be naturally expressed in some informative graphical domain, relieving the user from manipulating information-free general-purpose controls.
If the software properly infers as much as possible from history and the environment, it should be able to produce at least a reasonable starting point for the context model. Most of the user’s interaction will then consist of correcting (or confirming) the software’s predictions. This is generally less stressful than constructing the entire context from scratch.
Simplicity. “I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is make it so complicated that there are no obvious deficiencies.” C.A.R. Hoare, The Emperor’s Old Clothes Turing Award lecture (1980), p81. From a practical (and historical) standpoint, we can assume that no complex specification will be implemented exactly. This, in itself, is not a problem. However, multiple, decentralized implementations of a complex specification will be incorrect in different ways. A platform consisting of the union of all possible implementations is thus arbitrarily unreliable—the designer can have no assurance of what a recipient actually receives. For a platform to be reliable, it must either have a single implementation, or be so utterly simple that it can be implemented uniformly. If we assume a practical need for open, freely implementable standards, the only option is simplicity.*

All of our days are numbered, we cannot afford to be idle To act on a bad idea is better than to not act at all. Because the worth of an idea never becomes apparent until you do it.

—nick cave, 20000 days on earth

Juanjo Conti: Kowabunga

Contra una pared violentada y recuperada, Gonzalo "Kun" Vega lee Fluviality, un poema que aparece en Kowabunga de Santiago Pontoni (Ediciones Diatriba).

De fondo The Offspring se esfuerza por tapar su voz pero no lo consigue.

Juanjo Conti: Reimprimí Santa Furia

Faltaba una semana para que empiece la feria del libro y Santa Furia, mi libro de cuentos más oscuros, estaba agotado. Tomé la desición de reimprimirlo y por suerte la imprenta cumplió en tiempo y forma.

Ante la pregunta del imprentero, decidí cambiar el laminado de la tapa de mate a brillo y me gusta mucho el resultado.

santa_furia_brillo.thumbnail.jpg

Lo puden conseguir en la Feria del Libro de Santa Fe en el stand de las editoriales independientes: ¡al fondo a la derecha!

Juanjo Conti: Comprar software por impulso

Anoche un amigo hablaba en un progarma de radio. Lo empecé a escuchar en el auto y cuando llegué a casa quise seguirlo en la computadora. Entré a la web de la radio y el navegador se quejó de que me faltaba un plugin para reproducir Windows Media Player files en Mac.

Una rápida búsqueda me indicó que la única alternativa era paga. El software que necesitaba se llama flip4mac y su versión básica cuesta menos de seis dólares.

No tuve ningún reparo. Hice dos clicks, tipié mi password de PayPal, otros dos clicks y tenía la aplicación descargada. No habían pasado cinco minutos desde que llegué a casa.

Cuando por fin acceso a la página de la radio con un navegador soportando el formato de archivo que usaban, me encuentro con que la radio no estaba transmitiendo.

Ya lo reporté.