Blog personal de Pablo Morales

Con la gente del grupo Web & Beer armamos un checklist de los puntos importantes con los que debería cumplir una web antes de salir a producción. Estos puntos que se van a mencionar son importante en cualquier desarrollo web, y contempla la mayoría de los problemas. Es importante que chequeen estos puntos en sus desarrollos actuales, y traten de evitar tener problemas con los nuevos sistemas que vendrán.

- Validar formularios y entrada de datos desde el lado del cliente y desde el lado del servidor.
Este punto es uno de los mas importantes, muchos programadores validan los datos desde uno de los dos lados, o del cliente o del servidor. La idea es que siempre se validen los dos. Se podría obviar la validación del lado del cliente, pero nunca del lado del servidor, nosotros tenemos que saber que datos y de que tipo son los que entran en nuestro sistema. Para eso tenemos que comprobar si es alfanumérico, si es numérico, si es un mail, etc. No hay conformarse solo con validar los datos desde javascripts, ya que esto puede ser filtrado. La validacion del lado del cliente sirve para que no hagamos esperar al usuario mientras se procesan los datos en el servidor, sino escribió un dato en un campo obligatorio no lo dejamos enviar el formulario. Con un simple plugin de firefox puedo cambiar los datos que se envían por post agregando lo necesario para hacer un sql injection. Hay que chquear que la cantidad de caracteres que pueda ingresar sea igual o menor que la capacidad del campo que va a guardar este dato en la base de datos.

- Validar Claves y nombre de usuarios de los usuarios del sistema.
Los usuarios no pueden tener claves de 2 o 3 letras, tienen que tener claves seguras o por lo menos lo mayor posible, deberíamos asegurarnos que una clave sea de por lo menos 5 caracteres y no sea igual que el usuario, o no permitir secuencias de números o 5 datos repetidos como 55555, no estaría mal validar que los usuarios no ingresen claves que esten dentro de las claves mas comunes, como qwerty, 123456, dios!, miclave, password, etc. Esto es para darle cierta seguridad a nuestro sistemas y evitar casos de phishing. Otra cosa que veo muy seguido es que muchos validan que la clave sea alfanumérica, pero si quiero poner una clave del estilo ph1s#u!r no podría. Se debería permitir este tipo de claves ya que es mucho mas segura que una alfanumérica. Lo mismo con los usuarios, minimamente tienen que tener 5 caracteres y en lo posible alfanuméricos. Estoy viendo cada vez mas seguido web que usan los mails como nombre de usuario.

- Encoding.
Este tema es muy problematico, quien no ha tenido problemas con este punto?. Tenemos que ser homogeneos y elegir siempre el mismo encodign, el ideal es utf-8 ya que es con el que trabajan los servidores unix donde estarán alojados la mayoría de los sistemas web. Hay que revisar que los archivos que usemos, y las cabeceras de los xhtml que estén en utf-8, también tenemos que asegurarnos que nuestra base de datos este guardando los datos en utf-8.

- Paginas de errores.
Cuando alguien intenta acceder a una url de nuestro dominio que no corresponde a ninguna pagina activa, deberíamos mostrar un error personalizado de 404 y agregar links que lo dirijan a la home de nuestra web o a un buscador de contenidos.

- Cross Browser.
El gran dolor de cabeza de cualquier desarrollador. Esto es algo muy difícil de lograr ya que muchos navegadores implementan su propio estándar y no siguen el de la w3c, digase ie6, ie7, ie8. Pero también hay que saber que los navegadores interpretan algunas cosas de forma diferente por eso es ideal probarlo en distintos browsers para que no se rompa el diseño.

Es probable que tengas que usar Css Hack para que tu sitio sea cross browser

Puedes usar Browsershots para ver una screenshot de tu web en diferentes navegadores

- Evitar archivos de configuracion dentro del webroot.

