Cómo liberar gratis el LG Optimus 3D (O3D P920)

Tal y como dije en una entrada anterior, he cambiado de compañía de teléfono para ahorrar algo mes a mes y como consecuencia he tenido que ir liberando los terminales que tenía.

Uno de los terminales ha sido mi móvil, un LG Optimus 3D (P920).

medium02

 

 

En un principio sólo localicé códigos para liberar por imei con un coste asociado, pero gracias a Acura, un cocinero de ROMS de htcspain.com, he conseguido liberar de forma totalmente gratis mi teléfono.

El proceso ha sido bastante fácil y además existe muchísima información en la página de htcspain.com.

Básicamente ha consistido en cambiar la BB (Base Band),  que es el software GSM que gestiona toda la parte de telefonía, incluido el bloqueo.

Para poder liberar el teléfono sólo tienes que seguir los pasos de este enlace.

“Obtener información de internet es como intentar beber agua de una boca de incendios”
— Mitchell Kapor

Cómo liberar el módem usb Huawei k3765 de Vodafone

Hasta hace poco me ha sido rentable mantenerme con Vodafone gracias a la unificación de la línea de móvil mas el ADSL y que me seguían regalando terminales, pero ahora no hay forma de que regalen un móvil y encima los terminales que me ofrecen son más caros que comprarlos libres en tienda. Por esto he decidido cambiar de compañía y ahorrar unos eurillos a final de mes, que con el dinero ahorrado puedo comprar otro teléfono en un tiempo.

Ahora que cambio de compañía, tengo un módem USB que no me servirá para nada así que me he puesto a trastear con él para tratar de liberarlo y para sorpresa mía ha sido muy fácil.

vodafone_connect_3g-1

Metiéndonos en faena, he aquí los pasos para liberar el módem:

1 – Para empezar instalamos el módem con su software original, como si lo hubiésemos instalado para usarlo con nuestra compañía.

2 – Descargamos el fichero v4mpire_unlocker y lo descomprimimos. Dentro encontramos un ejecutable que abrimos como administrador.

3 – Introducimos el IMEI del módem y pulsamos CALC.

liberar_modem_1

 

4 – Anotamos el código de unlocking que nos da el programa.

5 – Descargamos el programa Code Writer, lo descomprimimos y lo ejecutamos como administrador. Una vez dentro pulsamos “Please select com port”.

codewriter

 

6 – En la ventana que nos aparece pulsamos en “Detect”

codewriter2

 

7 – Nos mostrará el modem en la lista. Lo seleccionamos y presionamos “Accept”

codewriter3

 

8 – El programa volverá a la ventana en la que estábamos antes, donde pulsaremos “Unlock Modem”

codewriter4

 

9 – En la ventana que no aparecerá introducimos el código que nos dio el V4mpire y pulsamos “OK”.

codewriter5

 

10 – Si todo ha ido bien, aparecerá el mensaje “Send Unlock Command… OK”

codewriter6

 

Ya tenemos liberado nuestro módem USB!!

Ahora lo único que tenemos que hacer es desinstalar el software de la compañía del módem e instalar el Dialup Genérico.

Mi primera aplicación en Google Play

435140425-play_logo

Ayer terminé la primera versión de un lector para este Blog y hoy ya está disponible en Google Play.

Consiste en un simple lector de RSS con acceso a las últimas entradas del Blog, pero espero ir actualizándola en un futuro con opciones de comentarios y alguna que otra cosilla.

Aquí van un par de capturas de pantalla:

ruymanhdez1

ruymanhdez2

 

Y éste es el enlace a la aplicación en Google Play 

“Comentar el código es como limpiar el cuarto de baño; nadie quiere hacerlo, pero el resultado es siempre una experiencia más agradable para uno mismo y sus invitados”
— Ryan Campbell

Documentar, documentar, documentar!!!

documentar

En el proyecto en el que estoy trabajando ahora mismo entramos en una fase de “traspaso de conocimiento al cliente“, en el que debemos entregar a los informáticos del cliente toda la documentación de los proyectos en los que hemos trabajado en los últimos 3 años.

Al principio recibí esta noticia sin ningún sobresalto. Sólo tendría que recopilar del gestor documental para cada aplicativo, el análisis previo realizado para la toma de requisitos con su correspondiente análisis funcional, la documentación de la base de datos, el manual de usuario y verificando que toda esta documentación estuviese al día y sumado a un código bien comentado tendría esta entrega preparada en, como mucho, un par de días, pero…

¿Existía toda esta documentación en el gestor documental?

Pues como muchos intuiréis, NO. Resulta que, a pesar de que los módulos y aplicaciones de los que me he encargado yo si tenían toda la documentación mencionada, para la mayoría de los módulos y aplicativos existía, como mucho, uno o dos de los documentos que yo esperaba encontrar, y es que por lo general no nos gusta documentar, pero eso no es excusa para hacerlo.

