Skip to content

Author: jahepi

Active Record, Data Mapper, ORM, SQL Wrapper

Un ORM o Mapeo Relacional de Objetos es la capa responsable de analizar la información de las tablas de las bases de datos convirtiendo esos datos en objetos, así en un catálogo de usuarios cada registro de esa tabla se traduciría a instancias u objetos de tipo Usuario y los campos de la tabla serían los atributos de nuestra instancia (aunque no necesariamente un campo de una tabla se traduciría a un atributo de una instancia), el ORM se encarga además de hacer el proceso inverso ya sea cuando se guarda o actualiza la instancia, donde el objeto es persistido en la base de datos y para ello se necesita que sea analizado, generando las consultas necesarias para guardarlo en la tabla de la base de datos.

Un ORM puede ser implementado comúnmente utilizando el patrón Active Record o también el patrón Data Mapper.

Active Record

Definición de la wiki:

Active record es un enfoque para aceso de datos en una base de datos. Una tabla de la base de dados o vista (view) está envuelta en una clase. Por lo tanto, una instancia de un objeto está ligada a un único registro (tupla) en la tabla. Después de crear y grabar un objeto, un nuevo registro es adicionado a la tabla. Cualquier objeto cargado obtiene su información a partir de la base de datos. Cuando un objeto es actualizado, un registro correspondiente en la tabla también es actualizado. Una clase de envoltura implementa los métodos de acceso (setter e getter) o propiedades para cada columna en la tabla o vista

Un ejemplo de Active Record:

Cabe mencionar que cuando es implementado este patrón de diseño, la entidad del dominio es responsable de persistirse en la base de datos, esto conlleva que dicha entidad tenga además de tener reglas de la capa de dominio (Método esMayorDeEdad), también quede acoplada a la capa de persistencia (Métodos guardar y obtener), esto trae una gran desventaja, si queremos en un futuro cambiar la forma de persistencia, que ahora en lugar de guardarse en una base de datos se guarde en archivos de texto plano (lo sé, es una locura), habría que hacer una refactorización de código inmensa, pero para proyectos donde la capa de persistencia se tiene por sentado que no cambiará es una forma buena de abstraer el cómo se gestionan las entidades de nuestros sistemas.

La forma en que utilizaríamos la clase:

Data Mapper

Definición de la wiki:

Data Mapper es una capa de acceso a los datos que realiza una transferencia bidireccional de la información entre la persistencia (frecuentemente una base de datos relacional) y los datos que se encuentran en memoria (La capa del dominio). El objetivo de este patrón es mantener la capa del domino y de la persistencia independientes

Como vimos hace rato, Data Mapper ataca el punto débil de Active Record donde la capa de persistencia queda acoplada a la capa de dominio, su objetivo es mantener las dos capas independientes, es por ello que este patrón de diseño es ideal para sistemas donde las entidades del dominio son persistidas en diferentes medios, haciendo uso de este patrón no habría mayor problema si en un futuro se cambia la persistencia, que podría ser una base de datos a una fuente de información distinta.

Ejemplo de Implementación:

Como vemos, nuestra entidad del dominio usuario ya no tiene conocimiento de la capa de persistencia.

Ahora vamos a implementar la capa de abstracción responsable de guardar las entidades del dominio desde cualquier fuente de información:

Implementamos el Data Mapper en caso de que nuestra persistencia sea una base de datos:

O si en un futuro cambia el sistema para que la fuente de datos sean documentos XMLs:

Ahora nuestro sistema dependería de una abstracción, y el modo de persistir los datos puede ser cambiado de base de datos a documentos XML, o inclusive otras fuentes:

Como conclusión, el patrón DataMapper las entidades como es la de Usuario son independientes, estas no conocen como persistirse en la base de datos, el que tiene la responsabilidad de hacer esto es otra clase que llamamos manejador (mapeador), la gran ventaja de esto es que nuestros objetos del dominio quedan totalmente desacoplados, el manejador se encarga de guardar las instancias en una base de datos, en un archivo de texto, en memoria, etc. Al final no importa dónde, el manejador hace lo necesario para que esa entidad sea persistida.

