Construcción de Chopera Casera

Hace tiempo que ya estaba cansado de embotellar.
Por eso había conseguido unos cornelius, y tubos de gas.
Pero la canilla que tenía sólo servía para tirar directo desde el corni.

Porque le falta el "shank" o acople, y en su lugar tiene uno que va directo a la válvula del corni con su rosca.

Entonces, evitaba embotellar, pero requería tener de alguna forma refrigerado el corni.
Igualmente tengo un freezer grande donde hago la maduración metiendo directo el corni (creo que podrían entrar hasta 10 cornis).
Pero era realmente incómodo tener que abrir el freezer para servirse.
Y además, nunca podía llevar el corni a cualquier lugar / evento y tomarla.

En otro orden de cosas, construí un artilugio para embotellar luego desde corni. Similar a una llenadora contrapresión, pero "de banco" y con dos picos, para embotellar dos por vez.
Ya haré un post sobre eso.


Entonces, la idea ahora era construir una chopera no-eléctrica, para poder llevar el corni, y tirarlo directo a temperatura ambiente enfriando con hielo.

Para eso compré una canilla por alienares

http://www.aliexpress.com/snapshot/6438699092.html?orderId=65359776025757

Acá la imagen del pasatanque ("shank") que trae

Y la canilla en sí:

Acá todas las piezas:

La idea era reutilizar una conservadora que antes usaba de macerador.
Es una heladerita comunacha de unos 28 litros (?).
Lo bueno es que tiene desagote inferior, lo cual va a ser fácil sacar el agua del hielo.

Dentro tendría una serpentina de aluminio (ideal sería de acero pero trabajar el acero para hacer una serpentina es un infierno, y además sale mucho más caro).
De una lado entra la cerveza,  pasa por la serpentina que estará sumergida en agua bien fría con hielo. De la salida se conecta la canilla.

Para eso agujereamos la heladera con una mecha de copa (no recuerdo la medida exacta ahora, pero es la misma mecha que usamos para agujerear los barriles para ponerles las canillas de 1/2).


Acá se ve ya la heladera agujereada y presentada la serpentina

