martes, 22 de diciembre de 2009

Enlaces y "popups" accesibles

A veces nos surge la necesidad de forzar que un enlace se abra en una ventana nueva o "popup". El problema es que debemos mantener el HTML válido para que estos enlaces sean seguidos por motores de búsqueda o puedan ser utilizados por navegadores sin Javascript.

En todos los sitios se ve el típico tutorial que dice "... utiliza el window.open() de Javascript ...". Efectivamente, hay que usarlo, pero sin obstruir ni hacer HTML chapucillas.

Vamos a presentar 3 formas de abrir un "popup", una "mala" y dos mejores.
  1. Con HTML "guarrete":
        onclick="window.open('http://davidasorey.net',
            'popup1', 
            'height=800,width=600,resizable=1,scrolling=1')">Enlace 1

    Fatal. El destino de este enlace está "falseado". A veces también nos podemos encontrar algo como:
    <a href="void(0)">
    Esta forma de hacer los "popups" puede ser aceptable sólo si explícitamente queremos que este enlace no se siga.

  2. Un poco mejor, dejando un href correcto:

    <a href="http://davidasorey.net/" target="popup2"
        onclick="window.open('', 
            'popup2', 
            'height=800,width=600,resizable=1,scrolling=1')">Enlace 2</a>
    
    
    Aquí jugamos con el atributo "target". El evento "click" abre una ventana "vacía" pero con un identificador "popup2". Cuando el navegador va a abrir el enlace, ya encuentra una ventana con este identificador y abre el enlace en esta nueva ventana.
    Es una mejora, desde luego: el enlace ya es un enlace "real" e indexable.

  3. Una solución sin Javascript "inline":

    <a class="popup3" href="http://davidasorey.net/">Enlace 3</a>

    Obviamente, esta es la solución más limpia, pero requiere un poco más de trabajo adicional.
    Con jQuery (se puede hacer con cualquier otra librería o "framework") hay que "capturar" todos los enlaces con la clase "popup3" y alterar su comportamiento:
    $(document).ready(function (d) {
     $('a.popup3').click(function (e) {
      e.preventDefault();
      var href = $(this).attr('href');
      window.open(href, 
                 'popup3', 
                 'height=800,width=600,resizable=1,scrolling=1');
     });
    });

    En pocas líneas alteramos el comportamiento de todos los enlaces con la clase 'popup3'. Nos ahorramos andar escribiendo el código Javascript en el evento onclick y todo el código y control de este comportamiento está en un sólo punto.

miércoles, 2 de diciembre de 2009

Manifiesto: "En defensa de los derechos fundamentales en internet"

Algunos argumentos o puntos de este "manifiesto" me chirrían un poco. Que conste que no estoy defendiendo este anteproyecto, en absoluto, pero si queremos que no salga adelante, las argumentaciones deben ser más sólidas.
Punto 4 del manifiesto: "La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. [...]"

Según el proyecto, "los órganos competentes podrán imponer a los prestadores de servicios que vulneren la propiedad intelectual en Internet el cese en tal práctica o la retirada del material". ¿Cómo puede esto afectar negativamente a un nuevo creador que, por ejemplo, publica su obra en la red con alguna licencia libre? ¿Entorpece en algo esto a un compositor o a un guionista? No veo la relación.
Punto 5 del manifiesto: "Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. [...] Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo."

¿Quiénes somos nosotros para dictar a un trabajador cómo debe plantear su negocio? ¿Me puede sugerir alguien alguna alternativa viable para una multitud de autores y artistas que no viven del directo?
Estoy realmente cansado de leer y escuchar la típica frase "... los músicos quieren vivir de las rentas ..." o "... que dejen descargar la música gratis y ya les veremos en directo ...". Quien argumenta así, no se ha parado a pensar en las "características" de la profesión "artista". Simplifican y aplican los mismos parámetros que podrían ser aplicables a  unos pocos artistas superventas privilegiados al resto.

La vida de muchísimos músicos es muy dura (ojo, estoy hablando de músicos, no de triunfitos ni nada similar). Años y años de estudio, inestabilidad laboral, en muchos casos, conciertos y giras en una furgoneta noche tras noche (no todos viajan en "jets" o superautocares lujosísimos). Hay que amar mucho a una profesión para dedicarse a esto y no dejarlo por una plaza fija en un conservatorio o en una academia. Me parece que eso no es tratar de "vivir de las rentas".

Se critica que los autores traten de vivir "de las rentas" y de que sus ingresos en un modelo basado en el control de las copias. Pongamos de nuevo el ejemplo de un compositor, para más "transversalidad", de bandas sonoras de cine.

Si su banda sonora gusta mucho a la gente, se reproducirá muchas veces, en radio, en los cines que pasan la película, en locales de ocio, venderá discos con la grabación de su obra, etc. ¿Cómo podemos remunerarle si no es con el control de las copias vendidas, emisiones de su obra, etc? ¿Alguna alternativa? Este señor (o señora) no se gana la vida dando conciertos. Componer es muy difícil. No se escribe una orquestación en diez minutos en la servilleta de un bar.
Si nos ponemos en términos mercantilistas (lo cual odio), este señor (o señora) ha sido muy productivo: su trabajo ha tenido mucha repercusión. Es lógico y deseable que se le remunere en proporción a ello, y la forma más directa que se me ocurre es midiendo la difusión de su obra (copias vendidas, emisiones radiofónicas, etc).

¿Qué pasa con los músicos de estudio? ¿Y con los guionistas? ¿Y con los ingenieros de grabación? ¿Cómo evaluamos lo que debemos pagarles? ¿Un fijo mensual? ¿Alguien se compromete?

Los artistas y creadores suelen ser trabajadores autónomos (no en el sentido legalista del término) y viven de "vender" su trabajo. Si deciden comerciar su trabajo con un determinado modelo, nuestra decisión como "consumidores" (odio  escribir en estos términos hablando de creación artística) es "adquirir" o no el producto.

Lo que hay que criticar es la voracidad de algunas discográficas y productoras (no todas son el demonio, no seamos simples, por favor), la falta de control y transparencia de algunas entidades de gestión y la imposición de un canon chapucero e inadecuado.

Vuelvo a citar el texto del manifiesto: "[...] y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo [...]".