Con este artículo tengo la intención de concienciar un poco a la gente para que trate de mantener una documentación mínima de los desarrollos en los que trabaja que, a pesar de ser una tarea aburrida y engorrosa, es también una parte importante de nuestro trabajo.

He oído muchísimas excusas para evitar documentar: La mejor documentación es el código fuente, el manifiesto ágil afirma que se valora más el software que funcione que la documentación exhaustiva, es una pérdida de tiempo, no se lo va a leer nadie…

Ninguna de las excusas para mi es suficiente. Soy un firme defensor de las metodologías ágiles y creo que es una mala interpretación de las mismas el hecho de descartar la documentación de los aplicativos ya que una cosa es que se valore mas el software que funcione y otra muy diferente es que no sea necesaria.

Para seguir con el ejemplo que estoy viviendo ahora mismo, en un proyecto con una complejidad media ahora mismo tenemos problemas para realizar la documentación de lo que no estaba documentado ya que las cosas que parecieron obvias en el momento de desarrollarlas ahora parece que carezcan de sentido y para las que parece que tienen sentido, desconocemos en qué reglas de negocio se basó su desarrollo. Ésto termina traduciéndose en que el propio programador que hizo un módulo hace 3 años, en el principio del proyecto, ya no sabe ni porqué hizo las cosas qué hizo ni cómo las hizo, entonces yo pregunto ¿Si tu no sabes cómo va, cómo pretendes que otra persona retome tu desarrollo?

En cuanto a qué nivel de documentación llegar no creo que exista un nivel óptimo y pienso que en cada proyecto es la propia experiencia la que define hasta donde debe cubrir la documentación, pero desde mi experiencia si he visto que normalmente se puede cubrir la documentación con 4 puntos mínimos:

  • Toma de requisitos: El primer punto que es necesario para documentar un aplicativo es saber qué se espera de éste. Ésta no será una tarea muy compleja si simplemente tomamos nota de qué es lo que quiere el usuario.
  • Análisis funcional: También debemos reflejar cómo resolverá el aplicativo las especificaciones  del cliente. Sólo será necesario apuntar en un documento de forma organizada qué será lo que se desarrollará para cada requisito.
  • Definición Técnica: En este documento especificaremos la tecnología utilizada, arquitectura, etc. En otras palabras lo básico para que un programador sea capaz de comprender cómo está montado el proyecto.
  • Documentación en el código: No creo que tenga que explicar mucho en este punto, pero todos sabemos que como mínimo debemos comentar las cabeceras de las clases, procedimientos y funciones, así como el código que no se explique sólo.

Podemos apreciar que ninguno de los puntos descritos supone un gran esfuerzo para mantener una documentación mínima ya que en la mayoría de ellos lo único que debemos hacer es reflejar por escrito  lo que estamos haciendo ya sea en un correo electrónico, un gestor documental o incluso un conjunto de notas tomadas en servilletas.

Por supuesto estos 4 puntos no son obligatorios, ni constituyen una metodología, ni nada por el estilo. Es simplemente un ejemplo de una forma de cubrir la documentación y que en particular en los casos con los que me he encontrado ha funcionado.

En conclusión, una documentación mínima no supone un gran esfuerzo si se realiza a medida que vamos desarrollando y evitará, en el mejor de los casos, que un nuevo compañero se encuentre completamente perdido y, en el peor de los casos, que seamos nosotros mismos los que nos perdamos.

“Por norma, los sistemas software no funcionan bien hasta que han sido utilizados y han fallado repetidamente en entornos reales”
— Dave Parnas

Integración continua

“La integración continua es una práctica de desarrollo de software donde los miembros de un equipo de trabajo integran su trabajo con frecuencia, por lo general cada miembro integra su trabajo por lo menos una vez al día. Cada integración es verificada por un sistema automatizado de construcción (incluyendo los tests) para detectar los errores de integración lo más rápidamente posible.” – Martin Fowler

Trabajando con IC

Pongámonos en situación en un ejemplo de proyecto real con integración continua:

  • El proyecto está bajo un control de versiones con SVN.
  • Tenemos instalada una herramienta de automatización de ejecución de tests y compilación.

En el momento en el que nos enfrentamos a una nueva tarea lo primero que hacemos es actualizar nuestra copia del proyecto local con lo existente en el repositorio del SVN.

Posteriormente realizamos la tarea que se nos ha asignado y creamos o modificamos los tests asignados a esta tarea.

Apoyándonos en nuestra herramienta de automatización (En mi caso, me gusta utilizar maven para los proyectos Java), lanzamos la ejecución de los test, compilamos y probamos el binario generado en un entorno idéntico al de producción.

Una vez verificamos que todo haya ido correcto, revisamos que el estado del repositorio sea el mismo que en el momento de actualizar nuestra copia local. En caso de no haber variado el repositorio, ya podemos subir los cambios a éste y en el supuesto de que ya se nos hayan adelantado subiendo una nueva versión de los fuentes, actualizamos nuestra copia local y volvemos a realizar la compilación y ejecución de los tests.

