You are currently browsing the monthly archive for abril 2013.

Una presentación con parámetros tweeter:

tweetPres

Anuncios

¡Fascinante!

Como siempre, el blog de Francis se hace eco de la noticia y la comenta en detalle con referencias a los artículos técnicos, etc. La estrella es Kepler-62 (recibe este nombre porque es la número 62 en la que misión Kepler ha encontrado un exoplaneta) y los planetas son Kepler-62e y Kepler-62f (para nombrar a los exoplanetas se acompaña con una letra minúscula del abecedario empezando por la b, las mayúsculas son para nombrar las componentes de la estrella si es múltiple, en función del orden en que se han ido descubriendo, al nombre de la estrella).

Para los legos en la materia, los exoplanetas son planetas que orbitan otras estrellas distintas al Sol y nos vamos acercando ya a los mil planetas extrasolares descubiertos, muchos formando sistemas planetarios, de manera que parece ser algo habitual que cualquier estrella este acompañada de éstos.

La zona habitable es aquella región alrededor de una estrella que permite la existencia de agua líquida. Está demostrado que puede haber vida mucho mas exótica, pero básicamente como nuestra vida esta basada en el agua, ésta es lo que se busca.

Finalmente, el post de Francis también enlaza esta fantástica animación de The New York Times sobre los exoplanetas descubiertos por Kepler.

Las dos misiones puestas en marcha hasta ahora, en órbita, son COROT de la ESA en 2006-2012(fallo ordenador),  y Kepler de la NASA en 2009. El JPL de la NASA tiene una página dedicada a exoplanetas.

Dado un \mathbb{K}-espacio vectorial E, diremos que la aplicación:

B:E \times E \longrightarrow \mathbb{K}

es un producto escalar si verifica:

  1. Fijado y \in E, entonces E \longrightarrow \mathbb{K} \,:\, x \mapsto B(x,y) es lineal.
  2. B(x,y) = \bar{B(y,x)}, \forall x,y \in E.
  3. B(x,y) \geq 0, \forall x \in E.
  4. B(x,x)=0 \leftrightarrow x=0, \forall x \in E.

Llamamos espacio pre-Hilbertiano al par (E,B).

Dos consecuencias inmediatas de estas propiedades son:

  1. Fijado x \in E, entonces E \longrightarrow \mathbb{K} \,:\, y \mapsto B(x,y) es sesquilineal.
  2. B(0,y)=B(x,0)=0, \forall x,y \in E.

Podemos definir la aplicación norma como:

q:E \longrightarrow \mathbb{R}^+ \cup \{0\} \,:\, x \mapsto \sqrt{B(x,x)},

que cumple la desigualdad de Cauchy-Schwartz:

|B(x,y)| \leq q(x)q(y), \forall x,y \in E,

dandose la igualdad cuando x, y son linealmente dependientes, y las propiedades:

  1. q(x+y) \leq q(x)+ q(y), \forall x,y \in E.
  2. q(\lambda x) = \lambda q(x), \forall x \in E.
  3. q(x)=0 \leftrightarrow x=0, \forall x \in E.

Podemos definir la aplicación distancia como:

d: E \times E \longrightarrow \mathbb{R}^+ \cup \{ 0 \} \,:\, (x,y) \mapsto q(x-y),

cumpliendo:

  1. q(x,y) = q(y,x).
  2. d(x,y)=0 \leftrightarrow x = y.
  3. d(x,y) \leq d(x,z)+d(z,y).

¿Qué pasa ahora si empezamos a eliminar requisitos en las definiciones? Se siguen cumpliendo propiedades interesantes de manera que las estructuras resultantes son ricas o no? Suponemos que si. Vamos a ver…

Simplemente enlazo esta página donde habla de como realizar flujos de trabajo aprovechando el poco coste del branching en Git.

También puede servir como punto de entrada al libro Pro Git de Scott Chacon. Ayuda mucho a entender el funcionamiento de Git sus explicaciones de como están implementadas internamente estas funcionalidades.

Algunas notas interesantes:

  • Git no guarda cambios incrementales sino que guarda instantaneas completas del estado del código en el momento del commit.
  • La rama principal y las demás ramas son apuntadores a estas instantaneas.
  • En el momento de crear una nueva rama, se crea un apuntador a la instantánea del último commit.
  • Esta política hace que el coste del branching sea bajo en comparación a otros
  • Permite, por tanto, la existencia y utilización con ramas temporales para los flujos de trabajo.

En la siguiente imagen del libro podemos ver reflejadas todas estas ideas:

gitBranching

Tiene Terry Tao una explicación en 20 posts de la demostración de la conjetura de Poincaré hecha por Perelman.

