Highlights de la ESA de 2015
Ya ha salido el tradicional resúmen del año de la ESA.
Notebooks jupyter en pdf via pandoc
Para poder controlar todos los detalles de la impresión de los notebooks de jupyter, podemos volcarlos primero a formato markdown y de ahí convertirlos a tex o pdf via pandoc. En general, el paso a pdf funciona muy bien con la plantilla article pero siempre hay detalles que podemos modificar en el tex que se genera de intermedio.
Si queremos que pandoc nos genere el pdf directamente, hacemos
``` convert.sh
jupyter nbconvert --to markdown $1.ipynb
pandoc $1.md -s -o $1.pdf
```
Si queremos volcar antes a tex para editarlo
``` convert_tex.sh
jupyter nbconvert --to markdown $1.ipynb
pandoc $1.md -f markdown -t latex -s -o $1.tex
```
En realidad esto debería generar el mismo tex que exportar directamente desde jupyter.
Personalizar manualmente el documento latex que genera pandoc
Podemos personalizar el documento tex es añadiendo algunos comandos adicionales.Idioma
En la cabecera del documento\usepackage[catalan]{babel}
Título del documento
Justo antes del begin document\title{Títol del document \\ Autor: Pere Vilás}
y justo después
\begin{document}
\maketitle \tableofcontents La razón de tener que poner el título a mano es que sale como sección y queda mal en el índice.
Imágenes
Las imágenes salen del markdown sin tamaño, así que hay que ir una por una añadiendo el width o la scale. También se puede aprovecha para cambiar el caption:\begin{figure}[htbp]
\centering\includegraphics[width=75mm]{X1.jpg}
\caption{X1}
\end{figure}
Saltos de página
\newpageUsar metadatos de pandoc
Personalización máxima de la salida de pandoc
Django modelo de datos genérico usando abstract
Habitualmente, tenemos los mismos campos en varias tablas (modelos); Por ejemplo, la descripción, la fecha de alta, la fecha de última modificación, etc. Una forma de representar esto en los modelos es usar una clase genérica con los campos comunes y darle el atributo abstract. Las clases derivadas heredarán esos atributos.
El la sincronización, Django no creará ninguna tabla en la base de datos si está marcada como abstract.
En cuanto al nombre de la clave primaria del modelo, particularmente prefiero darle nombre en vez de dejar que Django la nombre como id.
Hay que ir con cuidado derivando modelos: No es lo mismo una tabla (o una entidad) derivada que una vista. Por ejemplo, podríamos tener una entidad llamada Persona y otras derivadas llamadas Cliente, Proveedor, Agente, Transportista, etc. Si en Django derivamos esos modelos directamente de un modelo base (Persona), en la base de datos se crearán tantas tablas nuevas como modelos derivados (Clientes, Proveedores, ...). Esto no tiene nada que ver con tener una tabla llamada Persona y diversas vistas de esa única tabla llamadas Clientes, Proveedores, etc. En Django cada modelo equivale a una tabla (entidad), no a una vista. Para crear el equivalente a una vista debemos usar un QuerySet.
```python
# -*- coding: utf-8 -*-
from django.db import models
LENGHT_DESC=150 # longitud de las descripciones
H_DESC = 'Entre descripción'
def cPk():
# devuelve clave primaria
return models.AutoField(primary_key=True)
def cFum():
# devuelve fecha ultima modificación
return models.DateTimeField(auto_now=True, null=False, blank=False)
def cDesc(ml=LENGHT_DESC, df=''):
# devuelve descripción
return models.CharField(max_length=LENGHT_DESC, help_text=H_DESC, null=False, blank=False, default= df)
def cFechaAlta():
# fecha de alta del registro
return models.DateTimeField(auto_now_add=True, null=False, blank=False)
class ModBase(models.Model):
#
# modelo base con descripcion, fecha de alta y fecha última modificación
#
descipcion=cDesc()
fecha_alta=cFechaAlta()
fum=cFum()
También podríamos usar la el modelo base para hacer un logger de los cambios en la base de datos, apuntando el nombre de la tabla, operación, usuario, etc.