Mas argumentación chapucera. Primero: en Internet sí es posible tener un control de las "copias" vendidas o, para ser más correcto, de las emisiones de una obra. Es técnicamente factible y sencillo.
Segundo: "deberían buscar otro modelo". No puedo estar más en desacuerdo. Si un artista publica con una licencia o modelo que me desagrada, no lo leo, o escucho, o veo. Así de sencillo. Si nos empeñamos en acceder a la obra de esta persona contrariando sus deseos o forma de comercializarla, somos nosotros los que estamos vulnerando su derecho a elegir cómo llevar su negocio.

Soy desarrollador de software, me gustan las licencias libres y los pocos programas que he escrito fuera de mi trabajo los he licenciado abiertos y me gusta que la gente se los descargue. Pero no puedo pretender que todos los desarrolladores de software piensen como yo. Si un programa me gusta y no es gratuito tengo dos opciones: lo compro o no lo uso. Si me lo descargo o pirateo estoy vulnerando el derecho del autor (particular o empresa) a comercializar su obra como le apetezca.

La anterior sí que es una analogía válida y no las muchas simplonerías que se pueden leer por la red. Es válida porque habla de un producto inmaterial (un software), al igual que un bien cultural; que puede distribuirse en un soporte físico o por la red, como muchas creaciones de autores; y además está sujeto a la misma problemática: las descargas indeseadas de la obra (lo cual algunos llaman piratería).

Y aquí llegamos al meollo de la cuestión: la "piratería". No voy a entrar en el terreno legal, en el cual parece que está clara una cosa: la copia privada no es un delito ni nada que se le parezca. Se paga un (injusto) canon por cada soporte físico que se compra para compensar a los autores e industria por las copias originales que han dejado de vender.

¿Puede entenderse la distribución a través de la red de obras como copia privada o es una vulneración de alguna ley o reglamento?
Éste es el punto clave. No soy abogado y lo que he podido leer (y entender) es que no es un delito, aunque puede ser considerado un ilícito civil (no sé ni lo que significa).

Independientemente de su legalidad o alegalidad, personalmente, no puedo prescindir de analizar los factores éticos. Que algo sea legal para mí no es condición suficiente para que deba hacerse. En mi escala de valores personal, también debe ser legítimo, o ético, o como quieran llamarlo. Lo que me da realmente pena no es que la discográfica o el triunfito de turno vendan menos copias por las descargas, sino el montón de gente desconocida que vive de esta industria y que ve reducidos sus ingresos.

Eso sí, intentar frenar este fenómeno es como ponerle puertas al campo. Por cada medida de protección o cortapisa que se inventen, saldrá un parche o "hack" que lo evite o anule. Y lo que no puede hacerse es que para evitar este fenómeno se invada la esfera de la intimidad y se viole un derecho fundamental.

Para acabar, mis conclusiones:

El canon por los soportes es injusto porque se aplica indiscriminadamente, independientemente del uso que se le da al soporte. Debería cambiarse.

La recuadación que hacen algunas entidades de gestión es también injusta por su falta de transparencia y equitatividad para con sus socios. Su actuación debería ser pública y supervisada.

Muchas discográficas, productoras y artistas están en la inopia. El modelo de mercado está cambiando. El soporte físico desaparece, la cadena de distribución tendrá menos intermediarios. Deberían adaptarse a estos cambios, pero no podemos obligarles. Están en su derecho si quieren seguir en el Paleolítico. Desaparecerán.

Este anteproyecto de ley es injusto porque pretende violar un derecho fundamental, que es la inviolabilidad de las comunicaciones si no media un mandato judicial. No debe salir adelante.

Pero por favor, arguméntenlo bien, no digan sandeces y no mezclen churras con merinas. No nos hace ningún favor a nadie.

Este es el texto completo que está circulando por la red. Aunque no estoy plenamente de acuerdo con todos los puntos, como ya he expuesto, me parece interesante difundirlo:
Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que...

  1. Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

  2. La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

  3. La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

  4. La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

  5. Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

  6. Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

  7. Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

  8. Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

  9. Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

  10. En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.


miércoles, 23 de septiembre de 2009

Algunos fallos tontos en el desarrollo web con PHP

