Mi rincón en Internet

Este “post” me sirve de repaso y recordatorio de mis herramientas más o menos habituales de desarrollo web. Mi trabajo habitual es con PHP en el servidor y los típicos HTML, CSS y JavaScript en el navegador. También suelo utilizar Python en el servidor para tareas programadas (cron) y otros desarrollos.

Todas estas herramientas son libres (o al menos, gratuitas) y multiplataforma: de hecho trabajo indistintamente en equipos con Windows, Mac OSX y Linux.

• IDE
  Aunque sea un tanto pesado, Eclipse es una herramienta estupenda, por lo menos para mí. Los ‘plugins’ que más utilizo son:
  • SFTP Plug-in for Eclipse.
  • PDT (PHP Development Tools).
  • PyDev para desarrollar en Python.
  • Aptana es un IDE construido sobre Eclipse para desarrollo web.
• Editores
  Para edición más o menos rápida, un editor genérico con resaltado de sintaxis y alguna otra monería siempre viene bien.
  • En Windows, utilizo SciTe y ContText.
  • En Linux, SciTe o Kate.
  • En el Mac, TextWrangler.

  El editor jEdit también es una opción estupenda, a medio camino entre un editor sencillo y los IDEs más pesados. Hay multitud de plugins muy útiles ((S)FTP, HTML, PHP, …)

• Clientes (S)FTP
  Imprescindibles para subir archivos al servidor o editar “in situ”. No me gustan los clientes FTP tradicionales en los que editas en local y luego subes, para arreglos rápidos no es cómodo bajar, editar y subir.
  • Para Windows, WinSCP. Puede funcionar como cliente de (S)FTP tradicional o se puede configurar para editar en el mismo servidor.
  • Para Mac, la herramienta MacFusion permite montar como unidades locales servidores FTP o SFTP.
  • En Linux se puede utilizar el mismo administrador de archivos (Konqueror o Nautilus) para acceder a servidors FTP o SFTP.
• Navegadores
  Aparte de tener instalados todos los navegadores posibles, conviene tener un navegador que permita depurar, inspeccionar código fácilmente, …
  El navegador Firefox tiene muchas extensiones útiles para desarrolladores web. Mis preferidas son:
  • Web Developer. Entre sus muchas funcionalidades destacan la posibilidad de controlar las cachés del navegador, las “cookies”, validar código “on-line”, regla para medir distancias en pantalla, …
  • Firebug. Permite inspeccionar el árbol DOM del documento activo, seleccionar elementos, editar estilos, depurar JavaScript, analizar el tiempo de carga de una página, … Imprescindible.
  • Professor X. Proporciona información sobre las cabeceras HTML.
• Servidor web y BBDD
  Muchas veces es conveniente hacer los desarrollos en un servidor local antes de subirlo a los servidores “corporativos”. Aunque en algunos S.O. (Linux y/o Mac) viene ya habilitado el servidor web, no siempre nos sirve (por problemas con versiones de Apache/PHP, MySQL o lo que sea).
  Existen algunas distribuciones que empaquetan un servidor web (Apache), PHP y un servidor de BBDD (MySQL, generalmente). El proyecto Xampp proporciona distribuciones para distintos S.O. (Windows, Linux o Mac OSX) muy cómodas y sencillas de usar.

Curioseando un rato ya encontré la forma de depurar PHP con Eclipse. Eso de saber por dónde va el código a base de sentencias echo y var_dump no es muy serio.

La empresa Zend proporciona un “plugin” basado en PDT que incorpora un producto llamado “Zend Debugger”. En el momento de escribir ésto la versión “estable” de PDT es la 0.7, si bien existe una versión 1.0 que sólo funciona con Eclipse 3.3. El plugin que proporciona Zend se basa en PDT 1.0, pero funciona con Eclipse 3.2.

