Archivo del Autor: mvcarrillo

cabecera-git

Usando GIT desde eclipse.

Ahora que Sebas nos ha dado las explicaciones correctas para saber cómo montar GIT en nuestro servidor y unas nociones de uso básico, vamos a proceder a ponerlo en práctica con algo que es de lo más habitual, usarlo desde eclipse.

Para ello, tras seguir las explicaciones de Sebas he instalado GIT en mi Raspberry Pi con un simple:

pi@raspberrypi ~ $ sudo apt-get install git
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Se instalarán los siguientes paquetes extras:
  git-man libcurl3-gnutls liberror-perl rsync
Paquetes sugeridos:
  git-daemon-run git-daemon-sysvinit git-doc git-el git-arch git-cvs git-svn
  git-email git-gui gitk gitweb
Se instalarán los siguientes paquetes NUEVOS:
  git git-man libcurl3-gnutls liberror-perl rsync
0 actualizados, 5 se instalarán, 0 para eliminar y 15 no actualizados.
Necesito descargar 7.624 kB de archivos.
Se utilizarán 13,8 MB de espacio de disco adicional después de esta operación.
¿Desea continuar [S/n]? S
Des:1 http://mirrordirector.raspbian.org/raspbian/ wheezy/main libcurl3-gnutls armhf 7.26.0-1+wheezy1 [306 kB]
Des:2 http://mirrordirector.raspbian.org/raspbian/ wheezy/main liberror-perl all 0.17-1 [23,6 kB]
Des:3 http://mirrordirector.raspbian.org/raspbian/ wheezy/main git-man all 1:1.7.10.4-1+wheezy1+rpi1 [1.074 kB]
Des:4 http://mirrordirector.raspbian.org/raspbian/ wheezy/main git armhf 1:1.7.10.4-1+wheezy1+rpi1 [5.864 kB]
Des:5 http://mirrordirector.raspbian.org/raspbian/ wheezy/main rsync armhf 3.0.9-4 [356 kB]
Descargados 7.624 kB en 12seg. (597 kB/s)
Selecting previously unselected package libcurl3-gnutls:armhf.
(Leyendo la base de datos ... 90142 ficheros o directorios instalados actualmente.)
Desempaquetando libcurl3-gnutls:armhf (de .../libcurl3-gnutls_7.26.0-1+wheezy1_armhf.deb) ...
Selecting previously unselected package liberror-perl.
Desempaquetando liberror-perl (de .../liberror-perl_0.17-1_all.deb) ...
Selecting previously unselected package git-man.
Desempaquetando git-man (de .../git-man_1%3a1.7.10.4-1+wheezy1+rpi1_all.deb) ...
Selecting previously unselected package git.
Desempaquetando git (de .../git_1%3a1.7.10.4-1+wheezy1+rpi1_armhf.deb) ...
Selecting previously unselected package rsync.
Desempaquetando rsync (de .../rsync_3.0.9-4_armhf.deb) ...
Procesando disparadores para man-db ...
Configurando libcurl3-gnutls:armhf (7.26.0-1+wheezy1) ...
Configurando liberror-perl (0.17-1) ...
Configurando git-man (1:1.7.10.4-1+wheezy1+rpi1) ...
Configurando git (1:1.7.10.4-1+wheezy1+rpi1) ...
Configurando rsync (3.0.9-4) ...
update-rc.d: using dependency based boot sequencing

Una vez que lo tenemos instalado, en mi caso he creado un directorio ‘git-repo’ en el disco USB que tengo montado (para no castigar la tarjeta SD con continuas re-escrituras), al que he enlazado desde el ‘home’ de mi usuario con un:

pi@raspberrypi ~ $ ln -s /media/usb1/git-repo git-repo

Ahora nos creamos un repositorio de ejemplo y estamos listos para pasar a eclipse para configurarlo.

Para ello, con la versión de eclipse Java Developer tenemos suficiente, ya que integra GIT por defecto, aunque en los pantallazos que pondré a continuación veréis otra versión distinta.

Para empezar abrimos la perspectiva ‘Git Repository Exploring’ en eclipse y podremos ver que en la pestaña de la izquierda tenemos un listado de los repositorios de Git definidos.

Sobre los repositorios veremos 3 iconos que nos permiten:

  • Añadir un repositorio existente de GIT.
  • Clonar nuestra repositorio y añadirlo a la vista.
  • Crear un nuevo repositorio y añadirlo a la vista.

Seleccionaremos la segunda opción, dado que ya tenemos el repositorio creado en el Raspberry y lo que queremos es clonarlo y empezar a usarlo.

En la ventana que sale seleccionamos URI, ya que es un repositorio personal y no de GitHub, y en la siguiente ventana rellenaremos los datos de la conexión:

Configuración de la conexión

Configuración de la conexión

Rellenamos el campo Host con la IP o el nombre de la máquina, poniendo en ‘Repository Path’ el path al directorio donde hemos creado nuestro repositorio de ejemplo. En nuestro caso usamos ‘~’ para indicar que la ruta es relativa al directorio home del usuario.

A continuación intentará realizar la conexión y si es correcta, nos preguntará si queremos aceptar el certificado, a lo que debemos de responder que sí.

Seguridad - Certificado

Seguridad – Certificado

Luego debemos seleccionar la rama para la que queremos realizar la configuración, aunque al tratarse de un repositorio vacío no tenemos ninguna y nos engancharemos a la rama principal o ‘master’.

Selección de una rama

Selección de una rama

Ahora, hemos creado un proyecto de ejemplo que queremos incluir en nuestra rama, cosa que haremos mediante la opción Team -> Share Project del menú desplegable sobre nuestro proyecto.

Share Project en nuestro repositorio

Share Project en nuestro repositorio

Ahora seleccionamos sobre dónde queremos compartirlo, seleccionando Git:

Seleccionamos Git

Seleccionamos Git

A continuación seleccionamos el repositorio sobre el que hacer el Share.

Seleccionando el repositorio en el que compartir

Ahora podemos añadir nuestra clase de ejemplo al repositorio con la opción ‘Add’ y a continuación realizar nuestro primer commit:

Añadiendo el archivo

Haciendo commit del archivo

Nuestro primer commit

Nuestro primer commit

Ahora el fichero ya está incluido en el repositorio:

Fichero versionado

Fichero versionado

Lo único que nos queda es hacer un Push sobre el servidor:

Push

Push

Y así ya tenemos configurado en eclipse nuestro respositorio en Git.

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).