SQL Wrapper

Un SQL Wrapper es un envoltorio para generar consultas de una forma orientada a objetos, utilizando los métodos del wrapper o envoltorio se construyen las consultas dinámicamente, un ejemplo de cómo implementarlo vale más que mil palabras:

La forma en que utilizaríamos la clase:

 

Eso es todo por hoy, saludos :)

Leave a Comment

HTML5 vs FLASH

Hace muchos años vimos el nacimiento de una plataforma que abrió un abanico de posibilidades en el mundo de Internet, la plataforma de desarrollo conocida como Flash, en un principio creada por Macromedia para más tarde ser adoptada por Adobe permitió realizar cosas que antes nunca habíamos visto en la web, sitios con animaciones espectaculares, juegos que jamás llegamos a imaginar que pudiera ser posible ejecutarlos desde un navegador, en fin; grandes cosas surgieron en ese periodo.
Tengo un gran cariño a esta tecnología porque fue uno de los catalizadores que hicieron que me interesara en la programación y en el desarrollo de aplicaciones, Actionscript lenguaje nativo de Flash fue uno de los primeros lenguajes que aprendí, programé muchas cosas utilizándolo, me atrevo a decir que ha sido el lenguaje que más he disfrutado ya que me permitió hacer cosas que no creí posibles en aquella época.

La popularidad de Flash ha ido disminuyendo con el tiempo, todo esto por el advenimiento de HTML5, además que el plugin de Flash no es soportado en ciertos dispositivos, ¿alguien mencionó Apple? , Steve Jobs rechazó el uso de esta tecnología; pero a pesar de todo lo negativo estos últimos años, Flash sigue, no tan fuerte como antes pero aún es una gran herramienta para el desarrollo de aplicaciones.

Este es el motivo de esta entrada en el blog, quería ver las virtudes que HTML5 ofrece para el desarrollo de aplicaciones, compararla con Flash y dar mis conclusiones. Así que me vi en la tarea de hacer un pequeño juego usando el elemento Canvas y Javascript; cabe mencionar que este es mi primer intento de hacer un juego con HTML5, los juegos que llegué a desarrollar siempre fueron en Flash así que hice esto para tener un panorama más claro de lo que es HTML5 y porque está desplazando a Flash.
Dejo el código completo, tiene algunos errores en la detección de colisiones, no pude identificarlo hasta el momento pero si alguien lo encuentra o tiene algún comentario sobre el fuente estoy ansioso por escuchar sus comentarios.

 

Las teclas con las fechas hacía abajo y arriba rotan el personaje y las flechas izquierda y derecha lo mueven sobre el eje X y Y, con la tecla A disparan, el objetivo es destruir las rocas que salen volando, no tiene niveles, ni jefes, sólo es un juego sencillo a modo de aprendizaje.

Enlace al juego: http://games.jahepi.net/testgame/index.html

No voy a decir la verdad absoluta, el siguiente comentario está basado en la corta experiencia que tuve implementando esta demo.
HTML5 es una tecnología que no ha alcanzado el nivel de madurez que tiene Flash, no hay duda que trae grandes cosas, pero al final se me ha hecho más difícil programar y depurar el código, además que Javascript le faltan algunos detalles para llegar a ser un lenguaje 100% orientado a objetos como lo es Java o ActionScript 3, me hubiera gustado manejar mi clases en paquetes o indicar el tipo de dato en las variables, extrañe el uso de movieclips, sprites y todas las bondades que tiene Flash para facilitar el desarrollo pero aun así considero que como todo en la vida nos adaptamos a los cambios, en un futuro no tengo la menor duda que HTML5 junto con Javascript marcarán la web como Flash lo hizo en su día.

Leave a Comment

Autentificación con MySQL Symfony 2 Parte 1

Después de luchar durante horas finalmente pude integrar el bundle de seguridad de Symfony para realizar el proceso de autentificación de usuarios, documenté todo para poder consultarlo si llegara a olvidar algo y también puede que sea útil para otros.

