Archivo por meses: enero 2013

Truco: Spring 3.1 y error con persistence-unit de test.

Estaba recordando Spring, siguiendo un tutorial de Francisco Grimaldo, cuando me he encontrado con un curioso error.

Tras implementar un Unit Test para la recuperación de datos de la base de datos, la ejecución ha empezado a darme el siguiente error:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘entityManagerFactory’ defined in class path resource [test-context.xml]: Invocation of init method failed; nested exception is java.lang.IllegalStateException: Conflicting persistence unit definitions for name ‘springappPU’: file:/H:/Users/Manuel/Documents/workspace-sts-3.1.0.RELEASE/webMeet/target/classes, file:/H:/Users/Manuel/Documents/workspace-sts-3.1.0.RELEASE/webMeet/target/test-classes
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1486)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:524)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:461)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1117)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:922)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:83)

Tras comprobar si había metido la pata en alguno de los pasos y darle muchas vueltas, sin encontrar dónde estaba el error, he terminado encontrando una solución en (como no) Stackoverflow.

La solución, por si os sirve a alguno de ayuda, pasa por renombrar la persistence-unit usada por los Unit Test de nombre:

test/resources/META-INF/persistence.xml

<persistence-unit name="springappPUtest" transaction-type="RESOURCE_LOCAL">
	</persistence-unit>

test/resources/test-context.xml

<property name="persistenceUnitName" value="springappPUtest"></property>

Y luego unificar en el mismo persistence.xml ambos ficheros.

main/resources/META-INF/persistence.xml

	<persistence-unit name="springappPU" transaction-type="RESOURCE_LOCAL">
	</persistence-unit>

	<persistence-unit name="springappPUtest" transaction-type="RESOURCE_LOCAL">
	</persistence-unit>

No es la solución más óptima, pero al menos permite que el Unit Test se ejecute.

Sony y el acierto de su estrategia en Android

Hace algo más de un mes, el pasado 12 de diciembre de 2012, una noticia me llamó la atención sobre Sony y Android:

Sony apoya a la comunidad y soluciona problemas de compatibilidad de CyanogenMod

hoy mismo hemos sabido que Sony ha salido al paso para solventar un problema de compatibilidad con el audio de los Sony Xperia en CyanogenMod. Como lo oís, Sony se ha preocupado de corregir un problema en el código fuente de CyanogenMod. Para hacer esto sin tener que liberar el código fuente de los componentes el desarrollador de Sony, Oskar Anderö, examinó el código público de CyanogenMod y corrigió los errores decompatibilidad con el chip de audio de forma que ahora CyanogenMod cuenta con soporte total para el audio de los Xperia.

Hasta ahora, hacer root o flashear una ROM distinta a la que tu smartphone traía de fábrica, era sinónimo de posibles problemas, pérdidas de garantía o quedar expuesto a perder una (muchas veces) lenta ROM original en pro de una ROM que no termina de ir bien.

Sin embargo, esta noticia del pasado diciembre ofrecía un giro total a la política que la totalidad de fabricantes llevaban a rajatabla, al pasar de solo dar soporte con sus ROMs oficiales a ayudar, por primera vez, a la comunidad para mejorar la compatibilidad con sus dispositivo.

A esto hay que añadir que si dispones de un Xperia (yo tengo un Neo V), el hacer root puede ser mucho más sencillo de lo que hasta ahora era gracias a que la propia Sony te ofrece el método y código de desbloqueo del bootloader de tu Xperia en su propia página web:

Página de Unlocking de Sony

Página de Unlocking de Sony

Es decir, basta con aceptar sus condiciones, hacer una comprobación para verificar que el bootloader puede ser desbloqueado y seguir el proceso que ellos mismos te indican, te envía tu clave de desbloqueo y una vez recibida puedes llevar a cabo el proceso.

Pero, ¿cuáles son las ventajas para Sony con esta estrategia?

Por una parte consiguen mejorar su imagen, dentro de la comunidad de desarrolladores de ROMs y de los que no tenemos problema en lanzarnos a probar distintas ROM para nuestros dispositivos, lo que le repercutirá en mejorar sus ventas y ganar puestos entre las preferencias de muchos posibles clientes.

No olvidemos que uno de los grandes problemas de Android es la enorme fragmentación del sistema, que provoca que aún a día de hoy sigamos viendo terminales lanzados con versiones 2.3.6 del sistema, aunque ICS (4.0) lleva con nosotros más de un año y Jelly Bean (4.1) ha demostrado ser una versión muy pulida y apetecible.

Gráfico fragmentación Android

Fragmentación en Android, tremendo el porcentaje de Gingerbread a estas alturas

