Node.js me tiene impresionado. Es realmente poderoso el enfoque de la plataforma, todo lo que se puede y podría lograr con ella.
Creo que herramientas como esta, simples y poderosas, terminarán por desplazar muchas vacas sagradas, o al menos quitarán cuotas importantes de mercado. He estado investigando quiénes están detrás de la plataforma, o al menos utilizándola, y resulta increíble la cantidad de empresas importantes, entre ellas Yahoo! y Linkedin.
Claro, y es que no hace falta darle demasiadas vueltas a la plataforma para darse cuenta de lo poderoso que puede resultar algo que interpreta el lenguaje de programación más ejecutado (cuentan todos los navegadores del mundo!) y levanta servidores http o tcp con tal facileza.
En lo que vi la plataforma pensé en una sóla cosa: computación distribuida. Pequeños servidores instanciándose en computadores bajo demanda, sin mayores complicaciones, ofreciendo servicios REST y a la vez aplicaciones web que los consumen, bien programados, sin perder de vista buenas prácticas y patrones, bases de datos replicadas, ¿NoSQL?, etc, etc...
A raíz de todas estas ideas y reflexiones, decidí comenzar un proyecto que espero sirva de guía a programadores que se hagan las mismas preguntas que yo. Si bien la plataforma es brutal y tiene un gran presente y futuro, veo que quedan muchas cosas abiertas.
En mi espacio de github conseguirán el proyecto. Aquí el enlace directo. Si alguno se entusiasma y quiere echarle un ojo al proyecto, le recomiendo leer la wiki que iré actualizando. Espero ir haciendo entradas en el blog en español, pero por razones de difusión mantendré el proyecto en inglés.
El proyecto aborda conceptos típicos en aplicaciones de medio tamaño, como: i18n, MVC, DAO, SOA, REST, testing (xUnit style) y documentation (Javadoc style).
lunes, 23 de julio de 2012
viernes, 25 de mayo de 2012
PageSpeed: Optimizando el rendimiento de páginas Web
Aquí les dejo una entrada reciente que hice en 21 RedES: PageSpeed: Optimizando el rendimiento de páginas Web
Varnish: Acelerador de aplicaciones Web
Aquí les dejo una entrada reciente que hice en 21 RedES: Varnish: Acelerador de aplicaciones Web
domingo, 20 de mayo de 2012
Caché altenativa de PHP (APC)
Aquí les dejo una entrada reciente que hice en 21redES: Caché altenativa de PHP (APC)
Espero la disfruten,
Espero la disfruten,
sábado, 12 de mayo de 2012
Extracción de Requerimientos
Este es un artículo que publiqué en el blog de 21redES que mantengo con unos panas... Extracción de Requerimientos
jueves, 19 de enero de 2012
Algunos tips para gestionar mercurial-server
Agregando usuarios
Para agregar usuarios a una instalación de mercurial-server, basta con agregar la clave pública de la máquina -desde donde se conectará el usuario- al repo hgadmin.
Para generar la clave pública puede ejecutar los siguientes comandos:
Obtenida la clave pública del usuario, deberá pegarla dentro de la carpeta keys/users/ o keys/root/ del repo hgadmin, dependiendo de si quiere que el nuevo usuario sea "ordinario" o "admin", respectivamente. Los admin pueden hacer clone del repo hgadmin (modificar usuarios).
IMPORTANTE: Recuerde que la manera de modificar el repo hgadmin es clonarlo, modificarlo y empujar (push) los cambios al repo principal. NO MODIFIQUE DIRECTAMENTE SOBRE EL SERVIDOR!. Puede seguir los siguientes pasos:
En el momento en que empuje los cambios al repo se agregará automáticamente la nueva clave pública al archivo ~hg/.ssh/authorized_keys, verifíquelo.
Creando un repositorio remoto para compartir entre diferentes usuarios
Debe crear el proyecto en el servidor y luego clonarlo en la máquina donde desee modificar el repositorio. Para ello puede ejecutar los siguientes comandos:
Del lado del servidor
IMPORTANTE: Dar todos los permisos al usuario dueño del proceso "mercurial-server", en este ejemplo: hg
Del lado del cliente
Listo, nuevo repo creado y preparado para ser utilizado!
Para agregar usuarios a una instalación de mercurial-server, basta con agregar la clave pública de la máquina -desde donde se conectará el usuario- al repo hgadmin.
Para generar la clave pública puede ejecutar los siguientes comandos:
$ ssh-keygen -t rsa $ cat ~/.ssh/id_rsa.pub
Obtenida la clave pública del usuario, deberá pegarla dentro de la carpeta keys/users/ o keys/root/ del repo hgadmin, dependiendo de si quiere que el nuevo usuario sea "ordinario" o "admin", respectivamente. Los admin pueden hacer clone del repo hgadmin (modificar usuarios).
IMPORTANTE: Recuerde que la manera de modificar el repo hgadmin es clonarlo, modificarlo y empujar (push) los cambios al repo principal. NO MODIFIQUE DIRECTAMENTE SOBRE EL SERVIDOR!. Puede seguir los siguientes pasos:
$ mkdir hgadmin-tmp && cd hgadmin-tmp $ hg clone ~hg/repos/hgadmin . $ mkdir keys/users/newuser $ cp ~/newuserkey keys/users/newuser $ hg add * $ hg ci -m "Added newuser to repo" $ hg push
En el momento en que empuje los cambios al repo se agregará automáticamente la nueva clave pública al archivo ~hg/.ssh/authorized_keys, verifíquelo.
Creando un repositorio remoto para compartir entre diferentes usuarios
Debe crear el proyecto en el servidor y luego clonarlo en la máquina donde desee modificar el repositorio. Para ello puede ejecutar los siguientes comandos:
Del lado del servidor
$ cd ~hg/repos/ $ mkdir newrepo && cd newrepo $ hg init $ cd .. $ chown -R hg.hg newrepo
IMPORTANTE: Dar todos los permisos al usuario dueño del proceso "mercurial-server", en este ejemplo: hg
Del lado del cliente
$ mkdir newrepo && cd newrepo $ hg clone ssh://hg@hg.mydomain.com/repos/newrepo .
Listo, nuevo repo creado y preparado para ser utilizado!
lunes, 5 de diciembre de 2011
Servicios REST con Jersey y Ajax
Esta semana estuve de cursos en Indra Ciudad Real, por cierto, un grupo majísimo/panísima.
Hicimos un ejercicio de servicios REST con Java, Jersey, e invocación de estos con Ajax (una parte Prototype y otra jQuery) que no podía dejar pasar por alto. Utilizamos Eclipse como IDE, Derby como RDBMS y Glassfish como Servidor de Aplicaciones.
Les dejo los pasos en este artículo. El código completo lo pueden conseguir aquí.
Implementamos un CRUD para una entidad llamada Persona. Aquí les dejo la estructura de la BD.
El código incluye tres partes y de esa forma espero abordar este artículo, a saber: DAO, Servicio REST e Interfaz Gráfica de Usuario (GUI).
El DAO
Realmente aquí no hubo demasiada sofisticación, como el curso iba de Web 2.0, hicimos el menor énfasis en acceso a datos. Les dejo el pequeño DAO que hicimos para trabajar con la BD.
La interfaz, pensando en el uso futuro de IoC, la pueden conseguir aquí.
La clase concreta, aquí.
Si se fijan, la interfaz la implementamos siguiendo el estándar de nombrado de C# que me parece más fácil de seguir, es decir, agregamos una "I" al inicio de la interfaz. El resto es la implementación de la clase concreta. En caso de utilizar IoC, por ejemplo con Spring, la inicialización y destrucción de la conexión en el constructor y método finalize debería desaparecer. De hecho, como está ahora no me gusta mucho, pero lo hice de esta forma para mantener el código lo más simple posible.
La clase Persona es simplemente un POJO con todos los campos de la entidad: id, nombre y apellido. El código aquí.
El Servicio REST
El servicio REST lo implementamos con Jersey, que facilita bastante el código.
Para configurar Jersey se debe agregar como filtro en el Descriptor de Despliegue (web.xml), por supuesto después de haber descargado los JAR (en el proyecto dentro de WEB-INF/lib). Clic aquí para ver el web.xml.
Una vez configurado Jersey, implementamos la API, el código aquí. Cosas importantes que destacar:
La API se puede probar utilizando cURL. A continuación los comandos de prueba que utilizamos, que además ayudan a describir el funcionamiento de los servicios:
La GUI
La GUI la hicimos en HTML puro y utiliza una librería JS que separa las llamadas Ajax de la lógica de presentación.
El HTML lo pueden conseguir aqúi y la librería de utilidades (donde se manejan los eventos Ajax, con Prototype y jQuery) aquí. Cosas importantes que destacar:
Finalmente para ejecutar: http://localhost:8080/TiendaVirtual/persona.html
Espero este artículo sea de utilidad, sobre todo por el uso de Jersey y la invocación de la API vía Ajax. No conseguí demasiada información precisa y ejemplos que funcionaran desde el inicio. Inicialmente me apoyé bastante en el blog de Lars Vogel, aquí el ejemplo.
Hicimos un ejercicio de servicios REST con Java, Jersey, e invocación de estos con Ajax (una parte Prototype y otra jQuery) que no podía dejar pasar por alto. Utilizamos Eclipse como IDE, Derby como RDBMS y Glassfish como Servidor de Aplicaciones.
Les dejo los pasos en este artículo. El código completo lo pueden conseguir aquí.
Implementamos un CRUD para una entidad llamada Persona. Aquí les dejo la estructura de la BD.
El código incluye tres partes y de esa forma espero abordar este artículo, a saber: DAO, Servicio REST e Interfaz Gráfica de Usuario (GUI).
El DAO
Realmente aquí no hubo demasiada sofisticación, como el curso iba de Web 2.0, hicimos el menor énfasis en acceso a datos. Les dejo el pequeño DAO que hicimos para trabajar con la BD.
La interfaz, pensando en el uso futuro de IoC, la pueden conseguir aquí.
La clase concreta, aquí.
Si se fijan, la interfaz la implementamos siguiendo el estándar de nombrado de C# que me parece más fácil de seguir, es decir, agregamos una "I" al inicio de la interfaz. El resto es la implementación de la clase concreta. En caso de utilizar IoC, por ejemplo con Spring, la inicialización y destrucción de la conexión en el constructor y método finalize debería desaparecer. De hecho, como está ahora no me gusta mucho, pero lo hice de esta forma para mantener el código lo más simple posible.
La clase Persona es simplemente un POJO con todos los campos de la entidad: id, nombre y apellido. El código aquí.
El Servicio REST
El servicio REST lo implementamos con Jersey, que facilita bastante el código.
Para configurar Jersey se debe agregar como filtro en el Descriptor de Despliegue (web.xml), por supuesto después de haber descargado los JAR (en el proyecto dentro de WEB-INF/lib). Clic aquí para ver el web.xml.
Una vez configurado Jersey, implementamos la API, el código aquí. Cosas importantes que destacar:
- Los métodos de consulta (GET) producen JSON.
- Los métodos de modificación (PUT, POST y DELETE) producen HTML, success y error.
- El método POST está implementado para hacer POST y DELETE por restricciones impuestas por la librería Prototype (ver aquí), para peticiones diferentes de GET y POST; ésta hace peticiones POST especificando el método en la petición a través del parámetro _method. Se puede modificar la librería para no hacer esto, pero me parece más robusto y escalable hacerlo del lado del servicio REST.
- Para que pudiesen "convivir" Prototype y jQuery se tuvo que activar el modo de no conflictos de jQuery, ver aquí.
La API se puede probar utilizando cURL. A continuación los comandos de prueba que utilizamos, que además ayudan a describir el funcionamiento de los servicios:
$ echo "GET todos"; curl -X GET -H "Content-type:text/json" -v http://localhost:8080/TiendaVirtual/rest/persona $ echo "GET uno"; curl -X GET -H "Content-type:text/json" -v http://localhost:8080/TiendaVirtual/rest/persona/1 $ echo "PUT"; curl -X PUT -H "Content-type:application/x-www-form-urlencoded" -d "nombre=Cambiar" -d "apellido=Apellido" -v http://localhost:8080/TiendaVirtual/rest/persona $ echo "POST"; curl -X POST -H "Content-type:application/x-www-form-urlencoded" -d "id=1" -d "nombre=Cambiar" -d "apellido=Apellido" -v http://localhost:8080/TiendaVirtual/rest/persona $ echo "DELETE"; curl -X DELETE -H "Content-type:application/x-www-form-urlencoded" -d "id=1" -v http://localhost:8080/TiendaVirtual/rest/persona
La GUI
La GUI la hicimos en HTML puro y utiliza una librería JS que separa las llamadas Ajax de la lógica de presentación.
El HTML lo pueden conseguir aqúi y la librería de utilidades (donde se manejan los eventos Ajax, con Prototype y jQuery) aquí. Cosas importantes que destacar:
- Las llamadas de listar son síncronas, por lo que su manejo es diferente al del resto.
- Las llamadas de modificación (agregar, modificar, eliminar) son asíncronas y funcionan con callback sobre listar.
- Debido a que el código es de en un ejemplo para un curso, donde Javascript era uno de los temas, el listado se genera con DOM también (lamentablemente sólo funciona en Firefox, o al menos con Gecko como motor). Está deshabilitado por defecto, pero se puede activar con la variable TRABAJAR_DOM
Finalmente para ejecutar: http://localhost:8080/TiendaVirtual/persona.html
Espero este artículo sea de utilidad, sobre todo por el uso de Jersey y la invocación de la API vía Ajax. No conseguí demasiada información precisa y ejemplos que funcionaran desde el inicio. Inicialmente me apoyé bastante en el blog de Lars Vogel, aquí el ejemplo.
Suscribirse a:
Entradas (Atom)