31 Aug 2012

MSL Curiosity NavCams: Anaglyph Panorama of Bradbury Landing Site/ Panorama anaglifo del sitio de aterrizaje Bradbury

Click para ampliar / Click to zoom

Este es mi segundo trabajo con las imágenes de las cámaras de navegación (NavCams) del MSL tomadas el Sol22. Se trata del sitio de aterrizaje del Curiosity bautizado como Bradbury Landing Site en honor al escritor de ciencia ficción Ray Bradbury, recientemente fallecido. El monte Aeolis queda a la derecha.

La panorámica se ha realizado uniendo 4 fotografias y generando una proyección esteroscópica. El campo de visión es de unos 136 grados horizontales. He usado el pedrusco central como foco.

Algunos datos de las NavCams (Cámaras de navegación)

Posición de las NavCams en el mástil

Fuente: THE MARS SCIENCE LABORATORY (MSL) NAVIGATION CAMERAS (NAVCAMS). J. N. Maki1, D. Thiessen1, A.Pourangi1, P. Kobzeff1, L. Scherr1, T. Elliott1, A. Dingizian1, Beverly St. Ange1, 1Jet Propulsion Laboratory/California Institute of Technology, 4800 Oak Grove Drive, Pasadena, CA 91109. Fecha de consulta: 31/08/2012.

25 Aug 2012

MSL Navcams: my first anaglyph (3D image) / mi primer anaglifo con las imagenes de las navcams

Here is my first attempt to make an anaglyph from the navcams images. I have taken them from the Front Hazcams on (sol 16)

Anaglyph MSL navcams on sol 16

Comments welcome. I have been inspired by Un geólogo en apuros.

2 Aug 2012

Aún otro ejemplo de try, except, else, finally / Yet another try, except, else, finally example

Estaba pasando datos de una DB mysql a otra en django y me ha salido este "snippet" que ejemplifica el uso de try-except-else-finally.

try contiene el código que queremos proteger
except captura la excepción (usar la clase genérica exception para capturarlas todas)
else código que se ejecutará si no salta ninguna excepción
finally código que se ejecutará en todo caso tanto si hay como si no hay excepción

Las únicas obligatorias son try y except. Si queremos capturar más de una excepción, las ponemos una detrás de otra:

from django.core.exceptions import ObjectDoesNotExist
try:
    cl=Cliente.objects.get(clave=id)
except ObjectDoesNotExist, ex:
    print "el cliente no existe"
except Exception, ex:
    print "se ha producido un error", str(ex)

Ejemplo:

try:  
   try:  
     c=db_marcajes.cursor(MySQLdb.cursors.DictCursor)  
     c.execute("select id, fecha, event, door, user from logs where fecha>%s", (last_marcaje,))  
     rows=c.fetchall()     
   except Exception, e:  
     print "Impossible efectuar consulta"  
     exit(1)  
   else:  
     elapsed = (time.clock() - start)  
     print "Consulta realitzada en", elapsed, "msegs"  
     num_rows=len(rows)  
     print "Numero de filas ", num_rows  
     i=0    
     while i<num_rows:  
       row=rows[i]     
       print "procesando fila ", repr(row)  
       try:  
         em=Empleado.objects.get(pin=row['user'])  
         pt=Puerta.objects.get(pk=row['door'])  
         print ("guardando acceso %s de %s" % (row['user'],em.descripcion,))  
       except Exception, ex:  
         print ("Error de busqueda empleado %s puerta %s: %s", ( row['user'], row['door'], ex, ))  
       else:  
         try:  
           acc=Acceso(  
             empleado=em,  
             es=row['event'],  
             fecha=row['fecha'],  
             puerta=pt,  
             )  
           #acc.save()  
           print "Guardado"  
         except Exception, ex:  
           print ("Error grabando acceso: %s" % (ex,))  
       finally:  
         i+=1  
         last_marcaje=row['fecha']  
   finally:  
     c.close()           
 finally:  
   # guardam darrer marcatje  
   conv=Convenio.objects.get(pk=1)  
   conv.last_marcaje=last_marcaje  
   conv.save()  

27 Jul 2012

Prevenir el borrado de objetos via clave foránea / Prevent object deletion via foreign key

Una de los comportamientos por defecto más problemáticos de django es el de emular el DELETE CASCADE  cuando borramos una clave foránea. Desde luego, hay que ser animalito. Ya me veo a decenas de usuarios noveles preguntándose adonde han ido a parar sus datos después de efectuar un borrado de una clave foránea que tenía objetos relacionados.

La forma de "proteger" los objetos relacionados es via la definición del ForeignKey.on_delete que puede tomar los siguientes valores

CASCADE: Borrado en cascada, comportamiento por defecto.
PROTECT: Protege al objeto relacionado del borrado haciendo saltar la excepción django.db.models.ProtectedError.
SET_NULL: Asigna el valor null a la clave, sólo posible si null es True.
SET_DEFAULT: Pone la clave foránea a su valor por defecto (debe estar definido).
SET(): Asigna a la clave foránea el valor pasado en el set.
DO_NOTHING: No hace nada y deja el comportamiento por defecto de la db. (Si la hemos creado con syncdb, no hará nada)


Una práctica aconsejable en un entorno de usuario sería capturar la excepción via PROTECT y devolver un mensaje de error con la información para el usuario.Por ejemplo:

Si en la definición del modelo Factura usamos

cliente=models.ForeignKey(Cliente, on_delete=models.PROTECT)

Y ahora queremos borrar un cliente que tiene una factura asociada

try:
  cliente.delete()
except django.db.models.ProtectedError, ex:
  return HttpResponse( ('El cliente %s tiene al menos una factura y no puede borrarse.' % (cliente.descripcion,)), 'text/html')