Las quejas entre usuarios de Android por la falta de rigor a la hora de que los fabricantes dediquen esfuerzo y tiempo en traer las últimas versiones de Android a terminales recientes, son muy numerosas y suelen conllevar que muchos usuario renieguen de un determinado fabricante o incluso opten por lanzarse a comprar un Nexus de Google (cuando hay disponibilidad).

De ahí el acierto en la estrategia de Sony, por un lado consigue aprovechar el propio esfuerzo de la Comunidad en adaptar las últimas versiones de Android a sus terminales, lo que le puede ahorrar mucho esfuerzo y dinero si lo hicieran todo ellos mismos.

Por otra parte consigue contentar a muchos usuarios que se sienten más respaldados por el fabricante y que ven cómo tienen más opciones a la hora de decidir que ROM instalar, disfrutando así de versiones de Android que de otra forma no podrían instalar.

 

Por mi parte ya he desbloqueado el bootloader, así que ahora solo me queda decidir qué ROM terminaré probando.

Usar un D-Link DSL-524T como switch.

Hoy vamos a ver cómo podemos reutilizar un viejo modem-router para añadir conectividad en casa y dar acceso a internet a algunos dispositivos que por su sitio en la casa es más complicado conectar.

En casa tengo un router WiFi de ONO, un Netgear CG3100D con el que estoy muy contento desde  que me lo instalaron para quitar mi primero cable modem, dando conectividad al PC de sobremesa y los dispositivos con WiFi que tengo por casa.

Netgear CG3100D

Netgear CG3100D usado por ONO

El caso es que en el salón tengo un LCD Samsung LE37B651, que por defecto trae puerto Ethernet para conectarlo a internet e incluso aprovechar su funcionalidad DLNA+, y al que en su día se podía comprar un stick USB para darle funcionalidad WiFi, pero a un precio abusivo de 60€.

Junto al LCD tengo un O!Play HDP-R1, una de las mejores compras que he hecho, con el que reproduzco películas, aunque siempre con el handicap de tener que copiar las películas a un disco duro para poder reproducirlas.

Así que pensando en darle acceso a internet, y al PC de sobremesa donde tengo muchas películas, hace uno meses compré un kit PLC (TP-LINK) para conectar el O!Play o el LCD, o para llevar conexión a cualquier habitación a dispositivos sin WiFi.

Kit PLC

Kit PLC

Pero para no tener que andar desenganchando y volviendo a enganchar el cable del O!Play al LCD y viceversa, vamos a reutilizar un ‘viejo’ modem-router D-Link DSL-524T de Ya.com que me dio un amigo, para poder dar conexión a ambos dispositivos.

Modem ADSL+2 D-Link DSL-524T

Modem ADSL+2 D-Link DSL-524T

Para ello tenemos dos formas de hacerlo, una es con una configuración manual de la red para todos los dispositivos, teniendo para ello que introducir la IP/Máscara de Red/Puerta de enlace en cada dispositivo que conectemos. La segunda es manteniendo la características de DCHP del modem-router, de forma que cualquier nuevo dispositivo conectado tenga su configuración de forma automática.

Por ser la más cómoda, vamos a centrarnos en la segunda forma.

Lo primero es conectar el PC por cable al modem, para poder acceder a la consola web y configurar el mismo.

Por defecto, la IP del módem es 192.168.1.1, el usuario y password: admin/admin.

Una vez que accedamos nos encontramos con esta pantalla:

Home de la configuración

Pantalla Inicial de la consola

Lo primero que haremos será pulsar sobre la opción LAN, accediendo a la siguiente pantalla:

Configuracion LAN

Configuración LAN del módem

En esta pantalla cambiaremos la IP por defecto (192.168.1.1), dado que el router Netgear usa la misma y tendríamos un conflicto. Manteniendo la misma máscara de red para ambos (255.255.255.0), cambiamos la IP por una dentro de un rango libre en el servicio DCHP del Netgear (así evitamos que se la pueda asignar a otro dispositivo y ocasionar conflictos).

Una vez hecho esto, tras pulsar en Apply se cambia la IP en la barra del navegador y nos vuelve a pedir el usuario y password de acceso.

Accedemos de nuevo y esta vez nos vamos a la opción de  DCHP y seleccionar la opción ‘No DCHP’, de esta forma cuando conectemos un nuevo dispositivo a este modem, el que realmente estará asignando nuevas IPs será el Netgear

Una vez llegados aquí, y antes de colocar el modem en su lugar final y conectar los dispositivos, vamos a probar que funciona.

Conectamos a uno de los puertos el conector PLC, cuyo gemelo está conectado al Netgear en la otra habitación.

