Pudimos disfrutar de canciones como, La Revolución Sexual, Chicos Malos, La nueva Yma Sumac, No más Myolastán… Alternando canciones electrónicas con versiones al piano. Definitivamente “superguay”.

Podéis ver un resumen del concierto en el siguiente video.

Algunas de las metodologías que forman la integración contínua son: mantenimiento de un repositorio de código con, por ejemplo CVS, SVN o Visual Source Safe (tener un repositiorio de código además ayudará a tener disponible de forma sencilla la última versión del proyecto), mantener una copia exacta del servidor de producción para hacer pruebas, automatizar los despliegues, automatizar y hacer rápida la construcción (build) del proyecto si se utiliza un lenguaje compilado y la metodología de la que hablaré un poco más en profundidad, la creación de pruebas unitarias (Unit Testing).

El proceso completo de integración contínua consiste a grandes rasgos en realizar periódicamente (en periodos cortos, por ejemplo horas) los siguientes pasos:

• La descarga o actualización de las fuentes desde el sistema de control de versiones.
• Realizar los cambios necesarios para crear la nueva funcionalidad, realizar una modificación o corregir un bug.
• Subir el código al repositorio que posteriormente se desplegará en el servidor clónico al de producción una vez realizadas las comprobaciones automáticas y comprobada la estabilidad y corrección de la nueva funcionalidad mediante pruebas unitarias, mecanismos de control de métricas (complejidad ciclomática, nivel de anidamiento…), control de sintaxis, etc. , generar los informes oportunos.
• En caso de mantener más de una rama de desarrollo, al completar una funcionalidad, hacer merge de los cambios con la rama principal.
• Actualizar la versión en producción en caso de tratarse de un proyecto web o actualizar la última versión disponible en caso de tratarse de una aplicación de escritorio.

La realización de pruebas unitarias juega un papel fundamental en este conjunto de metodologías ya que es responsable de la comprobación automática de la funcionalidad individual de cada unidad de código, habitualmente cada clase, utilizando el paradigma de programación orientada a objetos.

El concepto de las pruebas unitarias, o unit testing es sencillo. Si tenemos que hacer un programa, e ir comprobando según lo vamos haciendo si la funcionalidad del programa se corresponde con lo que en principio queríamos hacer, ¿porqué no programar una pequeña aplicación que haga las comprobaciones por nosotros? El comportamiento habitual de la mayoría de programadores es o bien ir escribiendo texto por la salida estandar como “llego hasta aqúi”, “el valor de esta variable es…”, etc. código que hay que escribir, comprobar, y luego eliminar. Otra posibilidad sería escribir todo el código confiando en nuestra concentración y luego usar algún algún tipo de debugger si el código no hace lo esperado. En el primer caso, perderíamos mucho tiempo. En el segundo quizá la pérdida de tiempo sería menor pero probablemente estemos pasando por alto casos de prueba que podrían ser propensos a error.

Por todo lo anterior y para ganar en tiempo y corrección, actualmente la mejor solución es la realización de pruebas unitarias. Además, estas pruebas servirán, no solo para probar el código al programarlo por primera vez, sino para comprobar que al realizar un cambio en una unidad del proyecto, el comportamiento de otras unidades dependientes de esta se mantiene y no aparecen efectos colaterales inesperados. Por esto, las pruebas unitarias son tan importantes en la integración contínua. Sin ellas, los cambios realizados en a intervalos pequeños y regulares introducirían probablemente errores difíciles de detectar.

Para la realización de pruebas unitarias, existen herramientas y entornos de desarrollo (frameworks) que facilitan su creación en multitud de lenguajes de programación. Estas son algunas de ellas (hay muchas más):

• JUnit: Framework de pruebas unitarias en Java.
• JTiger: Otro framework de pruebas unitarias en Java.
• SimpleTest: Framework de pruebas unitarias de PHP, inspirado en JUnit.
• PHPUnit: Framework de pruebas unitarias de PHP de PEAR.
• PerlUnit: Framework de pruebas unitarias en Perl.
• lisp-unit: Pruebas unitarias en Lisp.
• tgM2: Pruebas unitarias en Modula2

Desde que en 2007 salieron las primeras imágenes de Dragon Ball Online en la revista V-Jump este juego está levantando grandes expectativas entre los fans de la serie y aficionados a los MMORPG.

