Bitácora de Vuelo

La década pasada arranqué con una costumbre que aunque cuesta un montón de trabajo termina dando resultados excelentes: el asado geek. Lo hice por varios años hasta que se cortó cerca del final de la década, luego vino la pandemia... y este año retomé.

Notablemente nunca hablé mucho de eso en este espacio. Ahora es un buen momento.

La consigna es clara: junto en casa a geeks de variada índole (familias/parejas bienvenides), la mayoría informátiques, pero hay de todo. La gente invitada es toda conocida mía de alguna manera u otra, lo más probable es que no conozcan a todo el resto, pero esa es la idea, que se crucen, que surjan todo tipo de charlas.

La excusa es un asado (carne y verduras a la parrilla, aperitivos, bebidas varias, postres, etc.). No es un evento formal, no nos vamos a sentar en una larga mesa y van a tener cuatro cubiertos y dos copas. Es más bien un controlado caos de distintos grupos desparramados por la casa comiendo sanguchitos y cosas, gente tirada en el pasto vaso en mano, etc. Ahora que la casa es más grande está la posibilidad de que surjan juegos de mesa, e incluso la pileta puede estar disponible si el clima es acorde.

Les invitades a priori no tienen que traer nada de comida o bebida, yo me encargo de comprar y preparar todo desde antes. Luego cuento asistentes, divido costos, y les pido la guita cuando se van yendo. Por otro lado siempre hay algún invitade que trae algún delicatessen que le regala a la asistencia (algún licorcito, una charcutería custom, verduras de su huerto, condimentos raros, etc.).

Bien. Como decía arriba, retomé. El finde pasado hice la versión 2023.

En la casa anterior la asistencia había ido creciendo hasta pasar las cuarenta personas. Era un bardo, y por suerte el clima más o menos siempre acompañó. Así y todo la zona del quincho era un quilombo, apenas podíamos movernos, era incómodo. En parte por eso dejé de hacerlo, no escalaba.

Para esta edición pude invitar más libremente. Luego de algunos años el público se renovó, invité gente nueva. Al final fuimos (entre adultes e infantes) exactamente cincuenta.

¿Cómo estuvo? Bárbaro.

Yo tuve el 20% del stress que sufría en ediciones anteriores porque al estar todes mejor distribuídes era mucho más disfrutable. Y al poder trabajar más libremente tuve más ayudantes para preparar sánguches, armar mesas, etc.

En esta oportunidad simplifiqué la comida, porque la parrilla es más chica que la que tenía antes. Entonces hice chorizos, bondiola, y bife de chorizo; todo en sanguchito, claro. Tonga trajo un kimchi casero que estaba bárbaro, y Runa una mayonesa de morrón y una salsa criolla que estaban geniales. Para el postre y la tardecita Moni preparó unas chocotortas y complementamos con algunas tortas compradas.

El día acompañó, pero hizo bastante calor. Pudimos disfrutar de la pileta, creo que se metieron casi casi todes. Tengo que explorar mejor la posibilidad que se armen juegos de mesa, algo hubo, pero casi nada, hay que intentarlo más ordenadamente cuando empieza a caer el sol.

Y es notable como les geeks te cuidan la casa: no se rompió ni un vaso.

Repetidas veces en la historia se ha visto que, para dispositivos de consumo masivo, para abaratar costos se terminan reemplazando con software funcionalidades que estaban en hardware: es obvio, si sacamos este pedacito que para mil dispositivos tenemos que fabricar mil veces y lo reemplazamos por un "software más inteligente" (que se copia gratis), se bajan los costos.

Hay muchos ejemplos, pero quizás el que más nos ha mordido a les usuaries de Linux es el caso de los módems hace un par de décadas (ustedes son muy jóvenes, pero...). Los fabricantes empezaron a hacer el jueguito antedicho pero sólo liberaban ese "software inteligente" para Windows, con lo cual hacer andar esos módems en Linux era una odisea, al punto que se acuñó el término "winmodem".

Bueno, hace un par de semanas se me complicó con algo parecido a eso.

Unos meses atrás me compré una Xiami Smart Band 7, muy bonita (aunque un poco chica para mis ojos cuarentones).