Para la serpentina compré unos 15 metros de aluminio de 1/4.
Estaba en duda, leí que varios usaban 3/8.
Pero las mangueras de presión de los cornis son bastante más chicas. El diámetro interno creo que es de 6mm. Lo cual, si no me equivoco es similar a 1/4.
Quise comprar 5/16'' pero no había :(

Otro hecho por el que quería un caño más bien chico es que, si miran bien en las piezas de la canilla, el acople para manguera, que es como una "L", es un cañito extremadamente pequeño.

Así que no quería tener una gran diferencia de medidas. Suponía que al adaptar varios tamañas iba a producir turbulencias después y generar muchas espuma (en algún lado leí eso).

La serpentina como se ve ahí la hicimos en dos secciones unidas (sin cortar el caño). Cosa de que quede más bien baja, y aproveche toda la superficie de la heladera.

Además no sellamos la canilla, con lo cual es preferible no llenarla hasta arriba para que no pierda por la canilla o la entrada de cerveza :P

Acá otra foto ya probando las conexiones

Los segmentos de manguera son de un metro de manguera cristal. La verdad que no se la medida. Fue lo más chico que conseguí. Será algo así como 1/4', o menos.

Finalmente acá probando todo con agua :(

Las conclusiones por ahora fueron:

• Hay que ponerle abrazaderas a todas las uniones. De otro modo a 1.5 bar empiezan a volar por los aires :P
• Parece ser poco caudal: capaz habría que probar con cerveza gasificada en lugar de agua. Pero la sensación fue que el caudal de salida era "poco". Se tolera, como primera versión, pero no sale suficiente. 

Queda pendiente detectar el problema del caudal.

La sospecha obvia es la "L" que vino con la canilla que es extremadamente chiquita.

Probablemente actúe como cuello de botellas.

Debería conseguir un acople de manguera más grande para esa rosca.

Esperemos que sea eso, y no la medida de la serpentina. Si bien 1/4 es chico, supondría que debería ir bien para el caudal. Sino, tendré que armar otra de 3/8. 15 metros son algo así como 220$ (hoy 06/2015)

Hasta aquí las novedades cerveceras.

Luego de casi un año volví a retomar esta actividad, así que, en una semanas probaremos la chopera con una Black IPA :)

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

Mis Libros del 2012

Acá va la lista de lo que leí en este año.

2012

1. "Designing Great Beers: The ultimate guide to brewing classic beer styles", Ray Daniels.
2. "Brewing up a business: adventures in beer", Sam Calagione.
3. "Brewing better beer: master lessons for advanced homebrewers", Gordon Strong.
4. "Yeast", White & Zainasheff
5. "Tasting Beer", Randy Mosher
6. "Radical Brewing", Randy Mosher
7. "Farmhouse Ales: Culture and Craftmanship in the Belgium Tradition", Phil Markowski.
8. "Brew like a Monk", Hieronymus.
9. "The Moon is a harsh mistress", Robert Heinlein.
10. "Barley Wine", Allen & Cantwell
11. "Extreme Brewing", Sam Calagione
12. "La Historia de la Revolución Francesa", Piotr Kropotkin

Justo la mitad de lo que suelo leer (o al menos anoté del 2011 y 2010). Supongo que me lleva el doble de tiempo leer en inglés :S

Igualmente, creo que me faltó anotar alguno.

En fín, ya creo que no hay mucho material más de lectura cervecera, así que para el 2013 espero volver a la lectura de: historia, ciencia ficción y algo de filosofía.
Miro con ganas el libro de Tolstoi,  "Guerra y Paz", pero parece un proyecto para todo un año, y teniendo en cuenta que es un libro de casi 2000 páginas con doble columna, no parece muy portable para lectura de viaje diario :S

#12 - Cream Ale - Embasado

Ayer embasamos la Cream Ale Navideña.
Eran unos ~20 litros en la versión Ale Americana, y unos ~16.5 en versión lager.

No hice un recuento de la cantidad de botellas finales pero en principio el cálculo era:

• 330cm3: 26
• 13 lager
• 13 ale
• 500cm3: 4 (2 y 2)
• 660: alrededor de 33
• 740 (patagonia): 4 (2 y 2)

Para el lavado estrené el arbolito para escurrir botellas. Muy bueno !
Acá un par de fotos:

Y así quedaban las botellas en heladera con temperatura controlada a 17.8°.
Las tapas azules son las Ale, las doradas las lager.

De la relación del modelo de negocios en general con la industria de software en particular

Hoy conecté dos hechos. Para más de uno resultará trivial. Ambas hechos parecían triviales por separado, ya hace un tiempo, pero no los relacionaba diréctamente.
Ahora es como una epifanía.

La industria de sistemas es una mierda, porque la industria y el modelo de negocios actual, en general (no solo en sistemas) es una mierda.

Todo verso. No se bien por qué en nuestro país se hace tan evidente. Bah,.. capaz pasa en todos lados.

Pero, por ejemplo, hoy en el trabajo me reenviaron un mail de esos acerca de las nuevas tendencias. En especial la de incluir las redes sociales como medio de contact para las empresas de servicio de atención al cliente, helpdesk etc.

Ahora, es todo una gran bola de mentiras. Complejidad accidental y extra. Palabras y tecnologías de moda, como si las empresas quisieran en realidad procrastinar la necesidad de realmente proveer atención al cliente. Verdadera.

Decía yo, no hace falta que Telecentro tenga facebook. Si se dignaran a descontarme los días que me dejan sin internet de la factura, cosa que podrían hacer automáticamente en lugar de tener que elevar un reclamo, yo consideraría a eso "buena atención".

No hace falta que Personal o las demás empresas de celulares te pongan un ejercito de personas, o te bombardeen con publicidades de que te chupan las medias. Si después llamás y no te atiende nadie. Y si tienen políticas evide y búrdamente enfocadas en cagarte.

Pregunto, qué piesan ustedes cuando los llaman de alguna empresa para ofrecerles algo ? ejemplo: un seguro de vida, un seguro para la casa, etc..

Yo estoy convencido de que es para ellos ganar más plata cagándotela. Es así. Basan sus negocios en cagar a la gente. No es nunca un ganar-ganar. Un, yo te doy tal servicio y vos me pagás lo apropiado. Yo te doy un "extra", un valor agregado, y gano tu confianza.

El modelo de negocios se basa entonces en:

• reducir costos
• aumentar ganancias

A costo de:

• cagar y ganar de los empleados
• cagar a los clientes

Y como los sistemas sirven para brindar un servicio, o automatizarlo (o bien un proceso de negocios), están inherentemente enfocados en eso.
Una vez en otro trabajo vino un tipo, un yankee "importante", que nos dió una charla a todos los que desarrollábamos el producto. El tipo mencionaba como algo muy positivo el hecho de que "con lo que están haciendo ustedes el Banco Pepito no va a necesitar todo el ejército de personas que tiene hoy día haciendo este trabajo en forma manual".

Bastante desmotivante para mí.
Pero ojo, no me parece mal la automatización. De hecho, bien enfocada me parece que es algo necesario. Hay que automatizar tareas mecánicas y monótonas. Tareas que no sean enriquecedoras para el trabajador. Pero bueno, luego de la automatización, la idea sería que esas personas del banco pasen a hacer algún otro tipo de trabajo más dignificante, donde aportar a través de su capacidad de razonamiento, o capacidades creativas. Desmotivante es que los echen a patadas.

Ahora, el vínculo dla consultoría e sistemas no se da solo en la finalidad u objetivo de lo que construimos. Sino que se vé más evidente en el entorno donde se dá la construcción del sistema en sí mismo.
El software es hoy en día también un instrumento de comercialización, que tiene a ser "masivo". Y por ende, los desarrolladores (y otros roles de la construcción de sw) commodities.
Y como tales, las empresas, tanto el cliente que compra, como la empresa que construye, se basan en esas mismas políticas de las que hablábamos antes.

El que construye sw intenta cagar al que le compra, pero también a sus empleados. El que compra intenta cagar al que le hace el sistema. Quiere pagar poco, por ejemplo. O pretender poner las mismas exigencias de "oferta-demanda" sobre la construcción de algo complétamente distinto a un producto enlatado o bien conocido, como tratar de exigir a un Michaelangelo a que tarde 2 meses en esculpir La Piedad.

La realidad es que por ésto, hay más software del que se necesita (así como también hay más productos o variedad de la necesaria en otros mercados), pero aún más preocupante, hay más software en construcción del que realmente se puede construir.

A modo de luz al final del tunel, yo creo que existe una posibilidad de que el software se salve, una esperanza, aunque no se cuándo se dé, ni si realmente va a suceder.
Es la misma idea que en otros mercados. La gente, el consumidor no es boludo, reconoce ser valorado por las empresas. Reconoce calidad. Se está viendo una pequeña tendencia a volver a valorar al pequeño negocio, al almacén de barrio, a los artículos artesanales. Un poco porque ya pasamos por el dumping de las grandes empresas, que ahora, en posición dominante, terminan imponiendo precios aún más caros que el de los artículos artesanales y naturales, por ej en alimentos, quesos, cervezas, salames, etc.

Así, creo que con el software debería suceder algo parecido. Volver a la idea de la construcción orgánica de software realmente útil y de calidad, para un cliente inteligente que valora todo esto. Y con el aporte indispensable de los empleados (o socios en el mejor de los casos), no como mano de obra barata sino como artífices de una obra de arte.

Quizás esto vaya de la mano con la idea de entrepreneurship, de construir productos y terminar de una vez con las consultoras y las software factories.

Ojalá suceda antes de que me canse y me ponga un carrito en costanera y venda bondiolitas :)