Por defecto la web muestra la última revisión, pero… ¿cómo hacemos para navegar por una anterior? Pues “muy fácil”, añadiendo el parámetro !svn/bc/XXX/ a la url, siendo XXX el número de revisión.

Es decir, si por ejemplo el repositorio está en http://svn.local/mi_proyecto/ y queremos ver la revisión 123, la dirección sería http://svn.local/mi_proyecto/!svn/bc/123/.

De todas formas si vas a hacer uso intensivo de esta herramienta quizá te interese utilizar otras aplicaciones como WebSVN, que incluyen muchas más opciones.

• a:link un enlace no visitado
• a:visited un enlace ya visitado
• a:hover el ratón está sobre el enlace
• a:active el usuario hace click sobre el enlace

En este ejemplo vamos a usar a:active para darle un efecto botón a un enlace. Para ello tendremos que añadir las siguientes reglas a nuestro CSS, así cuando un usuario haga click en el enlace éste se desplazará ligeramente hacia abajo dando la impresión de que se ha presionado un botón (lo cual puede ser una interesante ayuda visual).

a:active {
  position: relative;
  top: 2px;
}

Como wordpress.com no deja insertar estilos propios en los posts, no me queda más remedio que dejar el ejemplo en mi dominio: ejemplo de efecto botón con a:active.

Visto en “The definitive guide to styling web links“.

Casi el 50% de la red usa Unicode

El problema con los encodings está presente en los programas informáticos desde hace muchos años; el rápido crecimiento de Unicode en la web, cerca ya del 50% de las webs usan alguna variante de esta codificación (el gráfico proviene de estadísticas internas de Google basadas en las páginas indexadas por el buscador), nos permite ver algo de luz para aquellos cuyo idioma principal no sea el inglés. Puede que algún día dejemos de ver caracteres como ërnôn.

Una de las grandes ventajas de SLF4J es que no necesitamos inundar nuestro código con comprobaciones del nivel de log. Si usamos log4j, por ejemplo, podemos tener algo como:

log.debug("Esto es un " + texto + " muy largo, con " + variables[i] + " que se van añadiendo a una " + object.getCadena());

Por mucho que el compilador optimice este código (reemplazando las concatenaciones de cadenas usando StringBuilder), si se ejecuta muchas veces repetidamente sin necesidad (porque la aplicación está desplegada en producción y el nivel de log está por encima de debug, por ejemplo) podría llegar a afectar al rendimiento. Por lo que no es extraño ver código Java tal como este:

if (log.isDebugEnabled()) {
  log.debug("Esto es un " + texto + " muy largo, con " + variables[i] + " que se van añadiendo a una " + object.getCadena());
}

SLF4J nos permite parametrizar el log al estilo printf de C:

log.debug("Esto es un {} muy largo, con {} que se van añadiendo a una {}", texto, variables[i], object.getCadena());

Esto evita problemas de rendimiento al tratar con cadenas, pero evidentemente si los parámetros como object.getCadena() son costosos nada nos librará de tener que usar los dichosos if.

SLF4J tiene más ventajas, para conocerlas nada mejor que este artículo o el manual oficial.

Me encontraba a un solo click de comprar este soporte vertical, cuando se me ocurrió la idea del servilletero. Cutre, pero barato y completamente funcional. Ahora bien, he de buscar uno un poco más acorde con el ordenador y que no cante tanto

Se necesita una máquina que haga las veces de tracker y otra que sirva como seeder. Una vez creado el torrent, el resto de servidores comenzarán a descargar los archivos y a compartirlos entre sí; el despliegue es (obviamente) mucho más rápido que si subimos la aplicación servidor a servidor.

El proyecto, llamado Murder, está basado en BitTornado y está disponible en GitHub bajo la licencia Apache. Como ejemplo de despliegue dejan esta secuencia de comandos que usan Capistrano:

cap murder:distribute_files
cap murder:start_tracker
cap murder:create_torrent tag="Deploy20100101" files_path="/usr/local/twitter/production/current"
cap murder:start_seeding tag="Deploy20100101"
cap murder:peer tag="Deploy20100101" destination_path="/usr/local/twitter/releases"

• Confiar en que nuestras referencias nunca serán nulas y no realizar ninguna comprobación. Como es obvio, un tanto peligroso, sobre todo cuando utilizamos librerías de terceros cuyos resultados no conocemos con seguridad.

  List<Person> people = getPeople();
  for (Person person : people) {
    House house = person.getHouse();
    System.out.println("House price: " + house.getPrice());
  }
  

• Inundar el código con condicionales anidados, uno detrás de otro según el número de objetos que tengamos.

  List<Person> people = getPeople();
  if (people != null) {
    for (Person person : people) {
      if (person != null) {
        House house = person.getHouse();
        if (house != null) {
          System.out.println("House price: " + house.getPrice());
        }
      }
    }
  }
  