Este es otro de los puntos de seguridad grave que podemos llegar a tener.  Los archivos de configuracion que tiene los datos de acceso a la base de datos o accesos a web services tienen que estar fuera del webroot de nuestro sitio.

Estos son aspectos generales, pero ahora vamos a hablar de algunos puntos en cuanto a la accesibilidad y el SEO.

- Sitemap.
Es importante que si quieren que su sitio sea indexado por los buscadores tengas un sitemap, y den de alta el mismo en estos buscadores. Dice la leyenda que si tu sitemap tiene el nombre sitemap.xml, google lo indexa mejor que si fuese sitemap.php o cualquier otro nombre.

Wikipedia

- Imagenes.
Las imagenes son un ingreso de visitas importantes si se usan adecuadamentes. Hay dos puntos necesario para manejar las imagenes y conseguir visitas con ellas, tener un alt con la descripción de la imagen, y que el nombre del archivo haga una descripción del mismo, por ejemplo cristina_kirchner_en_la_rosada.jpg, si se fijan cuando ustedes buscan una imagen en Google Images se van a dar cuenta que usan estos dos criterios para la búsqueda.

- Paginas internas

Cada pagina que tenga nuestro sistema debería tener la descripción de esta en la url. Esto se llama clean urls, y se ve mucho en los cms, que nos permiten que el acceso a una pagina en vez de ser http://dominio.com/noticia/index.php?newsId=342 se convierta en http://dominio.com/noticia/newsId/342/ esto es mas claro que lo que vimos en el ejemplo anterior, perotambién podríamos mejorarlo mucho mas si nuestra url luciera así http://dominio.com/news/342_cristina_aumenta_sueldo_a_los_jubilados.html. Google indexa mejor los contenidos donde su url describe el contenido que va a mostrar. Esto es facil de solucionar agregando alias a nuestras paginas, o creando alguna regla de rewrite que maneje este problema, los que usen ZF pueden usar Zend_Route , pero siempre seria mas optimo que lo hagan desde .htaccess.

Si tu sitio tiene bajo control estos puntos te invito que revises los otros puntos creados por la gente de Web & Beer.

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/ )

Me decidi probar la nueva estella de Zend, Zend Server. Basicamente es un entorno de administracion para servidores web, las caracteristicas principales son la administracion de los archivos de configuracion, monitoreo de nuestros logs,monitoreo de aplicaciones, y promete un entorno seguro. Todo esto dentro de una interface Web que de hecho es bastante agradable.

Tambien viene integrado con Zend Core, asi que tambien tenemos Apache, php 5.x. Ya trae incluido un paquete con Zend Optimizer +, Zend Debugger, Zend Data Cache, Zend Guard Load, Zend Java Bridge, Zend Acelerator. Un administrador de extensiones, y algun que oto dellate mas. La verdad que no vale la pena pagar por este producto, creo que con un grupo de aplicaciones open source se puede conseguir esto y seguramente mucho mas. Por ahora voy a seguir usandolo hasta que se acabe la licencia de prueba. En estos treinta dias voy a tratar de sacarle mas provecho para entende porque pagar lo que sale la licencia. Quizas el soporte lo valga, pero pagar soporte para esto?. La instalacion la hice a partir del tar.gz, tengo Arch linux, asi que para hacerla facil preferi instalarlo a mano. Despues de bajarme el tar.gz, lo descomprimi en la carpeta /opt/. Tuve que crear un symlink de la carpeta /var/log/ y de /var/www/html para que se acople facilmente a la estructura de Zend Server. Despues cree los virtual host dentro de /opt/zend/apache2/conf/vhost/. Siempre uso esta carpeta para tener cada dominio/Subdominio con su propio archivo de configuracion, esto me facilita mucho la organizacion. Despues restarteo el servicio de apache, y ya tengo montado mi servidor web con Zend Server, hasta que tenga que pagar por esto

Este ultimo tiempo estuve bastante ocupado cerrando algunos proyectos por eso la falta de post en el blog.

