Go Cisterna! ♪ Go! Go! ♫

Con lote en mano necesitaba tener una reserva de agua; Agua que es necesaria para absolutamente todo, por lo que decidí hacer una cisterna subterránea. Por qué subterránea?

1. Para no arruinar el paisaje.
2. Mantiene el agua fresca.
3. porque quería que fuera subterránea.

Las opciones eran hacerla de material, cubica o cilíndrica. las cuales necesitaban gran cantidad de material para la base y losa superior y sobre todo el costo de mano de obra.
De hacerla de forma cilíndrica ahorraba en columnas.

Opté por una forma mas rápida y económica. Conseguí un par de tanques plásticos de agua y enterrarlos. elegí usar dos (2) tanques de 2750 litros de 150cm de diámetro y 200cm de altura. El tamaño del tanque fue por costo/capacidad/transporte. Tanques de 5000 litros salían exactamente el doble en la relación precio/litro sin contar con el transporte y la dificultad de manipulación.

Otra decisión importante fue no conectar ambos tanques por debajo. De realizar esa unión y esta se rompa sería imposible de arreglar.

Y así comenzamos...

Estime que necesitaría un pozo de 200cm de ancho x 400cm de largo x 250cm de profundidad. En un par de horas la excavadora hizo su trabajo.

La maquinola laburando....

Nota: luego que la excavadora termine medir de que dimensiones quedo el pozo. (cosa que no hice y me sobro lugar para todos lados.

Lo que salió

Lo que quedó

Con el pozo hecho. Se hizo un fondo de arena gruesa de aproximadamente unos 50cm para evitar que cualquier piedra haga presión sobre la base del tanque. Se mojó bastante para que se compactara.

Posicionado Tanques

Tanques rodeados con malla sima

Al ser tan livianos entre dos personas bajamos el tanque sin ningún tipo de inconveniente.

Uno sosteniéndolo de arriba mientras el otro lo dirigía de abajo. Se colocaron a 50cm de distancia entre ellos.

Se llenaron de agua para evitar su deformación cuando se deposite el material y también se le puso una malla sima de 200x500 rodeando cada tanque (queda perfecta).

Tanques, malla y fondo de arena

#Charannn!

Podemos observar como quedo el anillo de MDF

Anillado de Concreto

Para el encofrado utilice una plancha de MDF de 3mm el cual es lo suficientemente flexible como para tomar la forma circular. La corte a la mitad 90x260cm y entre ambas partes pudimos decir "El circulo está completo".

De esta forma nos queda un espesor de 10cm entre el tanque y el anillo para rellenarlo con concreto que junto a la malla sima le dan la resistencia necesaria para evitar el colapso por el peso de la tierra de al rededor cuando el tanque no tenga agua.

El llenado se realizó en dos etapas. se lleno la parte inferior hasta los 90cm. fraguó unos días y luego se elevó el anillo de MDF para completar con concreto hasta la parte superior del tanque. Luego el otro tanque.

Rellenando el resto con material estabilizado.

Se lleno con el material extraído dejando el ripio fino y la tierra (también llamado material estabilizado) hasta llegar al nivel del anillo de cemento regandolo por unos días (y unas cuantas lluvias) para que se estabilice y afirme.

Contrapiso superior

Nota: Bueno. Aca faltan un par de fotos debido a que el obrero no me llamó para cuando armo el contrapiso. pero pueden imaginarlo...

Coloqué otra malla de 200x500cm sobre ambos tanques. Abrí dos agujeros para que pasen las bocas de los tanques y las enganche con los alambres de las mallas que rodeaban cada tanque. Luego se lleno con concreto de un espesor de aproximadamente 15cm.

Contrapiso secandose

Altura: 40cm bajo tierra.

Todavía con agua :)

Columnas de acceso

Diagramando las columnas a ojo.

Debido a que quedo bastante bajo hubo que hacer unas columnas de cemento bastante altas. además las bocas quedaron mas separadas de lo esperado así que en vez de hacer solo una columna decidí hacer dos independientes.

Entre ellas va un caño de servicio para pasar caños de agua y/o electricidad. Además cada columna posee un caño del mismo diámetro para acceder desde afuera.

