CONTROL DE VERSIONES CON MERCURIAL


Mercurial es una herramienta que nos permite hacer un control de versiones de nuestros proyectos informáticos como documentación, aplicaciones desktop, sistemas web, aplicaciones móviles, etc.

Esta herramienta permite crear un lugar de almacenamiento donde estarán alojadas los proyectos y las subversiones de estos, es así que cada vez que nosotros modifiquemos algo en nuestro proyecto la versión anterior quedara almacenada y así no tendremos problemas si queremos recuperar algo.Para lograr esto debemos descargar e instalar el Mercurial para Windows, lo encontramos aqui.



Para empezar primero creamos una carpeta, en mi caso lo he creado en el Disco  Local C, con el nombre “repositorio”, es aquí donde se almacenaran todas las versiones del proyecto a desarrollar.




Luego usamos el comando init para inicializar  nuestro controlador de versiones e indicar la carpeta donde se alojara el repositorio.




Ahora agregamos un archivo al repositorio con el comando add  para que Mercurial rastrée los cambios en el archivo, en este caso trabajaremos con  “archivo1.txt”.




Podemos ver el estado con el comando status.   

 * M   : El archivo contiene modificaciones que no se han registrado en el repositorio   

 * A    : El archivo está marcado para ser añadido al repositorio en el siguiente envío de  cambios o “commit”  

  * ?    : El archivo no está siendo seguido por Mercurial. 





En nuestro caso se muestra  A, que indica que el archivo esta listo para su seguimiento.


Ahora hacemos commit  a los archivos, para ello nos creamos una carpeta dentro del repositorio a la cual lo llamaremos “archivos”



Usando el comando log  se puede ver una lista de los conjuntos de cambios que se han ido haciendo a lo largo de la historia de un proyecto. 

En nuestro caso hay tres cambios o actualizaciones que se hicieron:

0:7c3dda…  

1:9d1c9e… 

2:1117f3a… 


Podemos actualizar con el comando update las revisiones a cualquiera de las tres anteriores que se muestran.



Podemos ver las diferencias las entre dos revisiones con el comando diff


Podemos sacar copia o clonar los repositorios con el comando clone, en este caso clonaremos la carpeta “repositorio” a otra que la llamaremos “repositorio-copia”


Ahora trasladaremos información entre repositorios, esto se puede hacer de dos maneras. Ah pero antes no olvidemos hacer commit para realizar cambios, sino el push o el pull no lo encontraran. 


La primera es con el comando push: lo que hace es llevar a un repositorio remoto los de cambios del repositorio actual que no se encuentren en él.


La segunda es el comando pull que hace lo contrario al push, que es traer de un repositorio remoto los cambios al repositorio actual


Cuando integramos los cambios de distintos repositorios mediante push o pull , es probable que se produzcan desarrollos paralelos que den lugar a distintas ramas de desarrollo en el proyecto.


Bueno para localizar las distintas cabezas existentes en el repositorio usamos el comando heads.


Digamos queremos unir o mezclar  estos dos heads entre el 3 y 4, entonces usamos el comando merge.


Seguidamente hacemos un commit de mezcla


Tras la mezcla solamente nos queda una cabeza, el 5 el cual vemos con un hg heads



Bueno eso seria algo basico de Mercurial y las funciones que realiza, estén al tanto de otros manuales que pronto se subirán.




CRUCERO DE GUERRA TUMBADO POR UN CERO


Buque de guerra, el USS Yorktown (CG-48). Puesto en funcionamiento a principio de los 80, contaba con todo tipo de misiles, torpedos y otras armas de la época; circuló por el mar negro y las costas de Libia en diferentes misiones.


Al parecer en 1997, estando de maniobras, un técnico introdujo un número cero en una base de datos de los sistemas del buque, lo que provocó un error en cadena en otros sistemas de la red informática que gobernaba la nave, que eran 27 Pentiums Pro y un servidor, todos corriendo Windows NT 4.0.


 Esto hizo que se inutilizara completamente el sistema de propulsión de 80.000 CV, que se detuvo sin arrancar de nuevo. El Yorktown quedó a la deriva durante casi tres horas, lo que tardaron en anular los sistemas informáticos y conectar controles de emergencia para poder llevarlo a puerto. 


