Once you have installed the gem you will have two main features, it's easier if I just show you. First the messages when you install gems:

 
$ jgem install daemons
 
daemons 1.0.10 probably might not work, blaxter says 1.0 fails
Update http://isitjruby.com/daemons with your experiences!
 
Successfully installed daemons-1.0.10
1 gem installed
$ jgem install cucumber
 
cucumber 0.3.97 might work, 100% say 0.3.11.3 works on jruby
Update http://isitjruby.com/cucumber with your experiences!
 
Successfully installed cucumber-0.3.97
1 gem installed
$ jgem install faker
 
faker 0.3.1 is 100% verified jruby
Update http://isitjruby.com/faker with your experiences!
 
Successfully installed faker-0.3.1
1 gem installed
 

And also we have an explicit gem command:

 
$ jgem isitjruby faker
faker 0.3.1:    http://isitjruby.com/faker
    Blaxter says 0.3.1 works on GNU/Linux
        it works perfectly, and it passes all test.
$ jgem isitjruby daemons
daemons 1.0.10:    http://isitjruby.com/daemons
    blaxter says 1.0 fails on GNU/Linux
        Daemons use fork, jruby doesn't support fork, so it doesn't work and
        never will
 

And that's it. The code is on github be free of fork me or open any issues. The important thing is populate with relevant information isitjruby.com for benefit of all jruby community. Oh I forgot to tell you how to install it, very easy, I've uploaded the gem to gemcutter so you can install it with something like

$ jgem install rubygems-isitjruby -s http://gemcutter.org

It's also in github, but I think (and I hope) gemcutter will be the next rubyforge, so better gemcutter .

En el caso concreto de MySQL inicialmente haríamos algo como esto:

$ mkdir mydatabase && cd mydatabase
$ mysqldump --skip-extended-insert > data.sql
$ git init
$ git add data.sql
$ git commit -m "Initial dump of mydatabase"

A partir de entonces podemos automatizar el proceso con un script tan simple como este:

$ cat /usr/bin/git_backup_database
#!/bin/sh
BACKUP_DIRECTORY=$1
DATABASE=$2
 
cd $BACKUP_DIRECTORY && \
mysqldump --skip-extended-insert $DATABASE > data.sql && \
git commit -am "Updating dump `date +%Y_%m_%d__%H_%M`"

Según el volumen de consultas que tenga tu base de datos, te será interesante ponerlo en cron con una frecuencia determina u otra. Adicionalmente sería recomendable ejecutar $ git gc para optimizar el repositorio. Por ejemplo, dos veces al día y una vez a la semana mantenimiento:

0 0 * * * /usr/bin/git_backup_database /path/to/mydatabase mydatabase
0 12 * * * /usr/bin/git_backup_database  /path/to/mydatabase mydatabase
0 1 * * 1 cd /path/to/mydatabase && git gc

Además desde otro equipo nadie te impide hacer un $ git clone ssh://equipo:path/to/mydatabase y tener todo el historial de la base de datos en un plis (bueno eso es relativo, que ocupará lo suyo...) o incluso programar un $ git pull para tener varios backups en distintas maquinas. En definitiva, se abren un sinfín de opciones .

In translation phase 6 (2.1), adjacent narrow string literals are concatenated and adjacent wide string literals are concatenated.

Esto viene a decir que podemos partir nuestras cadenas en cualquier momento sin poner ningún signo de concatenación entre ellas, de esta forma:

 
const char s1* = "dum" "de" "dum";
const char s2* = "dum"
                 "de"
                 "dum"
;

Lo cual viene realmente bien para formar código bien indentado y formateado, pues aunque también podemos usar "\" para saltar de línea, el texto a continuación no puede estar indentado pues significaría incluir esos espacios/tabuladores en la cadena que estamos definiendo. Y lo realmente interesante es que todo esto está en la propia definición del lenguaje, no es ninguna ayuda concreta del compilador, a los ojos del programa todas las siguientes definiciones son idénticas:

 
#include <string>
#include <iostream>
 
const char * cmp( const char *s1, const char *s2 );
 
int main()
{
 
    const char * s1 = "My spoon is too big"
                      "My spoon is TOO BIG"
                      "I AM A BANANA";
    const char * s2 = "My spoon is too big\
My spoon is TOO BIG\
I AM A BANANA";
    const char * s3 = ( std::string("My spoon is too big") +
                        std::string("My spoon is TOO BIG") +
                        std::string("I AM A BANANA") ).c_str();
 
    std::cout << "s1 and s2 are " << cmp( s1, s2 ) << std::endl;
    std::cout << "s1 and s3 are " << cmp( s1, s3 ) << std::endl;
    std::cout << "s2 and s3 are " << cmp( s2, s3 ) << std::endl;
 
    return 0;
}
 