A un ladrillo de pandereta para finalizar

-

Columnas finalizadas con caño de servicio

A Rellenar! 

Queda por rellenar con ripio estabilizado hasta llegar al nivel de la tierra.

Las bocas hacia el exterior de las columnas las rellené con un poco de diario para evitar que se llenen de material.

También hubiera sido bueno diagramar las cañerías de servicio y así dejarlo listo para evitar tener que hacer mas tarde un pozo nuevamente.

En resumen

Modelo terminado

El proyecto demoró casi un año desde que se hizo el pozo hasta que se pusieron las columnas de ladrillo. Con los fondos suficientes creo que no debería demorarse mas de un mes, con fraguado incluido. Los costos de materiales fue significativamente menor, sin preocupaciones por filtraciones y/o impermeabilizar.

El principal inconveniente fue el obrero que una vez finalizada la obra pretendía cobrar 4 veces mas que lo presupuestado. Nota: Es de buena práctica escribir(le) un presupuesto y que lo deje firmado para evitar este tipo de incidentes.

Otro dato no menos importante es que ambos tanques todavía tienen agua de la primera carga (más de un año), sin ningún indicio de que este en mal estado. No me animo a tomarla pero se la doy a mis perros y están fuertes y sanos.

Lo que falta...

• Queda por realizar dos tapas con dos hojas por cada una para terminar con el proyecto.
• Un par de caños de 3/4 que bajen hasta el fondo de cada tanque con una válvula de retención para mantener la cañería siempre con agua.  
• Un sistema eléctrico con electro válvulas para intercambiar de que tanque tomar agua y así seguir bombeando agua evitando que la bomba trabaje en vacío.
• También estaría bueno un tablero para monitorear el nivel de cada tanque.  
• Un poco de pastito y tierra :)

El Futuro es Para Siempre

Con esta frase la Internet Society en el sitio World IPv6 Day  nos demuestra la importancia de la implementación de la nueva versión del protocolo de internet.

Por ahora viene a salvarnos las papas con la problemática de  numeración, pero IPv6 no es sólo eso... es mucho más. Es volver al origen, donde todos podemos conectarnos con todos, donde no haya limites, donde todos estemos al mismo nivel, donde todos seremos iguales.

8 de Junio - El Futuro es para siempre

Feliz día! IPv6.

Ensayando con la sinfónica

Vamos a practicar un poco con los esquemas y modelos  con doctrine.

Nota:
Antes que nada, evitar el uso de software que modifiquen las relaciones foreignKeys. Suelen cambiarle el nombre y esto provocará que al intentar realizar una migración probablemente falle.

Primero vamos a asignarle una base de datos a los entornos que hemos definido.Para ello necesitamos un usuario del motor con los privilegios necesarios para crear/eliminar una DB o la de root, lo cual no es recomendable.

./symfony configure:database "mysql:host=localhost;dbname=test" test testpass
./symfony configure:database "mysql:host=localhost;dbname=dev" dev devpass

Ahora podemos crear nuestra DB para el proyecto
./symfony doctrine:build-db --env=test
o destruirla... (muuaaajajaja)
./symfony doctrine:drop-db --env=test

Bien. Vamos a definir en nuestro esquema User con una propiedad name. Bastante simple para empezar.

schema.yml
User:
  columns:
   name:
     type: string(255)


Aquí vamos a salir del camino del libro y hacer un poco de travesía. Directamente vamos a "versionar" nuestro esquema y así poder cambiar de versiones de nuestro esquema de base de datos.

El primer paso es generar los scripts de migración a partir del modelo actual.
./symfony doctrine:generate-migrations-model

Esto generará una serie de scripts en lib/migration/doctrine uno por cada definición en el esquema. En este punto no debería haber problemas con estos scripts pero conviene mirarlos para ver que va hacer.

Vamos a probar los scripts, es conveniente probarlo en algún otro entorno, por si falla, vió!
./symfony doctrine:migrate --env=test

