• Obtener información:

   $ sox fichero.wav

• Reproducir audio:

  $ play fichero.wav

• Grabar archivo:

  $ rec -r 8000 -c 1 fichero.wav

  → graba con un muestreo de 8 kbps y a un canal (la extensión determina el formato).

• Convertir:

  $ sox fichero.wav fichero.ogg

  → convierte el fichero del formato “wav” a “ogg”

• Acelerar:

  $ sox fichero.wav acelerado.wav speed 2.0

• Recortar:

  $ sox fichero.wav recortado.wav trim 60 10

  → devuelve los 10 segundos posteriores al primer minuto.

• Escuchar podcast:

  $ play http://dondesea.com/ficheros/audio/podcast.mp3

La instalación de Ubuntu es muy sencilla:

$ sudo apt-get install sox libsox-fmt-all

Para otras plataformas: http://sox.sourceforge.net

La reproducción, grabado y/o conversión desde/hacia mp3 requiere de la librería lame.

Via | http://bitelia.com

Para un proyecto con múltiples carpetas que contienen este tipo de ficheros lo más sencillo es:

$ svn propset svn:ignore -F $HOME/ignore_file . -R

donde -R indica que se haga de manera recursiva desde “.” (el directorio actual) y -F indica que se tomen las reglas de exclusión del fichero inficado.

El contenido del fichero ignore_file podría ser, por ejemplo:

*.o
*.so
*.exe

Con esto quedaráin excluidos los ficheros objeto, las librerías compartidas y los ejecutables (suponiendo que todos tengan nombres acabados en .exe).

Para ello es necesario que indiquen correctamente la dirección de email al escribir el comentario (no es necesario publicarlo en el texto).

Cerraré los comentarios cuando ya no queden invitaciones.

Do not forget to fulfill the email field in the comment form.

Comments on the post will be closed where there are no invitations left to be sent.

En mi último viaje a Japón compré un Kohjinsha SC3 que monta este chipset. Así que he generado un pequeño paquete que permite compilar e instalar el driver en Ubuntu 9.10 (Karmic Koala).

Podéis descargar los fuentes aquí:

driver_staging_vt6656.tgz

Al descomprimirlo generará una carpeta llamada “driver”. Basta con hacer (dentro de la carpeta generada):

$ sudo make install

para que se añada el driver al arranque de Ubuntu. Si ejecutamos:

$ modprobe vntwusb

el driver se cargará y podremos conectar a la red usando nuestra tarjeta wifi con chipset VT6656.

Por último decir que, tal como indican en el thread relacionado con el bug, sólo funciona la encriptación WPA2. No funcionan ni WPA ni la mixta (WPA+WPA2).

Que lo disfrutéis.

function iPhoneCheck() {
    var agent = navigator.userAgent.toLowerCase();
    var iphone = (agent.indexOf('iphone')!=-1);
    if (iphone) {
        return true;
    } else {
        return false;
    }
}

Vía: http://blog.unijimpe.net/detectar-browser-iphone/

try {
   if (!window.openDatabase) {
      alert('not supported');
   } else {
      var shortName = 'mydatabase';
      var version = '1.0';
      var displayName = 'My Important Database';
      var maxSize = 65536; // in bytes
      var mydb = openDatabase(shortName, version, displayName, maxSize);

      // You should have a database instance in mydb.
   }
} catch(e) {
   // Error handling code goes here.
   if (e == 2) {
      // Version number mismatch.
      alert("Invalid database version.");
   } else {
      alert("Unknown error "+e+".");
   }
   return;
}

alert("Database is: "+mydb);

Con esto, sin más que implementar las transacciones necesarias, podemos hacer persistente la información cargada durante la sesión para su uso posterior.

Estas bases de datos se pueden utilizar para la implementación de aplicaciones Offline mediante Safari.

Para eliminar estas bases de datos creadas por aplicaciones web, basta con ir a la sección “Safari” de los ajustes del iPhone.

Vía: Safari Client-Side Storage and Offline Applications Programming Guide

La información se puede consultar online o hacerla persistente utilizamdo el instalador del siguiente enlace.

Enlace: AsistenteJeVWeb.

La clase que contiene este código:

1. Recibirá notificaciones de disparo del evento “dataChangeEvent”.
2. Debe implementar el método “onDataChagneEvent”.

Cuando algún otro objeto dispare el evento, las instancias de esta clase recibirán la notificación y ejecutarán el método especificado.

A efectos prácticos, supongamos un único fichero jar llamado “underTest.jar” (los resultados son extensibles) y la clase que contiene el método “main” es “MainClass”, dentro del paquete “mainpack”:

public class MainClass {
public MainClass() {
}

/**
* @param args
*/
public static void main(String[] args) {
System.out.println("Ejecutando el main...");
}

}

Así, el comando para ejecutar la aplicación sería:

java -classpath underTest.jar mainpack.MainClass

El resultado de la ejecución sería:

Ejecutando el main...

En este caso, podemos utilizar AspectJ para insertar puntos de ruptura, logear información de ejecución, de performance, etc.

Vamos con la prueba de concepto.

En primer lugar, vamos a crear una librería (jar) con los “aspectos” a utilizar. En este caso, algo muy simple: una clase que traza la entrada y la salida del método “main” de nuestra aplicación.

El código sería:

public aspect ProfilingAspect {

pointcut mainMethod() : execution(static * *.main(..));

before() : mainMethod()
{
System.out.println("Entrando al main...");
}

after() : mainMethod()
{
System.out.println("Saliendo del main...");
}

}

Podemos usar eclipse para crear un proyecto de tipo AspectJ, compilarlo y generar un fichero jar con soporte para AspectJ (echar un vistazo a las Cheat Sheets de eclipse con el plugin AJDT).

Supongamos que el fichero jar creado con el “aspecto” anterior es mainAspect.jar.

El siguiente paso sería modificar el comando utilizado para ejecutar la aplicación:

java
-classpath $ASPECTJ_HOME/aspectjweaver.jar:$ASPECTJ_HOME/aspectjrt.jar:.
-Djava.system.class.loader=org.aspectj.weaver.loadtime.WeavingURLClassLoader
-Daj.class.path=mainAspect.jar:underTest.jar
-Daj.aspect.path=mainAspect.jar
mainpack.MainClass

Donde $ASPECTJ_HOME apunta al directorio de instalación de las librerías de AspectJ (aspectjweaver.jar y aspectjrt.jar) en la máquina. Con esto el resultado de la ejecución sería:

Entrando al main...
Ejecutando el main...
Saliendo del main...

class NetworkService {
    private final ServerSocket serverSocket;
    private final ExecutorService pool;

    public NetworkService(int port, int poolSize) throws IOException {
      serverSocket = new ServerSocket(port);
      pool = Executors.newFixedThreadPool(poolSize);
    }

    public void serve() {
      try {
        for (;;) {
          pool.execute(new Handler(serverSocket.accept()));
        }
      } catch (IOException ex) {
        pool.shutdown();
      }
    }
  }

  class Handler implements Runnable {
    private final Socket socket;
    Handler(Socket socket) { this.socket = socket; }
    public void run() {
      // read and service request
    }
 }

En general, no se debería lanzar una excepción durante la ejecución de un constructor sin hacer un catch de la misma y llevar a acabo una “limpieza” de los recursos utilizados por la clase. Una solución sencilla podría ser utilizar el constructor por defecto para crear los miembros “seguros” de la clase y después llamar a un método de inicialización para los “no seguros”, incluyendo el exception handling en éste.

Veamos un ejemplo sencillo. Supongamos que tenemos el siguiente código:

class Employee {
   ...
   Image * m_pImage;
   AudioClip * m_pAudio;
};

Employee(..., string image, string audio) : ..., m_pImage(NULL), m_pAudio(NULL)
{
   ...
   m_pImage = new Image(image);
   m_pAudio = new AudioClip(audio); // throw point
}

Si el código “new AudioClip(audio)” lanza una excepción, el flujo de control sale del constructor y se produce un memory leak. El destructor sólo sería llamado si el objeto hubiera sido completamente construido, pero no ha sido así.

Entonces, la manera correcta de implementar ese constructor sería:

Employee(..., string image, string audio) : ..., m_pImage(NULL), m_pAudio(NULL)
{
   ...
   try {
      m_pImage = new Image(image);
      m_pAudio = new AudioClip(audio);
   }
   catch(...)
   {
      delete m_pImage;
      delete m_pAudio;
      throw;
   }
}

De manera que, si se levanta una excepción, los recursos reservados son liberados y se vuelve a despachar la excepción para que notificar al objeto que intentaba construir esta clase.

Esta solución es buena, funciona bien, excepto en el caso de que tengamos punteros constantes como miembros de la clase:

class Employee {
   ...
   Image * const m_pImage;
   AudioClip * const m_pAudio;
};

Estos miembros deben ser incializados por el incializador de miembros propio de la clase, donde no podemos poner bloques try… catch.

En este caso, podríamos utilizar la clase auto_ptr<> (o similar) como wrapper para los punteros, de manera que se conviertan en objetos locales a nuestra clase:

class Employee {
   ...
   auto_ptr<image> m_pImage;
   auto_ptr<audioClip> m_pAudio;
};

Como ya se ha dicho, si ocurre una excepción durante la ejecución del constructor, se ejecutan los destructores de todos los miembros locales a la clase. Es decir, se llamaría al destructor de auto_ptr<>, el cual libera, de la manera adecuada, todos los recursos reservados.