¿A qué desarrollador web no le ha pasado alguna vez tener algo que no funciona, probar mil cosas y luego darse cuenta que era un error o fallo trivial? Para tirarse de los pelos, ¿verdad? Voy a relatar algunos.

  • ¿Por qué no entra por el if?
    Este es típico: un if que controla una sóla condición. Ejemplo en PHP, pero aplicable a cualquier lenguaje -excepto Python :-)
    loQueSea();
    if ($varControl)
    hazAlgo();
    otraCosa();

    Al cabo de un rato piensas que  si entra por el if, además debes cambiar otra variable y escribes:
    loQueSea();
    if ($varControl)
    hazAlgo();
    $otraVarControl = true;
    otraCosa();

    Y nunca consigues que otraVarControl se quede a true. ¿Qué pasa aquí? Fácil: no hemos puesto llaves al if.
    Conclusión: aunque el if sólo controle una sentencia, mejor con llaves siempre. Al final siempre va a haber más de una sentencia bajo ese if:
    loQueSea();
    if ($varControl) {
    hazAlgo();
    $otraVarControl = true;
    }
    otraCosa();


  • ¡No pilla los cambios!
    Es la típica llamada de un cliente (o un jefe): ¡me has dicho que cambiaste el XXX y no lo veo, sigue como antes!
    Nuestro XXX puede ser un fichero .js, un .css, una imagen o cualquier otro tipo de recurso que estamos seguros que hemos actualizado y que aún así, nos dicen que no lo ven.
    A los desarrolladores web no nos gustan mucho las cachés, ni proxies, etc, y además nos conocemos todos los típicos trucos para hacer un refresco completo de la página, pero nuestros jefes, clientes y usuarios sí que utilizan cachés (en el navegador, en su proxy). Además no se saben esos "mágicos" atajos de teclado que utilizamos sistemáticamente (Ctrl-Shift-R, Ctrl-F5 en IE) para ver cómo va nuestro trabajo en el navegador.
    Solución: forzar el refresco. Supongamos el siguiente HTML que incluye un .js sobre el cual hemos hecho cambios importantes:



    ...

    Subimos el fichero actualizado al hosting o servidor de producción, hacemos la llamada o enviamos el correo de rigor ("oye, ya está hecho") y al rato tenemos el típico "yo lo veo como antes".
    Nuestro fallo: presuponer que el entorno del usuario es el mismo que el nuestro. Puede que esté navegando a través de un proxy (suelen guardar en caché los elementos que le solicitan), su navegador puede estar configurado para que también "cacheé" algunos recursos, etc.
    La solución más fácil es añadir un "query string" a la llamada al recurso. Esto nos garantiza que será tratado como un fichero diferente y cargado de nuevo:



    ...

    Nos da igual cuál es esta "query string", simplemente lo que queremos es que todos los proxies, navegadores y demás clientes entiendan que es un recurso diferente. Este truco es válido para CSS, imágenes, swf. Por ejemplo, en la regla CSS:

    div.cabecera {background-image: http://mi.servidor.com/img/fondo.png?r=1}

    Si se tiene todo el trabajo integrado en un sistema de control de versiones, es muy útil configurar nuestro "deploy" para que este "parámetro" tome siempre el número de versión. Si estamos desarrollando la aplicación todavía, el truco infalible para que el navegador siempre lea los recursos como "nuevos" es hacer las llamadas así en nuestro fichero .php:



    <script src="fichero.js?version=" type="text/javascript">
    <link href="fichero.css?version="  rel="stylesheet" type="text/css" />

  • Página en blanco, no se ve nada. ¿Qué falla?
    Este típico error suele pasar cuando PHP está configurado para no mostrar ningún error (lo más recomendable en producción). Las soluciones son dos:

    • Editar el php.ini y cambiar el ajuste "display_errors" (nada recomendable).

    • Escribir la siguiente instrucción para saltarnos este ajuste para un "script" en concreto:
      <?php
      ini_set('display_errors', 1);
      // Sigue nuestro script

      La función ini_set() permite ajustar parámetros de configuración para un script determinado. Es muy útil cuando algo falla y no vemos dónde.



  • Los usuarios de mi aplicación no pueden hacer "login", o unos acceden al perfil del otro.
    Este es un error bastante insidioso y puede tener diferentes orígenes. Hay que conocer cómo maneja PHP las sesiones: PHP asigna al usuario una 'cookie' única con el identificador de sesión. En el servidor se guardan ficheros de sesiones en un directorio, un fichero para cada sesión 'asignada' a un usuario. Problemas potenciales:

    • El usuario no está aceptando cookies: en este caso es imposible que PHP asocie una sesión y sus datos con un usuario. Se puede configurar para que PHP mande el identificador de sesión en la URL, pero no es nada recomendable. Se puede comprobar si el usuario acepta cookies intentando enviarle una y leyéndola a continuación. Si no la tenemos, sacamos una advertencia al usuario.

    • El directorio del servidor donde se guardan las cookies no está accesible (problemas de permisos, falta de espacio, etc).

    • Si tenemos una configuración con balanceo de carga (varios servidores atendiendo a la misma URL) tenemos que asegurarnos que una vez que un usuario 'entra' por un servidor, sigue siempre en el mismo servidor. Otra solución es guardar las sesiones en una base de datos en vez de almacenarlas como ficheros.




Hay muchísimos más fallos tontos que nos podemos encontrar, pero éstas son algunas de las que más tiempo me han hecho perder ;-)

martes, 21 de julio de 2009

Selectores CSS: la intersección entre diseño y programación

El uso de selectores CSS en los "frameworks" para JavaScript más conocidos ha permitido lo que hace unos años era impensable: los diseñadores entienden el código de los programadores y los programadores pueden comprender el CSS de los diseñadores.

jQuery es especialmente adecuado: no distingue entre selectores "por id" ni selectores por "clase" (Prototype tiene dos funciones diferentes, $() y $$(), para estas tareas).

$('.lateral a.externo').click(function(ev) {
// Código  a ejecutar
})


Este sencillo código es fácil de entender y un diseñador al verlo rápidamente intuye que en todos los tags A dentro de la "capa" lateral que tengan la clase externo se hará algo al hacer click.

.lateral a.externo {color: red; padding: 5px; margin: 0;}


Este fragmento de CSS afecta a los mismos elementos que el javascript anterior. Un desarrollador enseguida ve también a qué elementos afecta.

Lo bueno es que si el diseñador y el programador hablan en el mismo lenguaje (selectores CSS), el desarrollo es muy fácil y se puede trabajar en paralelo fácilmente.

miércoles, 15 de julio de 2009

Probando Android en un PC

Gracias al proyecto Live Android podemos probar en nuestro emulador favorito (VirtualBox, VMWare, ...) el sistema operativo para dispositivos móviles de una forma muy cómoda.

En mi caso he configurado en VirtualBox una máquina "Linux 2.6" con 256 Mb de RAM y 8 Mb de memoria de vídeo. Arrancamos desde la imagen ISO y ¡voilá!: ya tenemos Android en nuestro escritorio. Es un poco complicado usarlo con sólo las teclas, así que ahí va una "chuleta" (lo he encontrado aquí):

Arrows -> navigation
Enter -> confirm
Left Windows key -> home
Escape -> back
Menu key (next to right Windows key) -> application menu
+ F1 -> Console mode
+ F7 -> Graphical mode

(En el Mac no tengo tecla "Win" y la "manzanita" izquierda me "echa" del emulador. Ya lo miraré con más detenimiento).

He estado jugueteando un rato y la verdad, es un sistema muy apetecible no sólo para móviles, sino también para portátiles. A mi Aspire One le sentaría muy bien, tiene todo lo básico (correo, mensajería, cámara, álbum de fotos, reproductor de música, etc).

[gallery link="file" columns="4"]

miércoles, 24 de junio de 2009

Gasto de memoria en navegadores

Seguimos haciendo algunas pruebas con los navegadores mas recientes: Chrome 3 para Mac (beta), Safari 4, Firefox 3.5 beta y Opera 10 beta.

En la entrada anterior evaluábamos como se comportaban ante los tests de JS, hoy vemos el consumo de memoria. Chrome es un navegador multiproceso, así que la medida del consumo no es tan simple como sumar la memoria que consume cada proceso, aunque puede darnos una idea.

Estos son los datos que he obtenido en mi MacOSX:

[caption id="attachment_349" align="aligncenter" width="300" caption="Consumo de memoria con 7 pestañas abiertas"]Consumo de memoria con 7 pestañas abiertas[/caption]

[caption id="attachment_350" align="aligncenter" width="300" caption="Consumo de memoria con 12 pestañas abiertas"]Consumo de memoria con 12 pestañas abiertas[/caption]

Las pestañas que teníamos abiertas eran variadas: Gmail, Google Calendar, Youtube, un par de periódicos "online", ...

Conclusiones:

  • El "plugin" de Flash causa muchos problemas y provoca unos picos de consumo de CPU en todos los navegadores en general.

  • Chrome beta no puede usar plugins todavía, así que sus resultados están un poco falseados.

  • Firefox 3.5 [impresión subjetiva] parece que se mueve un poco mas ligero, pero sigue siendo bastante glotón.


Como he comentado en muchas ocasiones: si sigo utilizando Firefox, es por Firebug.

martes, 9 de junio de 2009

"Benchmarkeando" navegadores

En la siguiente dirección, la gente que desarrolla el motor de JavaScript para el navegador Chrome tiene una serie de pruebas para medir el rendimiento de JavaScript de un navegador.

Como es previsible (es parte interesada, ¿no?), Chrome obtiene la mejor puntuación y el nuevo Safari 4 también obtiene una muy buena puntuación.

Lo curioso es que el resto de navegadores sacan mucha peor puntuación, como un orden de magnitud menos. A ver si busco más "benchmarks" de JavaScript y paso otra batería de pruebas.

[gallery link="file" columns="4"]

También he incluido una captura de los IE 7 y 8 a título anecdótico. Se cuelgan en el test.

Actualizacion: he pasado el conjunto de "tests" que proponen en la web de Dromadeo con algunos navegadores. Ahora es Safari 4 el que gana, despues, Chrome.

Actualización II: Firefox 3.5beta gana bastante en rendimiento.

martes, 2 de junio de 2009

Bing está muy verde

Penti y Atlo
En mi opinión, el nuevo buscador de Microsoft, Bing, necesita mejorar mucho. Tendrá un diseño llamativo y será más o menos bonito, pero lo imprescindible en un buscador es que encuentre información relevante.

Bing por ahora no lo hace. En la misma página de Bing indican que es un producto "beta", pero creo que es un etiquetado demasiado optimista.

[caption id="attachment_314" align="alignleft" width="150" caption="¿Qué tiene que ver Counter-Strike con Windows?"]¿Qué tiene que ver Counter-Strike con Windows?[/caption]

[caption id="attachment_315" align="alignleft" width="150" caption="¿Ein? ¿Tanta relevancia tienen estos resultados?"]¿Ein? ¿Tanta relevancia tienen estos resultados?[/caption]

[caption id="attachment_316" align="alignleft" width="150" caption="¿Qué tiene que ver el texto de resumen con Linux?"]¿Qué tiene que ver el texto de resumen con Linux?[/caption]

Supongo que con el tiempo mejorará, pero esta vez lo van a tener muy difícil: Google está muy consolidado y tiene muy buena aceptación. Probablemente no funcione esta vez el tener una posición dominante en los sistemas operativos.

Tira nº 67: Nuevo deporte



Los resultados que tanto sorprenden a Atlo son reales (ver capturas). Realmente Bing está "beta", pero que muy "beta".

miércoles, 20 de mayo de 2009

Desmontando un Mac Mini

Hoy ha traido un compañero su Mac Mini al trabajo para ver qué le pasaba. Lo hemos desmontado y es muy fácil. Al final el fallo está en el disco duro, tendremos que cambiarlo.

[gallery link="file" columns="4"]

Actualización: efectivamente, era un problema del disco duro. Hemos puesto otro de un viejo portátil que teníamos por ahí y el sistema se ha instalado y corre de maravilla.


jueves, 14 de mayo de 2009

Firefox, mucho más que un navegador

Por eso cada vez lo utilizo menos como navegador (en favor de otros) pero cada vez más como herramienta de desarrollo web. Mi sesión de trabajo suele comenzar abriendo Firefox, el editor que esté utilizando en ese momento (no me acabo de decidir entre jEdit y Komodo Edit) y otro navegador (Opera o Safari, dependiendo del sitio -trabajo o casa-) para consultar el correo, documentación, etc.

Una de mis herramientas principales de trabajo, hoy por hoy, es Firebug. Sobre esta extensión se han construido algunas extensiones más para Firefox muy útiles como Firefinder (encuentra nodos en el DOM mediante consultas XPath o selectores CSS),  YSlow, (monitoriza la carga de las páginas) o FirePHP (ayuda en la depuración de scripts PHP escribiendo en la consola de Firebug). Otras extensiones que me resultan muy útiles para el desarrollo web son Web Developer y, recientemente, Tamper Data.

Si utilizo Firefox, es por Firebug. Así de simple. Como navegador de uso diario no me acaba de gustar: me parece demasiado pesado.

jueves, 7 de mayo de 2009

Desarrollando aplicaciones para dispositivos móviles: vuelta al pasado

Parecía que la idea de estandarizar los desarrollos y las plataformas ya estaba asentada, que todo el mundo tenía claro que el desarrollo "cross-platform" era preferible a tener que lidiar con distintos sistemas, dispositivos, APISs y demas.

Pero no. De un tiempo a esta parte, con la creciente implantación de los "smartphones", estamos volviendo atrás en este aspecto. En estos momentos ya tenemos unas cinco plataformas a las que atender si queremos desarrollar aplicaciones para móviles (seguro que me dejo alguna en el tintero):

Cada plataforma utiliza sus propias herramientas, APIs y lenguajes. Así no hay manera.

Parece que se pretende excluir a los desarrolladores "amateurs" del mercado de vendedores de aplicaciones o que estos se decanten por una plataforma en exclusiva.

Personalmente me sentía muy tentado por empezar a programar algunas cosillas para móviles, pero esta situación me desanima mucho. La única forma que me parece asumible es usar el mínimo común múltiplo, J2ME, y no estoy seguro de que todas las plataformas lo acepten, aparte del propio lío de "configurations" y "profiles" de J2ME.

sábado, 18 de abril de 2009

Habemus Acer Aspire One

