De esta manera evitas algunos errores:

1. La sobrecarga de peticiones a tus API´s, al servidor web y sobre todo rendimiento de proceso de CPU/memoria de tu equipo o servidor virtual.
2. Perdida de comunicación, que genera errores de conectividad para los procesos internos del código.
3. Incremento del tráfico en tus puertos de red.

Esto por listar las más obvias. Para este proyecto hay más desarrollo en los API´s de ActiveMQ bajo Java, donde puedes encontrar más información que en la librería echa para PHP.

Lamentablemente no hay muchas métricas en la documentación de stomp cli, pero encontré este reporte en el sitio de FuseSource.

Para que puede servir:

En nuestro del proyecto de FronteraEstates, qué es un portal inmobiliario para Latinos e Hispanos. Estamos coordinando algunos servicios externos de API´s de socialmedia.

Queremos integrar flickr, tweeter y un servicio para identidad digital como Facebook Connect y OpenSocial, todo lo estamos manejando de manera sincronizada, dado que asi lo tenemos en nuestras estaciones de trabajo. Pero a la hora de subirlas al servidor de desarrollo, tenemos ciertos servicios que varían por la naturaleza de nuestro hospedaje. Los resultados de la saturación de recursos se pueden identificar de la siguiente manera:

• Que se llene la memoria del proveedor (nuestro servidor).
• Negación de peticiones para conectarse.
• Que se sature la memoria del cliente.
• Acumulación de peticiones en el buffer.
• Que se agoten las respuestas a peticiones.

Las razones para que esto suceda pueden relacionarse a:

1. Red. En nuestra estación de trabajo recibimos el ancho de banda completa, pero dentro de un CPD hay problemas de conectividad, ya sea por latencia del cableado, problemas con puertos de switches/routers/VLAN´s y un largo etc. Problemas que ocurren diariamente dentro de un datacenter.
2. Hardware. Puede que la tarjeta de red del servidor pete o se dañe por cualquier razón. Que la memoria RAM se desgaste o simplemente que otro servicio necesite más memoria y nuestro servidor se vea afectada en su capacidad de procesamiento. Esto es normal por el uso del equipo y a saber si estamos en HW nuevo o de segunda mano. Tanto para nuestro servidor, como el equipo del cliente.
3. Programación. Uso incorrecto por parte de la lógica de programación de nuestra aplicación. Esto lo asumimos por que, como todos ustedes siempre estamos aprendiendo cosas nuevas e implementando lo que es viable para nuestro proyecto y no puedes evitar cometer errores.

Estos factores influyen en la cola de peticiones externas a nuestro servidor y si manejamos una conectividad asincrona, permites una mayor ventana para la respuesta al llamado de nuestra API. Por otra parte esta todo lo relacionado a la seguridad, aunque la mayoría de los servicios que ofrecen cuentan con maneras de gestionar privilegios y sistemas de autenticar.

Dentro del API tenemos una configuración relacionada a como interpretar cada petición:

CLIENT_ACKNOWLEDGE, este indica que se debe esperar al cliente para que confirme su respuesta y el resultado es un servicio lento, pero seguro de cada transacción que ejecuta – en mi opinión va contraría a la naturaleza de las conexiones por medio de Internet.

AUTO_ACKNOWLEDGE, envía y gestiona un paquete únicamente por petición, esto da también seguridad en la respuesta, sobrecargando el sistema si no se tienen recursos necesarios.

DUPS_OK_ACKNOWLEDGE, por último tenemos esta configuración que permite enviar varias respuestas y recibir varias confirmaciones, lo cual puede saturar el uso del ancho de banda.

Como todo en programación hay sus pros y contras a cada configuración, la decisión debe ir de la mano de nuestra topología de red, la manera que se han programado los procesos externos y cálculos internos de nuestra aplicación web; así mismo tomar en cuenta las características del equipo que dará este servicio y la posible configuración de los equipos clientes (lo cual en Internet es imposible).

Espero cumplir con mi promesa de un post más técnico.

Un saludo a tod@s.

