MailEnable : Imposibilidad de personalizar mensajes de bienvenida y despedida en listas de distribución de correo.

El servidor de correo MailEnable es bastante útil para su uso a pequeña e incluso gran escala en servidores Windows; no requiere muchos conocimientos avanzados para su puesta en marcha en cuestión de minutos, es cómodo de usar, bastante completo y su versión gratuita es más que suficiente para poner en marcha un servicio de correo a pequeña y mediana escala.

Sin embargo tiene una carencia que para mí resulta imperdonable y es el hecho de que no tiene prevista la internacionalización (o i18n), lo cual sumado a que tampoco permite la posibilidad de configurar los mensajes predefinidos que manda a sus usuarios en determinadas circunstancias, hace que sea poco útil para usuarios de habla diferente de la inglesa.

En concreto, es una pena que no sea posible configurar los mensajes de bienvenida y despedida a las listas de distribución gestionadas a través de este servidor de correo. Esta carencia me impide su utilización de una forma seria.

No he probado si las versiones de pago tienen prevista la i18n o la posibilidad de personalizar estos mensajes, sin embargo me he leído de cabo a rabo la lista de características de todas la versiones y la documentación, he dedicado horas a revisar la base de conocimiento online que tienen publicada y a leer posts en su foro oficial, y no he encontrado ninguna pista que me sugiera que en las versiones de pago existan estas opciones. Para mayor pena, su servicio de soporte es de pago para las consultas relacionadas con configuración, entorno o desarrollo. Sólo son gratuitas las consultas de instalación (estrictamente referidas al proceso de instalación), licencias, y actualizaciones.

Una pena de servidor de correo desperdiciado.

OpenX : Mis banners flash no cuentan clicks

Es posible que al dar de alta un banner flash en nuestro servidor de banners OpenX nos demos cuenta de que al cabo de unas horas la cuenta de clicks del mismo sigue en 0 (-) a pesar de haber realizado varios clicks de prueba sobre el mismo. La razón es sencilla: Dicho banner tenía el enlace codificado directamente dentro del mismo banner y OpenX no ha sido capaz de reescribirlo (a pesar de haber reportado que sí lo ha hecho). La razón para que esto ocurra es que para sobreescribir el código asociado a los enlaces “hard-coded”, OpenX presupone que el banner flash ha sido programado siguiendo unos patrones estándar de programación, sin embargo si dicho banner se ha programado de forma poco convencional, OpenX tendrá problemas para detectar y entender de la lógica de lo que está sobreescribiendo. En palabras tomadas de openx.org :

OpenX can’t check for every type of ActionScript and your link may be using non-standard code which is not easily detectable

Otro motivo por el que OpenX puede estar fallando a la hora de entender el código/reemplazar los enlaces del banner, es que dicho banner no haya sido producido con Adobe Flash, sino por una herramienta de terceros (hay muchas). En estos casos, el código generado también puede ser poco convencional, o simplemente la compresión realizada por dicha herramienta no ser reconocibel por OpenX. También en palabras de openx.org:

Also, if your swf banner was not created with Adobe Flash itself it could be compressed in a way that is not recognized.

La solución:
En estos casos y en general, es preferible utilizar el mecanismo que Adobe Flash pone a disposición de los usuarios para estandarizar la forma de asociar links a nuestros banners. Este estándar se llama clickTAG y es una manera de decirle a flash que ese contenido es enlazable y que dicho enlace será proporcionado desde fuera. La manera de asociar un clickTAG a un banner flash es decírselo a través del ActionScript asociado al evento release del botón asociado al banner (el que permitirá hacer el click). El código ActionScript recomendado es el siguiente:

on (release) {
	if (clickTAG.substr(0,5) == "http:") {
		getURL(clickTAG,clickTARGET);
	}
}

Notas acerca de este código:

  • La condición que rodea a la instrucción getURL no es necesaria pero sí muy recomendable para evitar que se inyecte código malicioso a nuestro banner por parte de terceros.
  • El segundo parámetro “clickTARGET” no es imprescindible, pero sí recomendable si queremos que el enlace se abra en una ventana diferente a la actual.
  • ActionScript es sensible al uso de mayúsculas/minúsculas, por lo que es importante escribir “clickTAG” y “clickTARGET” exactamente así. Por ejemplo “ClickTag” no tendría ningún significado para ActionScript.

Cómo migrar una tienda Prestashop de una ubicación a otra

Nota: Estas instrucciones son válidas para Prestashop 1.3, 1.4 y 1.5.

Los pasos a seguir para conseguir esta tarea son los siguientes:

1. Realizar backup de la base de datos de la tienda que se desea migrar:
mysqldump -u [usuario] -p -a [nombre_de_la_bd] > c:/ruta/backup.sql

2. Copiar los ficheros de nuestra tienda a la nueva ubicación.

3. Abrir el fichero /nueva_ubicacion/config/settings.inc.php y editar las líneas correspondientes a la definición de las variables __PS_BASE_URI_, _DB_NAME_, _DB_SERVER_, _DB_USER_ y _DB_PASSWORD_ para que se ajusten a la nueva ubicación y a la nueva base de datos.

4. Crear una nueva base de datos vacía e importar en la misma el backup previamente realizado.
mysql -u [usuario] -p -D [bd_nueva] < c:\ruta\backup.sql

5. Dar permisos al usuario designado en el paso 3 para que tenga acceso total a la nueva base de datos
grant all on [bd_nueva].* to [usuario]@localhost identified by "[contraseña]";
donde [usuario] y [contraseña] deben coincidir con los datos introducidos en el fichero settings.inc.php del paso3.

6. Nota: Este punto sólo es válido para Prestashop 1.3. Para 1.4 y 1.5 lee más adelante, el apartado actualizado el 20/03/2013.
Editar el valor de la variable de configuración PS_BASE_URI en la base de datos, cambiándolo por el de la nueva ubicación, que debe coincidir con el valor dado a la variable __PS_BASE_URI_ en el fichero settings.inc.php del punto 3.
update ps_configuracion set value="[nueva_ubicación]" where name="PS_BASE_URI";

7. Eliminar los archivos de la tienda de la ubicación original, así como su base de datos asociada.

Y listo, ya tenemos nuestra tienda en la nueva ubicación. Por supuesto se presupone que en la nueva ubicación ya hay un servidor web con php y mysql levantados.

Estas instrucciones son válidas también para clonar una tienda. En este caso simplemente basta con omitir el paso 7, y si alojamos el clon en la misma máquina que la tienda original, no es necesario dar de alta un nuevo usuario/contraseña para gestionar la BD, por lo que en el punto 3 sólo habría que modificar los 2 primeros parámetros y el grant hacia la nueva BD debería darse al usuario antiguo.

20/03/2013 - Actualización: Migrar Prestashop 1.4 y 1.5

Para migrar una BD de prestashop 1.5 es necesario realizar algunos cambios más:

  1. update ps_configuration set value="[nuevodominio.tld]" where name="PS_SHOP_DOMAIN" or name="PS_SHOP_DOMAIN_SSL";
  2. update ps_shop_url set domain="[nuevodominio.tld]",domain_ssl="[nuevodominio.tld]";
  3. Reemplazar en el .htaccess todas las referencias al antiguo dominio por el nuevo.

Si no se realizan estos cambios, la tienda nueva redireccionará a la URL de la tienda antigua.

OpenX : ¿Por qué mis banners tardan en verse? ¿Por qué tarda en actualizarse el conteo de clicks e impresiones asociados a mi banner?

Cualquiera que empiece a utilizar OpenX como servidor de banners por primera vez sin duda se hecho estas preguntas. La respuesta es sencilla: OpenX utiliza un sistema de caché propio para mejorar el rendimiento de la aplicación, lo que significa que los conteos no se escriben directamente a la base de datos sino que se actualizan cada X tiempo, donde X es un valor que podemos configurar; mientras tanto la información se mantiene en memoria o en un fichero de texto, dependiendo de cómo hayamos configurado el sistema.

El tiempo de caché por defecto es 20 minutos (1200 segundos), sin embargo esto puede ser un poco molesto cuando estamos haciendo pruebas para ver cómo queda un nuevo banner en nuestra página de destino, o para intentar comprobar que la contabilización se está realizando de manera correcta (lo cual puede ser necesario cuando se incluyen banners flash con enlaces ‘hard-coded’ o incrustados).

Para cambiar este tiempo por defecto lo primero que tenemos que hacer es cambiarnos al perfil de administración : Working as > Administrator Account, y posteriormente tenemos que ir al menú Configuration > Banner Delivery Settings y cambiar el valor Time Between Banner Cache Updates.

tiempo entre actualización de chache de banners

Es posible poner 1 segundo, lo que significa que la actualización será prácticamente inmediata, sin embargo es MUY IMPORTANTE acordarnos de dejar el valor por defecto o al menos un valor mayor no menor de 10 minutos cuando terminemos de realizar nuestras pruebas, sino el rendimiento de nuestra máquina puede resentirse en caso de estar sirviendo banners a algún site con muchas visitas.

Como burlar la papelera de Mac

