Swish-e es una libería que permite indexar texto, e-mail, PDF, HTML, XML y Microsoft®
Word/PowerPoint/Excel, también permite usar filtros para indexar PDF, gzip o PostScript. Tiene una lista de características sin fin.
Swish-e es rápido y existe una librería PECL para poder usarla.
Vía / Zend Developer Zone
Spinner Control es una librerÃa creada con Prototype que permite crear controles HTML que modifican su valor mediante botones incluidos en ellos. Ya hace tiempo implementamos nuestro propio controlador, por lo que no es necesario explicar cómo hacerlo.
Entre las caracterÃsticas que ofrece encontramos lo siguiente:
VÃa / dzone
A la hora de realizar un proyecto, debido a costes y a tiempos, puede llegar a ser rentable externalizar el diseño, ya sea comprándolo ya hecho o mandándoselo a hacer a otros.
La solución de comprar puede aportarnos algunas ventajas, como por ejemplo que es más barato que pagar a un diseñador o a una empresa que lo haga. El inconveniente es que podemos ver el diseño de nuestra página en otros lugares, pero bueno, habiendo tantas webs como existen hoy en dÃa, eso es difÃcil.
En algunos casos, incluso la compra no es necesaria, ya que existen lugares dónde las ofrecen gratuitas. He aquà una lista de recursos y páginas dedicada a las plantillas:
Great template resources and sites
VÃa / dzone
Según cuenta el autor, dice que hay una diferencia entre ser un buen diseñador web y un gran diseñador web, que es tomar atajos para hacer más sencillo tu trabajo sin que repercuta en la calidad. Por eso nos da una serie de consejos o trucos a seguir:
<link rel="stylesheet" href="simple. css" type="text/css" media="screen">
<style type="text/css" media="screen">
@import url(simple.css);
</style>VÃa / Digg
Para aquellos que usen Sphinx como motor de búsqueda en sus aplicaciones y que necesitan realizar búsquedas independientes de los acentos (buscar “jose” y encontrar “jose” y “josé”), les vendrá bien añadir este charset_table en el fichero de configuración de Sphinx.
Vía / Begin Rescue
Es cierto que a veces la carga del script de Google Analytics retrasa el carga completa de la página. La gente de AskApache, que suelen sorprenderme con sus entradas, nos ofrecen un truco para mejorar la velocidad de carga del script urchin.js.
Este script, que se carga del sitio de Google Analytics, a veces tarda en cargarse, por lo que una solución para agilizar esta carga es ponerlo en nuestro servidor y acceder en local.
Claro, que el problema es que este script se suele modificar con cierta frecuencia, por lo que deberÃamos tener la última versión en cada momento.
Crearemos una shell que borre el script de local, obtenga de nuevo el script alojado en Google Analytics y lo guarde en la ruta de local. A parte crearemos un job para el cron que ejecute este script cada 12 horas.
#!/bin/sh
rm /home/user/websites/askapache.com/z/j/urchin.js
cd /home/user/websites/askapache.com/z/j/
wget http://www.google-analytics.com/urchin.js
chmod 644 /home/user/websites/askapache.com/z/j/urchin.js
cd ${OLDPWD}
exit 0;
La lÃnea para el cron:
11 12 * * * /home/user/websites/1day.sh >/dev/null 2>&1
Cuando se trabaja en una empresa de desarrollo de software es muy común que entres en un proyecto que ya está empezado, por lo que deberás tratar con un código que no es el tuyo, y que da igual que sea bueno o malo, deberás adaptarte a él, algo que siempre puede dar algún problema. Más problemático es cuando sustituyes al único encargado del código y el traspaso de conocimientos se realiza en un par de horas (algo muy frecuente en las grandes empresas de consultoría).
Para aquellos que se encuentren en esas circunstancias, espero que los consejos que os voy a comentar, sacados de mi propia experiencia en el desarrollo web, os sean de utilidad.
Aún no sabes cómo es el código, si es bueno o es malo, pero un vistazo preliminar a la estructura de directorios y a los nombres de los ficheros suele darte una idea aproximada de la funcionalidad que pueden tener.
Por muy malo que sea un programador, éste tiene su propia lógica para la nomenclatura, échale un rato a intentar adivinarla y así podrás localizar ficheros de forma más sencilla en futuras modificaciones.
No esperes un diseño MVC claro, quizás ni exista y esté todo mezclado. Tú tienes tu forma de programar, pero aunque para ti sea perfecta, ni quizás lo sea, ni todo el mundo la comparte.
Lo más seguro es que no debas cambiar toda la aplicación de golpe, por lo que de poco te va a servir empezar a estudiarla completamente y entender todo su significado. Ve por partes, si tienes que hacer un cambio en una parte céntrate en esa parte del código y olvídate del resto.
Cuando te hayas pegado con una parte del código no se te olvidará fácilmente, por lo que si en otra ocasión tienes que volver a tocar esa parte te será más sencillo.
Afortunadamente el resultado del desarrollo web es visible para todos, tan solo debes ver el código HTML para ver qué se ha generado con la aplicación.
Normalmente, las modificaciones que se suelen realizar son del tipo “en tal página falla tal cosa”. Mira el HTML de esa página y encuentra algo que pueda ser exclusivo de ella.
Busca nombres de clases de etiquetas, las cabeceras de las páginas (<h1>..<h6>), textos explicativos. Una vez creas que tienes un texto más o menos exclusivo de esa página busca entre todo el código, por ejemplo en Windows puedes usar GlobalFind.
Debes tener cuidado porque a veces el código no aparece exactamente como lo buscas. Por ejemplo un texto largo puede estar dividido en varias líneas:
$texto = 'Texto largo que el desarrollador ';
$texto .= 'a cortado en líneas para verlo más claro, ';
$texto .= 'aunque sea menos eficiente por tener que ';
$texto .= 'concatenar strings.';O también puede darse la circunstancia de que el texto se forme por la unión de un texto y una variable:
$clase = array('empleados', 'facturas', 'resumen');
// Algo de código por aquí
echo '<div class="'.$clase[$tipo].'">...</div>';
// Más códigoQuizás te encuentres con ficheros de idiomas, y verás que el texto que buscas está asociado a un código, céntrate en ese código y búscalo.
La lógica del código es de todo menos lógica. Te vas a encontrar con partes de código que no vas a entender por mucho que lo estudies. No es bueno perder el tiempo intentando entender el código al 100%, ya tendrás tiempo para ello.
Cuando te encuentres con un trozo de código que no entiendas, métele trazas a todos los bloques para saber por dónde pasa:
echo 'Empezamos';
if ($condicion1 && $condicion7) {
echo 'Paso por aquí 1';
// código
if ($condicion3 || !$condicion4) {
echo 'Paso por aquí 2';
// código
} else {
echo 'Paso por aquí 3';
// codigo
if ($condicion5) {
echo 'Paso por aquí 4';
}
}
} else {
echo 'Paso por aquí 5';
// código
}
echo 'FIN';Fijándote en las trazas que devuelva verás que código se ejecuta y así podrás encontrar mejor el error.
La BD es muy importante a la hora de localizar información. Mucha gente usa la BD para almacenar los mensajes de error o de información, que serán fundamentales para comprender el funcionamiento de la aplicación.
Localiza dónde se ejecutan las consultas, si hay suerte estarán separadas del resto de código (normalmente a las clases que tratan con la BD se le llama modelos). Si tienes que modificar los datos que devuelve una consulta, aunque no sepas cómo se obtienen esos datos (la sentencia SQL exacta), si que puedes hacerte una idea de las tablas a las que accede. Busca entre los modelos el nombre de esas tablas y filtra por los campos que muestra en la página. Claro que el select * from puede ser nuestro mayor enemigo.
Examina los datos de la tabla para ver si coincide con los datos que se muestran. Un ejemplo sencillo es insertar un registro mediante la aplicación y ver qué se ha guardado en la BD, así entenderás más facilmente qué se guarda en cada campo.
En ellos está mucha de la lógica de la aplicación, estudiarlos durante un rato puede aclararnos muchas cosas, como por ejemplo rutas de ficheros, conexiones a la BD, sistema de trazas, clases auto-ejecutables…
Si programas en Java es posible que no encuentres el por qué de un problema porque quizás la ejecución dependa de un JAR externo. Localízalos y tenlos siempre presentes. Si trabajas con Linux o Unix puede que haya llamadas a la shell. Pasará algo parecido a los JAR, deberás saber dónde están y qué hacen.
No intentes poner la aplicación del revés o cambiarla radicalmente nada más empezar con ella. Ve poco a poco, con cambios sencillos, que te hagan enfrentarte con el código y empezar a conocerlo.
Los cambios que puedas realizar en una parte no sabes donde van a poder afectar, por eso debes ir con cuidado y empezando con cosas sencillas, que tendrán menos posibilidades de estropear otras cosas.
Reutilizar código no siempre es una norma para los desarrolladores. Aunque creas que has localizado el lugar dónde debes cambiar el código, no pienses que es el único lugar. Sigue buscando a ver si hay más lugares donde se deba cambiar.
No conoces la aplicación y no sabes que puedes estropear cuando tocas algo. Un cambio sin importancia puede hacer que todo falle, ten cuidado si arreglas algo de no estropear otra cosa.