Evitar que el reproductor de M80 se pare cada media hora

Hoy voy con un consejo que se aleja a lo que normalmente tengo habituado, pero que seguro que será de utilidad a mucha más gente que los otros: Cómo evitar que el reproductor de M80 radio se pare cada media hora.

Y es que si escuchas habitualmente esta radio a través de internet, te habrás dado cuenta de que cada media hora tienes que ir al reproductor y volver a darle al play, lo cual es un rollo.

Para solventar este problema, se puede instalar un plug-in o add-on para Firefox que recargue la página cada 29 minutos automáticamente, por tanto evita que se llegue a la media hora que es cuando se para. Escucharemos un corte de que se está recargando la página, pero al instante seguiremos escuchando la emisión.

Los pasos son:

• Utilizar Firefox (si no lo haces, instálalo, te lo recomiendo encarecidamente)
• Instalar el plugin "ReloadEvery"
• Pinchar en "Continue to Download"
• Pinchar en "Add to Firefox"
• Aceptar la ventana que aparece: "Instalar ahora" o parecido
• Reiniciar Firefox
• Con el plugin instalado, abrir la página de M80, el reproductor online
• Botón derecho sobre la pestaña y en el menú "Reload Every" seleccionar el valor deseado (algo que sea inferior a 30 min, yo recomiendo 29)
• Asegurarte en ese mismo menú que está activado (enabled) de lo contrario no recargará

Con esto ya está completado, mira a ver si te funciona y me cuentas

UPDATE: para el navegador Google Chrome se puede utilizar la extensión Easy Auto Refresh

Un saludo

El truco de la semana: Cambiar los tabs en Eclipse

Utilizo el IDE eclipse constantemente para programar, ya sea en Java o en PHP y me vuelvo loco cuando tengo que cambiar entre dos editores diferentes del mismo programa: estoy trabajando en un archivo y quiero mirar alguna cosa de otro... los dedos se me van automáticamente al ALT + TAB utilizado en windows para cambiar de ventana lo que hace que me salga del eclipse y vaya a parar a otra aplicación diferente. Esto me pasa no una vez, ni dos, sino constantemente y es un engorro.

Hoy he descubierto un par de atajos que pueden ayudar a moverse entre los editores de eclipse de una manera rápida y sin tener que echar mano al ratón:

CTRL + PgUp / CTRL + PgDown

Nos permite pasar al siguiente y anterior editor respectivamente

CTRL + F6

Tiene la misma función que el ALT+TAB de windows, pulsando F6 repetidas veces pasamos al siguiente editor, en el orden en que los hemos visitado, mucho mejor opción que la anterior.

CTRL + E

Abre un dialogo en el que vemos todos los editores abiertos y con las teclas del cursor y ENTER, saltamos a la ventana que más nos guste.

Mi solución:
La opción que más me gusta es la de CTRL + F6 pues funciona justo como yo quiero, pulsando una vez, voy al último editor visitado que generalmente es el que estoy buscando. Sin embargo la tecla F6 me pilla muy a desmano porque no la tengo entre las teclas más presionadas, por lo que he entrado en el editor de atajos de teclado y simplemente he cambiado la E por el F6, para cambiar sus funcionalidades cuando está CTRL pulsado.
Para hacer esto, en Window -> Preferences y ahí dentro de General, la opción Keys (o buscar Keys directamente en el cuadro de búsqueda superior)

Error de violación de seguridad Sandbox

Largo tiempo sin publicar... hoy lo hago para reportar este error que me ha surgido y que seguro a más de uno le puede ayudar a solucionar el problema, o incluso a mi en un futuro. Aquí va:

Si aparece en siguiente error de violación de seguridad:

Error #2049: Violación de la seguridad Sandbox:
http://100.100.100.100:7001/App/myApp.swf no puede cargar datos en http://100.100.100.200:8080/App2/dir/MyWebService?id=”5”

Hay que hacer lo siguiente.

Esto ocurre porque desde el archivo de Flex desplegado en la máquina 1 (IP:100.100.100.100 ) se está llamando a un web service situado en otra máquina 2 (IP: 100.100.100.200)
El problema se resuelve creando un fichero xml de nombre crossdomain.xml con este contenido:

<?xml version="1.0"?>
<cross-domain-policy>
 <allow-access-from domain="100.100.100.100" />
</cross-domain-policy>

Y se despliega en la raíz del servidor de la máquina 2. Es decir, tiene que estar accesible desde:
http://100.100.100.200:8080/crossdomain.xml

Ahora ya no debería aparece dicho error.

Apagar ordenadores desde escritorio remoto en Windows

El típico comando del acceso directo para poder apagar ordenadores desde el escritorio remoto de windows:

%windir%\System32\shutdown.exe -s -f -t 00

WicketSession fuera de Wicket

Wicket tiene su propio objeto de sesión que se puede utilizar dentro de una aplicación para guardar elementos entre distintas llamadas de un mismo cliente. Este objeto será una org.apache.wicket.Session o algún otro objeto que la extienda como WebSession o un objeto propio.

