Manual de Amazon Web Services con PHP

mayo 8, 2009

Extenso y completo tutorial que nos enseña cómo trabajar con Amazon Web Services (AWS) en PHP. Para lo cual primeramente nos explica qué servicios ofrece Amazon:

  • Amazon Simple Storage Service (Amazon S3): almacenamiento
  • Amazon Elastic Compute Cloud (EC2): servidores
  • Amazon Simple DB (SDB): base de datos
  • Amazon Simple Queue Service (SQS): cola de mensajes entre servidores

Después nos explica cómo funcionan los servicios para pasar por último a la parte técnica del PHP.

Introduction to AWS for PHP Developers


PHP Quick Profiler

abril 30, 2009

PHP Quick Profiler

PHP Quick Profiler (PQP) es una interesantísima utilidad que registra y recopila información sobre los recursos que está consumiendo nuestra aplicación PHP. Visualmente impecable, la representación de los resultados presenta datos sobre el tiempo de carga, la cantidad de consultas SQL, la memoria usada y la cantidad de archivos incluídos.

PQP fué extraída de las propias necesidades de sus autores a la hora de depurar el código de Wufoo, la aplicación Web 2.0 (gratuita y paga) para la creación de formularios online que incluso este mismo sitio usa.

Mientras nos descargamos PQP podemos aprender sobre sus características probándolas con esta demostración en línea.

Fuente: vivaphp.com.ar


QueryPath: maneja HTML con PHP como si fuera jQuery

abril 30, 2009

QueryPath es una librería PHP que permite trabajar con HTML, XML o web services de forma muy sencilla y parecida a la que se usa en jQuery, permitiendo usar métodos encadenados.

Puede usarse para importar documentos XML en una base de datos SQL, o pasar los resultados del SQL a un XML o HTML. Se pueden escribir documentos en HTML o convertir XML en HTML. Abrir documentos y buscar mediante selectores CSS3 o XPath.

  1. qp('sample.html')->find('title')->text('Hello World')->writeHTML();

QueryPath

Vía / Developer Works


¿Elegancia o sencillez?

abril 25, 2009

En el trabajo llevamos varios días peleándonos con la instalación de una versión de nuestro software en uno de nuestros sistemas. El sistema consta de unas diez estaciones de trabajo solaris y unos veinte PCs con Windows. En todos ellos corren aplicaciones nuestras, en su mayoría java. Estas aplicaciones tienen algunas partes comunes, pero son distintas en cada una de las estaciones y de los PCs (cada uno está especializado en diversas funciones, algunas comunes, otras no y comparten mucha información entre ellos). En las estaciones hay bases de datos Oracle, con muchas tablas comunes, pero otras distintas en cada estación. Y en todo esto reside el problema de la instalación.

La gente está dividida en dos posibles tipos de instalación.

Junto con algunos, yo soy partidario de implementar las distintas funcionalidades del sistema en jar distintos e instalar en cada estacion/PC sólo aquellos jar que son necesarios, de forma que ninguna estación/PC lleve más jar o ficheros de configuración que no va a usar. Esta es la solución que considero elegante, pero es más compleja. Requiere generar instaladores/zips disintos para cada estación/PC, así como ser mucho más cuidadoso en esta generación de instaladores/zips, muchos jar, muchos grupos de ficheros de configuración, partes comunes y partes específicas.

Otros piensan que es mejor hacer un único mega-jar, o unos pocos jar grandes, un único mega-grupo de ficheros de configuración e instalar todo en todos lados. De esta forma, un único instalador o un único zip vale para todas las estaciones/PCs. Luego es el propio software el que mirando el nombre de la estación/PC en el que corre, sabe qué fichero concreto de configuración leer, de qué clase principal hacer el new y actuar como lo que le toca. Esta instalación es, desde mi punto de vista, más chapuza, pero es innegable que es infinitamente más sencilla.

Y después de la pelea de estos días atrás para la instalación según mi punto de vista (disintos zips/instaladores que instalan en cada estación/PC sólo lo necesario), creo que estoy empezando a cambiar de opinión. Los instaladores/zips, desde luego, se hacen con procesos automáticos, pero alguien tiene que decirle a ese proceso qué debe meter. Según evoluciona el software y va llevando más funcionalidades y ficheros, hay que tocar la configuración de la herramienta que genera los instaladores/zips (izpack, maven assembly,…) y hay que hacerlo con cuidado. Este proceso es manual y está sujeto a errores humanos, por lo que a nuestros instaladores siempre les acaba faltando alguna cosa y necesitan su proceso de “depuración”.

En fin, no me gustan las chapuzas y tengo que pensar seriamente la forma de mejorar el proceso de generar los zips/instaladores, pero desde luego, es difícil resistirse a la facilidad de instalación de “todo va en todos sitios, aunque no se use”. Es mucho más fácil instalar un solo mega-jar en todos lados que instalar varios jar distintos en cada estación/PC.

Fuente: http://blog.chuidiang.com/2009/04/25/%C2%BFelegancia-o-sencillez/