Dragon Ball Online recreará el universo de Akira Toriyama y se situará cronológicamente 200 años después del fin de Dragon Ball Z. En él encarnaremos a un personaje del universo Dragon Ball que aunque no sea uno de los protagonistas tendrá un aspecto muy similar a ellos. Se podrá elegir la raza entre humano, namekiano o majin, que sería un demonio parecido a Majin Boo. Parece definitivo que no se podrá elegir la raza saiyajin. Se podrá elegir entre varias clases como guerrero, espiritista o ingeniero y decidir el aspecto del personaje: pelo, cara, ropa, color y otras características. Según la raza elegida, cambiará el punto de inicio de la aventura que puede ser la tierra, para humanos y saiyajins y namek para los namekianos. También existirá la posibilidad de empezar con nuestro personaje siendo un niño e irá creciendo según vayamos avanzando la aventura.

Como todo juego MMORPG, el desarrollo consistirá en acumular experiencia con el fin de conseguir nuevas técnicas (Kame Hame, Final Flash, …) y mejorar las características de nuestro personaje, realizando para ello misiones que nos vendrán dadas por personajes tan conocidos como Goku, Picolo, Vegeta…

Las misiones irán desde encontrar las Bolas de Dragón, combatir el Tenkaichi Budokai o entrenar para convertirse en uno de los grandes guerreros legendarios del universo Dragon Ball. Además existirá una trama principal en la que podremos tomar parte donde una amenaza dividirá a la tierra entre fuerzas de la luz y la oscuridad y en la que Trunks del futuro jugará un importante papel.

Este juego tiene muy buena pinta y probablemente quite el mal sabor de boca que dejará la película de Dragon Ball. El juego está siendo desarrollado en Corea, esperemos que algún día llegue a Europa…

Actualización: Se ha publicado al fin un video que muestra el juego en funcionamiento. En él se puede ver la configuración de los personajes, luchas entre varios jugadores, el sistema de menús, luchas contra enemigos no jugadores, el mapeado del juego, el planteamiento de una misión por Trunks y una secuencia clásica de Dragon Ball de Radiz llegando a la tierra. La calidad de la grabación no es muy buena pero al menos podemos ver algo más de este juego tan esperado de Dragon Ball Online:

Nueva actualización: Se ha publicado un trailer promocional con lo que parece la intro y algunas escenas. A continuación, el trailer de Dragon Ball Online:

Esta métrica, propuesta por Thomas McCabe en 1976, se basa en el diagrama de flujo determinado por las estructuras de control de un determinado código. De dicho análisis se puede obtener una medida cuantitativa de la dificultad de de crear pruebas automáticas del código y también es una medición orientativa de la fiabilidad del mismo.

El nombre “Complejidad Ciclomática” puede resultar engañoso para un programador ya que la idea de esta métrica no es contar los bucles (for, while, do…) en el código de un programa sinó en el resultado de contar el número de ciclos diferentes que se siguen en un fragmento de código de un programa habiendo creado una rama imaginaria desde el nodo de salida al nodo de entrada del diagrama de flujo correspondiente a este fragmento de código. Un nombre más adecuado podría ser Complejidad Condicional ya que el cálculo de esta métrica se ajusta más al hecho de buscar condiciones que contar ejecuciones de predicados dentro de bucles.

El resultado obtenido en el cálculo de la complejidad ciclomática define el número de caminos independientes dentro de un fragmento de código y determina la cota superior del número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.

La medida resultante puede ser utilizada en el desarrollo, mantenimiento y reingeniería para estimar el riesgo, costo y estabilidad. Algunos estudios experimentales indican la existencia de distintas relaciones entre la métrica de McCabe y el número de errores existentes en el código fuente, así como el tiempo requerido para encontrar y corregir esos errores.

Una vez calculada la complejidad ciclomática de un fragmento de código, se puede determinar el riesgo que supone utilizando los rangos definidos en la siguiente tabla:

A partir del análisis de muchos proyectos McCabe encontró que un valor 10 es un límite superior práctico para el tamaño de un módulo. Cuando la complejidad supera dicho valor se hace muy difícil probarlo, entenderlo y modificarlo. La limitación deliberada de la complejidad en todas las fases del desarrollo ayuda a evitar los problemas asociados a proyectos de alta complejidad. El límite propuesto por McCabe sin embargo es fuente de controversias. Algunas organizaciones han utilizado el valor 15 con bastante éxito.

Cálculo de la Complejidad Ciclomática

Para poder dar una definición acabada de la complejidad ciclomática, es necesario primero introducir una sencilla notación para la representación del flujo de control, denominada Grafos de Flujo de Control de un programa.

M = Complejidad ciclomática.

