Google Analytics

miércoles, 8 de junio de 2011

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.

martes, 26 de abril de 2011

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.

lunes, 21 de febrero de 2011

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.

sábado, 12 de febrero de 2011

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.

domingo, 5 de diciembre de 2010

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.

martes, 25 de mayo de 2010

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)

miércoles, 19 de mayo de 2010

Video libertad!

Parece que el querido google sigue sumando emociones al liberar el codec de video V8.
Juntos V8, vorbis y matroska forman WebM project e intentarán convertirse en el nuevo standard de video.
Con la fuerza de Mozilla, Opera, Google y otros creo que tiene futuro... :)

(vía http://barrapunto.com)