Stow maneja los siguientes conceptos:

• Package. Una colección de archivos y/o directorios que te gustaría manejar como una unidad pero que se tienen que instalar en directorios específicos del sistema.

• Target Directory — Donde los dotfiles deberian aparentar estar instalados (en home, .config, etc).

• Stow Directory — Donde los “packages” (en este caso los diferentes dotfiles) serán instalados. Este será el directorio ~/.dotfiles (por ejemplo).

• Package Directory — Un directorio que contiene los archivos de instalación (o en este caso los ficheros de configuración) de un sólo programa, por ejemplo el directorio zsh que contiene el archivo .zshrc. Estos “package directories” estarán dentro del “stow directory”.

Los symlinks son entradas del sistema de archivos cuya ruta se llama symlink source que apunta a otra localización del sistema de archivos llamada symlink destination, la cual no tiene por que existir. Si se cambia cualquiera de ellos, ambos cambian.

El proceso sería el siguiente:

• Se crea el directorio donde estarán los dotfiles (stow directory), por ejemplo ~/.dotfiles. El target directory es por defecto el directorio superior al stow directorio, por lo tanto $HOME

• Se mueven los dotfiles desde sus directorios de orgen a éste. Se pueden clasificar en distintos directorios (package directories). Si el directorio de origen no es el raiz, si no que está anidadao, hay que crear la misma estructura de directorios dentro del stow directory (o del package directory correspondiente). Por ejemplo, si el dotfile está en ~/.config/rstudio/rstudio.conf, en el stow directory podríamos tener ~/.dotfiles/rstudio/.config/rstudio/rstudio.conf.

• Desde .dotfiles se lanza stow . (si están sueltos) o stow nombre_package_directory para cada paquete.

tabla_unida <- list.files("ruta_archivos_excel", pattern = "xlsx") |>
    map(read_xlsx) |>
    list_rbind()

El problema con estas opciones es que no funcionan con objetos espaciales de clase sf. De hecho es más problemático, porque no es que el proceso falle, si no que el resultado es un data.frame normal (no un objeto sf) que pierde su columna geométrica.

Así que para leer un conjunto de archivos vectoriales y cargarlos todos en el mismo objeto sf, usamos dplyr::bind_rows:

objeto_sf <- list.files("ruta_archivos_espaciales/", pattern = "gpkg") |> 
    map(st_read) |> 
    do.call(bind_rows, args = _)

Para leer los archivos cada uno en un objeto diferente, podríamos usar assign:

lista_sfs <- list.files("files/geo", pattern = "gpkg", full.names = T) |> 
  set_names(basename) |> 
  map(st_read) 

for (i in seq_along(lista_sfs )) {
  assign(names(lista_sfs [i]), lista_sfs [[i]])
}

Así que recomiendan usar en general la inferencia bayesiana para las regresiones: si hay información previa disponible, se usa; y si no, una regresión bayesiana como prioris poco informativos aun tiene la ventaja de proporcionar estimaciones estables y producir simulaciones que nos permiten expresar incertidumbre inferencial y predictiva (o sea, estimadores con incertidumbres y predicciones probabilísticas).

Así, en general, en vez de:

fit <- lm(y~x, data=mis_datos)

usar:

library(rstanarm)
fit <- stan_glm(y~x, data=mis_datos)

Advierten que stan_glm puede ser lento con problemas grandes (no está claro cuánto es “grande”), en cuyo caso habría que usar la forma optimizada:

library(rstanarm)
fit <- stan_glm(y~x, data=mis_datos, algorith = "optimizing")

files/how_solve.pdf

Nadie quiere hablar sobre testing. Testing es el patito feo del desarrollo de software. El problema es que todos/as sabemos que el testeo es importante y que no lo hacemos lo suficiente. Y sentimos que nuestros proyectos no van tan bien como deberían y que probablemente más testeo haría que fueran mejor. Pero entonces leemos un libro sobre testing e instantaneamente nos venimos abajo con los múltiples tipos de testeos y las múltiples formas de hacerlos. No hay forma de que añadamos todo eso y aún nos de tiempo a programar.

Extreme Programming explained - Kent Beck

En el caso de funciones que usemos constantemente y especialmente para el caso de operadores (por ejemplo %>%), podemos evitar usar la notación paquete:: usando

