| 5 anteriores >> |
|
En un blog, el pasado suele estar abajo a la derecha, y el futuro, arriba a la izquierda. Por lo general, no queda sitio para el presente.
NOTA: Es curioso lo que ha pasado con este post que habla del Tiempo. Sin razón aparente o conocida, su registro horario se ha visto afectado y ahora aparece en primer lugar. No seré yo el que vaya en contra de este capricho de la tecnología o del azar, de manera que permanecerá en este lugar como estandarte de una de mis mayores obsesiones. |
Siempre he tenido entendido que la economía funciona si se mueve el capital, por ejemplo si los consumidores se gastan parte del dinero que ganan. Pues bien, si el gobierno ha subido el IRPF, pretende subir dos puntos el IVA y tiene intención de que no compremos ropa barata, ¿cómo vamos a salir de la crisis? |
Poniendo a punto Agile Mailer, un sistema de envío masivo de correo-e (pronto, un enlace, lo prometo), me he encontrado con problemas de SPAM, concretamente con Windows Live (Hotmail para los veteranos). Tras darle más de dos vueltas, he llegado a la conclusión de que se trataba de los headers, y por el resultado de las pruebas empíricas, diría que el problema estaba en el X-Mailer. Finalmente, la definición óptima se resumen en la siguiente lista: - Organization
- Reply-to
- From
- X-Mailer
Veámoslo con un ejemplo: $message = Swift_Message::newInstance() ->setSubject('Asunto')
->setFrom(array('emisor@dominio.org' => 'Nombre del emisor'))
->setTo(array('receptor@dominio.org' => 'Nombre del receptor'))
->setBody($body, 'text/html');
$headers = $message->getHeaders();
$headers->addTextHeader('Organization', 'Nombre del emisor');
$headers->addTextHeader('Reply-To', 'Nombre del emisor <emisor@dominio.org>');
$headers->addTextHeader('From', 'Nombre del emisor <emisor@dominio.org>');
$headers->addTextHeader('X-Mailer', 'SwiftMailer v4.0.6');
Hecho esto, deberían terminarse los problemas relacionados con el SPAM. No obstante, conviene repasar este documento de recomendaciones para evitar que tus envíos acaben en lugar indebido. |
El otro día me invitaron a probar GNOSS, y aunque he tardado en dedicarle el tiempo que merece, la experiencia ha sido bastante positiva. ¿Qué es GNOSS? Tal y como se definen ellos mismos, GNOSS es un sitio social diseñado para conectar inteligencias e intereses por medio de su red de comunidades; permite compartir, crear y distribuir conocimiento y desarrollar procesos de pensamiento colectivo y deliberación on-line.
Ciertamente se trata de una iniciativa altamente interesante, con una excelente gestión de las etiquetas y un sistema de relaciones entre personas, organizaciones y conocimiento que, aun sin haberlo podido explotar (este tipo de activos requiere tiempo), tiene una concepción teórica bien diseñada y prometedora. Su mayor potencia está en el uso de la web semántica, de la que ya hablamos hace tiempo, ya que permite establecer relaciones entre las entidades por conceptos casi humanos, en lugar de los meramente informáticos. Con el tiempo, y gracias a las aportaciones individuales, este tipo de sistemas adquiere cierta inteligencia propia que perfecciona dichas relaciones. Una característica que me ha llamado especialmente la atención es la posibilidad de definir facetas o aspecto de uno mismo. La definición de curriculum o trayectoria profesional no es nada convencional. En primer lugar, se pueden dar de alta tantas biografías (así se llaman) como se desee, y es un auténtico gustazo rellenarlas porque se estructuran en cuatro o cinco preguntas sencillas y sin rodeos. No obstante, he detectado un par de carencias que me gustaría exponer al equipo de desarrollo. Antes, eso sí, quiero dejar claro que llevo poco tiempo en la plataforma y algunas de mis observaciones pueden estar originadas por el desconocimiento. Dicho esto, me da la sensación de que GNOSS está aislado del mundo exterior. Echo en falta integraciones con otros sistemas, con otras redes sociales. Por ejemplo, sería de gran utilidad poder buscar a nuestros contactos no sólo por intereses o tags, sino también importándolos de GMail, Friend Feed, etc. Tampoco vendrían mal iconos para compartir el conocimiento interesante de GNOSS en otras redes sociales. Por último, creo que las etiquetas deberían tener mayor importancia, ser omnipresentes en todas o casi todas las vistas de la navegación. Ya sería de nota que fueran contextuales según la zona que estuviéramos visitando. Objeciones aparte, creo que GNOSS puede convertirse en un gran centro de conocimiento e intercambio profesional, principalmente porque, según parece, su equipo es bastante activo en las redes sociales y presta atención a sus usuarios. Si la gestión de los principales activos (profesionales y conocimiento) no se descuida y se potencia una mayor apertura de la plataforma, podríamos estar hablando de revelación para el 2010. |
Hace tiempo sufrí la extraña manera de JavaScript para gestionar el contexto de los objetos, concretamente de la palabra reservada this. Veamos un ejemplo de código JQuery: $.each( this.fields, function(i, field) { if (field.required && this.isNull(field)) { this.put(field, "El campo + $(field.labelId).text() + es obligatorio");
ret = false;
} else if(field.email && ! this.validateEmail(field)) { this.put(field, "El campo + $(field.labelId).text() + no es una dirección válida");
ret = false;
} }); Esta función forma parte de una clase, así que pensamos que se puede hacer uso de this para referenciar miembros de la misma. Sin embargo, la llamada this.validateEmailprovocará un error indicando que validateEmail no es una función. La explicación es que esa llamada sucede dentro del ámbito de una función nueva, $.each(this.fields, function(i, field)..., por lo que el contexto de this se pierde. En Prototype, al menos, se resolvía con un binding, que consiste en agregar .bind(this) al final de la función, de esta forma: $.each(this.fields, function(i, field) { if (field.required && this.isNull(field)) { this.put(field, "El campo + $(field.labelId).text() + es obligatorio");
ret = false;
} else if(field.email && !this.validateEmail(field)) { this.put(field, "El campo + $(field.labelId).text() + no es una dirección válida");
ret = false;
} } .bind(this)); Pero esto no funciona en JQuery, así que tras algunas búsquedas infructuosas, he tenido que improvisar y he hallado un método que funciona. Consiste en asignar this a una variable, que uso en lugar de la palabra reservada: var self = this; $.each( self.fields, function(i, field) { if (field.required && self.isNull(field)) { self.put(field, "El campo + $(field.labelId).text() + es obligatorio");
ret = false;
} else if(field.email && ! self.validateEmail(field)) { self.put(field, "El campo + $(field.labelId).text() + no es una dirección válida");
ret = false;
} }); De esta forma, podemos seguir usando los atributos y métodos de nuestra clase sin temor a perder el contexto. P.S.: Sé que podría usar el plugin validation de JQuery, pero no he visto que funcione a no ser que el formulario se envíe. En mi caso, ni siquiera estoy usando formularios. De todas formas, acepto sugerencias.
|
| 5 anteriores >> |
|
|