Primero montamos nuestro proyecto Symfony y además generamos un bundle, para este escenario creé un bundle llamado “LoginBundle”.

Damos de alta un catálogo de nombre “user” en la base de datos MySQL con los campos: id, username, password y isActive. Este almacenará todos los usuarios que serán autentificados desde el sistema.

SQL del catálogo user:

Ya que hayamos dado de alta el catálogo, procedemos a generar el XML donde se mapea la información de la tabla y después ese archivo lo utilizaremos para generar la entidad User en Symfony.

Generamos el XML de mapeo con el siguiente comando de Doctrine:

Le estamos diciendo que genere la entidad User del bundle LoginBundle, internamente Doctrine (ORM usado por Symfony) busca la tabla user en la base de datos y crea el XML con la información necesaria para generar dicha entidad.

Ahora con el siguiente comando generamos la entidad User con el XML recién generado localizado en: LoginBundle/Resources/config/doctrine/User.orm.xml

Con esto se crea la entidad User en la carpeta Entity de nuestro bundle.

Por defecto vamos a tener la entidad User con los atributos: id, username, password, isactive junto con sus getters y setters, se puede ver en LoginBundle/Entity/User.php.

Para activar la autentificación de usuarios desde la base de datos en Symfony la entidad usuario debe implementar 3 interfaces: UserInterface, Serializable y AdvancedUserInterface, así que abrimos el archivo de la entidad y procedemos a editarlo pero antes una explicación sobre las interfaces.

Entre las tres mencionadas UserInterface es la más importante ya que cuenta con los métodos: getRoles(), getPassword(), getSalt(), getUsername(), eraseCredentials().

Los métodos getPassword y getUsername no es necesario implementarlos ya que se crearon en la entidad User con el comando que vimos anteriormente, con respecto a los métodos restantes habrá que implementarlos.

Aunado a esto la interfaz serializable tiene dos métodos, serialize y unserialize, se implementan para que la entidad User sea serilizada en la sesión.

Por último la interfaz AdvancedUserInterface tiene los siguientes métodos: isAccountNonExpired(), isAccountNonLocked(), isCredentialsNonExpired(), isEnabled().

En esta caso se utilizó esta interfaz para indicar cuales usuarios están inactivos o activos por medio del método isEnabled, que lo vamos a saber usando el atributo isactive de nuestra entidad User.

La entidad User quedaría de la siguiente forma:

Explicación de algunos métodos importantes:

El método getRoles() por el momento tenemos el código en duro, regresa un arreglo con la cadena ROLE_ADMIN, todos los usuarios van a tener ese rol asignado, lo mejor sería que esos roles también los obtuviera de un catálogo de la base de datos pero esto lo dejaré pendiente para otra entrada.

El método getSalt() regresa un valor nulo, este método es utilizado para codificar la contraseña un nivel más, lo que hace internamente es agregar el valor “salt” a la cadena del password, codificando estos dos elementos da como resultado que sea mucho más difícil  descifrar cual es la contraseña si alguien llegara a tener acceso a estas, en este escenario no añaderimos ningún “salt” por eso regresamos valor nulo, pero es recomendable hoy en día agregar el salt a la contraseña por cuestiones de seguridad.

Estos dos métodos son de la interfaz Serializable, el atributo id es el valor más importante que se serializa porque hay un método interno en Symfony llamado refreshUser() responsable de cargar el usuario en cada petición usando el id.

El método isEnabled() lo encontramos en la interfaz AdvancedUserInterface, este método es utilizado por Symfony para saber que usuarios están activos o inactivos, para ello sólo vamos a regresar el valor del atributo isactive, es un valor booleano que viene del catálogo user de nuestra base de datos.

Vamos a generar el controlador responsable de verificar el acceso del usuario sea correcto:

Lo siguiente es crear en LoginBundle/Resources/views la carpeta Security, y dentro la plantilla:  login.html.twig

El código de esa plantilla es:

