Actualmente estas viendo el weblog personal de Carlos Montalvo, un profesional en el desarrollo web con sede en la ciudad de Lima, Perú.

Suscribete a posts o comentarios

Sigueme en Twitter

Apache Bench - ab

03 Sep

Escrito por hace 8 horas y 40 mins | Sin Comentarios

ApacheBench es probablemente el programa más utilizado para medir el tiempo de respuestas de un servidor web, viene incluido con todas las distribuciones de apache y su forma de uso es realmente sencilla.

Con la configuracion por defecto, apachebench realiza las pruebas enviando peticiones HTTP/1.0 sin compresión.

ab -n 1 -v 4 http://www.example.com/
This is ApacheBench, Version 1.3d <$Revision: 1.67 $> apache-1.3
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/
Benchmarking www.example.com (be patient)...INFO: POST header ==
---
GET / HTTP/1.0
User-Agent: ApacheBench/1.3d
Host: calinsoft.com
Accept: */*
---
LOG: header received:
HTTP/1.1 200 OK
Date: Tue, 07 Nov 2006 12:14:09 GMT
Server: Apache/2.0.54
Vary: Accept-Encoding
Connection: close
Content-Type: text/html;charset=UTF-8

Con este método, obtendremos información de como responde nuestro servidor enviando contenido sin compresión, pero si el servidor que probamos permite utilizar compresión de contenidos, los datos que obtenemos de estas pruebas no se ajustaran demasiado a la realidad.

(Leer el resto de la noticia »)

Categorizado :Desarrollo Web

Etiquetado :gzip,deflate,Apache,ab

Zend Server Community Edition (webserver)

02 Sep

Escrito por hace 17 horas y 32 mins | Sin Comentarios

Zend Server Community Edition (CE) es una versión del servidor de aplicaciones PHP Zend Server rápido y confiable que funciona en distribuciones de Linux, Windows y Mac OS X.

A diferencia de su versión de pago, Zend Server Community Edition (CE)es completamente gratuito, y usted puede usarlo en las fases de desarrollo, prueba y producción.

¿Que lo diferencia?

Al ser de Zend, este incluye:

  • Acelerador de código byte (Zend Optimizer+, incrementa el desempeño con cambios sin aplicación.)
  • Cacheo de Datos Zend ( Un set de funciones que permite a los desarrolladores cachear datos en una memoria compartida, o bien en un disco.)
  • Una distribución PHP 5.2/5.3 certificada .
  • Zend Framework.
  • Apache (o integración IIS).
  • MySQL (en Windows y Mac OS X).
  • Conectividad completa a todas las bases de datos comunes.
  • Conectividad de código Java.
  • Consola de administrador PHP basada en Web.

Instalación en Ubuntu 10.04

$ sudo -s

#Agregar el Repositorio de Zend
echo "deb http://repos.zend.com/zend-server/deb server non-free" > /etc/apt/sources.list.d/zend.list

#Agregar la clave del Repositorio
wget http://repos.zend.com/deb/zend.key -O- | sudo apt-key add -

#Actualizar la lista de Paquetes
apt-get update

#PHP 5.3
apt-get install zend-server-ce-php-5.3

#O PHP 5.2
apt-get install zend-server-ce-php-5.2

Manual Oficial de instalación completo

Categorizado :Desarrollo Web

Etiquetado :Zend,Ubuntu,php,MySQL

Quality Assurance en PHP

30 Aug

Escrito por hace 3 días y 19 horas | Sin Comentarios

Xdebug

Un depurador, perfilador y analizador de trazas para PHP con posibilidad de realizar code coverage (no me atrevo a traducirlo :) .

Lo mejor de esta herramienta son los volcados de pila y variables en memoria, una auténtica gozada después de sufrir durante años los echo, los var_dump y los printr.

El tema del perfilado de código también es bastante interesante de cara a ver dónde se pierden ciclos en los scripts. En Linux se puede ver el árbol de llamadas del código con el KCacheGrind de toda la vida (viene con KDE-devel en todas las distros); para los que sufren Windows está el port WinCacheGrind, pero ya aviso que es lento y pesado a más no poder. Para OSX ni idea, imagino que habrá un port de KCacheGrind o como mínimo se podrá utilizar la instrumentación de valgrind/callgrind a pelo, no se.

También se puede integrar con Eclipse + PDT para depurar sin salir del IDE, aunque es un poco fiable todavía.

Para instalar Xdebug lo mejor es tirar de los repositorios PEAR/PECL y compilarlo. Instalarlo desde ubuntu o debian ya no es cosa del pasado.

PHPUnit

Un framework para realizar tests unitarios de manera tan sencilla que da reparo no hacerlos :).

Antes utilizaba SimpleTest pero este me gusta mucho más por la versatilidad que ofrece y el rápido desarrollo. Está completamente orientado a objetos y puede funcionar conjuntamente con Xdebug para realizar unos bonitos informes de cobertura.

PHPUnit es una herramienta sobre la que se está trabajando muy activamente. Entre las cosas interesantes que se pueden hacer (a parte de lo que he dicho) quizá destacaría el mutation testing y el test para bases de datos PHPDBUnit que es un port directo del DBUnit de Java.

Otra herramienta increíble que puede interactuar con PHPUnit es Selenium. Con estas dos joyitas se puede construir un sistema de tests de aceptación completo para aplicaciones web.

Para instalar PHPUnit, lo mejor de nuevo, es tirar de Pear porque la versión que viene empaquetada en Debian/Ubuntu es bastante antigua.

Phing

¿Habeis utilizado alguna vez Apache Ant en Java? pues Phing es lo mismito pero para PHP; guarda una cierta compatibilidad con la sintáxis de Ant pero incorporando algunos targets útiles para PHP,como por ejemplo la integración con PHPUnit :) o el acceso a Subversion.

Tampoco es que me guste mucho utilizar XML para hacer los scripts de los despliegues... porque el XML tiende a hacer las cosas complicadas imposibles, pero para las tareas habituales no se requieren más de una docena de lineas.

Para instalarlo, más Pear.

Categorizado :Desarrollo Web

Etiquetado :Testear,php,Debugear,Debug

Cuando los usuarios meten la pata!

26 Aug

Escrito por hace 1 semana y 1 día | Sin Comentarios

Estos son algunos de los momentos memorables en algunos proyectos en los que he estado, tanto por la originalidad de las deducciones como de las respuestas o expresiones de algunos usuarios. A veces, mientras se toma uno un buen cafe salen a relucir entre risas:

  • (Un usuario de alto nivel) Será que ese programa está como lento, será que está cansado?
  • (Un usuario enojado en un fallo de respuesta en el servidor) Ese programa pone mucho problema cuando se cae el servidor, que programa tan rebelde!
  • (Llama la usuaria llorando) Hay no! Me van a matar!Me van a matar! Cerré el programa de la "equis" (Cerró una ventana de navegador).
  • (Aplicación web con base de datos centralizada) Mire caballero, a mí me tiene que funcionar ese programa con o sin red porque yo pagué mucha plata por él.
  • Eso es inaceptable, como así que su programa no puede hacer que cero dividido cero de como resultado cero. Cuál valor indeterminado! No sabe matemáticas o qué? Ustedes son programadores, deberían saber.
  • (Van 3 años de este proyecto y así comenzó) Mire, nuuuuu, eso es muy sencillito, es un programita con un arbolito, con 2 relojitos y listo.
  • (Una aplicación de una intranet) No me funciona el programa en la finca donde estoy, ¿Me puede ayudar?
  • Ese maldito programa no deja imprimir! Qué software tan malo! (suena la impresora después de unos segundos)... Ahhh... mmmm... un momento... Gracias.
  • (Una aplicación de alta gerencia) ¿Y no me le puede colocar un tigrecito que ruja cada que ingrese la gente?
  • (Un ingeniero de sistemas) Esa impresora HP, esa "Hupac"
  • (El mismo ingeniero) No prende el equipo? Eso debe ser el office... Ya se lo cambiamos.
  • (Y otra vez el mismo ingeniero sobre una aplicación web) Qué software tan malo! Se cae el servidor y deja de funcionar!

Categorizado :Desarrollo Web

Etiquetado :Usuarios

Buenas prácticas utilizando control de versiones

26 Aug

Escrito por hace 1 semana y 1 día | 1 Comentario

Sistemas de control de versiones hay muchos y muy variados: CVS, Subversion, Darcs, StarTeam, etc. Son herramientas muy valiosas, tanto que ningún programador puede omitirlas. En la siguiente nota voy a comentar algunos hábitos que he observado en la gente que las utiliza:

No utilices el control de versiones como si fuera un backup

Este es uno de los mayores errores a la hora de utilizar estas herramientas. Frecuentemente oigo la frase: ¿has puesto a salvo tu código en el repositorio?. ¡Mal! Almacenar el código en un repositorio no es sinónimo de seguridad, la seguridad la proporciona una copia de respaldo de ese código, no el repositorio en sí.

Tomaremos como ejemplo Darcs, un sistema de control de versiones no muy conocido. Este soft funciona en local, como un proceso más, sin necesidad de centralizar el control en un servidor como ocurre con otros sistemas como CVS o Subversion. En este caso, un fallo de disco podría echar a perder tu trabajo; por esta razón debes hacer copias de seguridad, el sistema de control de versiones no tiene nada que hacer ante este tipo de contingentes.

Los desarrolladores que utilizan el control de versiones con el rol de sistema de backup frecuentemente hacen un commit de su trabajo al día, por ejemplo cuando termina su jornada laboral, como una forma de respaldo diario. Esta no es una práctica aceptable, especialmente si formas parte de un equipo de desarrollo. Imagina que sólo actualizas tu proyecto por la mañana, cuando empieza tu jornada, y remites los cambios al finalizarla. Cada mañana perderás mucho tiempo únicamente lidiando con todos los cambios que enviaron tus compañeros el día anterior y que entran en conflicto con los que tu hiciste. No es una práctica muy inteligente, ¿no crees?

Remite los cambios tan pronto como conformen una unidad lógica

¿Cada cuanto debo remitir los cambios?. Hay que llegar a un término medio: no remitas cada línea que escribes ni lo hagas después de todo el día trabajando. Debes hacer un commit tan pronto como los cambios conformen una unidad lógica, por ejemplo cada vez que un conjunto de cambios tengan sentido.

Estas unidades lógicas responden en la mayoría de los casos a tu plan de desarrollo: encuentras un bug en la rama de desarrollo actual, planeas una estrategia para solucionarlo, lo arreglas y ahí tienes tu unidad lógica: envía los cambios al repositorio. El commit cobra sentido porque soluciona un bug específico; la versión X tiene un bug y la versión X+1 ya no.

No tengas miedo de remitir pequeños cambios con mucha frecuencia, nadie se enfadará porque seas conciso solucionando cosas pequeñas. Considera la situación extrema en la que, después de meses de desarrollo, necesitas recordar cuál fue la revisión en la que se solucionó aquella falta de ortografía en una cadena de depuración. Si utilizaste correctamente el patrón de "una solución, un envío" no tienes más que investigar la lista de envíos para descubrir cuál de ellos estas buscando.

Frecuentemente ocurre que estás trabajando en una "unidad lógica" cuando descubres que hay un error en otra parte del código y lo corriges, y envías la corrección junto con tus cambios todo dentro de un mismo commit haciendo que esta corrección pierda visibilidad. Esto debe evitarse en la medida de lo posible.

(Leer más »)

Categorizado :Desarrollo Web

Etiquetado :SVN,CVS

Paginación de datos

25 Aug

Escrito por hace 1 semana y 1 día | Sin Comentarios

¿Qué es el paginado?

El paginado de datos consiste en trocear una salida de datos muy larga en paquetes más pequeños y digeribles para el usuario. Hay ejemplos de paginados en la inmensa mayoría de aplicaciones, especialmente en las de Internet. Por ejemplo:

Paginado de Google:

Paginado de Flickr:

Paginado de Digg:

¿Por qué debo paginar?

  • Para el usuario es más sencillo ver 10 paquetes de 10 resultados que 100 de golpe.
  • Probablemente al usuario sólo le interesen los resultados más relevantes que son los que aparecen en la primera o segunda página.
  • Para la base de datos es más sencillo y rápido traer 10 resultados que 100.
  • Para el servidor HTTP es más sencillo y rápido servir 10 resultados que pesan 20Kb en lugar de 100 resultados que pesan 200Kb.

¿Cómo paginar datos?

Para paginar los datos necesitamos de antemano dos cosas: el tamaño de la pagina y el total de filas que tenemos de datos.

Contamos el total de filas:

SELECT COUNT(*) AS total FROM employees;

total
---------------
63

Mediante la instrucción SQL LIMIT n,m podemos Dividir en trozos los datos de salida y mostrar la pagina que nos interese. LIMIT acepta dos parámetros: el primero es el offset de la pagina y el segundo la cantidad de filas que devuelve.

Devolvemos 10 resultados de la página 3:

SELECT id,name FROM employees LIMIT 3,10;

id name
------------------------
13 José
22 Billy
34 Carlos
...

Necesitamos el total de filas para calcular cuántos paquetes de datos (paginas) necesitamos. En este caso tenemos un total de 63 filas paginadas de 10 en 10. Veamos un script PHP muy simple que nos devuelve las páginas:


$pagging = 10;

isset($_GET['page']) ? $current = (int)$_GET['page'] : $current = 1;

$q = mysql_query("SELECT COUNT(*) FROM employees;");

$row = mysql_fetch_assoc($q);

$total_pages = (int)ceil($row['total']/$pagging);

//header pagging

echo "Pagina $current de $total_pages ({$row['total']} resultados)nn";

//body pagging

$q = msql_query("SELECT id,name FROM employees LIMIT {$current-1},$pagging;");

while($row = mysql_fetch_assoc($q))

{

echo vsprintf("%dt%sn", array($row['id'], $row['name']));

}

//footer pagging
echo "«t";

for($i=0;$i < $total_pages;$i++)

{

if($i === ($current-1))

echo " [$i] ";

else

echo " $i ";

}

echo "t»";

Página 1 de 7 (63 resultados)

13 Pepe
22 Manolo
34 Jose
...

« [1] 2 3 4 5 6 7 »

Consideraciones para MySQL

Para calcular el paginado debemos utilizar obligatoriamente dos consultas como mínimo, si las consultas son complejas podemos tener un problema de rendimiento importante pero existen maneras de atajar el camino. Si la base de datos que utilizamos es MySQL existe un hack para devolver el resultado paginado y el total de filas en un solo paso.

Seleccionamos la página que nos interesa:

SELECT SQL_CALC_FOUND_ROWS id,name FROM employees LIMIT 0,10;

Miramos cuantas filas tiene en total:

SELECT FOUND_ROWS();

Siguen siendo dos consultas pero a efectos prácticos rinde como "una y media", en cualquier caso nunca será tan lento como hacerlo con las dos consultas anteriores.

SQL_CALC_FOUND_ROWS funciona a partir de la versión 4 de MySQL si no recuerdo mal.

Las instrucciones SQL_CALC_FOUND_ROWS y FOUND_ROWS() deben ir una detrás de otra, si hacemos consultas por en medio es muy probable que nos encontremos con resultados imprecisos.

Me consta que Oracle tiene una instrucción equivalente pero no sabría explicaros, no tengo suficiente experiencia con esa base de datos. PostgreSQL y SQLite sí que sé seguro que no pueden hacer uso de este hack, al menos en sus versiones actuales.

Nota: Para utilizar SQL_CALC_FOUND_ROWS y FOUND_ROWS() el valor de mysql.trace_mode debe ser off.

Si dudas de que este off al inicio de tu pagina php coloca.

ini_set("mysql.trace_mode", "0");

o en tu archivo .htaccess

[BASH]
php_value mysql.trace_mode "0"
[/BASH]

Categorizado :Desarrollo Web

Etiquetado :php,MySQL

Tres mitos sobre el testing

25 Aug

Escrito por hace 1 semana y 2 días | Sin Comentarios

Mito 1: ¡No tengo tiempo para hacer tests!

Esta es la excusa más frecuente de aquellos que no quieren escribir tests. Es verdad, se necesita algo más de tiempo para escribir tests, pero si de verdad quieres escribir tests estoy seguro de que vas a encontrar el tiempo necesario.

Mito 2: ¡Los clientes no me pagan por hacer tests!

Esto a menudo es verdad, por lo menos si le dices a tu cliente que necesitas 40 horas más para hacer los tests. Creo que la mejor táctica es no mencionar la palabra testing como un tema separado y tratar la producción de código y los tests como una unidad. Asi que para estimar el coste de una funcionalidad, suma el coste de producción del código mas los tests, y presenta el resultado al cliente. Si el cliente acepta la oferta, automáticamente te pagará por el esfuerzo de hacer los tests. De todas formas repercute en la calidad final del producto así que el cliente resulta el mayor beneficiado.

Mito 3: ¡Testear me hace ir más despacio!

En un primer momento puede parecer que tengas que escribir mucho más código, lo que significa menos producción de código útil por unidad de tiempo. Pero a la larga se nota el beneficio: necesitas mucho menos tiempo para depurar tu código, es más sencillo refactorizar sin romper la funcionalidad, y tienes que escribir menos documentación porque los tests describen que es lo que hace tu programa y como debería ser utilizado. Además hay cientos de frameworks para todos los lenguajes de programación que te ayudan en la labor de escribir tests y comprobar posteriormente el resultado de manera automática.

¡A testear todo el mundo!

Categorizado :Desarrollo Web

Etiquetado :Testear,Debugear

Event.Behavior es un lenguaje específico para describir y definir eventos en las aplicaciones JavaScript. Intenta aproximarse a cómo alguien describe un evento (en ingles) y permite extender el dominio con tus propios verbos. Las aplicaciones JavaScript se prestan especialmente a este tipo de programación.

Muchos desarrolladores prefieren JSON sobre XML sobre todo porque es más compacto y directamente interpretable por Javascript, pero depurar un stream de cierto tamaño es un dolor. JSON formatter permite dar un formato más legible a los datos.

A varias personas nos agrada el estilo del chat de gmail, porque
este es muy rápido y ligero para usar. Navegando por la red encontré un script
que simula su estilo y funcionamiento con lo cual podemos integrarlos a
cualquier página web y así montar nuestro chat con nuestros amigos. [ Descarga ] [ Demo ]

« 1 2 3 4 5 6 7 8 9 10