El proyecto que mas me ocupo mi tiempo es Personal Book que desarrollamos en Easytech. Basicamente PBOOK es un sistema de ventas de libro online, con el agregado que podes agregarle una dedicatoria a cualquier libro que compres. Atras de este proyecto esta una de las empresas grandes de Chile, Dimacofi.

Despues de viajar a Chile para ultimar detalles sobre el cierre del proyecto, hoy por fin se hace publica la pagina para que cualquier Chileno (por ahora), pueda comprar libros de forma online, sin la necesidad de depender de un stock y sin moverse de su casa.

Para el proyecto se decidio usar Drupal para el manejo del sitio, y los contenidos  y Zend Framework para todo el resto. Se uso 2 motores de base de datos, mysql para Drupal, y Oracle XE para el resto.

El sitio cuenta con varios subsistemas, que se comunican entre si a traves de colas de ActiveMQ, un sistema de colas de la gente de Apache Software Foundation, el cual nos resulto excelente para esta funcion.

Si tienen la oportunidad naveguen el sitio y vean como pueden trabajar en perfecta armonia Zend Framework y Drupal .

site: www.personalbook.cl

En los casos comunes de autenticaciones con Zend_Auth nosotros le pasamos un usuario y una clave, pero hay veces que necesitamos que valide por mas datos.

Una autenticacion comun seria la siguiente.

Pero que pasa si ademas necesitamos validar si el usuario esta o no activo en el sistema, o si no esta suspendido temporalmente?

Nososotros podemos pasarle un parametro extra a Zend_Auth_Adapter_DbTable, para que filtre por mas datos.

Por ejemplo el caso anterior, quedaria de la siguiente manera si ademas nosotros queremos saber si el campo status = ‘A’

De esta forma, cada vez que intentemos loguearnos nos va a encriptar la clave con la funcion MD5, y preguntar si status =’A’.

Si ustedes no necesitan encriptar la clave pueden usar directamente el signo de pregunta sin la funcion MD5, tambien pueden agregar mas funcionalidades, para mas detalle mirar la documentacion oficial

En el administrador del blogzf tenemos un ejemplo de implementacion de este sistema.

Gnome SSH Tunnel Manager es una heramienta GUI, para gestionar la adminsitracion de tuneles en nuestro sistema. Esto es para evitar abrir una consola por cada tunel que necesitemos.

La herramienta nos permite gestionar varios perfiles, yes muy facil de usar.

Para los que usamos los tuneles constantemente, esta herramienta se vuelve indispensable.

Para Instalarlo en Fedora Core 10 solo basta con hacer

$ sudo yum install gstm

Para debian y ubuntu supongo que sera algo parecido, pero con apt-get, sino se pueden bajar el fuente de sourceforge

Es muy interesante ver que en la actualidad la mayoría de las empresas serias de desarrollo web se están volcando al uso de framework en sus desarrollos. Esto tiene una ventajas para el empleador, el empleado, y el cliente.

El empleado esta aprendiendo a desarrollar con un framework y no solo un framework sino una estructura de trabajo la cual le sirve para agregar en su currículum, el empleador consigue ahorrarse tiempo en desarrollos y en controles, y el cliente obtiene en menor tiempo y con una mejor calidad sus productos.

La explicacion es muy simple, los frameworks web actuales no son desarrollados por un equipo reducido de personas, sino que están continuamente creciendo gracias al apoyo de las comunidades virtuales.

Estos Frameworks, generalmente son open source, y están desarrollados y apoyado por grandes corporaciones, por ejemplo el caso de Symfony que tiene como Padrino a Yahoo,  que  utiliza este framework en la mayoría de sus desarrollos con PHP, como es el caso de Delicius, Yahoo Answerr y Yahoo Bookmarks. Zend Framework es apoyado por la creciente Zend Company que son los creadores del lenguaje PHP.