El primero sera este viernes en las oficinas Sclipo, donde Javier Oliván explicara un poco las API’s de Facebook. Para todas aquellas personas que están interesadas en asistir, tendrán que enviar una petición por medio del grupo en Facebook, aquí. Solo hay 50 plazas así que animaos.

Hablando de Facebook, han liberado su API, así que todos los recursos que lo componen podrán ser utilizados por los desarrolladores y modificar los a su gusto. Aunque todavía no se sabe cuando lo podremos utilizar, el denominado fbOpen.

Creo que ya estamos en visperas del inicio de la guerra de las plataformas entre fbOpen y OpenSocial.

Para el 7 de Junio tenemos otro evento del grupo PHPBarcelona, que se dará lugar en el complejo de Citilab en Cornella.

Enhorabuena!! a los organizadores que se han estado moviendo desde principios de año organizando eventos para fomentar el uso de PHP y ayudando a unir a la comunidad de desarrolladores.

Para apuntarse y buscar mas información por favor entren al sitio de PHPBarcelona.

Saludos a tod@s y espero verlos en alguno de estos eventos.

Aqui esta el link.

Solo para hacer de su conocimiento, que la mayoria de los presentadores se encuentran a la disposicion de vosotros, si tienen preguntas o quieren darles animos, los invito a que les escriban, ya que la retroalimentacion es una parte esencial de toda ponencia, y estoy seguro que los presentadores quieren saber vuestra opinion.

En horabuena a los ponentes. Que sigan creando y compartiendo conocimientos.

Un cumplido para todos los organizadores del evento, ya que se llevo con una profesionalidad digna de grandes eventos. Todas las presentaciones se dieron a las horas acordadas.

También debemos darle las felicitaciones a todos los presentadores que se trabajaron muy bien las presentaciones, todos con un buen nivel de profesionalidad.

Sobre todo me agrado que una de las presentaciones fuera en ingles, ya que se mantiene lo multicultural que es Barcelona.

Hay que agradecer a los patrocinadores, que sin ellos no se pueden llevar estos eventos, ya que fue completamente gratuito.

Local Billing Solutions.

Small Squid.

Esperaremos ansiosamente este evento el año que viene.

Felicidades a tod@s.

Pues la presentación ha sido de lo más intersante, presento las herramientas esenciales, para hacer la tarea de optimización del “client side”.

Tales como:
- Firefox
- FireBug (Plugin de FireFox).
- YSlow.

Habló también de la regla de oro a nivel mundial del 80/20. Aplicandolo a la interacción de nuestra aplicación con el navegador, donde el 20 % del tiempo de descarga sera para el HTML y el resto del 80 % serán archivos JS, CSS e imagenes o elementos audiovisuales.

Se toco el tema de la percepción de la velocidad de descarga por parte del usuario, que creo es un tema que poco se habla en la mayoria de los libros, seria muy bueno plasmarlos, como pautas y reglas para su implementacion.

Un trucó muy bueno es la minimización del código de JavaScript y despues la compresión del mismo en gzip para mejorar el rendimiento de descarga de los elementos de nuestra web.

Entramos a la pausa.

Hablara de la optimización de código, para la mejor utilización de recursos de maquina, siendo lecturas a disco, utilización de ancho de banda.

Tenemos del lado del Servidor:

-Software Servidor.
Configuración de Apache.
No entro en mucho detalle, pero siempre hacer todo lo más simple posible. Como desactivar HostNameLookups, el .htaccess con “AllowOverrideNone”. No utilizar wildcards dentro de la configuración de Apache y desactivar todos los módulos que no utilizamos.

Lo que si me intereso de la platica es el tema del Keepalive. Donde recomienda hacer pruebas para ver si esta funcionalidad es necesaria.

Configuración de PHP.
Donde recomienda que se desactive:
register_globals
magic_quotes
expose_php
register_argc_argv
always_populate_raw_post_data
*Asi como desactivar el log de errores en nuestro sistema de produccion.