const char * cmp( const char *s1, const char *s2 );
{
    while( *s1 && *s2 && *s1++ == *s2++ );
    if ( ( *s1 != *s2 ) || ( *s1 || *s2 ) )
        return "different";
    return "equal";
}

$ c++ const_char_declaration_sample.cpp && ./a.out
s1 and s2 are equal
s1 and s3 are equal
s2 and s3 are equal

Para poder mejorar todo esto podemos usar par de útiles herramientas: (1) la plantilla para rdoc, hanna; y (2)bdoc como alternativa a gem server para visualizar la documentación.

Hanna es una plantilla para rdoc que mejora notablemente el formato por defecto. Podemos ver la diferencia fácilmente, por ejemplo, en la documentación de rspec con el formato típico vs la documentación hecha con hanna. La instalación es simple:

$ sudo gem sources -a http://gems.github.com
$ sudo gem install mislav-hanna

Para que a partir de ahora se generar la documentación con esta plantilla, puede añadir a tu .gemrc la siguiente línea:

rdoc: --inline-source --line-numbers --template=hanna

Y para convertir la documentación de todas tus gemas instaladas, puedes hacer algo como esto:

$ sudo gem list | awk '{print $1}' | xargs sudo hanna --gems

Por otro lado, gracias a bdoc podremos navegar fácilmente entre todas las documentaciones.

$ sudo gem install manalang-bdoc
$ bdoc

Ejecutando bdoc se nos abrirá en nuestro navegador por defecto listo para poder leer la documentación y poder movernos fácilmente entre las diferentes gemas (y versiones). Muy útil.

Estoy hablando de la implementación de John Torjo. Muy flexible a la hora de configurarla unido a un uso trivial de la misma (como tiene que ser, tampoco es que, la labor de logging, sea algo muy complejo que digamos...). Para conocer todos los detalles puedes leerte la extensa y útil documentación, aunque de primeras puede ser un tanto compleja debido a nuevos conceptos que se usan a diestro y siniestro.

Principalmente debemos de conocer dos cosas:

• Qué tipo de filtro queremos: el cual será el encargado decidir si un mensaje se escribe o no, dependiendo tanto de si el logging está activado, como si cumplimos la restricción de nivel (debug, warn, error, etc...)
• Qué tipo de log queremos: ¿cómo debe de ser el formato de salida?, ¿cuál es la salida/s? ¿cómo será su comportamiento?.

Una vez definido esto, podemos escribirnos un par de ficheros en los cuales definiremos el log que podrá ser usado desde cualquier parte de la aplicación, incluyendo el header, y siempre y cuando se haya inicializado previamente.

 
#ifndef __LOGGING_HPP__
#define __LOGGING_HPP__
 
#include <boost/logging/format_fwd.hpp>
 
using namespace boost::logging;
using namespace boost::logging::scenario::usage;
 
typedef use<
    filter_::change::single_thread, // how often does the filter change?
    filter_::level::no_levels,      // does the filter use levels?
    logger_::change::single_thread, // how often does the logger change?
    logger_::favor::correctness     // what does the logger favor?
  > finder;
 
BOOST_DECLARE_LOG_FILTER( g_log_filter, finder::filter )
BOOST_DECLARE_LOG( g_log, finder::logger )
 
#define L_ BOOST_LOG_USE_LOG_IF_FILTER( g_log(), g_log_filter()->is_enabled() )
 
void initialize_logs();
 
#endif // __LOGGING_HPP__

Aquí acabamos de declarar un log, sin niveles, para una aplicación simple sin usar un thread separado para el logging. Para ver otras alternativas puedes echarle un ojo a los namespaces boost::logging::scenario::usage::filter_ y boost::logging::scenario::usage::logger_.

Finalmente solo nos quedaría inicializar el log (o logs, recuerda que nada te impide tener tantos como quieras):

 
#include "logging.hpp"
#include <boost/logging/format_ts.hpp>
#include <boost/thread/xtime.hpp>
 
BOOST_DEFINE_LOG_FILTER( g_log_filter, finder::filter )
 
BOOST_DEFINE_LOG( g_log, finder::logger )
 
