
jueves, 12 de julio de 2007
miércoles, 11 de julio de 2007
WinMMA
Como comentaba en otras entradas, utilizo bastante el programa MMA. Al ser un programa en línea de comandos y con un fuerte "sabor UNIX" los usuarios de Windows pueden encontrarlo un poco árido y difícil de utilizar.
El proyecto WinMMA pretende ayudar a los usuarios de Windows que quieren utilizar MMA. Actualmente consta de un instalador que incluye MMA, documentación, un editor de texto (SciTE) preconfigurado y un editor "visual" (LeMMA) y otros archivos de soporte (intérprete de Python, librerías, etc).
El proyecto WinMMA pretende ayudar a los usuarios de Windows que quieren utilizar MMA. Actualmente consta de un instalador que incluye MMA, documentación, un editor de texto (SciTE) preconfigurado y un editor "visual" (LeMMA) y otros archivos de soporte (intérprete de Python, librerías, etc).
miércoles, 4 de julio de 2007
Tira nº 53: el anuncio de un regreso
domingo, 1 de julio de 2007
Depurar PHP con Eclipse
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 ;-)
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 ;-)
sábado, 23 de junio de 2007
¿Punto de inflexión?
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.
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.
Suscribirse a:
Entradas (Atom)