Es muy fácil de empezar a usar. Cuando se prende te muestra un QR que al escanearlo con el teléfono te lleva a descargar la aplicación Mi Fit. Ejecutás la aplicación, siguiente siguiente siguiente, te reconoce que hay una pulsera para enganchar, la sincroniza y voilà, funciona todo.

Hay cosas en la pulsera en sí (muchas, sólo he usado pocas, como cronómetro, o decirle que estoy haciendo tenis, que me mida las pulsaciones, etc), pero también hay otras en la app que son interesantes (como mandar las notificaciones a la pulsera, es MUY piola eso). Pero la app termina siendo imprescindible, porque es la única interfaz "inteligente" con la pulsera, la única forma de ver data histórica, etc.

Todo muy lindo. Hasta que falla.

Hace un par de semanas, decía, no sé que hizo la pulsera mientras estaba cargando y se reseteó a cero. La fui a buscar y estaba mostrando el QR que muestra cuando uno la saca de la caja al comprarla.

Bueno, a re-emparejarla con la app, total como todo el histórico está ahí no pasa nada. ¡Pero no emparejaba! La app no encontraba "ningún dispositivo cercano".

La app también tiene escondida en un menú la opción de "incorporar al dispositivo escaneando su QR". Con esta opción avanzó un poco porque se daba cuenta que había una pulsera pero no podía comunicarse con ella :(. Lo loco es que me decía que el problema es de la pulsera, y que tenía que resetearla "a cero" para que vuelva a estar como "de fábrica".

¿Pero cómo? Porque lo único que tiene la pulsera es una pantalla que obstinadamente me mostraba un QR. A diferencia de la gran mayoría de otros dispositivos a los que estamos acostumbrades, la pulsera no tenía ningún botoncito ni nada que dispare un reseteo de fábrica del hardware. Porque la pulsera no tiene ningún elemento móvil. Todo bien, si querés hacer un dispositivo que sea medianamente sumergible hacerlo totalmente cerrado te evita mil quilombos.

Pero igual podrían haber maneras. La pulsera tiene contactos eléctricos, después de todo, y uno manejable sencillamente por el usuario es el de carga de la batería. Podría tener implementado que si enchufás y desenchufás 10 veces el cargador te pregunte si querés que se resetee a cero. Pero no, seguramente los desarrolladores fueron demasiado optimistas de que nunca nada iba a malir sal.

Luego de pelearme por un par de horas con la pulsera, decidí apelar al último recurso con algunos dispositivos: drenarle la batería hasta cero (esperar a que se le acabe, bah). Pero oh, la pulsera ya de entrada consume poco y si detecta que no se mueve se pone en modo más económico, entonces nunca se me iba a descargar.

La tiré en lo profundo de un cajón, junto a mis esperanzas.

Un par de días después dije basta, y decidí mandarla a arreglar. Empecé a buscar service... y no encontré nada. Hay varias empresas que dan soporte de Xiaomi, pero todas sobre teléfonos. Nada de pulseras. En otras palabras, me habían vendido un hardware sin service en Argentina. Qué detalle, ¿no?

De nuevo al fondo del cajón, junto a mis esperanzas y mi bronca.

Una vez por día promedio se me ocurría buscar alguna cosa en internet, probarla. Hice mil intentos: la cargué full, limpié y borré la app que les mencionaba arriba, instalé otra (Zepp) que la encontraba pero la perdía, volví a limpiar todo, incluso borrando a mano directorios en el teléfono de las apps, y varias cosas que ya no me acuerdo.

Como diez días después del incidente, la prueba de turno fue borrar (de nuevo) toda app al respecto, borrar la pulsera de bluetooth, instalar Zepp, y ahí el comportamiento cambió... encontró la pulsera, que salió del QR y puso una pequeña imagen de "enlace"... que al rato perdió y volvió al QR. Pero volví a intentar los pasos anteriores y de repente la app me anuncia que empezó a bajar una actualización. Por lo que tardaba pensé que estaba bajándola a la pulsera pero no, después de un rato largo la pulsera me avisa que estaba instalando una actualización, y empezó a subir un porcentaje que tardó en completarse como veinte minutos.

Terminó, se reinició, y arrancó "bien", con la app sincronizando ok y todo. ¡Alegría!

Vaya uno a saber cuanto dura.

Luego de catorce años y medio, esta semana dejé de trabajar en Canonical.

Me costó tomar la decisión de renunciar, lo estuve masticando varias semanas, pero era momento. La empresa no es la misma que me gustaba tanto hace unos años, nuestros caminos de "cómo hacer las cosas" divergieron demasiado los últimos meses, y llegó el momento de descansar un poco.

Pasó mucha agua por abajo del puente.

Conocí un montón de gente, pero al mismo tiempo no les conocí tanto tampoco, uno de los "problemas" del trabajo remoto. Cuando trabajás presencial compartís muchos más espacios con tus compañeres... no sólo la convivencia en la oficina, sino también salir a almorzar, quedarse algún after-office, etc. En el trabajo remoto te encontrás a veces y algún lazo se crea, pero no es lo mismo. Esto ayudó a que cortar luego de tanto tiempo no sea "doloroso". Por otro lado, tuve la oportunidad de trabajar con gente que ya conocía, y eso estuvo buenísimo :)

