Otra mejora - Filtro de Carbon Activado para el agua

A fin de tratar de recotar tiempos y overhead adicional a las cocciones, decidí incorporar otra mejora al equipo, un filtro de agua.

Hoy en día, parte de planificar una cocción era estar atendo uno o dos días antes a dejar agua (unos 62 litros) reposando en recipientes, a fín de que se le vaya el cloro.

A veces usaba el cilindrocónico de 60L para esto. O cuando estaba ocupado varios sparklings de 20/25L.

Esto era molesto, porque además, como el equipo no lo tengo en casa, sino que está en lo de mis viejos, tenía que llamar y molestarlo a mi viejo para que cargue el agua.
Además, como en la habitación donde está el equipo no hay agua, tenía que pasar una manguera desde el patio hasta ahí. Un embole total.

Así que compré un filtro de 10 pulgadas de carbon activado.
Lo conseguí acá a un buen precio. En ML hay una dispersión de precios terrible.

Resta ahora todo el trabajo de hacer llegar el agua hasta la habitación, y amurarlo a la pared.

Con esto, uno puedo hacer pasar el agua por el filtro en el momento. Elimina el cloro y otras sustancias y olores raros que puedan venir en el agua.
Veremos cómo impacta en las próximas cocciones :)

Moledora a motor

Me harté de moler la malta a manija. El molino está muy bueno, y uno se ahorra unos pesos al comprar la malta sin moler. Además de que hay lugares donde solo te venden sin moler. Además, podés comprar una bolsa grande de 25 / 35kg, y la vas usando cuando querés, evitando tener que ir a comprar insumos todas las semanas.

Lo malo es que moler a mano es un dolor.

Por varios motivos:

• Lleva bastante tiempo: calculo un promedio de unos 40 minutos para moler unos 9 / 10 kilos.
• Cansa el brazo :P
• A menos que uno tenga ya todo bien aceitado, si cocinás solo es dificil aprovechar el tiempo al máximo, porque hacer cosas en paralelo mientras molés, conlleva riesgos innudar todo o calentar agua por demás, en fin madársela.

En el último tiempo calculé eso, que demoraba unos 40 minutos en moler. Pero además, que calentar el agua para el mash también llevaba como unos 35/40 minutos. Así que un par de veces lo hice en paralelo.

• Primero llenaba la olla de licor con agua y la ponía a calentar.
• Luego me ponía a moler.
• Para el final de la molienda, el agua ya estaba en la temperatura deseada.
• Así me ahorraba unos 40 mintutos.

 El tema es que no es tan simple. Porque llenar la olla de licor lleva un tiempo. A veces tengo que subirla desde el fermentador (que uso como depósito de agua para declorar) hasta la olla que está elevada, usando la bombita. Ahí también toma un rato. Y si uno se pone a hacer otra cosa, corre el riesgo de olvidarse y que desborde o pasar más agua de la necesaria.
Otras veces la subo "a mano" con bidones de 20L.
Por otro lado, moler también lleva un tiempo de organización. Buscar las maltas, pesarlas, ir mezclando y repartiendo lo molido, etc.

El problema es que mientras están las dos actividades en paralelo, para el final hay que estar medio a las corridas. Viendo que el agua no se pase, etc

O sea, se gana tiempo, pero también exige más esfuerzo y atención.

En fin, así que igual me cansé y quise automatizar la molienda. Para hacerla más rápida, y menos cansadora.

El motor

Para eso me compré un motor:

• Marca: Czerweny
• Potencia: 1/5 HP
• RPM: 1460 RPM

 Por lo que leí en los foros:

• Potencia: desde los 1/6 (o hasta 1/8) HP alcanza para ambos tipos de molinos (a disco o a rodillo). Algunos usan 1/2 HP, o 1/4, lo que tienen a mano.
• RPM: esto en cambio es más importante. En general conviene usar un motor de bajas revoluciones, porque justamente necesitamos que el molino no tenga demasiada velocidad. Los de 1400 RPM parecen ser algo estandares. Hay de menos RPM's pero no se ven tanto. Además, igualmente hay que reducir (por ahí leí a 150/200 RPMs), así que sí o sí vamos a tener que usar un volante de polea con cierta relación.