#' @importFrom paquete funcion

Para importar métodos de una clase S3 que no están explícitamente exportados en su paquete, algo que sucede habitualmente para funciones como plot o predict. Por ejemplo, para poder usar el predict del paquete randomForest, es necesario tener Depends: randomForest en DESCRIPTION y además importar el predictgenérico del namespace stats con

#' @importFrom stats predict

El código que mantiene su simplicidad a la vez que proporciona la flexibilidad necesaria para realizar posibles mejoras razonables en el futuro estaría diseñado de la manera correcta. Se usan muchas excusas para no resolver los problemas de la forma correcta:

• No conozco la forma correcta.

• El grupo no se pone de acuerdo en cuál sería la forma correcta.

• Estoy demasiado cansado/hambriento/desanimado para hacerlo de la forma correcta en este momento.

Understanding Software. Max Kanat-Alexander. 2017 Packt Publishing

• Una función trigger que realiza las acciones que se quiera.

• El trigger propiamente dicho, que es el que se encarga de enlazar la función con una tabla y establecer en qué casos se va a lanzar.

Algunas notas:

• El trigger no lleva schema en el nombre. Los triggers se crean específicamente para cada tabla, por lo que su nombre debe ser único sólamente entre los otros triggers de esa tabla.

• La función trigger no puede llevar argumentos en su definición. Sin embargo, cuando es llamada por un trigger, se generan varias variables especiales en su interior, una de las cuales, TG_ARGV, es un array (empieza en 0) de texto de los argumentos pasados en la sentencia CREATE TRIGGER.

Los tres principales criterios de la programción funcional como paradigma de computación se pueden resumir:

1. Cualquier operación se puede expresar como una llamada a una función.
2. El resultado de la llamada está definido únicamente por los valores de los argumentos.
3. El efecto de la llamada a una función es simplemente el valor devuelto.

John M. Chambers. Extending R.

mv nombre_antiguo nombre_nuevo
git rm nombre_antiguo
git add nombre_nuevo

o usar el atajo

git mv nombre_antiguo nombre_nuevo

Ambas opciones son equivalentes.

Si después se quieren ver los commits que han afectado a ese archivo, con

git log nombre_nuevo

sólo se obtendrán los commits realizados desde el cambio de nombre. Si se quieren visualizar todos los commits que le han afectado, incluyendo los anteriores al cambio de nombre, se puede realizar mediante:

git log --follow nombre_nuevo

1?? herejia!

Aunque no sea un lenguaje de programación, también en Postgres los arrays empiezan la cuenta en 1. Junto con AWK, y Matlab/Octave son de los pocos que no empiezan por cero.

Y aunque se suelen escuchar distintos motivos sobre el porqué los índices de los arrays empiezan en cero (algo que resulta poco intuitivo en principio), parece que realmente poca gente conoce los motivos reales.

En su interesante artículo Citation Needed, Mike Hoye hace una investigación muy completa para encontrar la solución.

• Esforzarse por mantener las funciones tan simples como sea posible (¡pero no más!). Generalmente, cada función debería hacer una cosa bien, y el propósito de la función se debería poder definir en una sola frase.

• Evitar mezclar efectos secundarions (side-effects) con transformaciones. Asegurarse que cada función o devuelve un objeto o tiene un efecto secundario. No ambas.

• Los nombres de las funciones deberían ser verbos. La excepción es cuando muchas funciones usan el mismo verbo (normalmente algo como “modificar”, “añadir” o “calcular”). En ese caso, evitar duplicar el verbo común y en su lugar centrarse en el nombre. En ggplot2 hay un buen ejemplo de esto: casi cualquier función añade algo a un gráfico ya existente.

alias add='git add'
alias br='git branch -v'
alias cambios='git log --date-order --date=short --graph --full-history --all --pretty=format:"%h - %ad - %s"'
alias cambios_autor='git log --date-order --date=short --graph --full-history --all --pretty=format:"%h - %ad - %an - %s"'
alias ci='git commit -m'
alias cia='git commit -a -m'
alias co='git checkout'
alias cob='git checkout -b'
alias deshacer_ci='git reset --soft HEAD~1'
alias gcaa='git commit -a --amend -C HEAD'
alias nuevo='git log HEAD@{1}..HEAD@{0}'
alias push='git push'
alias pushom='git push origin master'
alias st='git status'
alias unstage='git reset HEAD'