En su día me prometí no volver a comprar un ordenador de la marca Acer: mi último portátil me salió muy malo. Sin embargo, no he dejado de oir hablar maravillas del Acer Aspire One, así que al final, me he comprado uno (el modelo más pequeño, con 512 Mb de RAM, pantalla de 8'' y disco flash de 8 Gb).

[caption id="attachment_367" align="aligncenter" width="600" caption="El pequeñín frente al grandullón"]El pequeñín frente al grandullón[/caption]

¡Es una maravilla! Estoy encantado. Viene con un Linux algo rarito y 'tuneado' (Linpus) que está basado en Fedora 8.

Por supuesto, se puede trastear todo el sistema. Éstas han sido mis fuentes de información:

No voy a reproducir aquí todos los "truquillos" para personalizar este Linpus, pero se puede hacer de todo.

Mi favorito: rotar la pantalla a la derecha (xrandr -o 1), a la izquierda (xrandr -o 3) y volverla a poner "bien" (xrandr -o 0). ¡Adiós, Sony Reader, adiós, Kindle!

Lo más destacable es que viene con dos ranuras para tarjetas de memoria con diferente función. La llamada 'Storage Expansion' admite tarjetas SD y sirve para aumentar el espacio de almacenamiento del aparato, fusionando en un directorio virtual el directorio HOME con los contenidos de la tarjeta. Todo ello, de forma transparente. ¡No hay que tocar el /etc/fstab! ;-)

viernes, 17 de abril de 2009

A Python se le pasó el arroz en el 'Desktop'

Durante mucho tiempo he deseado que la gente de Python incluyera como 'toolkit' para hacer 'GUI's wxPython, pero no. Llegó Python 3000 y han mantenido el obsoleto Tkinker.

Escribir una aplicación de escritorio con Python + wxPython es una gozada, cómodo, fácil, documentado, etc. Pero distribuirla ... éso es otro cantar, sobre todo si lo haces para las tres plataformas mayoritarias (Windows, MacOSX y Linux). 

En Windows no hay Python ni wxPython, o pides que lo instalen o te curras un instalador que meta Python y todas las bibliotecas que use tu aplicación. Otro script a mantener.

En MacOSX por fortuna tenemos Python y wxPython, aunque no siempre la última versión.

En Linux es fácil instalar wxPython a través del gestor de paquetes, pero tienes que instruir al usuario cómo hacerlo si no es muy experto. También puedes encontrarte con problemas de versiones.

Es una pena. En el 'server-side', Python ya es un lenguaje consolidado y juega en la liga de los grandes (en parte gracias a Google, que fichó a GvR y lo utilizó como base de su AppEngine).

El último invento que me lleva un tiempo sorprendiendo es Adobe Air (vale, ya sé que es propietario). Es lo que AWT y Swing debió ser y nunca llegó. El 'runtime' de Java es enorme. ¿Por cuánto anda ya el JRE? ¿200 Mb?

El 'runtime' de Air es mucho más ligero y proporciona un instalador de las aplicaciones que nos bajemos muy chulo. Por otra parte, las aplicaciones se escriben en HTML+JavaScript (o Action Script/Flash/Flex), algo que muchos desarrolladores conocen.

Es una tecnología que tengo en cuarentena, estoy leyendo, haciendo "hola mundos" y poco más, pero promete mucho.

martes, 7 de abril de 2009

Vídeo en "streaming"

Datos del vídeo

No entiendo mucho de vídeo, códecs ni multimedea en general, pero, ¿no hay ningún otro formato para emitir vídeo en directo que no pase por usar los códecs de Windows Media?

No entiendo porqué casi todos los medios se emperran en emitir con el formato Windows Media. Para los que no usamos Explorer y/o Windows, es todo un problema.

Mi odisea personal para poder ver el vídeo en directo que muchos medios llevaban hoy:

- Buscar un plugin que lea WMV y WMA para Firefox.
- Comprobar que funciona el plugin, probados Xine plugin, el Mplayer plugin y VLC plugin.
- Quedarme tirado cada poco rato sin saber si lo que falla es la emisión, el códec, el plugin, el navegador o yo qué se.

Respecto al HTML para embeber estas señales, mejor ni mirarlo. En www.publico.es hemos acabado con este HTML en la portada.  Hay un montón de parámetros para configurar el visor o plugin:


























"Twitteando"

PantallazoPara que mis compañeros de trabajo no piensen que soy un viejales y que me he estancado ;-) ,  me he creado una cuenta de Twitter.

Le veo una cierta utilidad, pero me parece que como uno se descuide, acaba esclavizado y pendiente del tuiter todo el día. Por ahora, lo tengo en cuarentena.

domingo, 5 de abril de 2009

Informática para tod@s

En esta categoría están todas las entradas del blog "Informática para tod@s", blog que mantuve durante un tiempo en el diario Público. Actualmente está cerrado por falta de tiempo para actualizarlo.

viernes, 3 de abril de 2009

Cerramos

Las pocas personas que sigan este blog habrán apreciado que va a peor, me tiro semanas y semanas entre una entrada y otra.

Lo peor es que esto no va a mejorar: no tengo mucho tiempo para escribir, y cuando tengo algún hueco libre, estoy tan harto de estar delante de una pantalla que lo que menos me apetece es tratar de mantener actualizado el blog. Supongo que así mueren todos los blogs.

Muchas gracias a todas las personas que me han leído y comentado.

martes, 24 de marzo de 2009

Internet Explorer 8: problemas en clase

El nuevo IE8 lleva unos días disponible en su versión definitiva, y, en la mejor tradición de los navegadores de Microsoft, ya nos está dando quebraderos de cabeza a los diseñadores y desarrolladores web.

Ésta es la página web de Público (www.publico.es) vista en algunos navegadores:





















firefox-homeopera-homesafari-home
Mozilla FirefoxOperaApple Safari
chrome-homekonqueror-homeie6-home
Google ChromeKonquerorMS Internet Explorer 6

Como pueden ver, la "cajita" con las previsiones metereológicas se ve bien, tres elementos que internamente son una lista que se crea dinámicamente con JavaScript y a los que se les ha dado estilo con CSS, alineándolos usando la propiedad float y eliminando el "bolo" que suelen tener las listas por defecto.

Todos los navegadores en los que hemos probado hasta ahora muestran este módulo correctamente, incluido el vetusto Internet Explorer 6.