E = Número de aristas del grafo. Una arista conecta dos vértices si una sentencia puede ser ejecutada inmediatamente después de la primera.

N = Número de nodos del grafo correspondientes a sentencias del programa.

P = Número de componentes conexos correspondientes a las diferentes subrutinas, funciones o métodos.

Definidos estos conceptos, la Complejidad Ciclomática puede calcularse de la siguiente manera:

M = E − N + P

Una versión simplificada para el cálculo de la Complejidad Ciclomática es la siguiente:

M = Número de condiciones + 1

Ámbito de utilizacion de la Complejidad Ciclomática

La complejidad ciclomática puede ser aplicada en varias áreas incluyendo:

• Análisis de riesgo en desarrollo de código: Mientras el código esta en desarrollo, su complejidad puede ser medida para estimar el riesgo inherente.

• Análisis de riesgo de cambio durante la fase de mantenimiento: La complejidad del código tiende a incrementarse a medida que es mantenido durante el tiempo. Midiendo la complejidad antes y después de un cambio propuesto, puede ayudar a decidir cómo minimizar el riesgo del cambio.

• Planificación de Pruebas: El análisis matemático ha demostrado que la complejidad ciclomática indica el número exacto de casos de prueba necesarios para probar cada punto de decisión en un programa.

• Reingeniería: Provee conocimiento de la estructura del código operacional de un sistema. El riesgo involucrado en la reingeniería de una pieza de código está relacionado con su complejidad.

Aplicaciones para calcular la Complejidad Ciclomática

Algunas aplicaciones que implementan el cálculo de complejidad ciclomática son las siguientes:

• Covertura : Muestra la Complejidad Ciclomática en Java para cada clase y la media de Complejidad Ciclomática para cada paquete y para todo el proyecto.
• PEAR::CodeSniffer : Comprobador de código PHP para la verificación de varios estándares que incluye comprobación de Complejidad Ciclomática.
• Perl::Metrics::Simple : Analizador de código fuente Perl que comprueba varias métricas, entre ellas, la Complejidad Ciclomática de cada subrutina/método.
• complexity.py : Script en Python para comprobar la Complejidad Ciclomática en programas realizados en este lenguaje.

Consideraciones finales

En Softonic, empresa en la que trabajo, utilizamos esta y otras métricas para garantizar la calidad en nuestros desarrollos y puedo decir por experiencia personal que los resultados tienden a mejorar la claridad y estructura de código, reducir los tests necesarios para comprobar el código y minimizar el riesgo de errores.

Para una mayor profundización teórica en estos conceptos, recomiendo la lectura de los siguientes documentos:

A Complexity Measure – McCabe’s original paper (1976).
Complejidad ciclomática – Tésis sobre la complejidad ciclomática.

Un ejemplo de la localización de datos de usuarios en Google Maps se puede ver introduciendo las palabras “posts geolocalizados” en el input de búsqueda de Google Maps. Entre los resultados obtenidos aparecerán los correspondientes a la página de este blog titulada Posts Geolocalizados. Igualmente si buscamos “sitios interesantes de vigo“, Google Maps mostrará entre otros posibles resultados, los comentados en el post sitios interesantes de Vigo.

Generar contenido para Google Maps es muy sencillo. Simplemente hay que tener una cuenta de Google (la de Gmail) e identificarse con ella en Google Maps. Una vez dentro, seleccionando mis mapas, podremos crear un nuevo mapa y asignarle los puntos o áreas que queramos. A cada punto podemos asociarle un icono a elegir entre los disponibles o uno existente en una URL. Además podemos asociar un contenido que puede ser texto o HTML de forma que al hacer click en el elemento, se muestre su contenido.

La generación de contenido para Google Maps también puede hacerse utilizando Google Earth. De esta forma tenemos una interfaz más potente y cómoda para la edición de puntos que luego podremos guardar al un archivo .kml que se puede importar de Google Earth a Google Maps desde la opción importar de Google Maps.

De esta forma se inicia la carrera por geolocalizar posiciones relevantes para las keywords que nos interese promocionar en lo que, en mi opinión, ya se perfila como uno de los medios de búsqueda con más futuro a medio plazo.