También laburé en muchos proyectos a lo largo de los años. Arranqué en Ubuntu One, que era más cosas pero yo estuve casi únicamente abocado a la parte de sincronización de archivos (luego liberado open source). De ahí a ofrecer servicios online para el Ubuntu Phone. Un par de productos en el medio que no vieron la luz, y luego a trabajar en el Snap Store, donde estuve bastante en proyectos diversos. Y finalmente volver al lado del "cliente" para laburar en una biblioteca y una herramienta para facilitar el uso de Juju.

Por primera vez después de 30 años no voy a saltar de un trabajo al otro. Voy a estar algunas semanas sin laburar, viendo qué quiero hacer de mi vida, retomando algunos proyectos/hobbies/cosos abandonados o ni empezados por falta de tiempo.

Veremos qué depara el futuro.

Si ya voy mezclando palabras raras en el título pueden empezar a adivinar que este es un post técnico, y tendrán razón.

¿Qué significa pinning? Un montón de cosas, pero en el mundo del software, o al menos en la parte de distribución de software, significa especificar exactamente la versión de una dependencia.

Por ejemplo, yo puedo hacer un programejo que usa la biblioteca requests, y no me importa la versión, entonces en la lista de dependencias pongo requests y ya. Pero si quiero especificar exactamente qué versión de esa biblioteca necesito, pondría algo como requests == 2.7.1. Eso es pinnear (mezclando ahora inglés y castellano) la versión de la dependencia, que es como agarrarla con un alfiler para que no se mueva y siempre sea la misma.

¿Cuándo tiene sentido hacer eso y cuándo no? ¿Depende del entorno donde correrá mi programejo? ¿De las dependencias que estoy usando? ¿De la forma de distribución? Un poco de todo eso apunta a contestar este post.

Entonces...

Mi posición con respecto a pinning

Ya sabemos que los extremos son malos. Traducido al tema que nos atañe, podemos decir que no queremos ni nada pinneado nunca, ni todo pinneado todo el tiempo.

El problema de "nada pinneado nunca" es que es muy difícil poder garantizar la calidad del sistema que estamos armando. Si en desarrollo usamos la biblioteca versión X, pero luego cuando desplegamos todo en un servidor termina instalando la versión Y, puede ser que nos explote todo. O peor, que parezca funcionar, pero que no funcione correctamente. Y si lo distribuimos es aún más complicado: si el sistema lo instalan un montón de personas en sus computadoras vamos a tener mil combinaciones de distintas versiones.

Por otro lado, si tenemos "todo pinneado todo el tiempo", rompemos la evolución del software que contiene nuestro sistema. La evolución es un concepto central, no podemos cortar la evolución de las dependencias de nuestro software porque terminamos atados a versiones viejas. Y no es un problema de alguna funcionalidad más o menos, sino de seguridad: a menos que tengamos atrás un equipo de especialistas en seguridad haciéndose cargo del mantenimiento de versiones viejas, tenemos que tratar de usar todo lo nuevo en todos lados.

Entonces, tenemos que encontrar un balance entre ambos extremos, que es lo que les comento en el resto del post.

