development on /var/blog/jasamitier

Capturando URLs mediante expresiones regulares fáciles

Sat, 18 Feb 2017 15:40:24 +0600

Esta semana, hemos migrado un proyecto bastante grande a https. Es un proyecto implantado en varios países, de modo que tenemos que gestionar bastantes traducciones. En esta entrada me gustaría contar la forma que se me ocurrió para modificar todas las URLs contenidas en los textos de las traducciones para cambiarles el http por el https. Normalmente, con redirigir las peticiones http a https bastaría, pero como en muchas páginas y comunicaciones para los usuarios se pintan estas urls con el protocolo, necesitábamos cambiarlo ahí también.

Esta es la forma que yo ideé, pero no significa que sea la mejor. Mis conocimientos sobre expresiones regulares son todavía muy limitados y seguramente esto se pueda hacer en un sólo paso y de una forma mejor. Si estás leyendo esto y se te ocurre, no dudes en comentármelo.

Primero tenemos que capturar únicamente las URLs que nos interesan, de modo que tendremos que contrastar el texto de la traducción contra la siguiente expresión:

(http://)(www\.)?(proyecto1\.|proyecto2\.).\S+

El significado de cada grupo es:

(http://): que empiece por ‘http://’
(www\.)?: a continuación puede seguir o no por ‘www.’. El ? hace que el grupo a su izquierda sea opcional.
(proyecto1\.|proyecto2\.): el nombre de dominio, independientemente de su extensión debe ser ‘proyecto1’ o ‘proyecto2’
.\S+: Se dejará de capturar la coincidencia en cuanto haya un espacio

De modo que, de la siguiente lista, nos capturará únicamente lo que está en negrita:

http://www.proyecto1.com
http://www.proyecto2.pt/prueba esto es una prueba
http://www.proyecto3.hk
http://proyecto1.fr/hola que tal
http://www.proyecto3.im
http://proyecto2.it/

Ya tendríamos todas las URLs completas que coinciden con nuestro patrón, pero aquí me encontré un problema: no todos los sites tenían que tener https. Esa información la tengo para cada site en base de datos y cacheada en disco. Entonces lo siguiente que tuve que hacer fue buscar por URL en la base de datos para ver si cambiaba a https esa url o no. Para esto comparé las URLs resultantes de la expresión regular anterior, con esta:

(http://)(www\.)?(proyecto1\.|proyecto2\.).*(?=\/)

.*(?=\/): hace que siga desde el grupo anterior hasta el final pero se pare justo antes de la ‘/’. Para usar esto nos tendremos que asegurar que todas nuestras coincidencias anteriores terminen así.

http://www.proyecto1.com/
http://www.proyecto2.pt/prueba esto es una prueba
http://proyecto1.fr/hola que tal
http://proyecto2.it/

Estos ya son los resultados que yo necesitaba para cambiar dinámicamente el texto de las traducciones y que se pinten con el protocolo correcto en el html.

Más que un how to, mi intención con esta entrada es hacer ver que las expresiones regulares no son tan complicadas. Hace un par de meses no tenía ni idea, pero haciendo probatinas en el buscador de mi editor, fui aprendiendo bastantes cosas.

Algunos trucos git en la terminal

Wed, 25 Jan 2017 15:40:24 +0600

El otro día enseñé a Jorge un par de funciones de mi .zshrc que me facilitan la vida gestionando repositorios git desde la terminal y le gustaron bastante. He pensado que igual también resultan interesantes por aquí.

Cómo generar un .gitignore automáticamente

function gi() {
curl -L -s https://www.gitignore.io/api/$@ >> .gitignore;
}

de esta forma se puede ejecutar gi vagrant java intelliJ para descargar el .gitignore resultado de esa búsqueda en Gitignore.io

Cómo listar todos los repositorios (con sus respectivas ramas actuales) presentes en un directorio


function gls() {
for d in *; do
if [[ -d "$d" && -e "$d/.git" ]]; then
echo "$d -> $(cd "$d" && git_prompt_info | sed 's/%//g;s/{//g;s/}//g')"
fi
done
}

En uno de los proyectos en los que me encuentro tenemos que trabajar con varios módulos, cada uno de los cuales está en un repositorio git distonto. Muchas veces necesitaba poder saber de un vistazo en qué rama estaba cada uno de estos módulos. Se ve así:

~/.vim/plugged
▶ gls
YouCompleteMe -> master ✔
csapprox -> master ✔
ctrlp.vim -> master ✔
ferret -> master ✔
goyo.vim -> master ✔
jshint.vim -> master ✗
nerdcommenter -> master ✔
nerdtree -> master ✔
plaintasks.vim -> master ✗
tagbar -> master ✔
vim-airline -> master ✔
vim-airline-themes -> master ✔
vim-colorschemes -> master ✔
vim-fugitive -> master ✔
vim-gitgutter -> master ✔
vim-hybrid-material -> master ✔
vim-javascript -> master ✔
vim-jsx -> master ✔
vim-sensible -> master ✔
vim-strip-trailing-whitespaces -> master ✔

Requisito: la función git_prompt_info del plugin git de ohmyzsh

Cómo hacer git pull a sus ramas actuales en todos los repositorios dentro de un directorio

function gupd() {
current_directory=$PWD
for d in *; do
if [[ -d "$d" && -e "$d/.git" ]]; then
cd $d
echo "$d -> $(git_prompt_info | sed 's/%//g;s/{//g;s/}//g')"
git fetch
git pull origin $(git_current_branch)
cd $current_directory
fi
done
}

Por lo mismo que he contado en el punto anterior, a veces necesito bajarme los cambios de unos cuantos repositorios, para lo cual esta función me resulta muy cómoda. Además de listar los repositorios, también los actualiza. Evidentemente para poder hacer esto no puedo tener cambios sin commitear en ninguno de los repositorios.

Requisito: las funciones git_current_branch y git_prompt_info del plugin git de ohmyzsh

Estoy seguro de que puede hacerse mejor, por lo que cualquier comentario o idea será bien recibida :)

Cómo uso la terminal

Sat, 21 Jan 2017 23:00:00 +0000

En el trabajo, las dos aplicaciones en las que más centro mi atención son la terminal, donde hago cosas, y el navegador, donde las pruebo. No me gusta usas demasiadas aplicaciones porque eso me supone tener que aprender configuraciones y formas de trabajar que realmente no aportan demasiado. Además, como en el trabajo uso Mac OS y en casa Ubuntu, es un lío tener que usar distintas aplicaciones para lo mismo solo porque no estén en un sistema operativo u otro. En esta entrada me gustaría describir cómo y por qué uso la terminal.

Primero decir que las dos máquinas donde trabajo son:

Mountain Nickel 13", corriendo Ubuntu 16.04 “Xenial Xerus”, mi portátil personal.
MacBook Pro 13" Retina (2015) corriendo Mac OS 10.11 “El Capitán”, mi portátil corporativo

Ambas máquinas disponen de terminales *nix, que desde mi punto de vista es la terminal ideal para un desarrollador. A partir de aquí, intento que el funcionamiento de ambas terminales (y todo el software que corro en ellas) sea lo más similar posible. Además de las herramientas que proporcionan out of the box, yo también incluyo:

Zsh: shell alternativa a bash que tiene algunos detalles muy útiles para los que usamos mucho la terminal. En la presentación Why Zsh is Cooler than your Shell se pueden ver alguna de estas ventajas.
Oh My ZSH: conjunto de configuraciones y plugins construidas alrededor de zsh. Es algo pesada, pero aporta configuraciones muy convenientes con solo un par de clicks.
Vim: Editor de texto extremadamente configurable y eficiente. Lo uso para ~~todo~~ casi todo (vale, para proyectos Java empleo IntelliJ IDEA).
Tmux: Multiplexador de la terminal que además permite crear sesiones accesibles por ssh. Es ideal para hacer pair programming.
The Silver Searcher: Una herramienta para buscar texto alternativa a grep. Es muy muy muy rápida y sencilla de utilizar. La empleo para buscar y reemplazar código de forma masiva. Un must clarísimo.
Git: El sistema de control de versiones distribuído que uso para todos los proyectos, tanto profesionales como personales. Además de eficiente, también tiene un cli que permite hacer todo en la terminal fácilmente. Dejo por aquí la configuración que uso normalmente.

Estas son las herramientas que yo añado, pero uso muchas otras que me provee el sistema, algunas de ellas:

tail
find
grep
sed
curl
ssh
top
ps

Creo que no me dejo nada.

Nestor suele decir que él no usa un IDE, porque unix es su IDE. Un entorno de desarrollo integrado es una aplicación que agrupa un montón de herramientas (de búsqueda, refactoring, edicion de texto, linters…) que usar conjuntamente para desarrollar software. Unix provee muchas herramientas que si se saben usar a la vez, hacen que no necesites un IDE concreto. Por ejemplo, así es como reemplazo texto masivamente, sin usar el reemplazar de ningún IDE.

ag miVar ~/Development/miProyecto/ -l | xargs sed -i 's/miVar/miNuevaVar/g'

Con ag -l listo todos los ficheros donde encuentro la ocurrencia buscada. Con xargs, le paso este listado a sed, el editor de texto en memoria de unix, al que también le paso la orden de reemplazar la ocurrencia por la nueva palabra a todo el fichero. Lo que gano con esto es:

Trabajar en una sola herramienta, la terminal.
Mantener una configuración sencilla de mantener.
Tener una forma de trabajo portable en cualquier momento a otra máquina.

Docker en proyectos Java (I). Cómo desplegar una aplicación Java en tomcat usando Docker

Sat, 14 Jan 2017 23:00:00 +0000

De todas las cosas que aprendí en 2016, la que más ha cambiado mi día a día ha sido Docker y, sobretodo, la capacidad orquestación con Docker Compose. La orquestación de máquinas es algo que ya me llamó la atención durante mi paso por [Senpai Devs](http://senpaidevs.com), cuando [Néstor](http://nestorsalceda.com) nos enseñaba las virguerías que era capaz de hacer para montar diferentes entornos. Esta pretende ser la primera de las entradas sobre cómo monté mi entorno de desarrollo (Java EE + Elastic + Apache + tomcat + SQL Server) completamente sobre Docker. Empezaremos por tomcat.

[Apache tomcat](http://tomcat.apache.org) es el contenedor de servlets mas común a la hora de desplegar aplicaciones Java. Es ligero, no demasiado complejo de configurar y está delante de una comunidad enorme de desarrolladores. Además es software libre, lo cual también es importante.

Antes de empezar la fiesta, hay que tener claro que no estamos levantando máquinas, sino aplicaciones. Si necesitamos levantar 3 aplicaciones java, entonces levantaremos tres tomcats, cada uno en su propio contenedor, con su propia configuración etc. Si una aplicación falla, paramos esa aplicación, dejando las demás funcionando. Es por esto que vamos a usar Docker Compose. Para una sola aplicación no sería necesario, ya que con un `docker run` podríamos tenerla levantada con un comando, pero la idea de esta serie de entradas es mostrar cómo levanto todo mi entorno de desarrollo, para lo cual si es necesaria la orquestación.

Esto es lo que vamos a hacer:

- Crear un fichero de orquestación (`docker-compose.yml`) en el que estableceremos las aplicaciones que vamos a levantar (en este caso solo una llamada portal) y también cómo se construye esa aplicación (en este caso haremos que la construya con el fichero `Dockerfile` dentro del directorio `tomcat`).

- Asociar los puertos del contenedor con los de nuestra máquina. El puerto 8080, el de aplicación, lo asociaremos al 3000, y el puerto 8000, el que usaremos para poder debuggar la ejecución del tomcat, lo asociaremos al 4000.

- Establecer variables de entorno de nuestra aplicación: Le diremos que use 2Gb de ram.

Además, configuraremos el tomcat para que:

- Utilice la imagen [tomcat:7.0.73-jre7-alpine](https://github.com/docker-library/tomcat/blob/1651e929e7d4c9785b602cb93cdd2503573c3834/7/jre7-alpine/Dockerfile)

- Abra puerto de debug en el 8000

- Lea la configuración de la carpeta `conf` dentro del directorio `tomcat`

Necesitamos un fichero `docker-compose.yml` que contenga lo siguiente:

```

version: ‘2’

services:

portal:

build: tomcat/.
volumes:
- ./tomcat/conf:/usr/local/tomcat/conf
- ./webapps_portal:/usr/local/tomcat/webapps
environment:
- 'JAVA_OPTS=-Xmx2g'
ports:
- 4000:8000
- 3000:8080

```

Además necesitaremos un directorio `tomcat` con el siguiente fichero:

- `Dockerfile`:

```

FROM tomcat:7.0.73-jre7-alpine

ENV JPDA_ADDRESS=8000

ENV JPDA_TRANSPORT=dt_socket

VOLUME ["/usr/local/tomcat/conf"]

VOLUME ["/usr/local/tomcat/webapps"]

EXPOSE 8009

EXPOSE 8000

CMD [“catalina.sh”, “jpda”, “run”]

```

y el directorio `conf` del tomcat, donde podremos modificar la configuración del tomcat (context, logging…). Además, en el directorio principal necesitaremos también el directorio `webapps_portal`, donde dejaremos el war que desplegará el tomcat.

La estructura queda así:

```

├── docker_compose.yml

├── tomcat

│ ├── Dockerfile

│ └── conf

└── webapps_portal

```

Ahora solo nos queda levantarlo con `docker-compose up –build -d` (El `–build` solo lo necesitaremos la primera vez que lo levantemos, o cuando hagamos cambios en la configuración).

En la siguiente entrada veremos cómo meterle un apache por delante para poder decidir qué peticiones del apache van al tomcat y cuáles no.