Aunque habitualmente no trabajo con Mac, de vez en cuando tengo que lidiar con alguno de ellos. No tengo nada contra estas bonitas máquinas, pero siempre he preferido la versatilidad de los PCs, cuestión de gustos. Últimamente me he encontrado con un problema bastante sorprendente viniendo de un sistema operativo tan avanzado como el OSX Snow Leopard: siempre que se borra un fichero, este va a la papelera de reciclaje sin que se pueda hacer nada para evitarlo. Después de mucho buscar por la red tuve que aceptar con bastante sorpresa que este sistema operativo no tenía nada parecido al útil CTRL+Suprimir que permite eliminar algo de forma definitiva en Windows.

La imposibilidad de borrar ficheros sin utilizar la papelera es más que un problema de intimidad o de ocupación innecesaria de disco (la papelera resulta realmente muy útil, sin embargo hay cosas que uno sabe con seguridad que no va a necesitar en un futuro, así que ¿para que seguir ocupando espacio con ellas?), el problema se vuelve más grave cuando se trata de unidades externas de poca capacidad como un pendrive con capacidad de -digamos- 1GB. El problema es que al eliminar un fichero de este dispositivo, OSX en realidad lo guarda en un fichero temporal dentro del mismo pendrive, lo que significa que si tengo un fichero guardado de 1GB y lo borro para poder grabar otra cosa en él, sencillamente no podré hacerlo porque el fichero de 1GB sigue ahí aunque no lo veamos. La única forma que hay de recuperar nuestro espacio es vaciando la papelera… ¿Pero y si en la papelera hay cosas que tal vez vaya a querer recuperar en un futuro? ¿no es posible -al menos- borrar ficheros selectivamente de la papelera?… NO, no es posible, así que el sistema operativo nos deja vendidos: o borramos la papelera entera o nos quedamos sin espacio en el pendrive.

Afortunadamente hay una solución. No es la solución ideal y seguramente no gustará mucho a quienes no estén acostumbrados a utilizar la consola, pero merece la pena conocerla, pues el contenido de nuestra papelera puede salvarnos de un desastre cuando menos lo esperamos y su contenido merece un respeto. La solución es bien sencilla :
1. Abrir una consola (Aplicaciones > Utilidades > Terminal.app)
2. Cambiar al directorio en el que reside el pendrive, que estará bajo /Volumes : cd /Volumes/PendriveJuan/ (atención a las mayúsculas y minúsculas). El nombre del dispositivo que buscamos es el que se muestra automáticamente en el escritorio al insertarlo. Si dudamos, cd /Volumes > ls nos dará un listado de los dispositivos disponibles.
3. Utilizar el comando rm (remove) para eliminar los ficheros deseados. Este comando se salta por completo a la papelera de reciclaje, así que acto seguido podemos cerrar la consola y guardar cuantos ficheros nuevos queramos en nuestro dispositivo dejando a buen recaudo el contenido de nuestra papelera de reciclaje.

Esperemos que Apple enmiende y pronto su estupendo OSX incorpore la posibilidad de saltarse la papelera de una manera más “a lo Mac” a la que tiene acostumbrados a sus seguidores.

Problemas para subir ficheros en PHP bajo configuraciones Windows + IIS6

El problema: Script PHP perteneciente a cualquier aplicación que debería subir imágenes al servidor vía HTTP y no lo hace. El script se ejecuta en entorno Windows + IIS6. La versión de PHP puede ser cualquiera <= 5.3.1 (podría ser también mayor, pero hablo sólo de lo que yo he probado). Varias veces me he encontrado con el mismo problema, y varias veces me ha hecho perderder el tiempo. La primera vez hasta una semana dando tumbos por la red intentando averiguar el motivo de dicho comportamiento, revisando los permisos de las carpetas de la aplicación involucradas en el proceso, revisando los scripts, revisando la configuración del php.ini, y hasta dando permisos excesivos a usuarios potencialmente peligrosos para la web. El resto de veces sólo he perdido unos minutos hasta que recordaba: ¡Ah sí, los permisos de la carpeta temporal de Windows!.

Efectivamente, el problema es que PHP sube los ficheros a una carpeta temporal antes de pasarla a su ubicación final. Esa carpeta temporal puede variar en cada instalación, pero por defecto sería “c:\windows\temp\”. Es preciso verificar el valor de la variable de configuración “upload_tmp_dir” en el php.ini para asegurarse de cuál es la carpeta correcta en nuestra instalación.