Por suerte conseguí un motor nuevo, de marca conocida, y bastante barato por ML. Lo pagué unos $222  :)
Por lo que ví, motores similares nuevos salen no menos de $600

Algo "malo" es que no vino directo para enchufarlo, ni tampoco trajo polea.
Pero lo "bueno", es que el tipo me dió todos los elementos para armarlo:

• Un capacitor gigantote.
• Un relé.
• Un planito de conexión.

Va el planito, de paso le hago publicidad al tipo:

Así que compré:

• 1.5 metros de cable de dos polos
• 1 metro de cable de 1 y 1/2
• Un interruptor
• Un enchufe macho.
• Unas fichitas para concetar a las palas del relé.

Y conecté todo como indica el planito:

Polea y Volante

Hay unos posts por internet que explican las ecuaciones para calcular el diámetro necesario del volante  para bajar las 1460 RPM's. La idea era bajarlas a entre 150 y 200 RPM's, según leí por ahí también, en la lista de cerveceros.

La cuenta me daba que con una polea de unos 4/5cm necesitaría un volante de entre 35 y 40 cm.

Sin embargo no encontré nada más que una de 26 cm de diámetro. La polea además era para un eje de mayor diámetro. Eso lo solucionamos con una idea bastante pragmática de mi viejo, de agregarle al eje del motor (12mm) un complemento hecho de un segmento de manguera cristal que me sobraba, creo que de 3/8.
Eso calzó perfecto!

Estructura con taburete

Otra cosa que quería hacer era comprar un taburete de pino barato, y montar ahí. Sobre el asiento poner el molino con el volante, y luego sobre la madera que une las patas, montar el motor. Y dejar todo ahí fijo.

El problema es que nuevamente no conseguí una correa de más de 40 cm. Lo cual significa que entra justo el volante y muy cerquita tiene que estar la polea del motor.
Con lo lo cual lo del taburete quedó descartado (menos mal que no lo había comprado! :).

Así que simplemente cortamos una madera y presentamos todo en horizontal.

Tolva

Como tolva, lo más sencillo ahora que no está la manija (que tenía más radio de circunferencia que el volante), nos fue utilizar un bidón de 6L que había cortado para tal fin.

Así quedaba entonces:

Todavía resta amurar el motor, capacitor, etc, a la madera. Y también cortar la madera detrás del molino, haciéndole una tolva de descarga con chapa tipo de zinguería, para que el grano caiga directo a un tacho.

9 Zonceras de la industria de software

En su libro "El Manual de Zonceras Argentinas" de Arturo Jauretche, éste nos ilustra con la definición de zoncera:

"...es la repetición sistemática de un hecho falso, adjudicándole
la categoría de indiscutible para impedirnos reflexionar sobre su
contenido. De estas repeticiones supuestamente indiscutibles, resultan
beneficiadas las clases dominantes, no haciendo posible que logremos
advertir ese perjuicio propio e intentar acciones para revertirlo..."

La industria de software, a su manera, está repleta entonces de estas zonceras. De hechos que todos repetimos, o con los cuales convivimos sin cuestionar, y que bajo un análisis crítico u objetivo (si se quiere ser optimista en cuanto al objetivismo, caso contrario léase como "en otro contexto más general"), no cierran ni un poquito.

Veamos una lista de estas zonceras de la mano de un PM/manager:

1. Desarrollo distribuído: para abaratar costos podemos construir un sistema/producto con 2 personas en India,  3 en EE.UU., 5 en Argentina y 1 en China. Y de hecho, estamos siendo eficientes. Porque podríamos armar una rueda de trabajo continua con diferentes zonas horarias. El obrero que se va a las 18hs de Argentina, es reemplazado por el de China que llega fresco para retomar lo pendiente.
2. Los managers/gerentes no necesitan ser técnicos: el manager o gerente, como uno, no necesita saber/entender qué es lo que hacen los miembros de su equipo, léase, en qué lenguaje programan, con qué criterios de calidad, etc.
3. Los managers no necesitan ser técnicos, sin embargo podrán opinar y tomar decisiones sobre lo técnico: Por supuesto que el no entender no quiere decir que no podamos opinar. Porque nuestra opinión (de los managers) es la que realmente vale. Es la que hace a la diferencia. Es la que realmente hace mover las ruedas de la compañía. Porque todos sabemos que los desarrolladores son vagos, y si fuera por ellos nunca se tomaría ninguna decisión.
4. Se puede aplicar scrum sin cambiar la forma de vender software: o sea, scrum es una boludez, un jueguito con papelitos y reuniones estúpidas que quieren utilizar los desarrolladores, porque son vagos, y porque, como sabemos, les gusta jugar, y hacer de la vidad un juego, para evitar los compromisos, las urgencias y las responsabilidades de la gente grande. En realidad nosotros (los managers) sabemos que el vendedor  consigue la venta, como siempre lo hizo, haciendo lo que haga falta para conseguirla, y prometiendo lo que haga falta. ¿El producto no lo soporta? No importa, ya veremos. ¿El cliente no sabe lo que quiere? No importa, ya veremos. El producto todavía no existe y se lo estamos contando como que es lo más maduro del mercado? Ya veremos. Total después pasa a ser problema del equipo de desarrollo. Y sí, usen scrum pibes, usen lo que quieran.
5. OpenSource+Libre = Malo/Feo/Caca, Herramientas Privativas = Bueno: el producto es siempre demasiado crítico e importante como para depender de una serie de hippies y locos que, quién sabe, quizás de un día para el otro dejan de agregar bugs, o hasta se les ocurre incluir vulnerabilidades a las librerías. En cambio es mucho más "coherente" pagarle un dineral a una empresa privada, por un producto de increiblemente inferior calidad y con aún peor soporte que el de los hippies, claro.
6. El cliente siempre tiene la razón: Como los managers, no importa si no es técnico, o ni siquiera sabe qué funcionalidad quiere, lo que importa es lo que quiere, y que lo quiere YA !
7. Si se quiera arreglar un problema, hay que hacer una reunión: aparece un problema urgente y pum, inmediátamente hay que hacer una reunión si se lo quiere solucionar. Y así sacar teorías apresuradas, sin previo análisis de hechos, causas, etc. Acá es importantísimo incluir a esos managers que no hace falta que sean técnicos, para que nos ilustren con sus locas teorías, o bien a los que "vienen del palo técnico", que nos enriquescan con esas anécdotas tan útiles de COBOL o assembler.
8. Si se quiere ser "eficiente" a la hora de resolver un problema, hay que hacer una reunión, e involucrar a tantas personas como sea necesario (Task Force): y sí, los programadores son vagos, ya lo decía Taylor y Ford. Si aparece un problema, los tipos no se involucran. Nadie se va a hacer cargo, nadie va a mover un dedo. En cambio bien que se la pasan tomando caffé y charlando de series y jueguitos. En fín, entonces, para encarrillar a todos estos proletarios que esquivan al trabajo, y para, de hecho, garantizar que ante un problema URGENTE, se responde de manera URGENTE y "eficiente", es decir sin perder tiempo ni dinero (ejem), lo mejor es armar un grupo especial, llamado "task force" y encerrarlos a todos en una sala con mucho caffé (acá sí está bien el caffé porque queremos hacerlos laburar sin parar).
9. Estimaciones rápidas y bien por arriba: Otra característica del programador/QA, en general el ingeniero de software, es que le esquiva a las estimaciones. Nuevamente, porque, como dijimos, es "vago". Entonces no se quiere poner a estimar esa idea, esa ideiiita que le tiramos, que nos dijo el cliente un día mientras almorzábamos, entre copas. O bien que la anotó en una servilleta, con dibujito y todo. Siempre intentará excusarse con que no los requerimientos no están claros, con que son ambiguos. Con que falta nivel de detalle, y que pequeñas alteraciones en las definiciones podrían significar desvíos del 400%, 1000% de la estimación. Ante esos casos, hay que meterles más presión, pedirles un número, y aclararles que no se les está pidiendo una "promesa", que nadie luego les va a recriminar si se desvía o no. Obviamente que sí, haremos eso, llegado el momento, pero a no avivarlos !

Bueno y así podría continuar con las zonceras, contadas de la mano de uno de estos amigos "managers".

Quizás lo haga en otro post a futuro.

Saludos