Vas a ver un mensaje diciendo que se cambia de la versión 0 a la X, siendo X la cantidad de archivos que genero. No debemos olvidar aplicar los cambios en el entorno que estemos trabajando y por nada en el mundo generar las clases asociadas al esquema.
./symfony doctrine:migrate --env=dev
./symfony doctrine:build --all-classes


Esto generará las clases del modelo, forms y filters asociados al esquema. Genial, no ?

Es un buen momento hacer un commit de svn. agregamos el schema.yml y las carpetas en lib, model, form, filter y migration. Conviene llevar al día cada cambio, si hay algún problema podemos volver a una versión anterior.

Con el modelo actualizado, podemos hacer cambios nuevamente en el esquema. agregando Grupo.

schema.yml
User:
  columns:
    name:
      type: string
     group_id:
       type: integer
       notnull: true
  relations:
    Group:
      local : group_id
      foreign: id

Group:
  columns:
    name:
      type: string


De esta forma definimos un Group y la relación One-Many de los User.
Ahora hacemos un diff entre nuestros modelos y el esquema.

./symfony doctrine:generate-migrations-diff.

Esto generará un (o varios) archivo en lib/migration. Este incluirá los cambios que se realizarán en la DB. Generará un archivo para agregar, quietar o modificar campos o tablas, y otro para las relaciones (foreign keys) dependiendo del tipo de relación.

Prestar mucha atención con esto, no queremos que borre una tabla y la volver a generarla, sino cambios mínimos o creación de nuevas tablas.

Es el momento de migrar nuevamente, puede pasar sin problema., o un super mensaje en rojo diciendo porque falló. Casi siempre el mensaje en rojo no se entiende, jeje pero bueno. 
./symfony doctrine:migrate --env=test

En caso de error, deberemos identificar en que paso. Los errores mas comunes que me sucedieron en las relaciones. El campo local y foreign deben ser de igual tipo, largo y si es nulo.

Recordemos que en caso de necesitar empezar de nuevo podemos usar drop-db y build-db en el entorno test. También podemos ir migrando de a una versión a la vez incluyendo el número de versión. Si estamos en una versión superior, migrará hasta llegar a la versión 4 y de ser inferior ejecutara los scripts para llegar al mismo número.
./symfony doctrine:migrate --env=test 4

Una vez que estemos seguros que la migración funciona correctamente, deberíamos actualizar las clases:
./symfony doctrine:build --all-classes

Es tiempo de hacer un nuevo commit con los esquemas y modelos modificados y no olvides incluir los nuevos modelos y los archivos de migración.

Posteriormente migramos la db del entorno de desarrollo.
./symfony doctrine:migrate --env=dev

A Tener en cuenta:
En el caso de eliminar un campo, y este sea parte de una relación deberemos hacerlo en dos pasos:

• primero eliminar la relación del esquema, hacer el diff, migrar, build clases
• luego eliminar el campo deseado del esquema, diff, migrar y build clases.

Saludos.

Curso nivelatorio para tocar con la sinfónica

Buenas. Siguiendo con la historia hoy vengo a intentar volcar mis mañas de solista al querido framework y fracasar con todo el éxito posible.

Quizá se complica un poco adaptarse a la estructura y forma de funcionamiento, configuración, etc. pero vale la pena. Realmente.

Y aquí vamos. Imagino que leyeron los primeros capítulos de Practical Symfony.

Es muy recomendable colocar el framework en lib/vendor/, pero porque ?, podes ponerlo en donde quieras, pero es bueno seguir mas o menos los lineamientos del framework. Además symfony creara directorios dentro de la carpeta lib. Es más, deberías poner todas las librerias externas dentro de este directorio.

Si trabajas con SVN, es muy recomendable agregar el svn:external. Y también es recomendable el primer commit (cosa que yo no hice).

Hasta ahora solo tenemos un solo directorio en el proyecto, el cual es una librería externa ;). Ahora empieza la magia.
php lib/vendor/symfony/data/bin/symfony generate:project [NombreDelProyecto]

Veremos que genera un árbol de directorios que necesita symfony para trabajar. Esto es lo bueno con respecto a otros frameworks, empezás con solo una dependencia, vas viendo como crece el proyecto, y no tenes que andar adivinando que va en cada carpeta.