Y la solución es tan simple como otorgar permiso de escritura a esta carpeta al usuario IUSR_{NOMBRE_DE_LA_MAQUINA}. Mi recomendación es configurar el php.ini para que esta carpeta no sea “c:\windows\temp\”, sino una carpeta diferente como por ejemplo “c:\php\temp\upload\” por motivos de seguridad evidentes.

Cambiado esto, y supuesto que todas las demás cosas evidentes relacionadas con la subida de ficheros estén configuradas, todo irá sobre ruedas.

Problema de brillo en pantallas del nuevo iMac. La mala idea del glossy

Hace poco más de un mes compré un iMac de los nuevos con pantalla de 27″. Una preciosidad de máquina que funciona más que bien. Pero siempre hay un pero: tienen una pantalla que es incomodísima de usar porque brilla mucho. Para ver una película a oscuras es perfecta, pero para trabajar 8 horas delante de la misma resulta horrible. Y no soy el único que lo dice, a poco que se busque en internet, hay un montonazo de personas quejándose de este problema que produce dolores de cabeza, cansancio visual, dolor de cuello y espalda (debido a las malas posturas que hay que adoptar para conseguir ver bien según la iluminación de nuestro sitio de trabajo), etc., sin embargo, aunque es muy fácil encontrar las quejas, es más difícil encontrar una solución. Por parte de Apple hay mutis total, nadie dice ni pío. Según ellos todo el mundo quiere las pantallas glossy y no dan más explicaciones.

Pero navegando navegando he encontrado una solución de lo más sui-géneris. La apunta Joshua Sowin, un tipo que tiene un blog en el que habla de todo un poco y en el que comenta que después de intentar la solución más “lógica” y de descubrir que era peor que el problema, optó por una solución más drástica. La solución lógica consistía en el uso de un filtro que se pone por encima de la pantalla vendido por la empresa Photodon. Según Joshua y otros muchos usuarios de los que he leído comentarios relacionados con este filtro se produce en la pantalla un efecto de granulado que es inaceptable prácticamente para cualquier trabajo. La solución menos lógica pero mucho más efectiva consiste en quitar la capa protectora que recubre la pantalla del Mac.

El artículo completo de Joshua se puede leer aquí: http://www.fireandknowledge.org/archives/2009/04/21/a-free-easy-way-to-make-your-glossy-imac-screen-glare-free/

Se incluye un video demostrativo de cómo quitar y volver a poner la capa ¿plástica? que hay por delante de la pantalla y que es la que produce la mayor parte del molesto efecto glossy. Yo lo he hecho después de vencer el miedo inicial a romper la pantalla y he de decir que es increíblemente fácil y además es muy difícil que algo salga mal. Esta capa protectora está adherida al ordenador por magnetismo, así que sólo hay que ejercer un poco de presión en sentido inverso y se despega como por arte de magia. De todos modos recomiendo mucho ver el video antes de hacerlo.

La solución es buena además de genial, sin embargo evidentemente queda el marco de la pantalla al descubierto y se ven algunos tornillos y demás parafernalia que podría se peligrosa en una casa con niños (por poner un ejemplo), pero en un entorno de oficina no debería haber mayor problema.

Finalmente he de decir que este truco no soluciona el problema por completo porque la pantalla que hay detrás también produce reflejos, pero están lejos de ser lo molestos que son los que produce la capa protectora. Como sugiere alguien en los comentarios que se hacen en el blog de Joshua, sería un negocio redondo fabricar recambios de estas capas protectoras que no tengan el efecto glossy o incluso que eliminen por completo los reflejos de la pantalla. Quien lo fabrique probablemente se haga de oro. Si hay alguien por ahí que me avise, ¡yo compro uno!

Problema de caracteres al importar una base de datos UTF-8 en MySQL

Muchas veces es necesario trasladar bases de datos de una máquina a otra por múltiples motivos (cambio de proveedor, cambio de máquina de desarrollo, etc). La manera más cómoda de hacerlo, si se tiene acceso a las consolas MySQL de ambas máquinas es realizar un volcado en sql desde la máquina origen mediante el comando mysqldump y luego restablecer dicho volcado en la máquina de destino inyectando el script volcado anteriormente mediante la línea de comando de mysql:

mysql -h host -u usuario -p -D basededatos < fichero.sql

Si el servidor de origen y el servidor de destino están configurados exactamente igual en lo que a conjuntos de caracteres se refiere, no habrá ningún problema, sin embargo si las configuraciones son diferentes (el caso más común es utf-8 por un lado y latin-XXX por otro), al utilizar la nueva base de datos observaremos que los caracteres especiales se han convertido en ristras de caracteres raros. La manera de realizar la importación correctamente es utilizar el parámetro "--default_character_set", de modo que la línea de comando quedaría algo así:

mysql -h host -u usuario -p --default_character_set utf8 -D basededatos < fichero.sql

Es importante darse cuenta que este problema no tiene nada que ver con la conexión a la base de datos que se utilice en la aplicación en el nuevo host sino que se trata de un problema relacionado estrictamente con la utilidad de importación de mysql.

Instalación de Eventum 2.2 en un servidor Windows, con IIS

– Instalar PHP.
– Instalar MySQL.
– Instalar las extensiones GD y MySQL de PHP.
– Descargar y descomprimir los archivos de Eventum en una carpeta accesible vía web.
– Crear una base de datos vacía con el nombre que se desee y un usuario con permisos totales sobre dicha base de datos.
– Acceder a dicha carpeta vía web. El sistema nos lleva automáticamente a una pantalla de configuración. Rellenarla con los datos solicitados, en concreto el usuario y la base de datos creada anteriormente. Tener a mano también la información de configuración de la cuenta de email que se utilizará para realizar envíos de correo. Dado que es fácil que falle algo la primera vez, es conveniente marcar la opción “Drop Tables If They Already Exist”, que nos garantiza que podremos volver a ejecutar la instalación si algo falla sin obtener errores de tablas duplicadas.
– Si obtenemos el error : “Details: BLOB/TEXT column ‘sup_to’ can’t have a default value” se deberá a que el servidor de base de datos utilizado es MySQL>=5 y por defecto corre en un modo algo más estricto que las versiones anteriores. La solución es cambiar la forma en la que MySQL arranca eliminado el flag “STRICT_TRANS_TABLES” DE SQL Mode. Esto se puede hacer fácilmente con el MySQL Administrator accediendo a startup variables > Advanced > SQL mode.
– Finalmente, si todo ha ido bien, obtendremos una pantalla informándonos de que Eventum ha sido correctamente configurado y que está listo para ser usado. Lo último que deberemos hacer es o bien borrar la carpeta “setup” de Eventum, o bien cambiarle los permisos para evitar que pueda ser accedida sin nuestro conocimiento, ya que si se deja abierta, cualquier usuario externo podría cambiar nuestra configuración y estropear nuestra instalación.

¿Qué es Eventum?

Por si alguien está leyendo esto pero no sabe qué demonios es Eventum, se trata de un sistema que entra en la categoría de issue/bug trackers. Este tipo de sorftware está diseñado para permitir llevar un control detallado de todas las cuestiones relacionadas con el desarrollo de software, desde la anotación de bugs y planificación para su corrección, hasta la planificación de inclusión de nuevas características, tiempos de desarrollo, fechas previstas así como planificación de versionado. Resulta especialmente útil en entornos de desarrollo colaborativos.

Coca, cocaína, Sigmund Freud y Coca Cola

Recientemente he escrito un artículo para elherbolario.com sobre la hoja de coca. Este es un pequeño extracto:

“[…] ¿Qué diferencia hay entre coca y cocaína?. A nivel de definición es fácil: la cocaína es uno de los 14 alcaloides de la coca. Esto quiere decir, que si juntamos muchas hojas de coca y por algún procedimiento X las hacemos polvo, no obtendremos cocaína, sino una sustancia de 14 alcaloides junto con otra cantidad de elementos químicos no alcaloideos cuyo efecto poco tiene que ver con el de la cocaína. Dicho de otra manera y para corregir la definición que dio Freud, la cocaína no es un concentrado de hoja de coca, sino más bien un concentrado de un componente de esta hoja. Por si fuera poco, la concentración de cocaína en la hoja de coca es muy baja y por lo tanto ingerida de forma natural no produce toxicidad grave ni genera dependencia, sino que actúa como un estimulante leve mejorando la atención y coordinación de ideas, entre otros beneficios. Siendo simplistas se podría decir que el efecto que produce una ingesta natural sería el mismo que el de tomarse un café cargado[…]

[…] los estudios modernos demuestran que una hoja contiene aproximadamente 0.7mg de “hasta” 14 alcaloides. […] en los cultivos mejor conseguidos (los realizados por encima de los 1.500msnm tienen más concentración de cocaína que los realizados por debajo de esta altura) la cocaína supone aproximadamente un 2% de los alcaloides totales de la hoja, lo que significa que se pueden obtener 0.7mg x 0.02 = 0.014mg de cocaína por hoja de coca en el mejor de los casos. Haciendo una simple multiplicación podemos deducir que para obtener 1gr de cocaína harían falta 1000/0.014 = 71429 hojas de coca […]”

Si quieres puedes seguir leyendo el artículo completo.

@jfcapristan