Los campos de texto de la contraseña y el usuario deben de tener como nombre _username y _ password, esto es debido a que internamente Symfony agarra esos nombres por defecto al hacer la validación, se pueden cambiar si asi se requiere desde la configuración de seguridad, la ruta login_check que se llama dentro de la función path esta declarada en el archivo de configuración de las rutas que veremos enseguida.

El archivos de configuración de la rutas se encuentra en LoginBundle/Resources/config/routing.yml, definiremos las siguientes rutas:

El siguiente paso es habilitar en la configuración de seguridad la validación de la entidad User que esta vinculada a la tabla “user” de nuestra base de datos para restringir los accesos al sistema, vamos abrir el archivo app/config/security.yml, pero antes crea una copia de este archivo para su respaldo.

El contenido del archivo security.yml es:

Esta parte es la que me causó más quebraderos de cabeza, considero muy importante comprender cada una de estas partes para que todo funcione sin problemas, así que pasaré a explicar cada una de las secciones del archivo de configuración.

Sección Codificadores:

En esta sección definimos el codificador que se va a utilizar para que la contraseña de nuestro usuario sea cifrada, en la línea 2 se especifica la ruta (namespace) de la entidad User que será utilizada para este proceso, en la línea 3 asignamos el algoritmo de codificación, en este ejemplo es sha1 pero puedes utilizar otros si lo requieres, en la línea 4 es una bandera que indica si la contraseña también además de utilizar el algoritmo sha1 se utilizará la codificación base 64, lo deje en falso para este ejemplo y por último en la línea 5 es el número de iteraciones que será codificada la contraseña de usuario, sólo haremos el cifrado sha1 una sola vez, pero puedes indicar cualquier número de iteraciones para ofuscar más la contraseña.

Sección Jerarquía de Roles:

En la jerarquía de roles se pueden especificar qué otros roles entran o son válidos en determinado rol, es como una relación padre e hijo, estas restricciones de que partes del sitio son accedidas dependiendo del rol se declaran en la sección access_control que veremos más adelante.

En el ejemplo anterior vemos que el rol “ROLE_ADMIN” también tiene asignado el rol “ROLE_USER”, esto quiere decir que si hay ciertas rutas restrigidas donde sólo usuarios con el rol “ROLE_USER” pueden entrar, significa que también podran acceder los usuarios que tenga el rol “ROLE_ADMIN”.

Sección de Proveedores:

Le sección del proveedor (providers), declara el proveedor user_db, un proveedor de usuarios es la fuente de dónde se cargan los usuarios en el proceso de autentificación, estos pueden venir de un texto plano, xml, memoria, base de datos, etc. la fuente puede ser cualquiera, en este ejemplo la fuente es nuestra entidad vinculada al catálogo de nuestra base de datos. Dentro de la configuración en el atributo entity se especifica la entidad User que generamos anteriormente y la propiedad username es el criterio de búsqueda, esto quiere decir que Symfony buscará la entidad en la base de datos por su atributo username.

Seccion Firewall:

En el firewall el apartado login, tiene dos atributos pattern y security, en el pattern especificamos con una expresión regular que rutas serán descartadas en el proceso de autentificación, vemos que tiene el valor ^/admin/login$, así la ruta /admin/login será omitida del proceso de autentificación ya que el parámetro security tiene valor falso para que salte el  proceso de validación. (esta ruta es la que muestra el formulario de login).

Ahora iremos al apartado de secure_area donde pattern es otra expresión regular (^/admin) que dice que todas las rutas que empiecen con /admin estarán protegidas, no podrán ser accedidas hasta que el usuario se autentifique.

Vamos a la parte de form_login, donde check_path apunta a la ruta que definimos en el achivo de configuración y tiene como valor /admin/login_check, esta ruta dispara un proceso interno de Symfony responsable de la validación del usuario y ver si la autentificación se ha hecho corréctamente, aquí no es necesario implementar nada más que definir la ruta en el archivo de configuración de rutas que vimos anteriormente.

