Actualmente una empresa no solo tiene una web institucional, sino que muchas veces ofrecen servicios a través de esta y/o manejan una intranet/extranet y esto genera que tenga muchas aplicaciones con diferentes sistemas de usuarios, e información duplicada.

Pero como estructurar una aplicacion donde van a convivir varios tipos de usuarios en una misma estructura sin generar conflic

tos ?.

Lo que voy a plantear en este articulo es una estructura genérica para un problema especifico.

El problema es la unión de todas o casi todas las aplicaciones de una empresa que presta servicios online donde se unifique el flujo de la información.

Una empresa que tienen 5 aplicaciones no necesariamente tiene que tener toda su información repartida en 5 base de datos diferenntes Pueden llegar a compartir la misma base, o tener una base donde se unifica cierta información compartida. O si,  tener diferentes bases para cada subsistema, pero compartir la información común a través de los mismos sistemas sin la necesidad de duplicar una interfaz para administrar esa informacion o peor aun duplicar información corriendo el riesgo de generar una inconsistencia de datos.

Recuerdo mis tiempos en la UCA donde cada departamento tenia aplicaciones diferentes, desarrolladas independientemente por diferentes personas o grupos, sin una integracion clara entre ellas. Estoy seguro que hasta el día de hoy los alumnos se deben quejar porque tienen que loguearse con diferentes usuarios y claves, para distintos servicios que supuestamente están alojados en el mismo lugar.

Pero este no es solo el problema de una institucion con la embergadura de una empresa con mas de 10000 empleados. Este problema puede ocurrir en cualquier ámbito, hasta en una pymes, donde cuenta con dos o tres sistemas que son independientes entre si.

Los sistemas o subsistemas pueden relacionarse de manera muy fácil, y esto generalmente va a requerir menos horas de desarrollo que aplicaciones totalmente independientes, teniendo en cuenta que siempre habrá que administrar módulos de forma independientes.

Tengo que volver a mencionar la posibilidad de un servidor de usuarios, pero no crean que por referirme a algo como un servidor, implique costo de hardware y mantenimiento, esto puede estar alojado en una pc cualquiera compartiendo espacio con el resto de los sistemas. Un servidor de usuarios me parece la implementación perfecta, porque cada sistema siempre va a tener independencia a través de su dominio, pero va a evitar el re ingreso de creación de usuarios, permisos, y logueos, para un usuario con acceso a varios de los subsistemas.

Voy a dar un ejemplo simple, un programador de la empresa Zeta, cuando ingresa a trabajar se loguea en el sistema de ticket de su empresa para ver que cosas están pendientes. Luego de terminadas, se loguea en el sistema de horas, para cargar las horas trabajadas durante el día, al final del día decide agregar una entrada al blog de la empresa explicando uno de los descubrimientos que hizo.

Esto genero que el usuario tenga que tener cuenta en los 3 sistemas con los que trabajo, y no solo tener una cuenta sino que además se tiene que loguear en las tres.

Esto por ahi si hablamos de un programador no es problema porque esta acostumbrado. Pero supongamos que es un cliente que tiene su sitio web de ventas de remeras, y necesita revisar en el panel de administración si están al día las ultimas promociones que publicito,  revisar el trafico de visitas o de ventas del mes en el sistema de estadísticas del sitio, después revisar si entraron nuevos productos al tracker para poder procesarlos y despacharlos. No solo eso después va a querer agregar un ticket al sistema de ticket de la empresa Zeta porque uno de los módulos necesita una funcionalidad nueva. Y otro vez se va a loguear en el sistema de horas, para saber si todavia cuenta con horas disponibles dentro de su paquete mensual o necesita comprar mas.

Ahora el tema es mas complicado porque el tedioso trabajo de loguearse en cada aplicacion no lo hace el empleado que no le llega a molestar, sino lo hace un ejecutivo o un comerciante que no necesariamente se tiene que acordar de sus 20 claves, para los diferentes sitios. O peor aun tiene que usar claves muy simples para no olvidárselas o una única clave repetida.

Y esto es lo que se ve de afuera, porque por dentro seguramente tengamos un sitio web desarrollado con drupal con su base de datos MySql, un sistema de estadísticas hecho con alguna herramienta de reportes, un sistema de tracking desarrollado por nosotros al igual que el sistema de horas, y  el Trac o Mantis para administrar ticket.