Allí los ingenieros pasaron dos días hasta dar con el problema, reparando los motores y volviendo a dejar todo como estaba originalmente.Tras la investigación del incidente se concluyó que aquel «cero» había causado un" error de división por cero", uno de los más tradicionales errores lógicos en informática, que el gestor de base de datos no había podido digerir, provocando a su vez una cascada de fallos que inutilizaron el control del sistema de propulsión.





MARS CLIMATE ORBITER, DESAPARICION EN MARTE


El 23 de septiembre de 1999 la sonda MARS CLIMATE ORBITE de los EE.UU. desapareció después de haber realizado unas correcciones en la trayectoria que tenía esta. La desaparición fue confirmada después de haber perdido contacto con la sonda al haberse puesto detrás del planeta Marte cumpliendo con una nueva órbita.

En  Busca de Respuestas

El anuncio fue publicado horas después del incidente por el laboratorio de propulsión a chorro desde Pasadena (California). Centrándose en que el accidente se debió a una inestabilidad en el cálculo de órbita, ya que se tenía estimado sobrevolar Marte a 150KM, mientras que la sonda se encontraba a los 60KM, esto era una gran diferencia lo cual provocó la destrucción y pérdida de la sonda MARS CLIMATE ORBITE.

Un Error Inverosímil

Después de cierta investigación realizada se denomina que el error no pudo ser por parte del personal de control de órbitas porque con tantos años de la experiencia en la NASA sería casi imposible que haya pasado una falla como esta sin ser detectado por algún sistema.
Por tal motivo el incidente se refiere a un error muy lamentable por parte del sistema de control programado. Se apunta que la perdida de la nave fue por la variación en la órbita de la misma siendo la diferencia de 90 KM. Ahora ¿Por qué sucede esto? Se dice que la falla fue en el tipo de conversiones del sistema de navegación de millas inglesas a kilómetros. Por lo tanto si fue un lamentable error humano.





BANK OF AMERICA




En cuanto a la historia del antiguo Bank of America, antes de ser adquirido por el NationsBank, antes de 1998; este  nació a partir del Bank of Italy, fundado en 1904 por Amadeo Giannini, en San Francisco.
Durante el terremoto de San Francisco de 1906, Giannini pudo el dinero depositado en el edificio bancario. A diferencia  de los otros bancos, conservó la estabilidad de sus depositarios y prestó dinero para los afectados por el siniestro. Desde entonces se extendió por todo el país mediante la compra de numerosos bancos. Y en 1997, dado a problemas financieros, se vió obligado a su venta.
El 30 de marzo del 2009, Bank of America  anunció que integrará su filial Premier Banking dentro de la división “Merrill Lynch Global Wealth Management” lo que ocasionará el despido de cientos de empleados. Este cambio se produjo para mejorar la posición del Banco como administradores de clientes acaudalados que poseen fondos de $100 000 y $3 millones de dólares. Los administradores de clientes de Premier Banking que estaban a cargo de las relaciones a nivel personal con los clientes dejarán ese rol para convertirse en “especialistas de banca”, que asistirán a los 18000 asesores financieros de la compañía con recomendaciones de productos de banca. Los asesores, 16.000 de los cuales llegaron de Merrill Lynch & Co. se harán cargo del trato con los clientes.
En abril de 2009, los fondos de pensión, que representan 1% de las acciones de la empresa, se opusieron a la reeleción de Kenneth Lewis, presidente de Bank of America. Los fondos alegan que los directores del banco, los cuales nunca dieron explicación alguna en cuanto a  los beneficios de la compra de Merril Lynch en cuanto respecta a las acciones. El 29 de abril, los accionistas designaron a Walter E. Massey como presidente del directorio; y a Ken Lewis permanecerá como director general y presidente ejecutivo.


THERAC 25

THERAC 25 era una maquina de radioterapia producida por la empresa Atomic Energy  de Canadá Limited (AECL).

¿Pero qué hacia esta máquina?

Un acelerador de partículas, un dispositivo que aumenta la energía de las partículas atómicas cargadas eléctricamente. Estas partículas cargadas son aceleradas por la introducción de un campo eléctrico, produciendo partículas que luego son enfocados por imanes el cual se aplica a los pacientes con cáncer  pero mucho cuidado con esto porque la dosis solo es destinada a matar el tumor maligno.