Tengamos en cuenta que queremos distintos comportamientos si tenemos bibliotecas o aplicaciones, y en este último caso dónde correrán las aplicaciones, si del lado del cliente (luego de que empaquetamos el software) o en un servidor (que desplegamos directamente).

Bibliotecas

Si estamos trabajando con bibliotecas, las mismas tienen que ser lo más flexibles posible, ya que van a ser usadas de maneras que no se pueden prever: nunca vamos a tener el contexto en el qué se usarán nuestras bibliotecas.

Debemos especificar qué dependencias se necesitan, pero ser lo más libres y genériques posibles con respecto a las versiones, luego la aplicación que use nuestra biblioteca especificará la versión, o no. No es de nuestra incumbencia, nuestra biblioteca debería ser independiente de las versiones de sus dependencias... y aunque ya sabemos que esto no es posible en su totalidad, debemos tratar de restringir las versiones lo menos posible.

En otras palabras, está mal definir que nuestra biblioteca necesita la dependencia X en la versión == 2.7.1, pero está bien definir que la necesita en una versión => 2 o incluso => 2; != 2.0.4, en caso de que haya alguna incompatibilidad puntual. Y después será la aplicación la que defina en qué versión necesita sus propias dependencias, y se hará el análisis en conjunto para determinar si hay un conflicto. Si la biblioteca defina una dependencia X en una versión específica, y la aplicación también depende de la misma X, está condicionada a usar sólo esa versión. Peor aún, si la aplicación necesita las bibliotecas foo y bar, y foo define la dependencia X en una versión y bar define la misma dependencia X en otra versión, la aplicación directamente no podrá usar ambas foo y bar.

Entonces, recapitulemos: para las bibliotecas seamos lo menos específicos posible en las versiones de sus dependencias. Arranquemos con no indicar ninguna versión en ninguna dependencia, y vayamos agregando restricciones con el tiempo, sólo si encontramos alguna incompatibilidad.

Aplicaciones

Con las aplicaciones es diferente. En el momento en que empaquetamos una aplicación para distribuirla, o la desplegamos en servidores para ser usada, queremos poder garantizar que se ejecutará correctamente de cara a les usuaries finales.

La calidad de la aplicación la garantizamos con distintas evaluaciones que hacemos, que pueden ser pruebas de unidad, pruebas de integración, pruebas manuales. Un proyecto robusto siempre tendrá alguna combinación de todas estas pruebas que se realizarán para determinar la calidad de una determinada versión de la aplicación.

Pero esta versión de la aplicación, ¿qué versión de cada una de sus dependencias utilizará? Si corremos todas las pruebas para la versión que queremos liberar de nuestra aplicación usando la versión X de una dependencia, pero al momento de empaquetarla o desplegarla en un servidor se termina usando la versión Y de esa dependencia, en realidad las pruebas que corrimos no son válidas.

Tengamos en cuenta que en realidad no hay mucha diferencia entre si a la aplicación la empaquetamos para distribuirla o la desplegamos en un servidor para ser usada. En general tanto el proceso de empaquetado como el de despliegue terminarán instalando nuevamente las dependencias necesarias, y a menos que todas las versiones estén especificadas, no tenemos control de cuales serán usadas.

En otras palabras, para garantizar la calidad de la aplicación tenemos que pinnear las versiones de las dependencias, correr toda la batería de pruebas que tengamos utilizando esas dependencias, y luego empaquetar o desplegar la aplicación usando exactamente esas dependencias.

Pero si tenemos todo pinneado, volvemos al problema del que hablábamos antes de poder evolucionar, quedamos atrapados en versiones viejas con posibles problemas sin corregir. O peor, con fallas de seguridad expuestas.

La forma más piola que he encontrado de tanto poder garantizar la calidad final como también de evolucionar en el tiempo es tener dos listas de dependencias.

La primera lista tendrá las dependencias directas de nuestra aplicación (no las dependencias de las dependencias) de la forma más laxa posible: similar a lo que hacemos con las bibliotecas, a priori no especificaremos ninguna restricción, y sólo las agregaremos con el tiempo si encontramos incompatibilidades puntuales.