[Fuente: http://progtutorials.tripod.com]

Basta con añadir algunas directivas de inclusión de ficheros y la lista de ficheros de código:

include $(GNUSTEP_MAKEFILES)/common.make

APP_NAME = edictParser
edictParser_APPLICATION_ICON = icon.png
edictParser_RESOURCE_FILES = icon.png
edictParser_OBJC_FILES = main.m

include $(GNUSTEP_MAKEFILES)/application.make

Para el caso de querer utilizar código C++, sustituimos la línea:

edictParser_OBJC_FILES = main.m

por:

edictParser_OBJCC_FILES = main.mm

Y un pequeño truco para no tener que modificar el makefile cada vez que añadimos un fichero de código:

edictParser_OBJCC_FILES = $(shell ls -c1 *.mm)

[Nótese que la extensión para los ficheros Objective-C++ es mm.]

UPDATE [nombre_tabla] SET [nombre_campo] =
REPLACE([nombre_campo],'[cadena_actual]','[cadena_nueva]');

Por ejemplo:

UPDATE articulo SET cuerpo =
REPLACE(cuerpo,'à','á');

Por ejemplo, si vamos a utilizar expresiones regulares con caracteres no-ASCII (como la ñ o los caracteres acentuados).

Para establecer el locale, podemos utilizar el código:

const char* locstr = setlocale(LC_ALL, "es_ES.UTF8");

if (locstr == NULL) {
   printf("SETLOCALE ERROR!\n");
}

[Consultar API para setlocale.]

Si como ejemplo, buscamos la expresión regular “ñ” dentro de la cadena “este año es muy frío”, obtendremos un resultado diferente, dependiendo del locale definido:

1. Si se ha definido el locale “es”:

   start offset: 6
   end offset:  8
   

2. Si el locale es, por ejemplo, “us”:

   start offset: 6
   end offset:  7
   

Ya conocemos los problemas que presenta C/C++ para tratar caracteres unicode. Pero, al menos, podemos hacer búsquedas y sustituciones de una manera más fiable si el locale definido es el adecuado.

regex_t regex;
const int MAXMATCHES = 1;

regmatch_t matches[MAXMATCHES];

const char* str = "Look inside this string...";
const char* patt = "side";

size_t size = MAXMATCHES;

int cflags = REG_EXTENDED|REG_ICASE;
int eflags = cflags;

int result = 0;
int rescomp = regcomp(&regex, patt, cflags);
if (rescomp == 0) {
   result = regexec((const regex_t*)&regex, str, size, matches, eflags);
}
if (result == REG_NOMATCH) {
   printf("NOT MATCHED!");
} else {

   for (int i = 0;i < MAXMATCHES;i++) {
      regoff_t startOff = matches[i].rm_so;
      regoff_t endOff   = matches[i].rm_eo;

      if (startOff != -1) {
         printf("start offset:  %i", startOff);
         printf("end offset:   "%i, endOff);
      }
   }
}

Este código imprimirá en el terminal la siguiente salida:

start offset: 7
end offset:  11

Es decir, delimita el trozo de cadena que “machea” la expresión regular.

[En este enlace se puede consultar cómo construir expresiones regulares POSIX.]

La solución es utilizar el comando wget:

$ wget -r --user=nombre-usuario --password=pass ftp://nombre-dominio:puerto/path

Por ejemplo:

$ wget -r --user=ilikeblues --password=cutrepass ftp://midominio.com/micarpeta

Existen dos formas comunes de implementar una clase singleton en Java, que son: utilizar una instancia “public static final” o bien utilizar el método de “static factory” (podéis ver ejemplos en la wikipedia).

Sin embargo, existe un tercer método. Probablemente, este es el mejor, si se usa una versión de Java superior a la 1.5.

Se puede utilizar un “enum” . De esta manera, se obtinene la funcionalidad del Singleton de una manera muy sencilla, además de que no se necesita implementar la serialización, ya viene “de fábrica”:

package electro;

public enum YourSingleton {
   INSTANCE;

   public void doStuff(String stuff) {
      System.out.println("Doing " + stuff);
   }
}

Así, podemos utilizarla completamente seguros de que es singleton:

YourSingleton.INSTANCE.doStuff("some stuff");

Los navegadores suelen ser fáciles de configurar. Sin embargo,¿cómo hacer para que, por ejemplo, apt-get funcione correctamente?

Es bastante sencillo: sólo hay que añadir estas líneas al final del fichero /etc/profile:

http_proxy=http://{nombre_de_usuario}:{contraseña}@{proxy_server}:{puerto_proxy}/
export http_proxy

Por ejemplo:

http_proxy=http://pepito:grillo@proxy.midominio.com:8080/
export http_proxy

Reboot y listo. apt-get, y el resto de aplicaciones que hacen conexiones de tipo http a internet, funcionando correctamente.

Espero que lo disfrutéis…

http://www.bgoncalves.com/notes/2008/04/20/30-free-online-books/

El código:

fullScreenAction = new Action("Full Screen") {
   {
      setId("fullscreen");
      setActionDefinitionId("mypluginid" + "fullscreen");
   } //$NON-NLS-1$

   public void run() {
      // grab an IWorkbenchWindow and fullscreen it
      window.getShell().setFullScreen(true);
   }
};

Es muy simple. Para más información, tenéis este post.

[Este post es una traduccion de este otro, publicado en dzone.]

Si una función se ha declarado estática para restringir el acceso a la misma, para no incluirla en el API del módulo, ¿por qué “bypassear” la funcionalidad y acceder a ella?

En mi caso, la respuesta es sencilla: pruebas unitarias. ¿Cómo hacer pruebas unitarias de estas rutinas?

La respuesta es, creando punteros a estas rutinas, accesibles desde otros módulos. Y puesto que cualquier solución implica cambios en los módulos a probar, en el ejemplo a continuación trataré de ser lo menos “intrusivo” posible.

Supongamos el módulo stfunc.c:

#include <stdio.h>
static int funcprintf(const char* str) {
   return printf(str);
}

Para probar esta rutina, tenemos esta otra, en otro fichero diferente (main.c):

int main() {
   int a = funcprintf("Loquesea");
   return a;
}

Si intentamos compilar, obtenemos el error “undefined reference to `funcprintf’”.

Así pues, vamos a crear un puntero a esta rutina para permitir el acceso a la misma desde el módulo de prueba. Creamos un fichero llamado ptrdefs.h:

#ifndef _PTRDEFS_H
#define _PTRDEFS_H
int (*fpointer)(const char*) = &funcprintf;
#endif

Y modificamos los ficheros anteriores de esta manera:
Fichero stfunc.c:

#include <stdio.h>

static int funcprintf(const char* str) {
   return printf(str);
}

#ifdef UNIT_TESTING
#include
<ptrdefs.h>
#endif

Fichero main.c:

int main() {
   int a = fpointer("Loquesea");

   return a;
}

Con esto, basta añadir la opción -DUNIT_TESTING para tener acceso a la rutina.

Por tro lado, el fichero ptrdefs.h sólo estará disponible para los tests unitarios. Esto evita el acceso indeseado.

[Código completo del ejemplo: static.tgz]

Para empezar, una breve reseña acerca de la sobrecarga de métodos. Decimos que un método ha sido “sobrecargado” cuando han sido creados múltiples métodos con el mismo nombre, pero especificando distintos argumentos (en número o tipo).

Como ejemplo veamos este trozo de código:

class Dog {
   public static void main(String[] args) {
      bark();    // prints "no param"
      bark(100); // prints "with param"
   }

   public static void bark() {
      System.out.println("no param");
   }

   public static void bark(int decibels) {
      System.out.println("with param");
   }
}

En este caso, se ejecuta un método u otro dependiendo de si se especifica un parámetro en la llamado o no.

Supongamos ahora una situación como la siguiente:

class Animal {}

class Dog extends Animal {}

class TestOverload {
   public static void main (String[] args) {
      Animal a1 = new Animal();
      Animal a2 = new Dog();
      Dog d = new Dog();
      makeSound(a1);
      makeSound(a2);
      makeSound(d);
   }

   public static void makeSound(Animal a) {
      System.out.println("Making animal sound");
   }

   public static void makeSound(Dog d) {
      System.out.println("Making dog sound");
   }
}

A priori, podríamos pensar que la salida es:

Making animal sound
Making dog sound
Making dog sound

Sin embargo, la salida es:

Making animal sound
Making animal sound
Making dog sound

La razón es que Java determina qué versión del método sobrecargado va a ser llamada en tiempo de compilación.

Así pues, aunque a referencia a2 apunta a una instancia del objeto Dog, el compilador utiliza una referencia de tipo Animal para determinar cual de los métodos será llamado.

A continuación un ejemplo de lo peligroso que puede llegar a resultar esto. Un ejemplo en que la salida del programa no permite distinguir cual de los métodos está siendo ejecutado:

class Animal {
   public void doMakeNoise() {
      System.out.println("Making animal noise");
   }
}

class Dog extends Animal {}

class TestOverload {
   public static void main (String[] args) {
      Animal a1 = new Animal();
      Animal a2 = new Dog();
      Dog d = new Dog();
      makeSound(a1);
      makeSound(a2);
      makeSound(d);
   }
   public static void makeSound(Animal a) {
      a.doMakeNoise();
   }
   public static void makeSound(Dog d) {
      d.doMakeNoise();
   }
}

La salida sería:

Making animal noise
Making animal noise
Making animal noise

Esto se debe al polimorfismo y la llamada a doMakeNoise añadida en cada uno de los métodos makeSound.

Evidentemente, esto no es un problema si la funcionalidad final es la misma (pero en este caso se necesitaría una reorganización de código).

Lo importante, en cualquier caso, es tener en mente que Java determina el método sobrecargado a ejecutar en tiempo de compilación.

Supongamos el siguiente fichero de código main.c:

En este caso, el script de compilación y ejecución será compexec.sh:

Nótese como la herramienta gcov ha sido ejecutada con las opciones -b y -c. Según “man gcov”:

1. -b
   –branch-probabilities
   Write branch frequencies to the output file, and write branch summary info to the standard output. This option allows you to see how often each branch in your program was taken. Unconditional branches will not be shown, unless the -u option is given.
2. -c
   –branch-counts
   Write branch frequencies as the number of branches taken, rather than the percentage of branches taken.

Es decir, pedimos a la herramienta que devuelva información sobre ejecución de las “ramas lógicas”, dando como resultado el fichero main.c.gcov:

Aquí podemos ver información, aunque un tanto críptica, sobre la ejecución de dos bloques if-else. Como puede verse, cada uno de ellos presenta cuatro ramas, numeradas de “branch 0″ a “branch 3″. Veamos a continuación la explicación de estos datos:

Supongamos la condición:

if (a || b) {
   x;
} else {
   y;
}

Esta condición (o combinación de condiciones) da lugar a 4 ramas, que se corresponden con las posibles combinaciones de valores booleanos de las dos variables:

a b
—-
0 0
0 1
1 0
1 1

Podemos reescribir esta condición como:

if (a == false) {
   // Branch 0
   if (b == false) {
      // Branch 2
      y;
   } else {
      // Branch 3;
      x;
   }
} else {
   // Branch 1
   x;
}

Supongamos ahora la condición:

if (a && b) {
   x;
} else {
   y;
}

Como antes, esta condición (o combinación de condiciones) da lugar a 4 ramas, que se corresponden con las posibles combinaciones de valores booleanos de las dos variables:

a b
—-
1 1
1 0
0 1
0 0

Podemos reescribir esta condición como:

if (a == true) {
   // Branch 0
   if (b == true) {
      // Branch 2
      x;
   } else {
      // Branch 3;
      y;
   }
} else {
   // Branch 1
   y;
}

En cualquiera de los casos anteriores, la herramienta gcov (con las opciones -bc) nos devuelve el número de veces que cada una de las ramas nombradas más arriba ha sido ejecutada.

Si se omite la opción -c, los resultados son porcentajes, de manera que la suma de las ejecuciones de todas las ramas deberá ser el 100 %.

Además, se puede deducir que, en cualquiera de los casos:

1.- (nº de ejecuciones de rama 0) + (nº ejecuciones rama 1) = (nº ejecuciones
del if

2.- (nº ejec rama 2) + (nº ejec rama 3) = (nº ejec rama 1)

En conclusión, podemos deducir qué líneas de código y ramas lógicas han sido ejecutadas y añadir/modificar los test cases necesarios para alcanzar la cobertura deseada.

[Código completo y resultados.]

Para empezar el código fuente, main.c:

A continuación, las instrucciones de compilación y ejecución, compexec.sh:

Como se puede apreciar, son tres las opciones añadidas al compilador/linkador para obtener los resultados esperados:

1. -pgEsto es lo que dice “man gcc” acerca de esta opción:

   “Generate extra code to write profile information suitable for the analysis program gprof. You must use this option when compiling the source files you want data about, and you must also use it when linking.”

   Es decir, prepara el ejecutable para generar información suscpetible de ser utilizada por gprof para obtener información de “profiling”. Tras la ejecución de la aplicación generada con esta opción, se crea el fichero gmon.out.

2. -ftest-coverage
3. -fprofile-arcsEstas dos opciones son las que indican al compilador que, durante la ejecución de la aplicación, debe generarse información de cobertura.

   [La salida "man gcc" para estas opciones es demasiado larga para incluirla aquí, pero puede verse en este enlace.]

   El ejecutable compilado/linkado con estas opciones genera los ficheros main.gcno y main.gcda, que contienen los datos utilizados por gcov para generar información “legible” de cobertura.

Así pues, una vez ejecutada la aplicación y obtenidos estos ficheros, basta con ejecutar el comando gcov:

$ gcov main.c

(tal como se ha incluido en el fichero compexec.sh) y como resultado se obtiene el fichero main.c.gcov:

El fichero de resultados muestra el número de veces que un statement ha sido ejecutado.

Las instrucciones marcadas con “#####” son aquellas no cubiertas por la ejecución de la aplicación.

[Código completo y resultados.]

As soon as you go back to a previously written line of code (to read, check or even rewrite it…), you are entering the “maintenance mode”. That’s the reason why code maintainability is so important in software engineering. And, since mainly working on pseudo real-time systems (such as wireless sensor networks), performance in our tools is another important point.

So, TPTP eclipse plugin is a very useful tool for us. We integrate it in our projects from the very beginning of the development process.

From my point of view these are the strong TPTP plugin points:

1. Code Analyzer: it is fast, intuitive and highly configurable. A newbie will not spend more than five minutes to adapt it to his needs and correctly use it.
2. The “Quick Fix” functionality: in most cases, the solution proposed is pretty good.
3. The Profiling tool: though mainly interested in execution time and method coverage, I stated that this plugin covers many other useful functionalities.

On the other hand, there are some features that, of course from my point of view, should be improved.

Most of our application prototypes are being deployed as RCPs. And RCPs profiling executions are not completely working in all of our different development environments. In fact, Eclipse Europa environment and last TPTP plugin version (4.4) has been the first to give some information about that kind of applications (maybe due to unsatisfied dependencies in our previous environments).

In conclusion, some improvements in executions profiling will make this so helpful plugin be an indispensable tool for Java developers and SW engineers.