Falla del software: los pacientes recibieron una sobredosis masiva de radiaciones de aproximadamente 100 veces más de la dosis esperada, lo cual fue letal para estos. Esto  ocurrió entre  enero de 1897 y junio de 1995. Dice que  3  de los 6 pacientes murieron como consecuencia directa, para el resto solo fue cuestión de tiempo. Esto remarcó los riesgos de control por el software de sistemas de seguridad crítica, y estos se convirtieron en casos de estudios típicos de la informática médica y la ingeniería de software.






ARIANE 5


Otro ejemplo documentado sobre el daño ocasionado por software mal diseñado es el de la explosión del lanzamiento del Ariane 5 el 4 de Junio de 1996, cuando a 40 segundos después de la iniciación de la secuencia de vuelo, la lanzadera se desvió de su ruta, se partió y explotó. En el proyecto global se invirtieron 10 años de construcción y 7 mil millones de euros, lo que supuso un duro varapalo para la Agencia Espacial Europea (ESA).
El objetivo era poner dos satélites de tres toneladas en órbita. En cambio el resultado fue que a los 39 segundos del lanzamiento el cohete se desintegra, perdiendo los dos caros satélites.

A los 36,7 segundos el software de guiado inercial produce overflow al convertir un número representado en 64 bits (float) a 16 bits (int). Caída del sistema de backup, a los 0.05 segundos caída del sistema principal. El sistema de control principal recibe datos de diagnóstico que interpreta como datos de vuelo (ha cambiado la posición del cohete).Fuerte reacción para corregir la trayectoria. Desintegración por la fuerza aerodinámica. Autodestrucción. Causas: El sistema de guiado inercial es el mismo que en Arianne 4, por lo que no se prevé protección contra este overflow ya que estas comprobaciones se hacen en otro lugar, y no se había producido nunca. 

La velocidad horizontal de Ariane 5 es cinco veces superior a la de su antecesor, lo que provoca este overflow. Las especificaciones y pruebas realizadas no lo tuvieron en cuenta.«La excepción de sofware interna del SRI fue causada durante la ejecución de una conversión de datos desde coma flotante a 64 bits hasta valor entero con signo de 16 bits.

El número en coma flotante que fue convertido tenía un valor mayor del que podía ser representado por un entero con signo de 16 bits. Esto dio lugar a un Error de Operando. Las instrucciones de conversión de datos (en código Ada) no estaban protegidas de causar un Error de Operando, aunque otras conversiones de variables comparables en el mismo lugar en el código estaban protegidas.





ALLSTATE SEGUROS


La Corporación Allstate es la segunda más grande de líneas personales de seguros en los Estados Unidos y el más grande que cotiza en bolsa. La compañía también tiene operaciones de seguros de líneas personales en Canadá.

Allstate fue fundada en 1931 y se separó en 1993.  Su campaña publicitaria actual, en uso desde 2004, pregunta: "¿Está usted en buenas manos?", la ha traído beneficios y la ayudo a recuperarse económicamente después del fracaso que tuvo un proyecto fallido de automatización integral de para sus operaciones.  

 Allstate comenzó en 1982 un proyecto de software para automatizar todas las operaciones de sus oficinas. Se estableció  un calendario de 5 años y un presupuesto de $ 8 millones. Seis años y 15 millones de dólares más tarde, Allstate fijó un nuevo plazo y reajustó su mirada en un nuevo presupuesto.

Finalmente en 1993 el proyecto fue abandonado después de gastar $ 100 millones. La historia del desarrollo de software es un gran éxito. Basta con mirar a tu alrededor como  prueba de ello. Sin embargo, ese éxito tiene una sombra larga y oscura que no se habla mucho: está llena de fracasos colosales. Lo que es particularmente preocupante es que los fracasos colosales año tras año se repiten. Los nombres y las cantidades de dinero puede cambiar, pero la historia es de lo contrario la misma.  










BLUE CROSS


Blue Cross (Isapre norteamericana) perdió más de US$60 millones en pagos incorrectos debido a un error en el software por el que habían pagado más de US$200 millones.
Parte de las conclusiones de la comisión investigadora afirma:



“En el escenario del fallo, las causas técnicas principales son el error que se produjo al momento de que un operando trató de convertir la horizontal, sesgó la variable BH, y la falta de protección de esta conversión  hizo que  el equipo del SRI se detuviera”