Todos estos sistemas con Base de datos diferentes y datos duplicados, cada uno con su sistema de administración, donde damos de alta a los usuarios y sus permisos.

Todo esto se puede simplicar de sobre manera con un sistema de usuarios integrados. En otro articulo ya mencionamos teóricamente como crear esto, quizás me inspire y suba algún código que haga esto para evitar que pierdan tiempo pensando como hacerlo.

Le doy una extremada importancia al tema usuarios porque lo veo con Clientes que se quejan de esa falta de integracion y se que es molesto para ellos y se podría solucionar de forma muy fácil. Pero también podemos ver el tema de reportes.

No necesariamente para generar reportes hay que duplicar los datos de otras bases, de hecho este ejercicio a veces consumo muchos recursos que no queremos desaprovechar. Podemos reutilizar la base en el mejor de los casos o buscar otras medidas.

Un punto interesante es  que nosotros podemos usar aplicaciones pre-armadas como Drupal, trac, PHP Report, etc  y con algunos ajustes adaptarlas a nuestro sistema de integracion de usuarios. Cada sistema implementa su propia forma de autenticación pero nosotros podemos tomarnos el trabajo de mirar 15 minutos para ver como funciona su sistema de loguin e integrarlo en nuestro servidor de usuarios. El caso de Drupal es mucho mas simple ya que cuenta con un webservice para administracion de usuarios entre ellos el login y logout.

Escribir esto medio ganas de armar el sistema de usuarios y compartirlo para que vean lo fácil que se puede integrar.

Otro punto a destacar es que podemos interconectar nuestros sistemas a través de webservices sin la necesidad de que compartan la misma conexion de base de datos. O el mismo servidor.

Espero ver mas sistemas integrados después de esto. Quizás algun dia, pueda entrar a mi pc, abrir el navegador loguearme en una pagina X y acceder a todas mis web autenticandome unicamente en la pagina X, quizas el openId logre esto. Veremos, mientras tanto voy a seguir usando el administrador de cuentas de firefox (cuidado que este guarda la clave de forma plain en el filesystem ).