El login_path tiene como valor /admin/login, es la ruta que apunta a nuestro controlador que pinta la vista del formulario de login y verifica que el usuario se haya autentificado correctamente, es el controlador SecurityController que creamos anteriormente donde se ejecuta el método loginAction del controlador SecurityController.

El atributo default_target_path, es la ruta donde nos redireccionará la autentificación en caso de ser exitosa, en este ejemplo nos redirecciona a la ruta /admin, esta ruta llama al método loggedAction del controlador SecurityController.

Por último vamos al apartado de logout, el atributo path es la ruta que hace el proceso de salir de la sesión, esto también es interno de Symfony no se tiene que implementar nada más que definir la ruta en la configuración al igual que el parámetro check_path anterior.

Para finalizar el atributo target solo es la ruta a donde nos redirigirá Symfony cuando el usuario sale de la sesión.

Más info: http://symfony.com/doc/current/reference/configuration/security.html

Sección Control de Acceso:

En esta parte definimos la rutas y que roles tendrán acceso a esas rutas, el path es una expresión regular de la ruta y el atributo roles, qué roles tienen acceso a esta ruta.

Con esto finalizamos la primera parte de la autentificación, deberíamos tener la funcionalidad básica para que los usuarios puedan iniciar sesión.

En la siguiente entrada vamos a ver la parte de roles para que no estén en código duro y los tome de una catálogo de la base de datos.

Leave a Comment

Montar Proyecto Symfony con Git en servidor Centos

Vamos a dar de alta el proyecto Symfony con composer en nuestra carpeta /var/www/html de nuestro servidor, por defecto apache la coloca ahí pero pudiera darse el caso de tenerla en otra ubicación.

Para instalar composer ejecutamos las siguientes instrucciones:

Con esto deberiamos tener activo el comando composer, ahora creamos el proyecto symfony en la capeta www:

De esa manera empezará la instalación y pedirá algunas opciones de configuración, al finalizar deberías tener la carpeta proyecto_prueba con todos los archivos descargados.

Vamos a pasar nuestro proyecto como repositorio Git, para esto debemos tener Git instalado en el servidor, si no es así sólo ejecuta:

Una vez instalado vamos a inicializar nuestro repositorio desde la capeta del proyecto:

Antes de inicializar el repositorio vamos a renombrar un archivo que es .gitignore, y lo puedes ver en el listado de archivos de proyecto, el parámetro -a es para vel los archivos ocultos:

Ese archivo lo vamos a renombrar a .gitignore_copy, esto es porque cuando creamos el repositorio omite los archivos que vienen en el contenido de .gitignore y no queremos eso, lo que se pretende es hacer el repositorio del proyecto completo:

Ahora si, inicializamos nuestro repositorio, dentro del proyecto ejecutamos:

Luego añadimos todos los archivos al repositorio:

Hacemos el commit para mandar los archivos agregados y el mensaje con la descripción del commit con el parámetro -m.

Con esto tenemos el repositorio listo, pero hay un detalle, este repositorio no lo podemos clonar, para ellos necesitamos un repositorio conocido como “repositorio bare”, este es el que nos va a permitir hacer esto, y se crea a partir del repositorio que acabamos de inicialzar, entonces con el repositorio recien creado ejecutamos:

El repositorio proyecto_prueba.git lo creamos en la raiz del servidor, además es buena practica que el repositorio bare tenga la terminación “.git” para identificarlo más facilmente, si exploramos esta carpeta veremos archivos y carpetas como: branches, hooks, info, objects. Más adelante haremos uso de una de estas carpetas para poder identificar los cambios que se hagan en el repositorio.

Con esto finalizamos la creación del repositorio, podremos clonarlo desde cualquier equipo cliente en un entorno de desarrollo como Eclipse o NetBeans, internamente estos IDE´s ejecutan el comando:

Muchas veces cuando se trabajo en un ambiente web, se requiere que los cambios hechos en el repositorio también se vean reflejados en el servidor donde se encuentra el proyecto en la www, para ello hay que clonar el repositorio bare en la www e indicar en los hooks del repositorio bare que cuando haya cambios los replique al repositorio que se encuentra en la www.