NOTA: No olvides  check_configuration,php, muy útil para saber si symfony va a correr en tu server.

Ahora podes usar ./symfony para llamadas de consola. Es el momento de generar apps, tasks, etc. y ver como genera su estructura.

Estructura
La estructura principal de un proyecto esta dada por apps, lib, plugins:

• Plugins: extensiones que trabajan en forma independiente. Muchas veces es útil buscar un plugin que cubra una funcionalidad a crear, testear, etc.
• Lib: Aquí están las clases pertenecientes al Modelo, Formularios, Filtros, Tareas.  Además aquí deberías agregar las clases que necesites crear.
• Apps: (ejemplo frontend) dentro tiene módulos y librerías para uso propio. Además tiene acceso a lib y plugins del proyecto. 

También esta el directorio config en la raiz del proyecto, como así también, en apps y plugins. De esta forma permite configurar cada sección de nuestro proyecto independientemente del otro, y si así lo requiere acceder desde una app a algún dato de la configuración global.

Entornos (ENV)
Symfony permite trabajar con distintos entornos. Al principio parece una boludez, pero lo vas a necesitar. Podes generar entornos a tu antojo. no es necesario que los hagas todos de una vez. Básicamente, definís una DB para cada entorno y como se comportará cada entorno.

Una vez definidos, podrás hacer pruebas en algunos entornos. por ejemplo usé el entorno test para probar la migración de la base de datos. Pero cuidado, el modelo es común a todos los entornos, por lo que si lo regeneras es probable que algún otro entorno falle.

Configuración (Yaml)
En esto se puede ver la versatilidad de symfony, puedes configurarlo mediante PHP, XML y YaML. Quizá la primera impresión asusta pero lo mejor de lo mejor es YaML.

Configurar en PHP, es como seguir programando. Código donde no debería. Tedioso. A alguien que no sabe programar no le va ser fácil.

El XML es mas universal, sin embargo necesitas al menos conocer la sintaxis.

La ventaja de Yaml, es la simpleza, no necesitas recordar cerrar tags, y mucho menos hace falta saber cual es el api de configuración. Es simple, la llave seguida de dos puntos y el valor.

type: integer

En caso de poseer proliedades en una nueva linea con tabulación de espacios.
id:
   type: integer

 Es todo por hoy.

De solista a buscar con quien tocar...

Influenciado por algunos amigos entré en el mundo de los frameworks para PHP.

El recomendado fue CakePHP, la verdad es difícil, programes como programes, adaptarte al modelo de "otro" es complicado. muy complicado. Quizá se llevo todo el odio por ser el primer contacto con un framework, pero bueh... En fin... CakePHP me sirvió para poder asimilar el concepto de framework. desmenuzar los esquemas, controladores, vistas, módulos, rutas, helpers, widgets, plugins y toda las verduras y frutas que imagines.

Sin embargo CakePHP no convenció del todo. Quizá porque soy un rompebolas. Es probable. El mejor pero que encontré es que es mucho array, y no hay cosa que me desagrade mas es escribir accesos a los arrays. Agreguemos también que tiene un nivel medio de uso de objetos/clases, cosa que de solista, armaba todo en clases.

Bien, a empezar a buscar un framework que me convenza. Que cagada. Tarea complicada. Muy.

Entre los tantos que vi, visite me tope con Symfony. Un framework compuesto de muchos proyectos, lo que realmente me gusto. Con cosas raras como Yaml o ejecución de cosas por consola. Le di un vistazo a los manuales y me parecieron muy prácticos y didácticos. Además se destaca por requerir PHP 5, para explotar al máximo clases y objetos.

Tarea para la casa: Leer los primeros capítulos (por lo menos hasta el 4to)  de Practical Symfony, guía de cabecera para hacer una App de verdad.

Después les cuento como terminas amando al yaml, sacarle provecho a la consola y mis más experiencias con la sinfónica.

En busca del backup perfecto

Hace poco, relativamente poco le vi la importancia de hacer backup. Va! siempre fue importante, pero nunca le das bola... NUNCA. Un día te das cuenta, de que si llegas a perder lo que tenes en la compu, y me refiero al trabajo de años... (no a los videitos, y musiquita) es mejor abandonar a lo que te dediques y empezar a cuidar vacas.