void initialize_logs()
{
  g_log()->writer().add_formatter( formatter::idx(), "[%] "  );
  g_log()->writer().add_formatter( formatter::time("$hh:$mm.$ss ") );
  g_log()->writer().add_formatter( formatter::append_newline() );
 
  typedef detail::flag<destination::file_settings> flag;
  destination::file_settings file_settings;
  file_settings.initial_overwrite = flag::t<bool>( &file_settings, true );
  g_log()->writer().add_destination(
      destination::file( "app_debug.txt", file_settings )
    );
  g_log()->writer().add_destination(
      destination::cerr
    );
 
  g_log()->turn_cache_off(); // for showing output immediately
  g_log()->mark_as_initialized();
}

Aquí tenemos que hacer la definición del log y del filter de la misma forma que hemos hecho su declaración anteriormente. Definimos el formato de salida como más nos guste y finalmente solo nos queda indicar dónde se deben de escribir los mensajes. Se puede tener varios destinos, aunque básicamente podemos usar desde ficheros hasta cualquier stream, pasando por las salidas estándar (fíjate en los typedef de boost::logging:destination).

Una cosa importante que merece la pena mencionar es la llamada al método turn_cache_off(), especialmente importante si usas una salida a consola, pues por defecto el logging se cachea y solo se escribe al destino cada cierto tiempo, por lo que si monitorizas el log en tiempo real es crucial desactivar esta caché.

De esta forma, ya tendremos en cualquier parte de nuestro código donde incluyamos la declaración una macro L_ (o como la hayamos definido) lista para ser usada:

 
L_ << "Here we are";
 
unsigned int n = 42;
L_ << "The meaning of life is " << n;
 
L_ << boost::format( "We can even use the awesome %s library versión %d.%d.%d" )
    % "boost::format"
    % ( BOOST_VERSION / 100000 )
    % ( ( BOOST_VERSION / 100 ) % 1000 )
    % ( BOOST_VERSION % 100 );

• Calidad de imagen pésima. En 4:3 en vez de 16:9
• Mucha, mucha, muchísima publicidad. Durante la carrera, así a ojo, diría que te tragas alrededor de 30minutos de publicidad perfectamente.
• Comentarios penosos, subjetivos y sin calidad (excepto Pedro De La Rosa obviamente) por parte de Antonio Lobato y Víctor Seara (difícil decidirse cual de ellos es más ignorante).
  • No paran de confundirse y decir estupideces cuando se refiere al futuro de la carrera, solo entrando en razón cuando De La Rosa pone las cosas claras.
  • No retransmiten la carrera, comentan las acciones que pasan en función a cómo pueden llegar a afectar a un único piloto, a pesar de existir, por lo normal, 19 más.
  • Se centran en acontecimientos irrelevantes, y la mayor parte de las veces, mal; olvidándose del transcurso real de la carrera.

La solución es bastante simple, sobretodo si tienes alguna forma cómoda de ver tu ordenador en una pantalla de televisión. Por una parte necesitamos (1) una forma precisa de poder conocer el transcurso de la carrera, y por otra necesitamos (2) una imagen y, no está de más, algunos comentaristas que sean competentes en su trabajo. Para solucionar el primer punto tenemos el fantástico live timing de formula1.com, en el cual podemos ver los tiempos en tiempo real de todos los pilotos, sector a sector. Y para el segundo punto, tenemos la retransmisión online de la cadena catalana tv3. El resultado será algo como esto:



Formula 1 online: Tv3 y Live timing

Las únicas "desventajas" de este método son:

• Comentarios en catalán: pero realmente es muy fácil de seguir (si sabes español claro), y eso que yo soy un negado para los idiomas
• Resolución inferior al TDT: la resolución online no es nada espectacular, pero dado que no lo vamos a ver a pantalla completa, es más que suficiente para poder leer las letras y verlo de forma correcta.
• Retraso de 20seg.: la TDT en verdad tiene también un retraso respecto a la realidad, de unos 3-5 segundos (lo puedes comprobar con el live timing) en este caso, estos 20segundos no es un problema tan grande puesto que de esta forma te da tiempo a analizar la evolución de los tiempos y luego ver su "resultado" en la imagen. Se podría decir que la imagen va a ir "1 sector" atrasada, lo cual viene hasta bien.

Personalmente ganan las ventajas respecto a las desventajas, por lo que después de haber probado este método, para seguir este último Gran Premio de España, creo que repetiré para los próximos 12 de esta temporada.

]]> http://bicosyes.com/como-ver-por-internet-la-f1-de-forma-precisa-y-sin-anuncios/feed/ 7 http://bicosyes.com/como-ver-por-internet-la-f1-de-forma-precisa-y-sin-anuncios/