Al probar la página en el nuevo IE8, nos hemos llevado una pequeña sorpresa:

ie8-sincompatibilidad.jpg La caja en las que se muestran las previsiones meteorológicas es como si no entendiese los estilos: los elementos de la lista no se muestran alineados horizontalmente y cada uno de ellos muestra el "bolo" típico de las listas. Podría pensarse que es un problema de los diseñadores, que no han sabido maquetar estos elementos correctamente, pero las reglas que han aplicado en este módulo son correctas.

ie8-concompatibilidad.jpgSin embargo, si activamos el botón de "Vista de compatibilidad", la página se muestra correctamente, como con los demás navegadores, incluido el predecesor, IE7.

Según la página web de Microsoft, "no todos los sitios web están preparados para IE8" -- el original es éste:
"Internet Explorer 8 is a new release and some websites may not yet be ready for Internet Explorer 8".

Tras una breve investigación, al final Rodrigo y Daniel encontraron el problema: IE8 parece que tiene algunas incompatibilidades con una de las librerías de JavaScript más usadas (Prototype), el atributo HTML "class" y la propiedad DOM "className".
Los demás navegadores trabajan bien con el mismo código JavaScript, IE8 no. ¿Quién lo está haciendo bien y quién lo está haciendo mal?

Hasta ahora teníamos que hacer los desarrollos y diseños con tres navegadores: IE6, IE7 y el  resto de navegadores. Ahora tendremos que incorporar otro. Por fortuna, ya hay trucos para forzar a IE8 para que se comporte como su antecesor.

martes, 3 de marzo de 2009

Las elecciones desde el punto de vista informático

Pasada la resaca electoral, les voy a contar un poco por encima cómo trabajamos y lo que hacemos cuando hay elecciones.

Lo habitual es contactar unas semanas antes con el organismo responsable y solicitar una acreditación. En las elecciones que hemos cubierto hasta ahora (Generales 2009, Galicia y País Vasco 2009) el mecanismo ha sido similar: el organismo nos facilita una página web de acceso restringido desde la cual podemos descargar los ficheros con los datos de los recuentos.

Por lo general, antes del día "D" se ofrece una simulación con datos de prueba para que los medios podamos comprobar que nuestros desarrollos funcionan.

El formato de los datos no es estándar, cada organismo ofrece el que mejor le parece. En las pasadas elecciones generales se nos ofrecían un fichero de texto (comprimido) con los datos del recuento a nivel estatal, autonómico y provincial y otro conjunto de ficheros (también comprimidos) con el desglose del recuento por municipios.

Con antelación se nos facilitó la documentación sobre el formato de estos ficheros (por ejemplo: campo 1, tres posiciones, código del municipio; campo 2, dos posiciones, provincia; ....; campo n, código del partido, campo n+1, votos, ...)

Por fortuna, en las elecciones gallegas han utilizado un sistema informático similar, que emitía ficheros de datos muy parecidos, así que gran parte del trabajo ya lo teníamos hecho. Variaba la forma de desglosar: a nivel autonómico, provincial, comarcal y por municipios.

El Gobierno Vasco facilitaba los datos en un fichero XML único, en el cual también se desglosaban los datos a nivel autonómico, provincial y por municipios.

Una vez que hemos escrito el programa o "script" que analiza estos ficheros de datos, lo más conveniente es guardarlos en una base de datos relacional y escribir las consultas contra esta base de datos.

Como los ficheros de datos se van actualizando cada poco tiempo, lo más práctico es dejar que la computadora haga ella sóla el trabajo. En el caso de los datos del País Vasco, la dirección y nombre del fichero de datos ha sido toda la noche la misma, con lo que pudimos dejar un "script" corriendo cada minuto mientras pedíamos una pizza.

Los ficheros de datos del recuento en Galicia cambiaban de nombre cada vez que se actualizaba el recuento. Esto nos obligó a hacer un poco de trabajo manual, aunque lo teníamos también "semi-automatizado": llamábamos a un "script" pasándole el nombre de fichero de datos y se disparaba la actualización.

Por otra parte, en la página web se iba mostrando una especie de "marcador" con los datos parciales, el porcentaje escrutado, etc. Obviamente, estos datos provenían de nuestra base de datos, pero no podíamos arriesgarnos a que cada página vista disparase una consulta a la base de datos: saturaríamos los (ya bastante congestionados) servidores rápidamente.

La solución que adoptamos fue la siguiente: un "script" generaba un fragmento de HTML (haciendo las pertinentes consultas) cada 30 segundos, lo escribía en un fichero y lo que la página web mostraba era este HTML "precompilado". Bueno, bonito y barato ;-)Por otra parte, el lunes por la mañana, previendo que íbamos a tener muchas consultas para buscar municipios, resultados por comarcas, etc, en las páginas de resultados, decidimos "cachear" o guardar los resultados de las consultas, ya que estaba todo escrutado. De esta forma nos ahorramos muchas consultas a la base de datos, que suele ser el cuello de botella de las aplicaciones web.

Si usted busca los resultados electorales de su pueblo y la página tarda un poco en mostrarle los resultados, está de enhorabuena: es usted la primera persona que busca los resultados de este municipio, y, además, los siguientes usuarios que busquen los resultados de este mismo sitio tendrán una respuesta mucho más rápida.

Espero que les haya interesado esta entrada. Si quieren que les cuente algo más, dejen un comentario. Contestaré lo que mejor pueda.

domingo, 1 de marzo de 2009

Links2

Links 2

Una agradable sorpresa: el navegador Links 2 es una pequeña maravilla que puede correr en ordenadores realmente antiguos. Vean mi Texas Instruments del año 1997 corriendo Debian Lenny y el navegador Links 2.

Por supuesto, nada de CSS, ni JavaScript, ni cosas así, pero para una emergencia, leer el Gmail en modo  HTML básico (funciona), consultar documentación, etc, es suficiente.

Tira nº 64: redes sociales



Ya que está tan de moda el asunto };->

sábado, 28 de febrero de 2009

KDE4 en MacOSX

En la entrada anterior comentaba que había instalado KDE (3.5) en el Mac usando la herramienta Fink.
La gente de KDE también tiene preparada la versión 4 para instalarlo en el Mac, además no hay que compilarlos.

