Alex Medina

Porque todos los días se aprende algo nuevo…

Decode y Encode en Base64… pero On-line. Y direís y esto para que??? pues bien es muy útil por ejemplo para deshacer estos templates de worpress o otro CMS que llevan el churro abajo…

LINK: http://www.motobit.com/util/base64-decoder-encoder.asp

En la programación orientada a objetos siempre se debe lidiar con que a la hora de comunicarse con la base de datos se debe recurrir a convertir nuestros objetos a datos planos (cadenas, o enteros). Para eso existen las librerías de Mapeo Relacional de Objetos (mas conocida por sus siglas en inglés como ORM) que se encargan de, como su nombre lo indican, mapear las bases de datos de manera tal que trabajemos con ellas como si fueran mas objetos de nuestro desarrollo.
Y es acá que voy a nombrar algunas de estas librerías de PHP que se encargan de generar el código necesario para comunicarse con nuestras bases de datos.
Por supuesto hay frameworks completos que traen por default este mapeo como CakePHP, CodeIgniter, Symfony, etc, los cuales no incluyo en esta lista.

PHP Object Generator: es uno de los mas conocidos, y no en vano, ya que el generador online es excelente, uno ingresa el nombre del objeto y las columnas de la tabla a la que se desea mapear el objeto. Tiene soporte para PHP4 y PHP5.

Doctrine: esta realizada para correr únicamente en PHP5. Utiliza un sistema de queries personalizados que devuelven el objeto con la información de la base de datos:

Junction PHP: es una librería relativamente nueva (que todavía no está muy bien documentada). Se ve interesante, no alcancé a probarla aún.

ADOdb Active Record: ADOdb es una librería de abstracción muy reconocida desde hace años, y no podía faltar que alguien realizara un plugin (o algo así) que permina el manejo de ORM usando la misma librería para conexión. ADOdb Active Record, utiliza el método de Active Record y no difiere mucho de las otras alternativas.

EZPDO: es una de las mas completas y activamente desarrolladas librerias. Algo curioso de esta librería es que utiliza los comentarios para indicar relaciones y tipos de datos de cada objeto. Vale la pena tenerla en cuenta.

DB_DataObject: esta librería es un proyecto dependiente del framework PEAR, posee funciones genéricas para todo tipo de consulta desde los objetos sin tener que manipular demasiado los queries SQL. Es bastante avanzada.

Propel: es una de las mas antiguas y mejor documentada. Está muy completa y hasta incluye validación.

Podés encontrar mas en del.icio.us.

Muchas veces necesitamos hacer algún script rápido o algo custom que no se justifica utilizar un framework como CakePHP (aunque se pueden instalar como helpers o componentes del mismo), es aquí cuando nos conviene utilizar librerías o clases para simplificar (y/o asegurar) nuestro desarrollo.

Estas son algunas de las clases que uso en estos casos. Sin un orden en particular, solo las que encontré en mis bookmarks.

SwiftMailer: Cuando notamos que LibMail queda chico y phpMailer viejo.

ezSQL: Una clase para trabajar con bases de datos, sinceramente prefiero la DB de PEAR, pero esta tiene sus cositas, otra es la ADOdb (o ADOdb Lite).

Logger: Porque no queremos que nadie sepa de nuestros errores, o debug.

JSON-PHP: Porque JSON es muy sexy.

phpsprockets: A veces el generar HTML suele ser una tarea tediosa.

eZComponents: Varios componentes que cumplen con lo que prometen: Archive, Cache, Configuration, Debug, EventLog, Feed, ImageConversion, etc.

GeSHi: Para mostrar tu código con colores bonitos.

SimplePie: El mejor parser de RSS y feeds, lejos.

JpGraph: Estadisticas? Ok, gráficos. Otra puede ser esta. Después sino existen las Sparklines, para pequeños gráficos.

FeedCreator: Para crear feeds RSS de manera fácil.

spyc: YAML al alcance de tu PHP.

DomPDF: Convertir HTML a PDF, nunca fue tan fácil.

FPDF: Porque no todo se basa en HTML, esta librería permite generar PDF pasandole coordenadas métricas, especial para impresión.

XML-RPC: La infaltable e indiscutible librería server/cliente de XML-RPC, para quienes les gusta dar un poquito mas de lo que se ve.

XDebug: Para ver que está pasando en nuestro desarrollo. (Otra dBug, un poco mas Web2.0)