¿JSP o PHP?

abril 23, 2009

Esta es una pregunta bastante habitual en la gente que empieza a hacer aplicaciones web o, incluso en la gente que ya lleva tiempo en uno de esos dos lenguajes y se plantea si merece la pena pasarse al otro. No pretendo aquí dar una relación exhaustiva de los pros y contras de cada uno de ellos, pero sí algunos de los puntos que considero importantes a la hora de decidirse.

Librerías disponibles

Tanto un lenguaje como otro tienen muchísimas librerías disponibles para hacer un montón de cosas. JSP/Java tienes bastantes más, pero también es un lenguaje multi-propósito, por lo que muchas de ellas no nos servirán para nada en una aplicación web. PHP está más pensado para web y todas sus librerías son útiles para web. Por ello, lo único que debemos tener en cuenta en este punto concreto es qué librerías vamos a necesitar para nuestras aplicaciones y si las tenemos disponibles en el lenguaje que vayamos a elegir. En su defecto, qué nos costaría desarrollar esa misma librería.

Hospedaje en el servidor

La aplicación web debe ir en un servidor. Normalmente es más fácil encontrar servidor PHP con base de datos gratuitos que servidores que ofrezcan JSP/Servlets gratuitos. Si vamos a los de pago, también es más fácil y barato encontrar servidores PHP. Por ello, si el coste es un problema, posiblemente PHP sea mejor opción.

Si nuestra aplicación web está pensada para que la gente en general la use y la instale en sus servidores (por ejemplo, un blog estilo wordpress, una wiki estilo Mediawiki, etc), también tendrá más aceptación posiblemente si la hacemos en PHP, ya que de todos esos posibles webmaster que queremos que usen nuestra aplicación, la mayoría tendrán PHP pero no JSP.

Si nuestra aplicación es para uso particular en una empresa o en casa y el servidor nos lo vamos a montar nosotros mismos, en principio no hay ningún problema con un lenguaje u otro. Es prácticamente igual de fácil instalar, por ejemplo, un servidor Apache con PHP que un servidor Tomcat para JSP/Servlets.

La aplicación y el lenguaje en sí mismos

Entre los lenguajes Java y PHP hay una diferencia que considero fundamental. El primero es tipado, es decir, hay que declarar los tipos de las variables, los parámetros de los métodos, etc, etc. En PHP no hay tipado, se pueden usar las variables sobre la marcha y pueden contener cualquier cosa en momentos distintos de la ejecución. Java es 100% orientado a objetos, mientras que PHP permite mezclar clases con funciones de programación estructurada. Esta diferencia hace que según el tipo de aplicación, sea mejor un lenguaje u otro.

Si nuestra aplicación es una aplicación puramente web, en la que principalmente hay presentación en navegador y transacciones con una base de datos, en la que van a participar un número de desarrolladores no muy grande y el tiempo de desarrollo no muy largo, PHP puede ser una buena opción.

Sin embargo, en aplicaciones muy grandes, en la que pueda haber más código/algorítmica aparte de lo estrictamente presentación en navegador y transacciones en base de datos, va a haber muchos desarrolladores y tiene un tiempo de desarrollo largo, es mejor usar JSP/Servlets.

Y explico el motivo. Una función PHP puede parecerse a esto

function la_funcion ($el_parametro) {
$el_resultado = ….
return $el_resultado
}

mientras que un método similar en Java puede ser como este

public TipoResultado laFuncion (TipoParametro elParametro) {
TipoResultado resultado = …;
return resultado;
}

Mientras estamos codificando y con el código en la cabeza, casi da igual una cosa que otra. Pero si ese código no lo he hecho yo y tengo que mantenerlo o usarlo, o lo he hecho yo pero hace unas semanas, el código PHP no ayuda en absoluto a saber qué tipo de parémetro hay que pasar o qué devuelve (ni siquiera si devuelve algo), habría que leer el código interno de la función con detalle. El código Java, sin embargo, deja claro qué tipo espera como parámetro y qué devuelve, así que quizás no tengamos que mirar el código interno del método para usarlo.

El no saber los tipos de entrada/salida puede resolverse con una disciplina estricta y comentarios adecuados, pero recuerda, estamos hablando de un grupo de desarrolladores grande. En un grupo grande, siempre hay  un porcentaje importante de ellos que será poco disciplinado/novatos y pondrán comentarios graciosos.