Fue ahí que empece a buscar alguna solución, y escribí una lista de las necesidades a cubrir:

1. La principal, como para no tirar mis ideales por la borda tiene que ser software libre.
2. Tener backup siempre, donde quieras que estés. Dado que mi equipo es un laptop.
3. Que sea rápido, y que no desperdicie espacio. 
4. En caso de algún siniestro, poder recuperar todo... como si nunca paso nada.

Solo cuatro puntos ? nada mas ? jaja. pinta fácil... pero no.

Bien, empecemos. programas conocidos y usados.
Uso backuppc en el trabajo para servers, esta basado en rsync, todo muy automatizado, muy personalizable, todo muy lindo... pero... (siempre lo hay...) siendo un equipo móvil no tendría copia si no estoy en la red (chau punto 2) y tampoco tendría copia si no estoy el tiempo suficiente para que termine. Rápido; tampoco, cuando se pone hacer un full, estamos en el horno. Asesina a la red, al laptop (die die point 3), sin mencionar que se duplica el espacio usado. Recuperación. entras a la web, click en que vas a restaurar restauras y listo ! Fácil no ? pero... (otra vez) andá a encontrar que versión querés restaurar!

Probé déjà Dup muy integrado con gnome, permitiendo copias locales o remotas, "O". A pesar de eso, al momento del full, el mismo problema. Horas la compu andando a full, para algo que ya tenía. 

Hubo un par mas pero ni los recuerdo, o algunos muertos como TimeVault.

Me pregunté que habría sido de la vida de flyback. La primera impresión fue que estaba cambiado. Que tanto ? mucho, había cambiado su forma de hacer backups, reemplazando rsync por git (el sistema de versionado). Verdaderamente me sorprendió, cambio mi forma de ver como hacer backups. Muy bonita interfaz. muy práctico aunque con algunas limitaciones. Orientado a unidades externas, sin copia remota y dependiente de una interfaz gráfica para correr.

Aun así el concepto es muy bueno. por lo que decidí buscar a ver quien más hacia backup con git. Encontré gibak el cual es un script de bash + git. Comencé a usarlo y la verdad que me gusto. rápido, efectivo, con copia local, lanzandolo cada hora con cron, y demorandose segundos en hacerlo. Interfaz gráfica ? SI, la que quieras, gráfica ? gitg, web? gitphp o la que quieras.
Para cumplir con mis expectativas, faltaría la copia remota. y bueh, esa es la ventaja del software libre, esa parte la hice yo usando git+ssh. De esta forma, tengo backup local cada 1 hora, e intenta sincronizar con el remoto. y no tarda mas que segundos.
Que le falta: que agregue tags semanales y mensuales, es la parte fácil. que elimine las etiquetas viejas y sus archivos es lo difícil. Otra buena idea es pasar el script a un lenguaje multiplataforma.

Por acá gibak via github podes encontrar la rama en la que estuve trabajando.
De necesitar ayuda avisame, no soy un experto en git, pero algunas dudas puedo satisfacer.

Saludos y gracias por leer.

Por 200 Más ...

En este momento, veo como Don Sol asoma, el vapor del termo dibuja figuritas y el Sr. mate templa la mañana, pero algo falta. Esa sensación nunca es buena y te deja pensando un rato, Inspiración se hace desear pero finalmente llega y te dice: como fue que hoy no tengo una torta frita para celebrar?

Pasaron muchas cosas entre medio, partiendo desde el pueblo quiere saber de que se trata, haciendo escala en que se vayan todos y con una parada de emergencia hoy en donde esta mi torta frita!

Espero que al llegar al 300 mi país haya pasado la adolescencia, discuta menos y haga mas, mas niños con menos hambre, mas trabajo, mas dignidad.

Hoy 200 años después las costumbres argentinas siguen siendo las mismas, y no puedo creer es que tras 200 años de evolución todavía no hay un delivery de torta frita!

Felicidades Patria Mía, por otros 200 más...

(imagen http://www.cultura.gov.ar)