Hace hincapie que si nuestro proyecto, no esta relacionado a hacer una aplicación de alto rendimiento, podemos utilizar las diferentes variables de servidores web que se ofrecen en la red, tales como Tux y Lighttpd. Inclusive recomienda utilizarlos en conjunto Apache/Tux-lhttpd, ya que grandes empresas como Wikipedia y Youtube utilizan esta variación de configuración.

Como?
Por medio de separación de contenido, por medio de subdominios, que es la opcion mas fácil y ágil.

Habló de comprimir la salida de la información ya que la mayoría de los navegadores lo soportan, siendo una opción viable a la hora de planificar nuestra arquitectura de producción.

Así como la modificación del session handler.

-Sistemas de Caché.
En esta presentación se enfocó en los sistemas de caché.

APC, memcached y Squid, que son las soluciones mas implementadas hoy en día-

Donde guardarla:
-BD
-Disco Duro.
-Memoria Compartida.

Beneficios:
-Ahorro de accesos a disco.
-Lee la memoria usada del código compilado.
-Reducción de un 400 % del consumo del HD.
-Aunque se tiene que disponer de memoría a utilizar.
-Se puede configurar para ser accesible en diferentes servidores.
-Concede tiempos de Expiración (memcached).

-Optimización de Código.
El autor se quedo sin tiempo, asi que veremos los slides en phpbarcelona.org.

Para terminar este post.

Nota del Autor: Si esto se queda a medias, es por que ya me estoy quedando sin batería en mi portatil…….

Por parte de Arno Schneider. Que trabaja en Project Lead en Xinc. Donde desarrolla el papel de Arquitecto de Sistemas. Aunque su trabajo de dia es en Local Billing Solutions.

Basandose en Xinc y Cruisecontrol para inspirarse en el desarrollo de esta plataforma para llevar acabo tareas de integracion continua (CI..siglas en ingles).

Que es?

Empezo Arno hablando ¿que es Integracion?

Es todo aquello que altera o puede modificar el código fuente de nuestros componentes, el cual puede desestabilizar nuestro producto, por medio de “self-testing”. Es la unica solucion para mantener bajo control el numero de modificaciones que afecten el producto.

Muestra un grafica muy interesante, donde plasma la realidad de la mayoria de los proyectos de software-

Propone un workflow, donde empiezas a desarrollar una funcionalidad y creas una prueba de unidad (unit-test), verificas el cambio a nivel local, ya que haz verificado el cambio bajas el soourcecode del SVC y vuelves a probar tu funcionalidad. Ya pondre los graficos.

Reportare directamente desde el lugar BocaNord.

La primera hora esta hablando de los temas y sponsors. Localbilling.com y Bocanord.

Salu2.

Estoy muy emocionado ya que un buen amigo dara una charla en este evento.

Hablar sobre un Framework basado en la filosofia de Ruby on Rails, llamado Akelos.

Le deseo la mejor de las suertes en su presentacion, no se pierdan su charla dentro de la conferencia.

Aqui esta el link para mas informacion.

Mas adelante hablaremos un poco con Bermi Ferrer, para que nos comente en primera persona sus experiencias desarrollando este framework y las respuestas que ha tenido por parte de la comunidad PHP.

Un saludo Bermi y en horabuena.

Sobre el uso de una libreria de componentes para PHP, llamada Zend Framework. Que es de codigo abierto. La empresa Zend le da mantenimiento, lo cual da confianza de que tendra unos ciclos de mantenimiento y actualizacion regulares. Algo importante a tomar en cuenta a la hora de escoger una herramienta “open source” para utilizar en nuestros proyectos.

Rob es el autor del libro Zend Framework In Action, el cual debe ser agregado a la libreria de cualquier desarrollador que utiliza este framework en sus proyectos.

El documento no esta actualizado, espero en un par de semanas ponerme al corriente con el documento.

Ya que son dos.

1. Desarrollo de Aplicaciones con Zend Framework.
2. Como usar Zend_Auth del Zend Framework.

De momento eso es todo por hoy.

Un cordial saludo.