Bunny RegEx: Regular Expressions para idiotas (muy útil para mí, claro).

class.upload.php: Para subir y manipular imagenes.

Y acá los de PEAR que merecen una sección especial:
-Calendar: como su nombre lo indica, un montón de utilidades para trabajar con calendarios.
-Date: nunca mas tareas con fechas complicadas
-Text_CAPTCHA: para los spammers con amor.
-Text_Password: para la creación de contraseñas con onda.
-XML_Parser: para esas cositas que los programadores odiamos de XML. (Aguante JSON!)
-DB: para trabajar con bases de datos con un poco mas de seguridad que lo usual.
-HTML_QuickForm: para la creación, validación y proceso de formularios.
-Cache_Lite: a veces necesitamos ser un poco generosos con nuestro servidor.

Una gran utilidad es el PHP Object Generator, que es una aplicación que en base a los parámetros de la base de datos y nombre de objetos que le indiques genera el código PHP para manejar dicha base de datos.

Seguramente me olvido de alguna, pero bueno, todo no se puede.

Contame cuales usas vos.

Erase una vez un programador web realizando un script relativamente complicado… Lo prueba en su maquina, funciona de maravilla. Lo sube al servidor de producción.

Craaash. Y ni siquiera un rastro de error. Revisa que los errores están habilitados, revisa los logs, y nada. Busca algún rastro y nada….

Mis poderes de psíquico me dicen que es un error de memoria.

Usualmente, PHP captura esos errores y nos lanza el ya típico error “Allowed memory size of x bytes exhausted”. Esto es debido a que por precaución contra malos programadores, y especialmente en servidores compartidos, es posible limitar la memoria ocupada por cada script.
Para lidiar con estos problemas, he aquí unos tips básicos que harán tu experiencia un poco menos difícil.

1. Revisa el uso de memoria de tus scripts
   La función memory_get_usage te regresa el numero de bytes que tu script esta ocupando. Sin embargo esta función no esta disponible en todos los sistemas, ya que hay que compilar php con el parametro –enable-memory-limit. Si en tu servidor no existe esta función puedes emularla de la siguiente manera.if( !function_exists('memory_get_usage') ){
function memory_get_usage() {
exec(”ps -orss -p “.getmypid(), $output);
return $output[1];
}
}
Es similar a la incluida en php, aunque no es tan exacta, pero te puedes dar una buena idea de lo que esta sucediendo. Requiere privilegios de ejecución, ya que utiliza el comando ps.
2. Cuando termines, no te olvides de limpiar
   Si ya no utilizas una variable que contenga una fuerte cantidad de memoria, destrúyela con unset($variable). Esto liberara inmediatamente la memoria ocupada.
3. Dí no a las globales
   Esta es una extensión de la anterior. Ten cuidado al usar variables globales. Cuando usas unset en una variable global adentro de una función solamente se destruye la variable local, no la global. Así que una razón mas para NO usar variables globales. (como si hicieran falta )
4. No confies en el barrendero
   En general he notado que al finalizar una función, esta desactiva las variables locales. Sin embargo, no siempre es el caso o bien no se libera la memoria que estas variables usaron, por lo que cuando uses variables pesadas dentro de una función, desactivalas con unset antes de terminar el script si ya no haces uso de ellas.
5. Olvida tan pronto como puedas
   Si vas a utilizar por ejemplo, un archivo de muchas lineas, evita mantenerlo en memoria. Esto ultimo es lo mas facil pero puede provocar errores a la larga. En su lugar ve procesando el archivo linea por linea y escribe el resultado en un archivo. tmpfile y las funciones fopen, fclose y similares son tus amigos. Este consejo es el que mas te va a salvar la vida en estos casos, créeme.
6. No ignores los avisosComo recomendación general, cuando estés debuggeando scripts utiliza error_reporting con E_STRICT. Esto te dará un poco mas de información que E_ALL, aunque con el tiempo y conforme vayas mejorando tus habilidades no notaras la diferencia.
7. Fuerza bruta
   Como ultimo recurso, si nada de lo anterior funciona (que no he encontrado caso en que no funcione) es posible aumentar la memoria disponible para tu script, mediante la directiva ini_set(”memory_limit”, “16M”) la cual elevaría a 16 MB la capacidad de tu script. Esta directiva esta disponible en cualquier servidor que permita la ejecución de la funcion ini_set. Aunque se cuidadoso, especialmente si tienes un servidor compartido, se buen vecino y no acabes con el servidor.