La segunda lista tendrá todas las dependencias de nuestra aplicación y a la vez todas las dependencias de las dependencias, y las dependencias de las dependencias de las dependencias, etc., con la versión específica con que fueron instaladas. Todas las pruebas que correrá el desarrollador, o el sistema de CI/CD (Continuous Integration / Continuous Delivery) que tengamos, se harán utilizando esta segunda lista con todo bien especificado. Y el proceso posterior de empaquetado o despliegue también utilizará esta segunda lista, con lo cual terminamos garantizando la calidad de la aplicación. Incluso, si dudamos de la procedencia de los archivos de nuestras dependencias, podemos hasta sacar el hash de las mismas y luego validarlas; entonces no sólo indicamos que los tests se hacen con la versión foo == 2.1.7 sino que también podemos validar que cuando el server instale esa versión específica el archivo con el que lo haga sea exactamente igual al que usamos nosotros, y nadie nos vendió gato por liebre en el medio (lo que sería un tipo de ataque MITM).

Entonces, ya sabemos que tenemos dos listas para las dependencias de nuestra aplicación, la laxa que nos permite evolucionar y a partir de la cual se arma la muy específica sobre la cual se valida calidad y libera la aplicación.

¿Cómo vamos de una lista a la otra? En tiempo de desarrollo. Será responsabilidad de nosotres les desarrolladores el cada tanto (no tiene que ser todo el tiempo) generar el entorno de desarrollo desde cero utilizando la lista laxa y generar a partir de esa instalación la lista específica. Las distintas herramientas que nos permiten trabajar con entornos de desarrollo en general también nos dan la posibilidad de generar la lista específica a partir del entorno creado (por ejemplo en fades tenemos la opción --freeze).

Para terminar, tengamos en cuenta que todas las dependencias que vengo mencionando son las de producción, aquellas bibliotecas que nuestra aplicación necesita para finalmente correr.

Pero también tenemos aquellas dependencias de desarrollo: todas las bibliotecas y utilidades que usaremos les desarrolladores para, justamente, desarrollar la aplicación. Estas dependencias no se instalarán, incluirán, ni usarán en el paquete que armemos para distribuir la aplicación o en el servidor. Un ejemplo de este tipo de dependencias podría ser pytest, el corredor de pruebas de unidad.

Para estas dependencias tendremos otra lista, separada de las de producción. Hay distintas formas de manejar esta separación; por ejemplo, si utilizamos archivos de dependencias podemos tener un requirements.txt para las de producción y requirements-dev.txt para las desarrollo.

El punto es que a las dependencias de desarrollo no las tenemos que pinnear para nada (obviamente, a menos que encontremos alguna incompatibilidad o bug en particular). Siempre utilizaremos lo último de lo último cuando armemos los entornos de desarrollo, y si en algún momento algún test falla porque las herramientas que utilizamos evolucionaron (por ejemplo, flake8 detectando un caso nuevo) corregiremos nuestro código y seguiremos adelante. Pero no hay motivo alguno para pinnearlas.

Hace rato que tenía ganas de aprender un poco sobre el arroz.

Me llamaba la atención que esté ese "arroz para sushi" que en su preparación se le pone vinagre y sale muy "pegajoso" para armar las distintas piezas. O que esté la dicotomía entre "hacerlo en mucha agua y colarlo" y "hacerlo en la cantidad justa de agua". O que para la paella recomienden "ni tocarlo" y en el risotto le hagan bailar la tarantela.

Empecé a juntar algo de info, entonces, de lo cual resumo un poco a continuación y le doy algo de orden, haciendo foco en los detalles que me interesaron. Obviamente no es un "tratado sobre el arroz", nada más lejos de eso, y toda la data que tiro acá se puede encontrar más o menos rápido en Internet; si quieren profundizar arranquen por Wikipedia, el INTA, y Alimentos Argentinos.

Lo primero que quiero resaltar, para tirar abajo todas esas recomendaciones o recetas genéricas que te dicen "al arroz hay que hacerlo de tal manera o hacerle tal cosa", es que no podemos hablar de "el arroz".