• E-commerce department
• Praktikant Content Softonic.de
• Praktikant Webdesign
• Responsable Area Calidad Web
• IT Journalism – Internship
• Analista/Programador Senior Php/Mysql
• Administrador senior en sistemas Linux/Unix
• Content Director Softonic Netherlands
• Editor de Contenidos (Linux)
• Editor de Contenidos (Windows)
• Internship Online Marketing (en.softonic.com)
• IT-Redakteur / Software-Tester
• Rédacteur Spécialisé informatique pour Softonic Fr
• Software and Games Redactor Softonic Portuguese
• Soporte Técnico y Atención al Cliente
• Campaign Manager
• Customer Support Manager International
• IT Content Editor Softonic Polish
• Maquetador / Diseñador Web, imprescindible CSS2
• Project Manager (LAMP)
• QA Tester
• Responsable de Informática
• Secretaria de Dirección
• Software Journalist / Web Content Editor
• Técnico de Selección

VIA: http://blog.albertlg.com/se-busca-seo-programador-90940

La lista de películas es la siguiente:

• The Shawshank Redemption (Cadena perpetua)
• Fight Club
• Memento
• American History X
• Blade Runner
• Life of Brian
• Darkness
• Primal Fear (Las dos caras de la verdad)
• Identity
• El Maquinista

Soy consciente de que me estoy dejando muchas películas interesantes pero por ahora, ahí queda la lista. Por otro lado, seguro que sería más difícil hacer un post sobre las peores películas porque habría muchas más candidatas.

Espero vuestros comentarios y vuestras listas

IMPORTANTE: La información a partir de este punto incluye datos revelados en los capítulos 5 y 11 de la cuarta temporada de Lost. Si no has visto la serie hasta el capítulo 11 de la cuarta temporada y no quieres conocer estos datos no sigas leyendo.

El cómic en cuestión, es el mostrado por Richard Alpert a John Locke en su infancia con el objetivo aparente de comprobar si Locke es cierto personaje reencarnado siguiendo un ritual típicamente budista que consiste en mostrar varios objetos de forma que la persona reencarnada señale cuales le pertenecieron en su otra vida.

La portada del cómic, a simple vista, muestra un hombre asombrado mirando por una ventana una ciudad flotante pero si nos fijamos más detenidamente, hay varios detalles relevantes:

• El primero, es el nombre del relato corto: “HIDDEN LAND“. Es una clara referencia a la isla, un lugar escondido del mundo. Además, el texto completo “What was the secret of the misterious HIDDEN LAND!” se corresponde con una historia como la de de Lost, llena de secretos y misterios.
• El hombre está aterrorizado por lo que acaba de descubrir mirando por la ventana de lo que es ni más ni menos que un avión. Esto se puede apreciar en la parte inferior derecha, donde se puede leer la palabra “Airlines“. Recordemos que el accidente de avión fue el punto de partida de la serie.
• A lo anterior hay que añadir la posiblidad de espacios y tiempos alternativos ya presentada anteriormente el el capítulo The Constant (quinto de la cuarta temporada), de forma similar a lo que sería esta “ciudad alternativa” en las nubes.




• La ciudad en las nubes recuerda bastante a la ciudad que se puede ver en el reflejo de algunos carteles promocionales de Lost.

  
  

  
  
  

Por todo esto, y por su fecha de publicación (abril de 1956) es más que probable que los creadores de Lost se hayan inspirado en este cómic como origen para toda esta trama de misterio.

El cómic fue editado en su versión original por Atlas Comics (empresa que fue absorbida por Marvel Comics) y hubo una reedición en un recopilatorio titulado Mystery Tales Marvel Masterworks, número 4 en los 80 pero actualmente es difícil, casi imposible, encontrar una copia, ni siquiera escaneada, de este cómic. Además este comic también tiene el valor añadido de ser una de las primeras publicaciones de Steve Ditko, co-creador de Spiderman y Dr. Extraño.

Los afortunados compradores del cómic han creado un blog sobre el cómic Mystery Tales 40 contando su experiencia.

Tras todo esto, se me plantean las siguientes dudas:

¿Algún día se divulgará el contenido del cómic?

¿Contendrá este cómic las respuestas al origen de esta retorcida historia?

¿Jacob es Vincent?

Según va avanzando, aumentan las divisiones en las cuadrículas de los lados del cubo. Aunque al principio parece fácil, poco a poco va aumentando la dificultad hasta convertirse en un reto interesante.

Totalmente recomendado para pasar el tiempo y quemar algunas de neuronas.

Andorra la Vieja, capital del Principado de Andorra es un lugar bastante curioso. Es como un enorme centro comercial al aire libre rodeado de montañas nevadas, aunque eso sí, lo de los precios baratos, en mi opinión se ha exagerado. Estuvimos sacando unas cuantas fotos de Andorra algunas de las cuales muestro a continuación.