Para ello debemos clonar el repositorio bare en nuestra carpeta www, pero antes vamos a borrar la carpeta original donde inicializamos nuestro primer repositorio del cual generamos el bare.

Los parámetros -rf son para que el borrado sea recursivo y la “f” para forzarlo.

Ahora si clonamos el repositorio en la www:

El siguiente paso es detectar los cambios que se hacen en el repositorio bare para mandarlos al nuevo repositorio que esta en la www, lo que se tiene que hacer es ir a la carpeta del repositorio proyecto_prueba.git y dentro hay una carpeta llamada hooks, en esa carpeta vamos a crear un archivo que se llamara post-update:

Si no tienes nano lo puedes instalar con la instrucción:

Escribe el siguiente contenido en el archivo post-update:

Una breve explicación del archivo, se declara una constante WEB_DIR con la ruta del proyecto en la www, GIT_DIR ahora hará referencia a esta carpeta, pushd nos coloca sobre el directorio del repositorio y se hace el pull para bajar los últimos cambios del repositorio bare, al finalizar quitamos de la pila el $WEB_DIR del pushd anterior.

Guardamos el archivo “control+x” si estás en windows y asignamos permisos de ejecución al archivo:

Con estos pasos se deberían reflejar los cambios cada vez que se hacen modificaciones en el repositorio bare, el script post-update se ejecutara actualizando los archivos en el repositorio que esta en la www, así las personas que tengan el repositorio clonado en cada una de sus máquinas cuando manden sus cambios al repositorio con push también el repositorio que se encuentra en la www será actualizado.

Leave a Comment

Instalación de PHP, MySQL y Git en Centos 6.x

Instalación PHP

Para instalar PHP en Centos sólo es necesario ejecutar el siguiente comando:

Una vez instalado reiniciamos el servicio HTTPD:

 

Instalación MySQL

Ahora para instalar el servidor MySQL ejecutamos lo siguiente:

Iniciamos el servicio de MySQL:

Finalmente utilizamos este comando para establecer las opciones de seguridad de Mysql como asignar contraseña al root entre otras cosas:

 

Acceso Remoto a MySQL

Hay un detalle cuando instalamos MySQL en el servidor, no vamos a poder conectarnos de forma remota, habrá que modificar los permisos del usuario con el que nos conectemos, pondré el ejemplo si quisiera conectarme con el usuario root (lo recomendable es crear un usuario nuevo con esos permisos y asignar las bases de datos a las que tiene acceso), lo haríamos de la siguiente forma en el servidor:

Editamos el archivo de configuración de MySQL llamado my.cnf, lo encontramos por lo general en /etc/mysql/, si no sabes donde esta, búscalo con el siguiente comando linux:

Vamos a editar el archivo con el comando nano o vim, buscamos la línea de bind-address y skip-nerworking y las comentamos:

Reiniciamos MySQL:

Iniciamos el modo consola de MySQL

Dentro de la consola de MYSQL dar permisos de acceso remoto al usuario root con la siguiente consulta:

Sustituir la palabra PASSWORD con su contraseña actual para ese usuario.

Y hacemos un FLUSH para que los privilegios del usuario sean actualizados:

Más detalles en la siguiente liga: http://stackoverflow.com/questions/23733734/how-to-enable-remote-access-of-mysql-in-centos

 

Instalación GIT

Por último para instalar Git ejecutamos el siguiente comando:

Leave a Comment

Hola Mundo

Después de mucho pensarlo decidí reiniciar mi blog en un nuevo dominio, antes los tenía en blogspot pero lo dejé olvidado hace muchos años, cosa que no se repetirá en este.

Y bueno, algunos se preguntarán que voy a hacer con este blog; escribiré sobre cosas que me apasionan en la vida como la música, video juegos, desarrollo de software, comida, deporte, etc., son bastantes cosas, ¿no?, espero abarcar todos estos temas, y que sea de su agrado.

Les mando un gran saludo :-)

 

Leave a Comment