Hay cerca de diez mil variedades de arroz, con un buen rango de distintas propiedades, entonces siempre hay que ser un poco más específicos, y hay que tener especial cuidado si estamos viendo recetas o recomendaciones de otros países ya que quizás no usen el mismo tipo de arroz que nosotros. Todas estas variedades son de la misma especie Oryza sativa (que me causa gracia su nombre porque la "oriza" es una especie de plato con filo que se usa en un libro de Stephen King como arma para decapitar enemigos, al tirarla como un disco), y tiene dos subespecies: la índica, que suele cultivarse en los trópicos, y la japónica, que también crece en climas templados y se caracteriza por su alto contenido en almidón (ya vamos a ver donde esto es importante).

Además, también depende de procesos que se le hagan al arroz luego de cosechado. El más común, que se le hace a la mayoría de arroces, es que se "pulen" para sacarles de la cubierta que los protege (que se convierte en salvado), lo que elimina así aceites y enzimas del arroz. Pero también hay otros procesos, algunos cuento abajo.

Se produce mucho arroz. Alrededor de 750 millones de toneladas anuales, lo cual, obviamente, no nos dice nada porque no llegamos a "entender" un número tan grande. Las proporciones y comparaciones ayudan: el 90% de la producción y del consumo se concentra en el continente asiático.

En otras palabras, el 10% se produce y consume afuera de Asia. América es el segundo continente (aproximadamente un 6% del total), de lo que le corresponde un tercio a Brasil, el principal productor.

Argentina, puntualmente, no se destaca: sólo un 3.5% del continente. Concentra su producción en Corrientes (50%), Entre Ríos (32%), Santa Fe (13%) y el resto principalmente distribuido en Chaco y Formosa.

Algunos detalles del arroz a nivel nutricional:

• tiene más lisina que el trigo/maíz/sorgo; la lisina es uno de los nueve aminoácidos esenciales para los seres humanos, y debemos incorporarlo de alguna manera

• ojo cuando está limpio (sin salvado): tiene menos fibra que otros cereales

• proporciona mayor contenido calórico y más proteínas por hectárea que el trigo y el maíz (lo que es importante a la hora de alimentar poblaciones)

• ¡no tiene gluten! por lo tanto es apto para consumo por personas celíacas o con otras sensibilidades al gluten, pero no puede usarse para hacer panificados

Decía que hay muchos tipos de arroz. La principal categorización es por la forma, o más bien por la relación entre su largo y su grosor (no podemos dejar de mencionar a Les Luthiers... "Mi nombre es Oblongo, que en dialecto Swahili quiere decir más largo que ancho").

Tenemos varios tipos:

• grano corto: es casi esférico, ideal para sushi porque los granos quedan unidos incluso a temperatura ambiente.

• grano medio: su longitud es de entre dos y tres veces su grosor; es el que más se consume en Argentina en particular, sudamérica y centroamérica en general, y es el tipo de arroz que se usa en el risotto o la paella (el arroz bomba pertenece a esta categoría).

• grano largo: es entre cuatro y cinco veces más largo que grueso, no se ve mucho por acá; tiene mucha amilosa (almidón), por lo que necesita mucha agua en la cocción.

• silvestre: es de casi 2 cm de largo

A algunos tipos de arroz se les dice glutinosos, para indicar que son pegajosos después de cocerse (¡no que tienen gluten!), efecto que viene dado por el tipo de almidón que contienen. También hay los aromáticos, característica de algunos tipos de arroces que desprenden aromas (a flores, frutos secos, etc.) luego de ser cocidos.

También podemos separar el arroz en común o integral, aunque esto es sólo una cuestión de proceso. Al integral sólo se le quita la cáscara exterior (o gluma), que no es comestible. Conserva el germen íntegro con la capa de salvado que lo envuelve, lo que le confiere un color moreno claro.

Si entramos en el detalle de la estructura del grano de arroz, veremos que es similar al de otros cereales, especialmente a la cebada y avena que también tienen una cáscara externa. El grano está constituido fundamentalmente por cuatro partes:

• una cáscara externa que envuelve el grano

• el salvado, constituido por diferentes capas que se encuentran por debajo de la cáscara

• el germen, que es el embrión de la semilla (la parte reproductiva que germina para crecer y dar lugar a una nueva planta)

• el endospermo (la parte más importante del grano en peso y tamaño) que contiene nutrientes de reserva que son utilizados durante la germinación (principalmente almidón).