Estos dos son los grandes frameworks de PHP, pero hay muchos mas, muchisimos mas. La elección de cual les conviene mas, tiene que ser evaluada por la empresa, teniendo en cuenta quien le da mas o mejor de estos frameworks.

El caso de Akelos es bastante interesante, ya que su idea es construir aplicaciones en PHP al estilo Ruby On Rails, este ultimo también un gran framework y muy popular debido a la facilidad de uso y a su código bastante simple.

En la balanza aparecen muchos factores, y cada factor es importante. Yo elijo Zend Framework porque me da una flexibilidad sin atarme a ningun mecanismo. Puedo desarrollar si quiero sin implementar MVC, o incluir Zend Framework dentro de Wordpress para manejar los plugins, como es el caso de este blog.

Lo mas importante, es que una empresa no tiene que preocuparse como hacer una librería para la conexion a la base de datos, o para crear a un web service, o como manejar templates dentro de su sistema, como validar formularios, etc. Y no tiene que preocuparse no porque no lo tenga que hacer, sino porque estos frameworks le brindan una solución, les dice como crear formularios, validarlos tanto del lado del cliente como del servidor, manejar distintos templates, manejar base de datos, etc, etc,etc. Y no solo soluciones del tipo “necesito conectarme a una base de la mejor manera posible”, es lo que no simplifica un framework, sino que nos brinda todo una forma de trabajo como es la division por capas MVC (Model View Controller), sino una estructura de directorios prolija, y clara. Sobre todo que hace fácil y organizable cualquier modulo o aplicacion.Ademas como el caso de Zend Framework, nos da una recomendacion de como escribir nuestro codigo, y trabajar en grupo.

Otro de los puntos a favor de un framework, es que es gratis. La empresa no tiene que poner un centavo y obtiene cientos o miles de lineas de código para que use sin ningún limite sin nada a cambio.

Recuerdo mucho tiempo haber rediseñado clases para la conexion a la abase de datos, o generar capas de abstracción para hacer ciertas funcionalidades, como el manejo de formularios. Y todo ese tiempo perdido si bien tengo que reconocer que aprendí bastante con la prueba y error (hubieron muchos errores lamentablemente), mis desarrollos hubiesen sido mejores y en menos tiempo aprovechando estos recursos.

Como dije en un post anterior de este blog, el costo de aprendizaje es mínimo, ya que no se tarda lo mismo generando código de cero, que aprender a usar un código existente que cumple lo que nosotros necesitamos.

Sobre el lenguaje de programacion a elegir para los desarrollos web, también depende de muchos factores, uno de los puntos a tener en cuenta, es  la cantidad de programadores que hay en el mercado, y lo que cobran estos programadores. Viendo estos factores PHP parece la mejor alternativa, pero Python con Django esta pisando fuerte y mas solido de lo que hizo Ruby On Rails hasta ahora.

Links Interesantes

Akelos

Zend Framework

Symfony

CakePHP

Ruby On Rails

Django

Codeigniter

Plugins.

En ZF podemos utilizar plugins. Estos plugins se van a ejecutar en determinado momento, como puede ser el Predispatch o el PostDispatch. En muchos proyectos con ZF se utiliza una capa superior para los controllers para obligar al sistema que ejecute siempre la capa superior donde en esta capa podemos tener varias funcionalidades comunes para todos los controllers.

Esto no es una mala decisión, de hecho en nuestro blog tenemos un controller genérico. Pero también podemos hacer uso de los plugins, estos además de servirnos posteriormente para extender la funcionalidades, como puede ser el agregado de un contador de visitas, o cualquier funcionalidad extra que queramos darle al sistema sin necesidad de tocar el código existente, solo extendiendo el que hay. Como es el caso de los plugins en Wordpress, también podemos tener algunos plugins genéricos, para que procesen acciones genéricas, como puede ser el caso de configurar la vista, el layout, o la base de datos, el manejo de sesiones, etc.

