Yaml essentials

YAML

Inicialmente llamado «Yet Another Markup Language» (YAML), que sin embargo no es un Markup Language, si no que ha acabado siendo un lenguage de serialización de datos fácilmente legible por humanos, razón por la que cambió su nombre a «YAML Ain’t Markup Language».

Pensado para ser fácilmente legible por humanos, por lo que sus casos de uso son:
– Ficheros de configuración
– Almacenage de datos

Sintáxis
– Usa (2) espacios para indentar (nunca tabs!)
– La indentación agrupa cosas que van juntas
– Guiones para listas
– Dos puntos para key: values (atención al espacio tras los dos puntos)
– Usa comentarios con # seguido de un espacio en blanco (o tab)

Estilos:
– Block: el habitual
– Flow: es una extensión de JSON

Tipos
– Mappings: key:values
– Secuencias: array o lista de items, uno por línea precedido de un guión
– Escalares: strings, números o booleanos

Podemos partir un string en múltiples líneas (preservando el salto de línea) mediante «|» o sin preservarlo (pese a tener salto de línea dentro del yaml para facilitar la lectura) con «>»

schedule: |
  2018-10-01 - Whatever here
  2018-10-02 - And here
done_by: >
  A large sentence that
  has been broken into pieces
  but will be presented together.

Estructuras:
– Opcionalmente, un yaml file puede empezar con tres guiones. Ésto es obligatorio cuando usas herramientas como «Ansible».
– Los tres guiones también se pueden usar para separar diferentes documentos dentro de un mismo fichero.

Los anchors sirven para reutilizar datos dentro del fichero yaml. Seteamos la línea o el bloque con &anchorname y hacemos referencia a él con *anchorname.

 
locations:
  &EUlocations
  - Spain
  - Portugal
  - Italy
samelocations:
  *EUlocations

Más info
https://yaml.org/start.html
Linux Academy: Yaml essentials

Apuntes de Python 3 (3ª parte)


Tras año y medio desde la segunda entrega de los Apuntes de Python, llega la tercera entrega, con únicamente un par de secciones bastante genéricas (comunes a muchos lenguajes de programación) y unos cuantos snippets a modo de resumen. Pero antes de nada, te recuerdo los enlaces que preceden a este post:

Guía de estilo para Python

  • Usa (4) espacios en lugar de tabular
  • Nombra a tus variables y a tus funciones en minúsculas usando «_» como separador. i.e. return_code
  • Nombra a tus constantes en mayúsculas y de nuevo, usando «_» como separador. i.e. MAX_SIZE
  • Puedes usar comillas simples o dobles para strings [Más info]
  • Para strings con triple comilla, usa siempre comillas dobles. i.e. «»» Aquí el docstring «»»
  • Usa 2 líneas en blanco antes de funciones y definiciones de clases
  • Usa 1 línea en blanco antes de métodos dentro de una clase
  • Dentro de las funciones, usa una línea en blanco para separar secciones lógicas
  • Respecto a los comentarios, deben ser frases completas. Dejando un espacio entre la almohadilla y el comentario, empezándo en mayúscula y acabando la frase con un punto.

[Más info] [Y más]

Continuar leyendo «Apuntes de Python 3 (3ª parte)»

Apuntes de Python 3 (2ª Parte)

python3Ya tenemos aquí el segundo post de apuntes de Python 3, que sigue al primero que publiqué hace ya unos meses. Pincha en el siguiente link si te lo perdiste:

Apuntes de Python3 (1ª Parte)

1. Funciones (continuación)

Argumentos de la función (continuación)

Podemos setear un valor por defecto de uno o más argumentos de la función, de tal manera que si al llamar a la función no le pasamos dichos argumentos, éstos tomarán el valor por defecto. Podemos pasarle como valor por defecto, una variable, pero mucho cuidado pues el valor por defecto se seteará en el momento de la definición, con lo que si modificas la variable después de la definición de la función, no variará el valor por defecto del argumento.

>>> def myfunc(a,b=33,c='hello'):
>>>   print(a,b,c)
>>>
>>> myfunc(1,2)
1 2 hello

Respecto a los argumentos al llamar a una función, deberíamos usar «keyword arguments» (aka «kwargs») en lugar de argumentos posicionales. Es más largo pero es mucho más claro.

def myfunc(a,b,c):
   pass

myfunc(1,2,3)            #argumentos posicionales
myfunc(a=1,b=2,c=3)      #kwargs

Podemos usar un único argumento al definir la función para capturar cualquier número de argumentos posicionales (un asterísco) o kwargs (dos asteríscos) que se le pasen a la función.