Enlazo aquí su Lecture 0 que nos puede servir tanto como introducción de los conceptos básicos de la geometría Riemanniana, que hemos tratado anteriormente en unos cuantos posts, como para ir leyendo el resto de posts en los que se sumerge en la explicación de la (complicadísima) demostración…

Enlazo también un artículo interesante sobre Grisha en el que se puede leer algo asombroso:

Todos sus compañeros de escuela y del club de matemáticas en el que estaba inscrito (en la antigua URSS los clubes de matemáticas, a los que asistían los estudiantes después de clases, jugaban un papel central en su formación) recuerdan como rasgo sobresaliente de Perelman no su rapidez ni su elegancia o brillantez para resolver un problema, sino más bien el nada despreciable hecho de que jamás, ni una sola vez, hubo un error en sus soluciones.

Diagrama de clases en UML2 que hicimos de la aplicación ParaMul con VP-UML y que utilizaremos desde Kunagi para diferentes elementos de Scrum y GitX para el control de versiones:

UML_CD_ParaMul

Roles

  • Product Owner: es el que sabe como debe ser el producto, por lo que escribe historias de usuario (requisitos funcionales), las ordena por prioridad, las coloca en el product backlog, pone fechas y se encarga de aceptar o rechazar los entregables. Por ejemplo, en kunagi:

scrum_PO

  • ScrumMaster: es el encargado de asegurar que los procesos Scrum se cumplan, que se cumplan las reglas, que los equipos trabajen como es debido, eliminando obstáculos y aislándolos de distracciones. Por ejemplo, en kunagi:

scrum_SM

  • Development Team: es el equipo multidisciplinar de entre 5 y 9 personas con habilidades transversales (diseño, implementación, documentación…) que se autoorganiza para tener los entregables en los plazos.

scrum_T

Reuniones

  • Daily Scrum (15m): cada dia a la misma hora y en el mismo sitio de pie para que cada miembro del equipo diga que hizo ayer, que ara hoy y que impedimentos está encontrando.
  • Scrum de Scrum (15m):  después del daily scrum y a nivel de equipos cuando existen varios. Un representate por equipo para explicar que hizo su equipo ayer, que ará hoy, que problemas tiene y si va a subir algo que se encontraran el resto de equipos.
  • Sprint Planning Meeting (8h): al empezar un sprint para prepararlo. Seleccionar que es lo que se hará, construir el sprint backlog y asignar plazos.
  • Sprint Review Meeting (4h): revisar que se ha conseguido y que no. Demo únicamente de lo entregable.
  • Sprint Retrospetive Meeting (4h): opinión de todos sobre las demos.

Documentos

  • Product Backlog: que se tiene que hacer en el producto.
  • Sprint Backlog: que se tiene que hacer en el sprint actual.

En la web de ScrumAlliance encontramos el siguiente resumen:

scrumFramework

En el siguiente post de Henrik Kniberg comenta como llevar a la práctica los conceptos tratados en los posts sobre Software Configuration Management y Agile Software Development.

El siguiente gráfico, del mismo post, resume todo lo tratado en el artículo:

gitScrum

A continuación sencillos comentarios interesantes que aparecen en el post:

  • Cada branch (rama), incluso la mainline (tronco), tiene un owner (propietario) y una policy (política).
  • Tenemos to do, in progress y done como estados para cada user story.
  • Done (hecho) significa releasable (entregable), es decir, que si en ese momento el cliente quisiera entrar y empezar a probarlo, nadie tuviera que decirle que no puede, que tiene que esperar.
  • El tronco es la rama hecho, es decir, la que entrará en producción llegado el momento.
  • La política del tronco puede ser o (exclusivo) entregable at any time (en cualquier momento) o lo antes posible (asap).
  • Crear ramas cuantas menos mejor. Solo crearemos una cuando queramos probar algo y no lo podamos hacer con ninguna de las existentes sin violar sus políticas.
  • Como entegrable incluye las pruebas de integración y no podemos hacerlo sobre la mainline, necesitamos una nueva rama: work branch (rama de trabajo) o development branch (rama de desarrollo).

Leyendo el capítulo dedicado a Lagrangianos y Hamiltonianos del libro de Roger Penrose El camino a la realidad me sorprendió cuando en un momento, después de presentar al Lagrangiano

\mathcal{L} = \mathcal{L}(q^1, \ldots, q^n, \dot{q}^1, \ldots, \dot{q}^n )

como una función, de posiciones generalizadas q^i que etiquetan los puntos del espacio de configuración \mathcal{C}, una variedad diferenciable de dimensión n, y velocidades generalizadas \dot{q}^i:=\frac{d}{dt}q^i, cuya interpretación física es la diferencia entre energía cinética K del sistema y la energía potencial V debido a fuerzas externas, es decir, \mathcal{L} = K-V, las ecuaciones de Euler-Lagrange quedan como:

\frac{d}{dt} \frac{\partial}{\partial \dot{q}^r}\mathcal{L} = \frac{\partial}{\partial q^r} \mathcal{L} con r=1 \ldots n,

recordando que cada \dot{q}^r debe tratarse como una variable independiente.

Esto, aquí mi sorpresa, es idéntico a lo que utilizamos en este post

\frac{d}{dt} \frac{\partial}{\partial \dot{x}^i} g = \frac{\partial}{\partial x ^i} g

para calcular las geodésicas de una variedad Riemanniana sin necesidad de pasar por el cálculo de los símbolos de Christoffel a partir de su métrica, por ejemplo, para encontrar su conexión…

Así pues, la conclusión es que, como cada punto \alpha de la variedad n-dimensional \mathcal{C} representa una configuración del sistema y, a medida que evoluciona en el tiempo, describe una curva \alpha(t) \in \mathcal{C}, esta trayectoria puede considerarse como una geodésica en el espacio de fases \mathcal{C}.

Para terminar, pone un sencillo ejemplo donde el sistema consta de una única partícula de masa m que se mueve en el campo gravitatorio cerca de la superficie terrestre V(t,x,y,z)=mgz. Utilizando \frac{1}{2}mv^2 para la energía cinética, nos queda que el Lagrangiano es:

\mathcal{L} = \frac{1}{2}m(\dot{x}^2+\dot{y}^2+\dot{z}^2)-mgz,

por lo que la ecuación de Euler-Lagrange para z nos queda:

m\frac{d}{dt}\dot{z} = mg \Leftrightarrow \ddot{z} = g,

que es lo que esperabamos :-).

El Agile Software Development (desarrollo ágil de software) es un paradigma de la ingenieria del software cuyas principales características son:

  • la idea general es el desarrollo iterativo e incremental minimizando costes.
  • una iteración es el software desarrollado en una unidad de tiempo, entre una y cuatro semanas.
  • cada iteración no agrega mucha funcionalidad pero debe estar libre de errores y funcionar.
  • en cada iteración: planificación, analisis, diseño, implementación, prueba y documentación.
  • al final de cada iteración se reevaluan las prioridades del proyecto.
  • se enfatiza la comunicación cara a cara.

Scrum es un ejemplo concreto de metodología ágil. El diagrama de la empresa Mountain Goat Software de Mike Cohn es bastante autoexplicativo:

scrum

aquí una introducción de ellos mismos a estos temas.

¿Alguna herramienta libre para llevar ésto a la práctica? Pués, por ejemplo, PangoScrum o Kunagi. Según ellos mismos, “PangoScrum is a agile project management tool for Scrum.Keeping it simple, it focus on the continuously efficiency improvement of software development”, “Kunagi is a free web-based tool for integrated project management and collaboration based on Scrum“.

Finalmente, en esta página de Scrum Manager, los princípios de la Orientación a Objetos.

Seguimos con SCM, con el libro Software Configuration Management Patterns: Effective Teamwork, Practical Integration, desde donde lo dejamos en el último post sobre el tema.

Private Workspace

¿Cómo lo hacemos, con una codeline que cambia contínuamente, para realizar progresos sin que nos distraiga este entorno cambiante debido a los que están por debajo de nosotros?

Realiza tu trabajo en un workspace privado donde controlemos las versiones del código y los componentes que estamos utilizando. Debemos tener control total sobre cuando y como cambia nuestro entorno.

Repository

¿Cómo obtener las versiones correctas de los componentes correctos en un nuevo workspace?

Private System Build

¿Cómo verificas que tus cambios no rompen la construcción o el sistema antes de colocarselos?

Antes de hacer un submit al control de fuente, construir el sistema de manera privada de manera similar a como será.

SCM_psb

Integration Build

¿Cómo asegurarse de que el código base siempre se construye de manera fiable?

Asegurate de que todos los cambios (y sus dependencias) se construyen utilizando un proceso para la construcción de la integración centralizado.

SCM_ib

Third Party Codeline

¿Cúal es la estrategia mas efectiva para coordinar las versiones de vendedores de código con las versiones de productores de código?

SCM_tpc

Task Level Commit

¿Cuanto trabajo debemos realizar entre submits al sistema de control de versiones? ¿Cuando tiempo deberíamos esperar antes de colocarlos?

Realizar un commit por cada pequeña tarea de grano fino consistente.

Codeline Policy

¿Como saben los desarrolladores en que codeline deben comprobar su código y que tests deben realizar antes de hacerlo?

Para cada rama o codeline define una política que determine cómo y cúando los desarrolladores realizarán cambios. La política debe ser concisa y auditable.

Smoke Test

¿Cómo saber que el sistema seguirá funcionando después de que realizemos un cambio?

Somete cada construcción a una prueba de humo que verifique que la aplicación no se rompe de una manera evidente.