En nuestro blog actualmente hay varios plugins, y cada uno bien separado su funcionalidad, hay un plugin extra especialmente para el admin, el cual maneja la seguridad (por ahora solo eso), pero también tenemos un plugin para instanciar la vista, y decirle de donde sacar el menú, y todo lo necesario para renderear la vista, además de un plugin para el manejo de layouts, otro plugin para la base de datos. Y además de esto una capa de abstracción superior en los controllers.

El uso de plugins en Zend Framework, es muy fácil y se cargan desde el bootstrap, cuando agregamos los controllers y antes de hacer dispatch, le decimos que plugins cargar.

Como se puede apreciar en el código de nuestro bootstrap, cargamos 4 plugins. Estos plugins los ubicamos en la carpeta library/Blogzf/Controller/Plugin, esta ruta es para tener una hegemonía con la estructura de directorios de ZF.

Estos plugins son muy fácil de programar. Cada clase implementa una interfaz genérica que cada método corresponde a una instancia de ejecución de nuestra pagina. Tenemos un método para preDispatch, otro para el postdispatch, que cada vez que le toca ejecutarse a estos metodos se llama a los plugins, antes del controller. Nuestros plugins extienden de la clase padre Zend_Controller_Plugin_Abstract . Un plugin normal con dos metodos como son PreDispatch, PostDispatch, quedaría como el siguiente.

Si necesitamos que algun dato persista, podemos usar Zend_Registry

Como se daran cuenta, estos plugins son muy facil. No requieren mucho mas que esto.

Si van al codigo de blogzf van a encontrar el codigo de los otros 4 plugins.

Mas informacion

Hace un tiempo desde que probe fluxbox que estoy bastante maniatico con lo extremadamente ligth, de hecho ahora mientras escribo esto estoy tomando una Villa del sur levite (cuack).

Mp3Blaster es un reproductor de mp3 que funciona desde la linea de comando. Tiene una interfaz muy diferente al Winamp y tambien muy diferente la cantidad de recursos que consume, pero hacen lo mismo, reproducir nuestros MP3.

La instalacion como siempre en linux, FACIL. En ubuntu.
$ sudo aptitude install mp3blaster

En cualquier otra distro, hay .deb, y rpm dando vuelta por la red.

Sino se pueden bajar las fuentes desde la pagina de sourceforce de mp3blaster, y hacer el clasico ./configure && make && make install y listo.

Con mp3blaster vamos a poder crear playlist, y reproducir de forma liviana nustros Mp3. Si quieren consumir menos recursos haganlo desde una terminal xterm, y no las pesadas gnome-terminal y komander.

Estos dias me estuve debatiendo entre el uso o no de Zend_Dojo. Sinceramente siempre use Jquery, mootools y prototype, la verdad es que en un punto llegan a ser lo mismo, alguna aporta algo que la otra no, pero masomenos tienen el mismo fin, hacernos la vida mas facil, y este no fue el caso de Dojo, ultimamente estaba usando Zend_Dojo para un proyecto, y me costo bastante usarlo, y nunca llegue a aprovecharlo al maximo, termino escribiendo mucho codigo  y no me gusta los resultados que obtengo y tampoco me acostumbro a su sintaxis, tan diferente a la facilidad de mootools. Debido a esto y a una charla con scrammatte decidi usar mootools y no complicarme la vida con estas cosas que no aportan gran cosa. Asi que a partir de ahora vamos a usar Mootools en el blog que estamos desarrollando con Zend Framework, y nos olvidamos de Zend Dojo.

Una de las principales razones que desisti de Dojo fue cuando scramatte me mostro Mochaui, enseguida me atrajo esa interfaz tan agradable y practica. Estos dias voy a tratar de adaptar mochaui al Backoffice del blog.

Y no solo van a ver a Mochaui, tambien vamos a empezar a trabajar con otros componentes mas de mootools, como son fvalidator, mootab, porque no mooflow, despues vamos a analizar cual conviene o no implementar, por ahora solo sepan que vamos a trabajar con Mootools.