Como interfaz gráfica suelo usar git-cola. Como visor de historial y de ramas no he llegado a encontrar ninguno que me guste demasiado, pero suelo usar el DAG que viene con git-cola o gitk que viene con la propia instalación de git.

Cuando trabajo con R, utilizo el panel de Git que incluye RStudio, ya que es lo más ágil.

in2csv -f json -k issues archivo_exportado.json > tabla_salida.csv

Desde Bitbucket se pueden exportar los “issues” a un archivo json que guarda todos los datos relacionados con los mismos: contenido, comentarios, adjuntos, versiones, logs, etc. Aunque es un formato ¹ muy completo, que permite exportar e importar cómodamente entre repositorios git, no es lo más cómodo para ser leido por personas (es lo que tiene el json, muy fácilmente procesable por máquinas, pero aunque legible por humanos, no es especialmente amigable).

Una forma rápida de extraer parte de la información es a través del comando in2csv del paquete ² csvkit. En este caso, nos quedaríamos con las características principales (estatus, prioridad, tipo, titulo y contenido, usuario que reporta, etc) y se quedarían fuera comentarios, adjuntos y otras informaciones.

En primer lugar hay que descomprimir el archivo que se genera al exportar desde Bitbucket y quedarse con el fichero llamado db-1.0.json o similar.

in2csv -k issues archivo_exportado.json > tabla_salida.csv

Tras el parámetro -k hay que indicar la clave “top-level” que se quiere extraer y es obligatorio si el JSON contiene más de una de estas claves. En nuestro caso, las claves son:

• issues,

• comments,

• attachments,

• logs,

• meta,

• components,

• milestones

• versions

TL; DR

Cada comando de una tubería se ejecuta dentro de una subshell, con su propio contexto y entorno de variables. Incluyendo los bucles si estos forman parte de la tubería.

var1=0
echo $VARIABLE1 | 
while read task; do
  # cuerpo del bucle
  var1=2
  # ...
done
echo "$var1"


> 0

var1=0
 
echo $VARIABLE1 |
{ 
  while read task; do
    # cuerpo del bucle
    var1=2
    # ...
  done
  echo "$var1"
}

> 2

No puedes reproducirlo si no entiendes de dónde viene un número.
No puedes reproducir lo que no recuerdas. Y creéme: no lo recordarás.
No puedes reproducir lo que has perdido. ¿Y si necesitas acceder a cómo era un archivo hace 1, 10, 100 o 1000 dias?

Ben Bond-Lamberty @BenBondLamberty

Aerobatic

Hasta ahora esta web se desplegaba usando Aerobatic. Aerobatic se instalaba como un complemento de Bitbucket. Se indicaba una rama del repo y con cada push, Aerobatic ejecutaba Jekyll de forma interna y volvía a construir el directorio _site y a servirlo en forma de página web. El plan gratuito permitía utilizarlo con un máximo de dos repositorios y utilizar un dominio personalizado.

Por desgracia, han avisado que para marzo (de 2017) se introducen cambios en el sistema de precios del producto, de forma que ahora, aunque el plan gratuito permite tener tantos proyectos como se quiera, no permite usar un dominio personalizado (sólo se pueden usar direcciones del tipo: https://nombre-del-sitio.aerobatic.io ), de forma que no podía seguir usando mi dominio dmts.es. El plan de pago más barato suponen 15$ al mes, lo que para un blog tan sencillo como este me parecía excesivo ¹.

• mostrar los datos,

• inducir al observador a pensar sobre el contenido y sentido de los datos más que sobre la metodología, el diseño, la tecnología con que se ha construido el gráfico o cualquier otra cosa,

• evitar deformar lo que los datos tienen que contar,

• presentar muchos números en un espacio pequeño,

• conseguir que los grandes conjuntos de datos sean coherentes,

• animar al observador a comparar diferentes porciones de los datos,

• revelar los datos a diferentes niveles de detalle, desde la vista general al detalle,

• servir de forma clara a un propósito razonable: descripción, exploración, tabulado o decoración,

• estar perfectamente integrado con la descripción estadística y verbal del conjunto de datos.