def myfunc(*myargs):     #myargs será una tupla con todos los argumentos posicionales
def myfunc(**mykwargs):  #mykwargs será un diccionario con todos los kwargs

Continuar leyendo «Apuntes de Python 3 (2ª Parte)»

Apache Maven

maven-logo-black-on-whiteRecupero un post que ha estado en borradores un largo tiempo, pese a que ahora esté de moda Gradle 🙂

Teniendo en cuenta que vengo del mundo PHP, estaba empezando a documentarme sobre Apache Maven (una herramienta para la gestión -compilación, reporting y documentación- de proyectos Java) y sin tener demasiada idea, me ha parecido que tiene cierta similitud con Apache Ant. Como no podía ser de otra manera, no soy el primero que se ha preguntado en qué se diferencia Apache Ant de Apache Maven, y en StackOverflow dan un par de respuestas interesantes:

«Ant is an imperative build system, whereas Maven is a declarative build system» -> Un script ant le dice a ant qué ha de hacer, mientras que un script maven le dice a maven qué es lo que quieres conseguir, y maven se encarga de hacerlo.

Maven nació con la intención de estandarizar la creación de proyectos Java, definir de forma clara en qué consiste un proyecto determinado, facilitar la publicación de la información del proyecto y permitir la compartición de los ficheros JAR entre diferentes proyectos.

Continuar leyendo «Apache Maven»

Apuntes de Python 3 (1ª Parte)

python3
Bueno, este artículo contiene una serie de apuntes que me han parecido interesantes, referentes a un curso sobre Python 3. Así pues, no es ni mucho menos, un curso de Python 3, pero con suerte le será de utilidad a alguien (además de a mí mismo). De momento, aquí el primer post que he creado mientras he ido avanzando en el curso.

1. Introducción

1.1. ¿Por qué Python?

  • Escritura eficiente: requiere escribir menos código que otros lenguajes
  • Lenguaje de alto nivel y propósito general
  • Funciona bajo cualquier sistema operativo
  • Popular y gratuito
  • Cercano al pseudo-código, enfatiza la legibilidad

1.2. ¿Qué es Python?

  • Soporta múltiple paradigmas de programación (orientación a objetos, funcional, etc.)
  • Type checking done at runtime
  • Gestión automática de la memoria / garbage collector
  • Modular (core pequeño, extensible con módulos)
  • El código python puede ser paquetizado en un único ejecutable listo para distribuir (ej. dropbox)
  • Open-Source
  • Uno de los objetivos más importantes de los «pythoneros» es que sea un lenguaje divertido de usar
  • Creado por Guido van Rossum (aka BDFL)

Continuar leyendo «Apuntes de Python 3 (1ª Parte)»

Algunos apuntes sobre Bash

bashHe querido recoger algunas notas de Bash scripting para no tener que correr a Google (o a cualquier página de StackExchange) cada vez que las dudas me asalten.

/usr/bin/env bash vs /usr/bin/bash

Leí en la siguiente página sobre las «mejores prácticas en Bash» acerca del uso de «#!/usr/bin/env bash» en lugar del habitual «#!/usr/bin/bash» o «#!/bin/bash«. La idea es usar»#!/usr/bin/env bash» pues de esta manera lo que hacemos es buscar en el PATH dónde está bash, el cual es probable se encuentre en ubicaciones distintas en servidores diferentes. Ésto evitará problemas portando scripts a otros entornos. [Más info] [2]

#!/usr/bin/env bash

Corchete simple vs Doble corchete