Hay además otras dos ventajas fundamentales en los lenguajes tipados:

  1. Los IDE tienen un autocompletar mucho mejor. Cualquier IDE de java moderno, pones la variable, un punto y te saca los posibles métodos/atributos a los que puedes llamar. Un buen IDE de PHP lo intentará, pero no siempre lo conseguirá. En el ejemplo anterior, si en java escribimos elParametro., el IDE nos pondrá los posibles métodos porque sabe que elParametro es de tipo TipoParametro. En PHP, poniendo el_parametro->, el IDE no nos puede poner absolutamente nada, porque no sabe de qué tipo es eso.
  2. Precisamente por eso y por la necesidad de declarar los tipos, un IDE no nos dejará, por ejemplo, llamar a un método que no existe o asignar a una variable no declarada. PHP sí nos dejará hacerlo o nos dejará, por ejemplo, poner $nuemro (me he equivocado a posta, en vez de $numero he puesto $nuemro) y declarar sin querer una nueva variable. Todo esto fallará, si tenemos suerte, cuando hagamos nuestra ejecución. Pero si no tenemos suerte, errores de este tipo no saltarán al ejecutar, el programa símplemente no dará el resultado esperado y perderemos horas de depuración. En java directamente no compilará y el IDE nos cantará el error en cuanto lo escribamos.

Así que si la aplicación es grande y con muchos desarrolladores, es posiblemente mejor usar un lenguaje tipado.

Gustos personales

Finalmente, cómo no, los gustos personales de cada uno, las prisas, ganas de aprender, etc. Alquien puede tener preferencia por uno de los lenguajes, o bien ser el que domina y no querer meterse en el otro, o bien todo lo contrario, querer meterse para aprender. Si vas a hacer una aplicación web sencilla, pero dominas java, tienes prisa en hacerla y te importa tres pepinos PHP, posiblemente la hagas en JSP, aunque alguien que domine PHP quizás tardaría menos en hacerla en PHP.

En resumen

Supongo que al menos parte de estas razones son las causas principales por el que en el ambiente de internet al público, la mayoría de las aplicaciones son PHP (wordpress, mediawiki, etc), mientras que las aplicaciones JSP/Servlets se quedan más para ambientes empresariales o intranets. Ojo, hay cosas de ambos tipos en ambos ambientes, símplemente estoy indicando lo que parece ser mayoría.

¿A alguien se le ocurren más motivos a tener en cuenta?

Fuente: http://blog.chuidiang.com/2009/04/23/%C2%BFjsp-o-php/


Sun anuncia MySQL 5.4

abril 23, 2009

Las cosas están cambiando rápidamente en la base de datos MySQL. El martes, al inicio de la MySQL Conference & Expo, Sun anunciaba nuevos planes de liberación. La primera preview de MySQL 5.4 está disponible desde hoy, y aseguran que es un 90 por ciento más rápida que MySQL 5.1 para determinados tipos de consulta. Aunque todavía es pronto, el jefe ejecutivo de MySQL es optimista y cree que Oracle verá el valor de MySQL y les permitirá continuar su desarrollo sin problemas.”MySQL es tan omnipresente que su propiedad es irrelevante”, dijo Karen Tegan Padir, vicepresidente de infraestructura de software en Sun.
Fuente: barrapunto.com


Crear páginas de error 404

abril 19, 2009

Un error 404 ocurre cuando un visitante no encuentra una página web, esto por que la dirección ingresada no existe, han escrito mal la dirección URL o por que la ruta ya no existe por que se editado o eliminado. Por defecto el browser muestra una pantalla indicando el tipo de error el cual es ininteligible para la mayoría de usuarios, por ello veremos la forma de personalizar este tipo de mensajes.

error404

Creando las paginas de error 404
Lo primero es editar el archivo .htaccess que esta en la raíz de nuestro servidor e incluir la siguiente línea de código, el cual hará que cada vez que no se encuentre el archivo solicitado se muestre la pagina error404.hml al visitante

  1. errorDocument 404 /error404.htm

Lo siguiente es crear este archivo, ahora como esta página es solo informativa no es necesario que sea indexada por los buscadores para ello es necesario agregarle un header indicando el tipo de error:

  1. <?php header(“HTTP/1.1 404 Not Found”); ?>

Otra forma si no se tiene acceso a PHP es agregar un metatag en nuestro html para indicarle a los robots que no indexen la página:

  1. <meta name=“robots” content=“noindex, nofollow”>

Lo que sigue es creatividad para crear un archivo de error personalizado. Si desean ver una muestra de diferentes paginas de error pueden visitar 404 Error Pages, One More Time.

Páginas de error personalizadas con Google
Si eres usuario de Google Webmaster Central podrás hacer uso de un widget para incluir en tus páginas de error 404, el cual sugerirá al visitante las urls semejantes a la ingresada e incluso un buscador, de esta forma le brindamos al usuario posibilidades de encontrar la información deseada.

Para utilizar este script, accedes a tu panel de Google Webmaster Central, seleccionas el dominio que deseas, luego accedes en el menu ToolsEnhance 404 pages, en donde encontrarás un código javascript el cual debes incluir en tus paginas de error.

  1. <script type=“text/javascript”>
  2. var GOOG_FIXURL_LANG = ‘es’;
  3. var GOOG_FIXURL_SITE = ‘http://blog.unijimpe.net/&#8217;;
  4. </script>

De esta forma ya tienes una página de error personalizada y sobre todo que le dará al visitante las opciones necesarias para encontrar lo que busca.

Fuente: http://blog.unijimpe.net/crear-paginas-de-error-404/