• Utilizar anotaciones (@Nullable y @NotNull) que nuestro IDE usará para advertirnos de posibles riesgos de obtener un NullPointerException. No nos evitará el tener que hacer comprobaciones, pero podemos fiarnos si no hay warnings.

  @Nullable
  private List<Person> getPeople() {
    // ...
  }
  
  // ... 
  
  List<Person> people = getPeople();
  // recibiremos un warning, y es que "people" puede ser nulo
  for (Person person : people) {
    House house = person.getHouse();
    System.out.println("House price: " + house.getPrice());
  }
  

• Utilizar algún patrón como Null Object pattern o una versión más general (Special Case) propuesta por Martin Fowler. El problema es que esto no soluciona las interacciones con librerías externas (que pueden seguir devolviendo nulos) y complica el proyecto con un montón de objetos nuevos.

Por desgracia, la nueva versión de Java no incluirá ningún operador específico para solucionar esta situación. Estuvo en los planes incluir algo similar al operador Elvis safe navigation operator de Groovy:

List<Person> people = getPeople()
println people?.get(0)?.getHouse()?.getPrice()

pero finalmente todo seguirá igual. Una pena porque esto mejoraría enormemente la legibilidad del código; lo pondría incluso por delante de nuevas características como las closures (que llegan tarde, esperemos que no mal y arrastro).

Según comentan en el blog de desarrolladores, PHP proporciona muchas ventajas a Facebook: es más rápido de aprender que otros lenguajes, más simple a la hora de programar, y mucho más sencillo encontrar trabajadores en esta tecnología. Salvo en lo último, en el resto no estoy de acuerdo; pero este no es el tema.

El caso es que en Facebook estaban decididos a mejorar PHP, y parece que lo han conseguido con HipHop for PHP. Hoy mismo lo harán open source y estará disponible en GitHub para que cualquiera que quiera lo instale en su servidor.

Básicamente, lo que hace HipHop es transformar el código fuente PHP en código C++, para luego compilarlo con g++; en dicha transformación trata de hacer al lenguaje lo menos dinámico posible, traduciendo después las sentencias directamente por su equivalente en C++ (no parece hacer ningún tipo de optimización adicional).

Con la implantación de HipHop for PHP desde Facebook indican que el rendimiento aumenta de media un 50%; actualmente el 90% de las peticiones a Facebook ya son servidas por HipHop, por lo que su fiabilidad debería estar más que probada.

Y también vuelve Kate, por supuesto

Tras su estreno en la cadena americana ABC, mañana los usuarios de Digital+ podrán disfrutarla en versión original subtitulada en castellano (¿se bajarán los subtítulos de lostzilla.net?), aunque eso sí, previo pago. Para el resto de los mortales, Cuatro emitirá la serie con una semana de retraso pero en perfecto castellano.

Yo, para continuar con la tradición, ya le estoy sacando brillo al Transmission; ya no está Mininova, pero por suerte hay alternativas.

Para el que tenga problemas de memoria y necesite un refresco de lo que ha ocurrido hasta ahora, nada mejor que hacerse con el capítulo 6×00.

Vuelven los números chungos. ¿A que ya no los recordáis?

La negativa de Apple a incluir Flash en sus dispositivos móviles está trayendo mucha cola. A la empresa californiana no le gusta la tecnología de Adobe, y así lo confirman los rumores sobre unas declaraciones de Steve Jobs:

Apple no soporta Flash porque está lleno de bugs. Siempre que un mac se cuelga, muy probablemente la causa es Flash. Nadie va a usar Flash, el mundo se está moviendo al HTML5.

Es una apuesta arriesgada por parte de Apple, pero como muchos ya están señalando, esto puede haber ocurrido ya en el pasado a menor escala con la salida de Firefox. Cuando Mozilla lanzó el navegador del zorro rojo (o un panda, me es lo mismo), éste no renderizaba bien muchas páginas importantes como bancos o tiendas online, y sin embargo la respuesta de los usuarios obligó al mercado a adaptarse a los estándares y a día de hoy es raro encontrar una web que no funcione correctamente en Firefox (aunque hay excepciones, está claro). Apple tiene ahora mismo más de 70 millones de dispositivos móviles por todo el mundo (entre iPhones e iPod Touchs) que no soportan Flash, una cantidad que empieza a ser importante.

Los movimientos de los grandes protagonistas en Internet juegan a favor de HTML5 (aunque la polémica de los codecs puede ir para largo), aunque el soporte de Flash en Android puede darle algo de vida a Adobe.

¿Es Flash una tecnología con futuro o simplemente fue un parche para dotar de capacidad multimedia a un lenguaje (HTML) que no lo soportaba de serie?

Es tiempo para que Adobe juegue sus cartas; el próximo mes presentará en el Mobile World Congress la versión 10.1 de Flash para móviles y su estrategia para estos dispositivos. Y porqué no decirlo, puede que el porno, como ya lo ha sido otras veces, sea clave en esta guerra no declarada.