Ya mencionamos varias veces el almidón. ¿Qué es? Es una macromolécula, compuesto por dos tipos de glucosas, la amilosa y la amilopectina, en distintas proporciones (cuanto de una y de otra varía según el vegetal). Es la forma en que la mayoría de los vegetales reservan energía, y notablemente es el carbohidrato más consumido por humanos.

El arroz no es excepción y también contiene almidón. Nos afecta en dos situaciones, puntualmente.

El primero es el nutricional: aporta muchas calorías y no deja de ser un tipo de carbohidrato que convertimos en azúcar (lo cual es un riesgo para aquelles que sufren de diabetes). Habiendo dicho eso, existe algo que se llama almidón retrógado, que se consigue enfriando el arroz luego de cocinarlo, y que evita que el almidón sea digerido por el cuerpo, sino que pasa directamente y es aprovechado por los microbios intestinales. Así que ya saben, ¡nada como una buena ensalada fría de arroz!.

El otro detalle con respecto al almidón es que cuanta más amilosa contiene un grano de arroz, más temperatura, agua y tiempo requiere para su cocción, y más pegajoso quedará luego. Al lavar o enjuagar el arroz, sacamos una capa importante de almidón y de esta manera terminamos consiguiendo arroz suelto y seco luego de cocinarlo. Si decidimos conservar el almidón al final quedará cremoso y pegajoso. Entonces, si queremos arroz para una ensalada (como recomiendo arriba), mejor lavarlo, y si queremos hacer un risotto, mejor no.

Hay otro factor que afecta esta dinámica: revolver el arroz cuando se está cocinando. Si estamos buscando que la preparación no salga pastosa debemos evitar revolver mucho, para que el arroz no largue el almidón, lo cual sí queremos cuando hacemos un risotto (y por eso se lo mueve tanto).

Y antes de dejar de hablar sobre formas de cocinar el arroz, un detalle sobre lo cual estaba intrigado: el agregarle vinagre al arroz del sushi. Parece ser que esto se hace para evitar el crecimiento bacteriano (el vinagre es un bactericida natural, como la canela que se usan en algunas preparaciones de la India), ya que el arroz crudo suele llevar esporas en estado de hibernación como la bacillus cereus, que produce toxinas que afectan al sistema gastrointestinal. Estas esporas sobreviven las altas temperaturas de cocción, por eso el arroz debe servirse inmediatamente tras su cocinado o conservarlo refrigerado, lo cual es fácil hoy en día pero muchas recetas o costumbres provienen de épocas donde mantener en frío no era sencillo o directamente imposible.

Les había prometido unas palabras sobre procesos que se le hacen al arroz. De quitarle la cáscara exterior (y convertirlo de integral a pulido ya hablé antes). Vamos con algunos otros.

El parboilizado (o vaporizado) es el proceso donde se somete el arroz con cáscara a un remojo de 60 ℃ y luego a una fuerte presión de vapor. De esta manera se elimina una buena parte del almidón pero se conservan vitaminas y sales minerales (se trasladan de la fibra al grano) que los arroces tradicionales pierden durante su pulido. Es por esto que el arroz vaporizado tiene un 80% del valor nutricional del arroz integral. Luego del proceso el arroz queda más duro y brillante que otros arroces (porque el almidón se gelatiniza), lo que lleva a requerir más tiempo de cocción, quedando luego más firme y menos pegajoso.

El precocido es, obviamente, cocinar el arroz antes de presentarlo para su venta. El proceso es muy genérico, y se usa como medio para otros fines. Se destacan el lograr un "arroz de cocción rápida" (como característica de venta), precocer el arroz parboilizado (para compensar que ese proceso aumenta el tiempo de cocción necesaria), y el precocido y posterior deshidratado del arroz, para preparar comidas pre-hechas (como esas que vienen en un sobrecito para hidratar y calentar y te sale el guiso listo). Ojo, no confundir este proceso de deshidratación recién mencionado con el proceso de secado que se le hacen a todos los arroces luego de cosechados para que los granos no se deterioren mientras están almacenados.

Bueno, se hizo largo pero espero que les haya gustado. Yo, por lo pronto, aprendí un montón, así que objetivo cumplido :)

Lo que me quedó pendiente es hacer una investigación de mercado... ¿qué tenemos a "nuestro alcance" a la hora de comprar arroz? ¡Comenten si saben!