Básicamente, ambos sirven para evaluar expresiones. «[» es un alias para el comando «test» y tanto uno como el otro están disponibles en el estándar POSIX. «[[» sin embargo es una keyword, no un programa, y se trata una versión mejorada para evaluar expresiones, únicamente disponible en Bash, KornShell y Zsh. Si no estás preocupado por la portabilidad de tus scripts con sistemas donde no cuentes con Bash, es mejor usar siempre el doble corchete, por la funcionalidad extra que aporta (posibilidad de usar && y ||, expresiones regulares, pattern matching, etc.). [Más info] [2]

La siguiente evaluación será «true» pues b és mayor que a, 8 mayor que 4, y abcd entra dentro del patrón «a*»:

if [[ b > a && 8 -gt 4 && abcd = a* ]]; then ...

PD: Dejo un enlace a la wikipedia donde se especifican los nombres en inglés de éstos símbolos, según la zona.

Continuar leyendo «Algunos apuntes sobre Bash»

Resumen de Scrum desde las trincheras

scrumEste es mi resumen de la parte de Scrum (sin incluir XP) del libro «Scrum y XP desde las trincheras» de Henrik Kniberg. No es la biblia ni debe ser una referencia, pero sí que puede ayudar a refrescar algún concepto o a empezar con Scrum.

Scrum = marco de trabajo

1- Pilas de producto

Lista priorizada de requisitos/historias en jerga del cliente.

  • Id
  • Nombre: de 2 a 10 palabras
  • Importancia: más alto = más importante. La importancia la da el product owner.
  • Estimación inicial: la unidad son puntos de historia [PH en adelante] (días/persona ideales). Ojo, no es un contrato ni un compromiso. Las estimaciones absolutas no son importantes, lo son las relativas. P.ej. Una historia con 2 PH debería durar la mitad que una con 4 PH.
  • Cómo probarlo: descripción a alto nivel de cómo testearlo (descripciones simples).
  • Notas: otra info breve.

El product owner se encarga de los objetivos del negocio y no interviene en decisiones técnicas.

Debe existir la pila de producto, con las importancias, antes de empezar el sprint.

Continuar leyendo «Resumen de Scrum desde las trincheras»

Comandos básicos de GIT

git

Ésta seguramente acabará siendo una entrada que iré modificando una y otra vez, ya que lleva en borradores más de un año, y desde entonces, he entrado decenas de veces a editar y a ampliar el contenido.

En fin, git es un sistema de control de versiones open source y distribuido, que cambia el concepto de trabajo de los antiguos sistemas de control de versiones tipo «subversion». Git mantiene una copia completa de todo el repositorio, en cada uno de los ordenadores de trabajo, de tal manera que el programador siempre trabaja en local con su copia completa, lo cual le permite trabajar sin conexión o desde cualquier PC con acceso al repositorio de git (lo cual le permitiría clonar de nuevo el repositorio y continuar trabajando en local en el nuevo PC).

Si estás empezando con git, mírate bitbucket, que quizá te interese, y planteate usar algún cliente Git, como SourceTree. Si eres más de Linux y terminal, entonces quizá ésto te interese.

Git clone

Para copiar en local el repositorio entero de git, bastará con ejecutar git clone, seguido del fichero git con el repositorio a clonar. Por ejemplo:

[root@adripc]# git clone https://[email protected]/miproyecto/mirepo.git

El git clone, habitualmente, creará en el directorio local en el que estamos ubicados, un nuevo directorio que contendrá todo el árbol con el repositorio git. Hará un clonado en local, en toda regla. También podemos usar git clone para clonar nuestro repositorio local a un segundo repositorio local.

Continuar leyendo «Comandos básicos de GIT»

Crystal Reports e impresión en A4

sawing

Desde hace tiempo, trabajamos con Crystal Reports para generar informes con datos de bases de datos SQL Server. Por defecto, este tipo de aplicaciones, como Crystal Reports, al parecer ajustan la vista tanto de diseño como de previsualización, al área definida en la impresora predeterminada configurada en el PC desde el que se trabaja. Es decir, si estamos trabajando con un ordenador que tiene configurada una impresora predeterminada, configurada a su vez para imprimir por defecto en A3, esto afectará directamente a Crystal Reports, que por defecto nos mostrará un área de diseño y previsualización, también de tamaño A3.

Alguna vez nos hemos encontrado, que la vista de diseño del informe ha resultado ocupar un área de impresión mayor que la definida en la impresora predeterminada, y hemos necesitado cambiar la impresora predeterminada por algún programa como PDF Creator, con el área de impresión definida para nuestras necesidades.

El problema, es que cuando desde Crystal Reports se exporta a PDF el resultado del informe, se imprime con el tamaño definido en la impresora, que a su vez, hemos adaptado para que tenga un tamaño “no estándar”. Esto se puede solucionar, usando un programa gratuito, como PDF-XChange Viewer, que permite imprimir sobre PDF seleccionando la opción de escalado “Organizar las páginas largas”, la cual parte el fichero PDF original adaptándolo al tamaño de impresión, permitiendo imprimir, por ejemplo el fichero en varias páginas A4.

Seguramente habrá formas más sencillas de hacer este proceso. Si es así, no te cortes y propónlas 😉

Flickr! Foto por Bitterjug

Ocupado

Hace unos días leí un post con mi Google Reader que me llegó vía el gran Xavi , el cual describe a la perfección el porqué no he podido actualizar el blog estas últimas semanas.

Un saludo.