PHP Report Maker ( http://www.hkvstore.com/phpreportmaker/ )
Drupal (http://drupal.org)
Mantis ( http://www.mantisbt.org/ )
Trac ( http://trac.edgewall.org/ )

Creando un blog desde cero.

Introduccion al proyecto.

La idea de este proyecto, es tratar de transmitir mis conocimientos sobre Zend Framework, y mostrar que es muy simple trabajar con el. Hace tiempo que llevo trabajando con este framework, y me facilita mucho el trabajo diario, y el trabajo en grupo. El blog posiblemente cuando se termine reemplaze a mi worpress, pero eso veremos mas  adelante como evoluciona el proyecto.

Cuando ustedes lean esto el blog va a estar bastante encaminado. Cada parte importante del desarrollo del blog voy a postearlo para que hagan comentarios, y el aprendizaje sea de apoco y no todo de golpe.

Subi el proyecto a google code, por cada corte importante del proyecto cree un tag, ese tag corresponde a un post especifco donde se explican los cambios y porque aplicamos tal o cual cosa.

Una vez el proyecto este terminado cualquiera tiene derecho a implementar este  blog que vamos a desarrollar aca es open source, y totalmente libre.

Manos a la obra

La gente que este leyendo este post, y no sepa nada de Zend Framework quizas les cueste un poco mas entenderlo porque hay conceptos que ya se hablaron en este blog, y no quiero repetirlos, si hay algo que no entienden pueden preguntarlo o googlearlo.

Lo primero que vamos a hacer es armar la estructura, que va a ser practicamente la misma que en el articulo que arme hace varias semanas, pero con algunos cambios, la carpeta apps, se va a llamar application, y la carpeta html sera webroot. Ademas vamos a mover la carpeta layout dentro de webroot.

Creando el virtual host.

# Blog para el proyecto

    ServerAdmin soporte@blogzf.com
    DocumentRoot /var/www/html/blogzf/webroot
    ServerName blogzf.dev
    
        Options FollowSymLinks
        AllowOverride All
    
    # Opciones de PHP
    php_value include_path .:/var/www/html/blogzf/webroot
    ErrorLog logs/blogzf-error.log
    CustomLog logs/blogzf-access.log common

Lo primero que vamos a crear es el bootstrap, que va a ser muy simple por ahora, y generar un layout basico que vamos a pedir prestado por ahi. La configuracion inicial va a quedar bastante basica. Vamos a crear un controller IndexController, un bootstrap index.php en la carpeta webroot, un .htaccess en la carpeta webroot tambien, y una carpeta con el nombre del layout, tambien vamos a agregar como external la libreria de Zend al proyecto. Si queres saber mas sobre como hacer esto, ya hay un post en el blog.

Para ir viendo como quedo esta parte del blog pueden bajarse los archivos del tag de esta version del proyecto haciendo.

$ svn import http://blogzf.googlecode.com/svn/tags/paso_1_layouts_y_configuracion/

Si crearon bien el virtual host, con solo escribir en el navegador http://blogzf.dev:8001/, tienen que ver algo parecido a esto.

Analizando el codigo.

Como primer punto voy a describir el bootstrap, basicamente este archivo tiene que tener una configuracion basica, para que pueda llamar al controller que correspondiente, y asi ejecutar la accion que requerimos.

Nuestro bootstrap es el siguiente.

 'colorpaper/colorpaper',
                'layoutPath' => 'layout/'
);
Zend_Layout::startMvc( $options );
/**
 * Setup controller
 */
$controller = Zend_Controller_Front::getInstance();
$controller->setParam( 'config', 'config.default.ini' )
    ->setControllerDirectory('../application/controller')
    ->throwExceptions(true)
    ->dispatch();

Hacemos unas configuraciones basicas, y despues que le decimos lo path del sistema, esto lo hacemos para que la comunicacion entre carpetas, sea mas sencilla. Algo importante que va a tener nuestro sistema de Blog, es que vamos a usar Zen_Loader::registerAutoload();, lo que hace este componente, es tratar de incluir el archivo que estes llamando, de esta forma si escribis bien el nombre de una clase, haciendo referencia al path, no necesitas hacer un required, o include. Si bien esto no es muy recomendable, porque cae un poco el rendimiento, tambien es cierto que es muy comodo , igual despues mas adelante, cuando optimizemos el sistema, vamos a arreglar un poco este problema.

Las siguientes lineas corresponden a la configuracion del layout, que en este caso agregamos un layout, que se llama colorpaper, y queremos que ejecute colorpaper.phtml.

Las ultimas lineas ejecutan el controller,

Si vemos el codigo vamos a ver que no hay nada raro en especial tenemos un controller (IndexController), con un preDispatch, y un indexAction. El preDispatch ejecutamos todo lo que necesitamos que se cargue antes de empezar a ejecutar la accion.

view->staticServer = 'http://blogzf.dev:8001/';
        $this->view->appServer = 'http://blogzf.dev:8001/';

        /**
         * Agrego el titulo de la pagina
         */
        $this->view->headTitle()->append('Blog con Zend Framework');
        /**
         * Agrego los css para esta pagina
         */
        $this->view->headLink()
            ->appendStylesheet( $this->view->staticServer . 'layout/colorpaper/css/jd.gallery.css' )
            ->appendStylesheet( $this->view->staticServer . 'layout/colorpaper/css/pink.css' )
            ->appendStylesheet( $this->view->staticServer . 'layout/colorpaper/css/style.css' );

En las primeras lineas del preDispatch, configuramos dos propiedades, que van a afectar a las vistas y al layout, uso dos tipos de variables para guardar el dominio, porque puede surgir que yo tenga por un lado un servidor para las imagenes, css, html y en otro servidor la aplicacion en si. Por ahora va a ser la misma, pero esto va a depender de ustedes.

Al hacer $this->view->staticServer, le estamos diciendo que cree una propiedad staticServer, esta es la forma en que ZF comunica desde un controller a una vista.

Despues tenemos la linea

$this->view->headTitle()->append('Blog con Zend Framework');

Aca estamos seteando el titulo del blog.

Y en la siguientes lineas, agregamos los css, que vamos a trabajar.

Cuando nosotros apendeamos, un titulo, los meta, los css, y los js, podemos mostrarlos desde la vista muy facilmente, usando los metodos que van a encontrar en el layout, que veremos mas adelante.

Por ahora nuestro indexAction no hace nada, lo mismo que la vista del mismo.

Como primera meta de este proyecto me propuse tomar un diseño modernoso, y adaptarlo al sistema de layout de Zend. Quise darle un aspecto atractivo, para que llame la atencion, y vean un poco el potencial del proyecto, que a veces el problema con excelentes proyectos de este tipo el problema es que no son atractivos y no llaman la atencion, este proyecto busca llamar la atencion, por eso este diseño. Lo unico que queria para esta parte es que me mostrara los datos de forma estatica pero minimante configurado el layout, y digo minimamete porque este layout va ir mutando a medida que avanze el proyecto.

Com hablamos antes en el preDispatch, apendeamos el title, y los css del layout, para mostrarlos desde nuestro layout, hicimos lo siguiente.

<!DOCTYPE HTML PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html dir=”ltr” xmlns=”http://www.w3.org/1999/xhtml” lang=”en-US”>
<head profile=”http://gmpg.org/xfn/11″>
<?= $this->headMeta() ?>
<?= $this->headTitle() ?>
<?= $this->headScript() ?>
<?= $this->headLink() ?>
</head>
<body>

Bueno por hoy es suficiente, para la proxima vamos a seguir separando el layout, para que nos quede mejor dividido, y vamos a usar archivos de configuracion, para guardar los datos de nuestros sistemas.

En esta parte del proyecto vimos los siguientes componentes.
* Zend_Controller
* Zend_Loader
* Zend_Layout

Una interesante publicidad de Zune, al final no me quedo muy claro lo que realmente querian expresar, Zune sera una mierda?

Zune Paint from Sibling Rivalry on Vimeo.

Hoy encontre un servicio bastante interesante, 123 People. La idea de este servicio es buscar gente, y su actividad por la red.

Lo interesante es que funciona, de hecho puse, pablo-morales.com, y aparece una foto mia, por suerte no encontre que aparezca mi mail ni mi telefeono, algo que seria un poco mas grave.

123 People busca los nombre por los grandes servicios, tal como linkedin, xing, picasa, google, etc.

Hay que tener cuidado con las cosas que hacemos por internet.

El sabado lei que para el lunes google Maps iba a mostrar las calles de Buenos Aires, pero a la hora que yo me fije no habia nada todavia. Hoy despues de leer una nota de Critica de la Argentina donde confirman que google maps ya soporta Buenos Aires decidi chequear nuevamente y con la la satisafaccion de poder ver esto.

Al parecer todavia no estan habilitados los servicios extras, pero ya anunciaron que se iran habilitando. Como el servicio para el Iphone tan esperado.

Estos dias estuve con el sitio caido porque contrate un VPS, y me mande un par de cagadas con los dns, y eso llevo a mucho tiempo de inactividad.

Lo importante es que ahora deje dreamhost. El motivo para mi fue basico, el servidor de mysql se caia cada dos por tres, esto me genero mas de un problema con mis clientes y algunos irreparables. La gente a veces no entiende que uno no tiene el servidor en el cuarto, y puede ir y meter mano cuando quiera y entiendo que eso sea dificil de comprender, por eso decidi cambiar. Ademas buscaba algo mas potente.

La gente de datawebhosting, me ofrecio un VPS (algo asi como un dedicado compartido, donde cada cuenta tiene control absoluto ), el servicio anda de 10 y la atencion mejor.

Con ayuda de la gente de datawebhosting, y de Gonzalo Gorosito, pude solucionar mis cagadas.

Voy a subir un post proximamente de las cosas que necesitamos para configurar nuestro propio Servidor, para que no les pase lo mismo.

Metodología Open de Gestión de Proyectos GEDPRO. Esta metodología tiene como objetivo dotar a los Project Managers de un método para gestionar todo el ciclo de vida de los proyectos.

Top 10 de expresiones regulares en PHP

Guia de estilo de codigo en Python

Herramientas y ejemplos para mejorar tu trabajo como freelance

Appcelerator PHP videos on Youtube. Una serie de videos con notas de lo que dejo la ZendCo 08.

Dojo 1.2 Final Release

20 Excellent AJAX Effects You Should Know

Y por ultimo un video de la web semantica