He probado a instalarlo, no hay más que ejecutar el instalador y ya está.
Novedades respecto a KDE3 en Mac:

  • No necesita el sistema XWindow para correr.

  • Las aplicaciones aparecen bajo un directorio propio bajo /Applications


Esto último es un problema: por ejemplo, Konqueror o Dolphin esperan encontrarse los programas auxiliares (Kate para editar textos, Okular para visualizar pdf, Gwenview para ver imágenes, etc) en el PATH, pero estas aplicaciones no están como tal, no existe el ejecutable, sino el "Application Bundle" o directorio .app. 

Como curiosidad no está mal, pero no veo muy estable este KDE4 como para usarlo habitualmente, además falla de vez en cuando.

Para desinstalarlo hay que borrar /Applications/MacPorts/Qt, /Applications/KDE4 y una buena ristra de ficheros y directorios bajo /opt/local (cuidado ahí, que otros programas también dejan ahí sus ficheros).

[gallery link="file" columns="5"]

miércoles, 25 de febrero de 2009

¿Dependemos en exceso de algunas compañías?

Tras la caída de Gmail ayer, mucha gente se está empezando a replantear si tenemos una dependencia excesiva de Google (u otras empresas) y si estamos ante un nuevo monopolio.

Personalmente, mi relación con los productos de Google es de amor/odio. Su buscador me parece muy bueno, Gmail es el correo web que más me gusta de todos los que he probado y otros "inventos" suyos me parecen geniales (GTalk, Maps, Groups, muchas de las APIs para desarrolladores, ...).

El odio viene provocado por la envidia ;-)
Como desarrollador web no puedo dejar de admirar, desde el punto de vista técnico, lo bien que han hecho algunas cosas.

Sin embargo, reconozco que puede que estén acumulando demasiado poder. Muchos responsables de sitios web viven pendientes del PageRank de su web, la publicidad AdSense (una de las principales fuentes de ingresos de Google) no es del agrado de todo el mundo y su actuación en algunos países es bastante cuestionable (p. ej., en China).

Pese a todo, veo dos diferencias muy importantes respecto a otros monopolios existentes:

  1. Sus productos, por lo general, son buenos. Algunos, muy buenos. De otras compañías no puede decirse lo mismo (estoy pensando en los navegadores de Microsoft).

  2. Este monopolio es consentido por los usuarios. No viene preinstalado en nuestros ordenadores. Nadie nos obliga a utilizar Google para hacer nuestras búsquedas, ni usar Gmail para nuestro correo, ni pinchar en los anuncios AdSense.


¿Qué opinan? ¿Estamos dando mucho poder a esta empresa?

domingo, 22 de febrero de 2009

Tira nº 63: enredado


Que ningún programador/a se sienta ofendido/a. Todos hemos escrito código guarro alguna vez que otra ;-)

META: estoy intentando retomar las tiras y voy a hacer el esfuerzo de publicar con mayor frecuencia. Para la semana que viene ya tengo otra preparada.

viernes, 20 de febrero de 2009

El desarrollo de una página web

Me ha dado mucha envidia José Pujol con sus "posts" en los que explica el día a día de su trabajo, así que en esta entrada voy a hacer lo mismo.

En la web de Público tenemos dos partes muy diferenciadas: el gestor de contenidos y las páginas que genera (básicamente, la portada, las subportadas y las páginas con noticias) y el resto (blogs, video, sección de cine, archivos estáticos, etc).

Hoy voy a tratar de contar cómo hemos construido la página web del concurso Foto Libre.

Lo primero que hicimos fue reunirnos con la gente del periódico que organizaba el concurso (departamentos de fotografía, "marketing" y sistemas). En esta reunión se estableció la mecánica del concurso desde un punto de vista genérico, sin entrar en detalles técnicos.
Esta fase se suele denominar "toma de requisitos" y es fundamental para que un proyecto salga adelante. Tienen que quedar perfectamente especificadas todas las características deseables.

Con esta información, desde la parte de diseño y programación web (nosotros) se hicieron unos bocetos o esquemas de las páginas. Por ejemplo: "pantalla de inicio, desde ahí el usuario puede ir al formulario de registro o a la galería de fotos", o "pantalla de registro, el usuario introduce sus datos para participar y se le envía un correo de confirmación", etc.
Existe un término llamado "casos de uso" que sirve para documentar las posibles interacciones y flujo de trabajo de una aplicación.
En este punto, todavía no se ha escrito nada de código, pero son pasos necesarios para que todo salga bien. Si no está claro qué se quiere obtener, difícilmente el proyecto será del gusto del peticionario.

Cuando todos los implicados han dado el visto bueno a estos bocetos, empieza el trabajo de los diseñadores (Matteo y Daniel) y programadores (Rodrigo y el autor de estas líneas).

El separar funciones es bueno y productivo y permite avanzar en paralelo. Mientras los diseñadores van esbozando las distintas pantallas, los programadores vamos haciendo el trabajo "de trastienda": diseño de la base de datos (si es necesaria, claro), elección de la tecnología que se utilizará en el desarrollo (lenguajes de programación, "frameworks", etc), diseño funcional de la aplicación (separación de las distintas funcionalidades de la aplicación), etc.

En este punto, los diseñadores nos proveen con algunos archivos HTML y CSS estáticos. Los programadores los "desmenuzamos" y asignamos a cada parte de la aplicación una labor, algunas de estas unidades funcionales son las que se encargan de generar el HTML de forma dinámica (obteniendo los datos de las fotos de una base de datos, validando los datos que introducen los usuarios cuando se registran o suben fotos, etc).
Es la llamada "capa de presentación".

Hoy en día muchas webs se diseñan siguiendo un patrón o modelo muy conocido: MVC (Modelo, Vista, Controlador).
La capa M (modelo) abstrae, representa y ofrece mecanismos de acceso a los datos "crudos" de la aplicación, la capa C (controlador) se ocupa de gestionar las peticiones de las distintas páginas y solicitar los datos para generar estas páginas.
Por último, la capa V (vista o presentación) "pinta" o representa los datos en un formato determinado (en nuestra aplicación de Foto Libre, en HTML).

Para muchas páginas web sencillas o informales esta separación está casi más en la mente de las persona que escribe el código, pero en desarrollos de mayor entidad conviene separar físicamente estas funcionalidades.