La instalación es muy fácil, en la página de Zend se describe. Sobre una instalación de Eclipse sólo hay que irse al “Update Manager”, poner la URL de Zend (http://downloads.zend.com/pdt) y listo.

Al grano. Veamos cómo se depura.

Tenemos un script muy sencillo (hola.php):

<?
$uno = "Hola, ";
$dos = "mundo";
echo $uno . $dos . "!";
?>

Veamos cómo se depura. Creamos un “PHP Project” y un archivo “PHP file”.

Haciendo doble click en el margen del editor de código se añade un punto de interrupción.

Con el botón derecho, damos al menú “Debug as PHP Script”. Se nos cambia a la perspectiva de PHP Debug y empieza la fiesta: podemos examinar y modificar el contenido de variables, poner más puntos de interrupción, saltar funciones, lo típico en un depurador.

Lo que todavía no he conseguido es depurar las peticiones enviadas por el navegador (”Debug as PHP Web Page”). Estamos en ello

Es la primera vez que un desarrollo chapuza llega a los medios de información generalistas y al gran público. Por supuesto, estoy hablando de la página web del Congreso de los Diputados.
Lo que comenzó siendo una crítica de algunos desarrolladores a una web realmente mal hecha ha terminado siendo un tema de conversación y de preocupación para el ciudadano de a pie.
Lo triste es que no es la primera vez que ocurre, sobre todo en desarrollos para la administración, donde el control del producto final no suele ser tan estricto como en corporaciones privadas.

Todos/as los que vivimos de esto sabemos cómo se trabaja en las grandes consultoras y empresas de desarrollo de software (hay excepciones, por lo visto: no todo va a ser malo)

Proyectos mal planificados y peor gestionados. Venta de “humo”. Buzzwords. Incompetentes dirigiendo equipos y proyectos ^[1]. Intereses creados –”partners”. Becarios “vendidos” a los clientes como expertos. Subcontratación. ¿Seguimos?

Ya está bien de tomaduras de pelo. A ver si a partir de ahora los clientes, los usuarios, la administración y la opinión pública en general se van concienciando de que las cosas se pueden hacer bien, pero si hay voluntad de hacerlas bien. Lamentablemente, hoy por hoy, lo que impera en el mercado no es la calidad del producto sino los beneficios y la supuesta rapidez en el desarrollo.

Nunca se han tenido tantas metodologías, herramientas y técnicas disponibles para el desarrollo de software (OOP, UML, Patrones de Diseño, bla, bla, bla, …) De nada sirven si lo que al final tenemos es una porquería de producto.

Si una empresa privada quiere malgastar su dinero contratando desarrollos con consultoras con renombre pero cutres en el fondo, peor para esa empresa. Pero un desarrollo para la administración lo pagamos todos/as. No puede consentirse que estas chapuzas salgan a la calle.

Es obligatorio por ley que las páginas web de la administración sean accesibles. No vale con colocar el iconito de WAI, como hacen en muchas webs. Es ilegal hacer eso.

[1] Acabo de leer un artículo sobre esto en Fogonazos (mis felicitaciones a su autor). Lo clava.

Estoy empezando a cacharrear con Wordpress, su API y la posibilidad de desarrollar temas personalizados.

Ya sé que Wordpress no es la herramienta más adecuada para utilizar como gestor de contenidos (CMS), pero es que me encanta su sencillez y facilidad de uso.

El mayor problema que me estaba encontrando era el siguiente: cuando se tienen varias categorías anidadas, al seguir el enlace de la categoría “madre”, ésta mostraba todas las entradas de sus categorías “hijas”, aunque ella misma no tuviese entradas. Esto está bien para un “blog”, pero no era lo que yo necesitaba.

Lo que quiero es lo siguiente: al “pinchar” en el título de la categoría “madre” mostrar la descripción de la categoría o algo similar si no tiene entradas, pero no mostrar las entradas de sus “hijas”.

Cacharreando un poco, ya he encontrado la manera de hacerlo. Ej. del fichero archive.php:

Estamos “dentro” del código <?php if (have_posts()) : ?> y del <?php while (have_posts()) : the_post(); ?>

La función single_cat_title(”, false) nos devuelve la categoría actual (por ejemplo, el nombre de la categoría “madre”), la función get_the_category() nos devuelve todas las categorías a las que pertenece una entrada, así que sólo hay que comparar si son la misma o no.

Nuestro archive.php queda así, más o menos:

<?php$categoria = get_the_category();
if (single_cat_title('', false) == $categoria[0]->cat_name) {
?>
    <div class="post">
    </div>
<?php  } ?>

En el blog “MalaWeb” se analizan páginas y sitios Web mal hechos o chapuceros.
No lo actualizo con frecuencia, pero los análisis son bastante concienzudos.