Conectamos el PC (lo desconectamos y volvemos a conectar) a otro de los puertos, y teniendo configurada la red para que pida automáticamente la conexión, deberíamos tener conexión a la primera sin problemas y abriendo un navegador para acceder a cualquier web comprobaremos que ya todo funciona correctamente.

De esta forma, podemos reutilizar cualquiera de nuestros viejos modem-router ADSL como switch y ampliar nuestra red con un mínimo de inversión en tiempo y quizás algún cable de red extra que podamos necesitar (más el kit PLC en mi caso).

Doble rasero (Google/Apple).

No voy a negar mis preferencias por la gran ‘G’ (Google), y mucho menos que mi simpatía por Apple no va más allá de reconocer su aportación al mundo de la tecnología al haber sabido ofrecer productos tecnológicos para la gran mayoría de consumidores con una estética mucho más atractiva o una gran usabilidad.

Google-VS-Apple

Pero dejando al margen estos preferencias personales, me llama mucho la atención el doble rasero del que muchas veces hacen gala en los USA a la hora de vigilar a uno u otro.

En este caso me encuentro con la siguiente noticia sobre Google:

Google must change search business practices after FTC decision

The Federal Trade Commission handed down a full bag of decisions in its antitrust investigation of Google during a press conference on Thursday.

Essentially, Google is going to have to make a number of changes to its business practices — especially regarding search.

For starters, in a 4-1 vote, the FTC ordered Google to stop using patents purchased by Motorola to exclude competitors. These patents cover “standardized technologies” across smartphones, laptops, tablets, and gaming consoles.

Cuando Google decidió salir de compras y comprar Motorola Mobility, se hizo con un montón de patentes sobre tecnologías usadas ampliamente en el mundo de las comunicaciones y telefonía móvil.

En aquel momento, Apple había lanzado una ofensiva contra todos los fabricantes de móviles que se decantasen por sacar modelos con Android, buscando bloquear las ventas haciendo uso de sus patentes a base de demandas.

Así que cuando Google hizo esta compra, muchos pensamos que se produciría una guerra directa, que en realidad nunca se llevó a cabo. Aunque eso sí, Google empezó a ceder a algunos fabricantes alguna de sus recién adquiridas patentes, para poder forzar a Apple a negociar para no verse a su vez bloqueada.

Por eso, desde el principio las autoridades USA han estado muy encima de Google para discernir si esta nueva situación podría suponer una posición de monopolio.

Pero lo realmente llamativo, es que mientras a Google se la vigila de esta forma (absurda a mi entender, dado que si ha comprado las patentes son suyas y no hay más que hablar), las mismas autoridades no han sido igual de controladoras con Apple:

Apple consigue paralizar las ventas del Galaxy Nexus en Estados Unidos

Una jueza de EE UU aprobó el pasado viernes, a petición de Apple, una orden judicial por la que se prohíbe la venta del Samsung Galaxy Nexus de la compañía surcoreana por infringir varias patentes, convirtiéndose en la segunda victoria legal de los de Cupertino frente a Samsung en una semana.

Apple es también propietaria de patentes usadas por otros fabricantes, de dispositivos o SO para móviles, por lo que su forma de actuar también supone una práctica monopolista.

Sin embargo, la Administración USA se muestra mucho más laxa con Apple, como si fuese su ‘niña bonita’ a la que permite actuar de forma sucia y caprichosa.

Y lo que es peor, este tipo de actuaciones conllevan ciertos problemas añadidos que se destacan en el primer artículo:

The FTC’s stance on this is that, “if left unchecked,” these patents could give way to higher prices “as companies may pay higher royalties for the use of Google’s patents because of the threat of an injunction, and then pass those higher prices on to consumers.”

The worst-case scenario, according to the FTC, would be for the technology industry to abandon standards, limiting innovation and investment altogether.

Es decir, por un lado se aumenta el precio final del producto por tener que pagar altos ‘royalties’ por estas patentes, y por otra parte se frena la innovación e inversión al preferir muchas empresas vivir de las rentas antes que seguir invirtiendo en I+D.

Lo curioso es que esta parte se aplique hasta ahora solo a Google, a quien se le impondrán medidas para evitar que pueda abusar de su posición dominante (sobre todo en lo relacionado con las búsquedas), pero no se haga lo mismo con Apple que corre el riesgo de lastrar un mercado en auge como es el de la telefonía móvil.

Espero que por el bien de todos los consumidores, las autoridades no se ciñan únicamente a uno de estas empresas y tengan a bien vigilar al resto para evitar situaciones dominantes en base a las (muchas veces absurdas) patentes.