Unit Test

¿Cómo comprobar si un módulo continua funcionando tras realizar un cambio?

Desarrolla y realiza pruebas unitarias.

Regression Test

¿Cómo asegurarse de que el código existente no empeora con las nuevas mejoras?

Ejecutar pruebas de regresión en el sistema siempre que lo desee para asegurar la estabilidad de la codeline, como antes de liberar una construcción, o antes de un cambio especialmente arriesgado.
Crea las pruebas de regresión a partir de los casos de prueba que hicieron fallar al sistema en el pasado.

Private Versions

¿Cómo puedes experimentar con un cambio complejo y beneficiarse del sistema de control de versiones sin hacer el cambio público?

Provee a los desarrolladores de un mecanismo de checkpoints de cambios en una granularidad que se sienta cómodo. Esto puede hacerse mediante un área de control para versiones locales. Sólo los conjuntos de código estables se registrarán en el repositorio del proyecto.

Release Line

¿Cómo mantener versiones publicadas sin interferir en el trabajo actual de desarrollo?

SCM_rl

Release-Prep Codeline

¿Cómo se puede estabilizar una codeline para un lanzamiento inminente, además de facilitar el continuar trabajando en la codeline activa?

SCM_rpc

Task Branch

¿Cómo puede nuestro equimo hacer a una codeline múltiples cambios a largo plazo superpuestos sin comprometer su consistencia e integridad?

SCM_tb

Calculamos la curvatura escalar R para la métrica de Kerr-Newman, es decir, para la solución analítica a las ecuaciones de Einstein en presencia de momento y de carga (J \neq 0 y Q \neq 0).

La métrica es:

g = -\frac{J^2+M^2 \left(Q^2+r (-2 M+r)\right)+J^2 \text{Sin}[\theta ]^2}{M^2 r^2+J^2 \text{Cos}[\theta ]^2} dt \otimes dt +

+ 2 \frac{J M \left(Q^2-2 M r\right) \text{Sin}[\theta ]^2}{M^2 r^2+J^2 \text{Cos}[\theta ]^2} dt \tilde{\otimes} d\varphi +

+ \frac{M^2 r^2+J^2 \text{Cos}[\theta ]^2}{J^2+M^2 \left(Q^2+r (-2 M+r)\right)} dr \otimes dr +

r^2+\frac{J^2 \text{Cos}[\theta ]^2}{M^2} d\theta \otimes d\theta +

+ \frac{\left(\frac{J^2}{M^2}+r^2\right)^2 \text{Sin}[\theta ]^2}{r^2+\frac{J^2 \text{Cos}[\theta ]^2}{M^2}}+\frac{J^2 \text{Sin}[\theta ]^4}{M^2} d\varphi \otimes d\varphi.

Como ya hemos hecho con la métrica de Kerr, solo mostramos una componente de cada elemento calculado debido a su extrema complejidad (como para realizar los cálculos manualmente…):

R^{r}_{\theta \varphi t}:

tRiemann_kn_rthvpt

R_{r \theta}:

tRicci_kn_rth

Utilizando nuestras funciones, obtenemos los siguientes gráficos:

M=0.9, J=0.1, Q=0.5:

R_M09_J01_Q05

M=0.9, J=0.1, Q=0.25:

R_M09_J01_Q025

M=1, J=1, Q=1:

R_M1_Q1_J1

M=0.1, J=0.9, Q=0.5:

R_M01_J09_Q05

Volvemos a representar los gráficos de este post pero ahora en coordenadas cilíndricas, que tienen mas sentido:

Calcularemos el tensor de Riemann, el de Ricci y la curvatura escalar para la métrica de Kerr correspondiente a un agujero negro en rotación y sin carga eléctrica (J \neq 0, Q=0), cuya métrica ya utilizamos.

A continuación, mostramos nuestras funciones para realizar los calculos automáticamente:

tensor de Riemann:

riemanNd

tensor de Ricci:

ricciNd

curvatura escalar:

rNd

y obtenemos (solo escribiremos una elemento de cada debido a su complejidad):

R^{t}_{tt\varphi}:

tRiemann_rtttvp

donde x1=t, x2=r, x3=\theta, x4=\varphi.

R_{r\theta}:

tRicci_rth

y dos gráficas correspondientes a su curvatura escalar R:

curvaturaEscalar3D2

curvaturaEscalar3D

En la definición de la métrica, tenemos la restricción 0 \leq \frac{a}{M} \leq 1, que en nuestro caso, como imponemos M=1, nos queda 0 \leq J \leq 1. A continuación una serie de gráficos en los que hacemos el valor de

J=0.1, 0.25, 0.5, 0.75, 0.9, 1:

abril 2013
L M X J V S D
« Mar   May »
1234567
891011121314
15161718192021
22232425262728
2930