De este modo, tendremos como resultado en el repositorio una versión estable de nuestro proyecto en cualquier momento del ciclo de vida del mismo, ya que los errores son detectados rápidamente y solventados antes de actualizar los trabajos en la línea principal del repositorio.

Realización de una tarea con IC

Realización de una tarea con IC

Prácticas clave para trabajar con integración continua

Mantener un repositorio de código fuente único.

El uso de un repositorio de código fuente nos permite garantizar que todo el mundo tendrá acceso a los mismos recursos. Hay una gran variedad de repositorios pero cada vez se está empleando mas como estándar el SVN o Subversion.

Automatizar la construcción

A medida que los proyectos van creciendo, la construcción de los mismos puede llegar a ser muy complicada (compilar en un orden determinado, mover los archivos de aquí a allá, cargar los esquemas en BBDD, etc). Esto acarrea dos problemas fundamentales:

  • Si pretendemos construir nuestro proyecto una o varias veces al día para testear el trabajo realizado nos quitará mucho tiempo y se convierte en una tarea pesada.
  • La construcción manual de un proyecto complejo termina significando errores ya que puede que se nos quede atrás algún paso en el proceso de construcción.

Para evitar estos problemas, podemos automatizar estas tareas, de modo que se puedan ejecutar con un solo comando.

Para mi la herramienta por excelencia para los desarrollos en Java es maven, que además de construir nuestro proyecto es capaz de ejecutar los test definidos.

Incluir tests automatizados

Cada vez se generaliza más el empleo de técnicas como TDD (Test Driven Developer), lo que ha fomentado que muchas personas se den cuenta del valor de programar unos buenos tests.

Para el caso de los proyectos Java yo suelo utilizar la librería jUnit, con la que es muy sencillo preparar las pruebas unitarias y específicamente para los proyectos Web Selenium, que permite preparar pruebas funcionales de las aplicaciones.

Por supuesto, los test no garantizan que todo funcione correctamente, pero nos asegura un mínimo de funcionalidades que están correctas, reduciendo el número de Bugs de las mismas.

Todo el mundo debe subir los cambios a diario

Este punto quizás es uno de los mas importantes. Cuando se pasan muchos días si subir los cambios se puede convertir en un infierno integrar los cambios realizados con la línea principal del proyecto.

Probar el resultado en un clon del entorno de producción

Hemos visto hasta ahora todo el proceso desde el punto de vista del programador, pero la IC no acaba ahí. Una vez se suben los cambios al repositorio es importante probar el proyecto completo en una copia exacta del entorno de producción, teniendo de esta forma la certeza de que la última versión es estable.

En resumen

Con el uso de la IC tendremos las siguientes ventajas:

  • Posibilita la detección temprana de errores, minimizando los costes de resolución.
  • Se minimizan los costes de integración entre las funcionalidades que se van añadiendo al producto.
  • Se anima a los desarrolladores a integrar su código lo antes posible.
  • Permite controlar la estabilidad del producto.

 

Enlaces de interés: artículo de Martin Fowler sobre integración continua.

“Los estándares son siempre obsoletos. Eso es lo que los hace estándares”
— Alan Bennett

Probando Artifactory Open Source – Parte IV – Uso

Para finalizar el análisis de Artifactory veremos cómo añadir artefactos manualmente al repositorio y cómo utilizar nuestro repositorio de Artifactory en nuestros proyectos.

Despliegue manual de artefactos

Para desplegar manualmente nuestros artefactos iremos a la pestaña Deploy y subiremos nuestro artefacto compilado.

10-artifactory-deploy-artifacts

 

Posteriormente configuraremos la información detallada del artefacto y pinchamos en Deploy Artifact.

11-artifactory-deploy-2

 

Con esto ya tendremos nuestro artefacto disponible en el repositorio.

Configurar el repositorio para nuestros proyectos

Para que nuestros proyectos hagan uso del repositorio de Artifactory tenemos dos opciones:

  • Configurar el settings.xml de nuestra instalación de maven.
  • Configurar el pom.xml de nuestro proyecto maven.

En ambos casos bastará con sustituir, o añadir en caso de que no existan, la definición de los repositorios por lo siguiente:

<repositories>
    <repository>
        <id>central</id>
        <url> http://[host]:[port]/artifactory/libs-release </url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
    <repository>
        <id>snapshots</id>
        <url> http://[host]:[port]/artifactory/libs-snapshot </url>
        <releases>
            <enabled>false</enabled>
        </releases>
    </repository>
</repositories>
<pluginRepositories>
    <pluginRepository>
        <id>central</id>
        <url> http://[host]:[port]/artifactory/plugins-release </url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </pluginRepository>
    <pluginRepository>
        <id>snapshots</id>
        <url> http://[host]:[port]/artifactory/plugins-snapshot </url>
        <releases>
            <enabled>false</enabled>
        </releases>
    </pluginRepository>
</pluginRepositories>