Exportar de blogger a github pages

Crear un blog en github es realmente sencillo.

Lo primero es decidirnos por uno de los varios proyectos que nos facilitarán la tarea: Yo he escogido pixyll porque me parece muy de estilo "content first", es decir, prima la visualización del contenido. No puede ser más fácil de instalar ya que nos lleva ya hecho el servidor jekyll y las página de estilo usando el rapidísimo basscss.

Si por ejemplo nuestro nombre de usuario en github es usuario nos vamos al proyecto pixyll y le hacemos un fork (el botón está arriba a la derecha). Esto copiará el proyecto en nuestra cuenta de github. Ahora nos vamos a nuestra cuenta de github->Repositories, seleccionamos pixyll y le cambiamos el nombre entrando en Settings->Repository name.

El nombre del repositorio debe ser: usuario.github.io

Ya podemos entrar en el sitio web http://usuario.github.io recién creado.

Las entradas se hacen en formato markdown, para crear una navegamos en proyecto a _posts, aqui creamos un nuevo archivo cuyo nombre debe seguir esta sintaxis:

YYY-MM-DD-titulo-de-la-entrada.md


Editamos el fichero en markdown; La cabecera siempre debe ser del tipo

---
layout: post
title: titulo de la entrada
---

bla bla bla

Con el fichero creado, le damos a commit y, después de unos segundos, ya tendremos la nueva entrada en nuestro blog!!.



También podemos tener una copia del blog en nuestra máquina local y sincronizarla con github.io. Para ello sólo tenemos que clonar en nuestro ordenador el repositorio




git clone http://github.io/usuario/usuario.github.io



Con nuestro flamante nuevo blog en marcha, ahora tenemos que migrar los contenidos de blogger a github. Yo lo he hecho con este script ruby, que debemos copiar en nuestro directorio del blog, junto encima del directorio _posts.



ejecutamos el script con




ruby blogspot_to_jeckyll.rb http://usuario.blogspot.com/feeds/posts/default?max-results=300



Que nos copiará las entradas al directorio _posts. Podemos arrancar el servidor jeckyll para ver el resultado, en el directorio usuario.github.io hacemos

gem install github-pages

jekyll serve

Para probar vamos a http://localhost:4000/

Una vez que comprobemos que todo está perfecto,  añadiremos las nuevas entradas al blog. Para ello entramos en el directorio de _posts y 



git add *

git commit -a -m "Migracion de entradas desde blogger"

git push



Lo que copiará todas las entradas antiguas al nuevo blog en github. A partir de ahora, ya podremos editar nuestras entradas en markdown, sin depender del horroroso entorno de blogger. Feliz blogeo!.

Permisos de apache en directorios

Entrada bastante completa en serverfault que presenta distintos escenarios y las combinaciones de permisos óptimas.


Si el host es mantenido por un solo usuario:

chown -R eve contoso.com
chgrp -R www-data contoso.com
chmod -R 750 contoso.com
chmod g+s contoso.com
ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

Si Apache tiene que escribir en algún directorio, le damos permiso de escritura al grupo

chmod g+w uploads
ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

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

Algunas veces las imágenes u otros elementos no quedan bien colocados, generalmente sólo hay que introducir algún final de página para que queden en su sitio.

\newpage

Usar metadatos de pandoc

Este método de personalización es más automático que el anterior y no hay que editar el tex. Consiste en editar el markdown para añadir la cabecera al principio del documento. Las cabeceras de metadatos de makdown están en formato yaml y lucen tal que así (hay que poner las tres rayas de inicio y final):

``` cabecera del documento markdown

---

title: Título del documento

author: Pepe Pérez

header-includes:

    - \usepackage[utf8]{inputenc}

    - \usepackage[catalan]{babel}

    - \usepackage{fancyhdr}

    - \pagestyle{fancy}

    - \rhead{Universidad a distáncia}

    - \lhead{Asignatura xxxx}

    - \rfoot{\thepage}

    - \fancyfoot[CO,CE]{Prueba3}

toc:

    true

---

```

Estos metadatos instruyen a pandoc para formatear el documento de salida. De esta forma podemos generar el pdf personalizado directamente a partir del md con

pandoc doc.md -o doc.pdf

Personalización máxima de la salida de pandoc

También podemos modificar directamente la plantilla de pandoc personalizándola según nuestros intereses. Primero hacemos una copia de la plantilla por defecto con

pandoc -D latex > plantilla.tex

Personalizamos la plantilla y generamos el pdf 

pandoc -s -N --template=plantilla.tex doc.md -o doc.pdf

Python simbólico resolver ecuación

Resolver esta ecuación en wolfram alpha,

... y su equivalente usando sympy



>>> from sympy import symbols, var
>>> v1,v2,v3,vo,r1,r2,r3,r4,rf=symbols('v1,v2,v3,vo,r1,r2,r3,r4,rf')

>>> from sympy.solvers import solve

>>> from sympy import init_printing

>>> init_printing(use_unicode=False, wrap_line=False, no_global=True)

>>> solve(v1/r1 + v2/r2 - ((v3*(r4/(r3+r4)))-vo)/rf, vo)

 r1*r2*r4*v3 - r1*r3*rf*v2 - r1*r4*rf*v2 - r2*r3*rf*v1 - r2*r4*rf*v1 

[-------------------------------------------------------------------]

                           r1*r2*(r3 + r4)                 

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()

   

    class Meta:

        abstract=True

# esta tabla tendrá todos los campos de ModBase más los propios

class Personas(ModBase):

    # el nombre de la clave primaria es persona

    persona=cPk()

```    

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.

Virtualenv python3 django

sudo apt-get install python-virtualenv
cd ~
virtualenv -p python3 env_django
source ~/env_django/bin/activate
pip install Django==1.8.6


Para MacOS este tutorial incluye información de cómo configurar pyvenv.

brew install python3
python3 --version
pip install --upgrade pip
pip install virtualenv
pip install virtualenvwrapper
mkdir ~/.virtualenvs
vi ~/.bashrc
--> Añadir:
export WORKON_HOME=~/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh
--<
source .bashrc
--> buscar directorio de python3 con
which python3
mkvirtualenv --python=python3_path env-django
--> ya tenemos el entorno con python3 activado
deactivate
workon env-django
pip install Django==1.9