¿Cómo implementar GD en PHP5 para Windows?

GD es una biblioteca de funciones gráfica usada por varias aplicaciones que generan imágenes dinámicamente. En el caso de PHP5 para Windows, se supone que los pasos para implementar GD son los siguientes:

• Descargar los binarios para Windows (gd-2.0.34-win32.zip)
• Descomprimir el zip y de la carpeta "bin" extraer el archivo "bgd.dll". Éste es equivalente a "php_gd2.dll" según http://www.boutell.com/gd/faq.html
• Renombrar "bgd.dll" como "php_gd2.dll" y ubicarlo en "c:\php\ext\" (o en la carpeta correspondiente a las extensiones de la instalación local de PHP5).
• Editar php.ini y asegurarse de que la carpeta de extensiones está correctamente configurada (por ejemplo extension_dir ="C:\php\ext") y que está habilitada la extensión gd2 (extension=php_gd2.dll).
• Reiniciar el servidor web (Apache o IIS).

Eso dice la teoría, pero al reiniciar Apache, me encuentro con este error:

PHP Startup: Invalid library (maybe not a PHP library) 'php_gd2.dll'

¿Alguna idea de por qué pasa y cómo resolverlo?

Voto electrónico en Colombia

Las críticas a cómo la Registraduría y el CNE han llevado las recientes elecciones parlamentarias han vuelto a poner sobre la mesa opciones como el voto electrónico. ¿Qué tan viable es en Colombia?

          Analicemos uno por uno los retos que enfrentaría el voto electrónico de ser integrado al sistema electoral: fraude por suplantación de los votantes, fraude en el conteo, demora en entrega de resultados y desconfianza de los abstencionistas.

          Para evitar la suplantación de los votantes los sistemas biométricos son mucho más fiables que la presentación de la cédula.  Aunque entre estos sistemas el de lectura de la retina sea preferido sobre el de la huella dactilar, el segundo es más fácil de implementar porque ya se dispone de las huellas.

          Aunque las ventajas del voto electrónico (del cual ya se hizo un piloto en las pasadas elecciones parlamentarias) son obvias ante el fraude en la mesa de votación y la demora, queda la desconfianza de los abstencionistas. Éstos podrían aumentar porque justamente lo que hace a la votación electrónica eficiente y segura es lo que impide que pueda auditarse. Al no haber tarjetones físicos no puede haber reconteo y el mandato constitucional de que el voto sea secreto inutiliza el mecanismo tradicional que hace fiables las transacciones electrónicas: saber quién hizo qué y cuándo.

          Una alternativa probada ya en Australia es que el software para procesar los votos sea de fuente abierta (open source). Así no hay temor de que se entregue la soberanía nacional al fabricante de un software propietario y que los académicos y profesionales del país estén blindando permanentemente al sistema contra intentos de fraude de particulares o de funcionarios del mismo gobierno.

          En conclusión, la identificación biométrica de los votantes sí puede ser una mejora importante que se podría implementar mientras se superan los obstáculos para un sistema de voto electrónico a nivel nacional. Y quién sabe, tal vez esté más cerca de lo que pensamos.

Cómo ver morir a Windows vía Twitter

Ahora, gracias a Twitter, ya es posible monitorear de manera gratuita las reacciones del público ante un producto o servicio. El caso más reciente es el de @WindowsDeath, un programa que está permanentemente monitoreando Twitter (un Twitter bot) y que registra cada vez que algún usuario trina (‘tuitea’) que Windows sufrió una caída fatal del sistema usando las expresiones "BSOD" (Blue Screen Of Death) o "blue screen".

          Este no es el primer caso. Ya algunos entusiastas habían programado sus propios ‘twitter bots’ para registrar cada vez que un televidente trinaba un comentario sobre sus series favoritas, por ejemplo LOST. La diferencia está en que esta es la primera vez que veo que un bot hace algo útil con la información, específicamente publicar el conteo total de caídas reportadas y el promedio diario (130 diarios a 14 de junio de 2009, después de sólo 12 días de monitoreo).

          Evidentemente este tipo de monitoreo tiene sus límites: el 76% de la población mundial todavía no tiene acceso directo a Internet, y de ese 24% de usuarios directos, sólo hay alrededor de 3.5 millones que tienen cuenta en Twitter. Eso nos deja con que sólo trina el 0,22% de los usuarios de Internet y el 0,05% de la población mundial. Sin embargo, si se tiene en cuenta que hay ciertos productos y servicios cuyo mercado es precisamente el de la minoría que usa computadores y servicios de Internet, entonces ese porcentaje que parecía tan pequeñito puede ser muy relevante. Como por ejemplo el de los usuarios de Windows.

Cómo consumir desde .NET 2.0 un webservice implementado con PHP 4.4.7/NuSOAP 0.7.2

En los servidores de alojamiento de bajo precio, lo más común es encontrar todavía PHP 4, que no tiene un soporte nativo a webservices en las clases base. En estos casos, hay que recurrir a opciones como NuSOAP, que no requiere extensiones adicionales que de todos modos no son fáciles de instalar y configurar en un servidor compartido.
          En el caso de NuSOAP 0.7.2 (la vigente en octubre de 2007), la forma más directa de implementar un cliente que pueda consumir el webservice es usando el WSDL suministrado por el servidor. Sin embargo, como la última versión liberada de NuSOAP data de marzo de 2004, no incluye soporte para la última especificación de Basic Profile 1.1 de la Web Services Interoperability Organization (WS-I), que es la soportada por .NET 2.0.
          Por esta razón, al intentar consumir desde .NET 2.0 un webservice implementado con esta configuración de PHP 4 / NuSOAP 0.7.2, se obtiene un mensaje de error como este:

The request failed with the error message:

--

<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">

<HTML><HEAD>

<TITLE>301 Moved Permanently</TITLE>

</HEAD><BODY>

<H1>Moved Permanently</H1>

The document has moved <A HREF=\"http://www.server.com/publish/services.php\">here</A>.<P>

</BODY></HTML>



--.

Esto ocurre porque el WSDL generado dinámicamente por NuSOAP en http://www.server.com/publish/services.php?wsdl no genera completa la dirección que el cliente .NET necesita para encontrar el servicio. Lo que el servidor genera es un <soap:address location="http://server.com/publish/services.php"/> (sin el “www”).
          Una forma sencilla de corregir esta situación es grabar la declaración del wsdl que genera el webservice como un archivo (por ejemplo services_wsdl.xml), de tal forma que se pueda publicar en el servidor donde los clientes potenciales puedan encontrarlo. En el archivo hay que completar a mano el wsdl así: <soap:address location="http://www.server.com/publish/services.php"/>
          De esta forma, en el proyecto .NET 2.0 en Visual Studio 2005 se puede usar como WSDL de base http://www.server.com/publish/services_wsdl.xml , tanto para generar una clase proxy usando la herramienta WSDL.EXE como para adicionar un Web Reference. Adicionalmente, hay que cambiar el archivo App.config del proyecto para que incluya la actualización de la ruta del servidor:

< applicationSettings >
  < Module.Properties.Settings >
    < setting name = " Module_com_server_www_publish " serializeAs = " String " >
      < value > http://www.server.com/publish/services.php </ value >
    </ setting >
  </ Module.Properties.Settings >
</ applicationSettings >

Eso es todo. Muchas gracias a Juan Camilo Rincón, sin cuya ayuda todavía estaría preguntándome qué changos le pasó al webservice que funcionaba tan bien al ser consumido desde NuSOAP.

Sentido del humor ñoño

Creo que ya entendí por qué después de 12 años trabajando como ingeniero, me han empezado a parecer divertidísimas las matrículas de carros como "DBA 073" o "FTP 532":

Cómo parchar una aplicación Windows Forms

Desarrollé una aplicación WinForms .NET 2.0 de escritorio con Visual Studio 2005 que usa una base de datos implementada en archivos XML. Generé un instalador con el proyecto "Setup" de VisualStudio2005 que ubica el programa (un ejecutable .exe y varios .dll) y los archivos XML en una carpeta dentro de "c:\program files".
          Generé un nuevo instalador con el proyecto "Setup" de VisualStudio2005 de la misma forma que el instalador original pero sin los archivos que no cambiaron y sin los XML para que no los sobreescribiera. Cuando lo ejecuté, Windows me regañó e interrumpió el proceso porque ya hay una versión previa de ese mismo software que ya está instalada.
          Gracias a la recomendación de Jaimir Guerrero probé cambiando el "Assembly version" y el "File version" en las propiedades de la aplicación. Ahora Windows se negaba a instalar argumentando que la versión existente era más reciente que la anterior (???). Entonces probé configurando el instalador para que no verifique si hay instalada una versión más reciente y ya Windows no protestó por la instalación previa, incluso decía que la instalación de la actualización finalizó con éxito, pero cuando probaba la aplicación, aparecía la original y no la actualizada.
          Probé entonces el método "xcopy deployment" sugerido por Ricardo González, que consiste en copiar vilmente los nuevos archivos (el ejecutable .exe y sus .dll) en la carpeta de la aplicación instalada. Aunque logré que un script hiciera la tarea más o menos automáticamente, cuando probaba la aplicación ahora Windows me respondía que la aplicación no coincidía con lo que había salido del instalador original y se rehusaba a ejecutar.
          Desesperado, fui hasta la carpeta misma de la aplicación y di doble clic directamente sobre el ejecutable y... funcionó. Por alguna extraña razón que espero me ayuden a aclarar, los accesos directos a la aplicación que mi instalador original puso en el escritorio, no abren directamente el ejecutable sino que usan algún intermediario que verifica que las versiones cuadren.

Conclusiones:
Al generar una actualización de una aplicación Windows Forms instalada con el instalador generado por el proyecto Setup de VisualStudio 2005 es necesario:

• Cambiar la propiedad "Version" por un número mayor. Esto provoca que VisualStudio proponga un nuevo valor para la propiedad "ProductCode", lo cual es necesario para que no haya colisiones con la versión previamente instalada.


• Si aún así Windows protesta, me funcionó cambiar también la propiedad "DetectNewerInstalledVersions" a falso. En teoría esto no es necesario si se ha actualizado la versión, por lo que supongo que hice algo mal.


• Siempre debe permanecer inalterada la propiedad "UpgradeCode" porque es la que permite a Windows saber que la actualización es otra versión de la misma aplicación y no otra aplicación completamente diferente.


• En el instalador de la actualización se deben incluir también los accesos directos para que sobrescriban los que ya estaban instalados, no solamente los archivos que cambiaron de una versión a otra. Esta es la razón por la cual el método "xcopy deplyment" es muy útil en aplicaciones web que no usan accesos directos regados por todo Windows, pero que exigen algo más de trabajo en una aplicación de escritorio.

Las rubias lindas también estudian Unix

No puedo creerlo, le gané al hombre burro en encontrar algo increíbe: que las rubias lindas también estudian Unix.