Mientras no nos salgamos de la aplicación de Wicket todo va bien y tendremos la sesión disponible... pero ¿y si tenemos que enviar al usuario a otra parte de nuestro servidor que se sale de nuestra aplicación? A un servlet distinto o un formulario de otra parte, por ejemplo. En ese caso perderemos la sesión y no podremos saber que se trata del mismo que viene de la aplicación Wicket.

Hay una solución para este problema y que nos dejará la sesión disponible en cualquier otro lugar (servlets, jsps...) y es a través de un filtro especial llamado WicketSessionFilter que hará justo lo que deseamos, transportar la sesión a otros lugares.
Para usarlo, debemos configurarlo primero en el archivo web.xml del servidor de aplicaciones:

<!-- The WicketSesionFilter can be used to provide thread local access to servlets/ JSPs/ etc -->
  <filter>
    <filter-name>WicketSessionFilter</filter-name>
    <filter-class>org.apache.wicket.protocol.http.servlet.WicketSessionFilter</filter-class>
    <init-param>
      <param-name>filterName</param-name>
      <!-- expose the session of the input example app -->
      <param-value>FormInputApplication</param-value>
    </init-param>
  </filter>
 
  <!-- couple the session filter to the helloworld servlet -->
  <filter-mapping>
    <filter-name>WicketSessionFilter</filter-name>
    <url-pattern>/helloworldservlet/*</url-pattern>
  </filter-mapping>

En el parámetr filterName, debemos poner el valor de otro filtro que ya tengamos en nuestra aplicación (la verdad que esto no lo se muy bien por qué, pero es como me ha funcionado) y el resto de campos se puede ver bastante bien en el ejemplo: el mapping al servlet en el que queremos tener disponible nuestra sesión de Wicket.

Ahora ya se puede acceder a la sesión desde el servlet de la siguiente manera:

Session wicketSession = Session.get();

Que dentro de un servlet quedaría algo así:

public class HelloWorldServlet extends HttpServlet
 {
        public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException,
                IOException
        {
                res.setContentType("text/html");
                PrintWriter out = res.getWriter();
                String message = "Hi. " +
                        (Session.exists() ? " Veo la sesion de Wicket " + Session.get() + "."
                                : " No encuentro la sesion de Wicket.");
                out.println(message);
                out.close();
        }
 }

Fuente: http://wicket.apache.org/apidocs/1.4/org/apache/wicket/protocol/http/servlet/WicketSessionFilter.html

Cisco Scientific Atlanta EPR2320 Drivers para el modem de ONO

Después de volverme medio loco buscando los drivers para el cable modem EPR2320 que viene (o venía) con ONO, he encontrado el enlace a los drivers desde la página de Cisco (el CD que viene no vale para nada, sólo trae un enlace a una página completamente desfasada de antes de que Cisco comprar Scientific Atlanta). No me entretengo más y dejo el enlace a los drivers:

http://www.cisco.com/web/consumer/support/modem_DPR2320.html#~drivers

Espero que a alguien le sirva!

Jugando con medidas y javaScript

Me está tocando realizar alguna que otra labor con javaScript y como yo pertenezco a la vieja escuela en este lenguaje, intento siempre sacarlo todo a través de las propiedades del propio lenguaje.

Esto, si bien tiene la ventaja de que aprendes javaScript puro y duro, tiene la desventaja de que hay que saber ciertos trucos si queremos obtener los mismos resultados independientemente del navegador que se esté usando. Y esto generalmente va referido a Internet Explorer que es el que más problemas causa y ha causado históricamente.

Por poner un ejemplo, para obtener la posición de la barra de scroll del navegador, en Firefox o Chrome nos valdrá con la propiedad window.pageXOffset; pero no en Internet Explorer 9 (y anteriores supongo) en el que hace falta coger el document.body.scrollLeft. De esta manera tenemos que empezar a hacer cosas como:

var hscroll = (document.all ? document.body.scrollLeft : window.pageXOffset);
var vscroll = (document.all ? document.body.scrollTop : window.pageYOffset);

Con esto hay que tener cuidado pues uno se puede ir a casa tranquilamente pensando que su trabajo funciona para encontrarse al día siguiente con que el cliente le dice "no funciona en Internet Explorer" y tu piense... ¿qué era Internet Explorer? ¿No lo habían prohibido ya? y te toque ponerte a buscar la solución para el navegador de los hacks.

Lo mismo pasa con otras propiedades como el ancho/alto del navegador o el ancho/alto del viewport de la página que estamos viendo: hay que dar varias vueltas para obtener el valor que de verdad queremos. Cansado de ello, he decidido pasarme a la nueva escuela e introducir jQuery para obtener todos estos valores. A través de sus funciones ya implementadas no es necesario preocuparnos del navegador, pues ellos lo hacen por nosotros.
Así por ejemplo, para obtener el scroll de la página nos vale con:

var hscroll = $(window).scrollTop();
var vscroll = $(window).scrollLeft();

O lo mismo para obtener el ancho y alto del navegador:

 var winW = $(window).width();
 var winH = $(window).height();

O para obtener el offset de un elemento con respecto a la ventana:

var imgOffset = $("#elementID").offset();

Conclusión: está muy bien saber por qué funcionan las cosas y jugar con las diferentes propiedades y en los diferentes navegadores, pero cuando hay que hacer algo serio que tiene que funcionar, es preferible usar alguna de las librerías fiables que existen en internet.