Espero no haberles aburrido mucho. Es difícil condensar en unas pocas líneas tanta información. Otro día les contaremos más cosas sobre el trabajo que hacemos.

KDE en MacOSX

Gracias al proyecto Fink tenía instaladas algunos programas que no vienen de serie en el MacOS X, además del estupendo gestor de paquetes apt. En el trabajo utilizo Linux (Kubuntu) y especialmente konqueror y sus kios

Así que me he armado de paciencia e instalado KDE en el Mac. No es complicado, sólo hay que seguir las instrucciones de la gente de mac.kde.org. Pero es muy tedioso: hay que compilar todo y aunque la herramienta fink es muy buena, una noche entera de gcc no se la quita nadie al ordenador.

El resultado merece la pena, por lo menos a mí. Además es muy curioso.

Kicker+Dock
konqueror

 

 

 

 

 

 

 

 

 

Por cierto, se trata de KDE 3.5 y corre bajo el sistema XWindow. Creo que el KDE 4 ya corre nativo en MacOSX, pero no me atrevo a probarlo todavía.

lunes, 16 de febrero de 2009

jQuery vs Prototype

La aparición de estas librerías o "frameworks" para programar JavaScript han supuesto un ahorro de tiempo importante para los desarrolladores. Ya no hay que estar tan pendiente de las incompatibilidades entre navegadores, simplifican mucho el trabajo con el árbol DOM, etc.

Empecé a trabajar con Prototype un poco por "imposición técnica" y ya me pareció una maravilla el poder abstraerme de los XmlHttpRequest y demás. Desde hace un tiempo estoy empezando a profundizar más en jQuery, y, en mi opinión, me parece más cómodo y sencillo.

  • En jQuery los selectores utilizan la sintaxis de CSS y son uniformes, es más claro -- p. ej.: $('#titulo') ó $('div.resaltado') en Prototype serían $('titulo') y $$('div.resaltado').

  • En jQuery las operaciones típicas como ocultar/mostrar un elemento o conjunto de elementos son más sencillas: da igual que nuestro selector nos devuelva un sólo elemento o un conjunto de ellos, el método es el mismo -- p. ej.: $('#titulo').hide() ó $('div.resaltado').hide()

  • Generalizando mucho, podemos decir que jQuery es más conciso y Prototype más explícito.

lunes, 9 de febrero de 2009

Buscamos un programador

La oferta está en Infojobs:

http://madrid.oferta.infojobs.net/programador/of-i505412954531003515812741935302

Que nadie se eche para atrás con tanto requisito. Lo de J2EE y Spring es deseable, no imprescindible. Respecto al CSS y (X)HTML, lo básico para montar una página con sentido. De la presentación se encargan nuestros diseñadores.

Resumiendo, queremos un desarrollador LAMP.

viernes, 6 de febrero de 2009

Cajetín de búsqueda de funciones PHP para Firefox

No me lo puedo creer, pero no he encontrado un motor de búsqueda que funcione para consultar las funciones de PHP desde Firefox.

El único que he encontrado (https://addons.mozilla.org/en-US/firefox/addon/8984) no sé porqué no lo puedo instalar (tengo cuenta en addons.mozilla.org).

No he sabido buscar, puede que sea un poco torpe; así que he hecho un copia-pega de uno de los que tenía instalados y retocando un par de parámetros, ya tengo el mío.
Está en esta dirección: http://davidasorey.net/static/php-manual-search.xml



Para utilizarlo, sólo hay que salvar el fichero xml en nuestro directorio “Profile”/searchplugins de Firefox y listo.

Un día de estos lo subiré a addons.mozilla.org ;-)

jueves, 5 de febrero de 2009

Tramposos/as …

Se va acercando el final de la primera semana del concurso "Foto Libre" y estamos empezando a comprobar la veracidad de las votaciones. Es sorprendente: casi todas las fotos más votadas lo son fraudulentamente.

¿Cómo detectamos votos fraudulentos?

Tenemos mucha información: la dirección IP desde la que se emite el voto, la marca de tiempo, el identificador de la sesión, etc. Con estos datos es muy fácil controlar los votos no válidos: por ejemplo, desde la misma IP cada medio minuto llega un voto a una foto determinada. Paran un rato y luego siguen.

Cuando las IPs son de empresas, universidades u otras entidades, estos patrones se dan sobre todo en horario laboral. Las IPs "particulares" presentan este patrón diferente, más continuado, sobre todo de noche.

Es curioso cómo, cuando hay dinero por medio, la gente es capaz de estarse horas (hemos detectado algunos "tramposos" que han estado hasta cuatro horas en la madrugada) delante de su ordenador votando a su foto (o la de su amigo) repetidamente. ¿Acaso piensan que en este tipo de concursos no existen mecanismos de control?

En fin, no se fíen mucho por ahora de las fotos más votadas porque están siendo revisadas.

martes, 20 de enero de 2009

¿Nos toman por tontos?

Supongo que muchas personas estarán al tanto de la campaña que ha montado el Ministerio de Cultura, "Si eres legal, eres legal". Entre otras cosas, han montado una página web en la que nos advierten de lo dañina y perjudicial que es la piratería.

Sin entrar a valorar esta campaña y lo que pretende, me chocó ver como "testimonio ganador del mes de diciembre" la siguiente perla:
Testimonio ganador del mes de diciembre

Me lo contaron en el colegio, entre y me bajé películas, me entraron virus y me tuve que cambiar el cpu porque los virus se metieron en el procesador, no os bajéis cosas, son gente que pone cosas malas dentro de los archivos y te roban tus datos, tus fotos, y todo!!!! Se legal FACILMENTE!!!

Captura de pantalla

Tras una breve indagación, me he enterado de que este mensaje lo mandó un usuario con una intencionalidad totalmente satírica y burlesca (en varios sitios mencionan la anécdota).

Lo que me pregunto es si la gente que gestiona este sitio es tan incompetente ignorante como para dar crédito a un testimonio tan absurdo y claramente guasón o es que consideran que los ciudadanos somos idiotas y que nos creemos semejantes "testimonios". No sé qué pensar.

Desde luego, lo menos que pueden hacer para que su mensaje sea tomado en serio es ser rigurosos. Con un alarmismo facilón como éste no creo que consigan tener mucha credibilidad.