Como convertir imagenes webp a png usando la linea de comandos

El formato webp, es el “nuevo” formato de google para compresion de imagenes sin perdida ideal para internet. Una misma imagen en webp ( 94k ) y en png ( 1.1 M ).

Sin embargo,  no todas las aplicaciones de linux ( o windows o mac ) estan preparadas para trabajar con este formato. Asi que para poder usarlas fuera del navegador deberemos convertirlas.

En linux existe una herramiento webp que vamos a instalar

sudo apt install webp

Y ahora podemos hacer la conversion con el siguiente comando

dwebp <imagen.webp>  -o <imagen.png>

Por si acaso, tambien podemos hacer el camino inverso. Hacer la conversion al nuevo formato webp usando el comando

cwebp <imagen.png> -o <imagen.webp>

Yo ya tengo varios proyectos web y mobiles donde valdria la pena usarla.

Docker Compose Build Image

En la configuración de tu archivo docker-compose.yml, puedes definir si quieres descargar una imagen del dockerhub o si prefieres construirla tu mismo usando el archivo dockerfile de tu proyecto.

Sin embargo, tambien puedes usar las dos instrucciones al mismo tiempo:

build: .
image: testing:prod

En este caso, docker-compose usara el comando build para construir la imagen, pero le pondra el nombre indicado en image 😀

DU Ordenado

Uno de mis comandos favoritos es

du -hs *

el cual me permite conocer los directorios y la cantidad de Gigas que ocupan. Sin embargo, en una lista larga de archivos estos suelen venir desordenados. Y aunque se puede concatenar con el comando sort, al tener estos registros un sufijo ( K, M, G ) suele ser inservible utilizar el comando sort.

Sin embargo, hoy descubri un parametro de sort ( -h ) el cual le permite entender los sufijos. Ahora si tengo una lista de 50 directorios, perfectamente ordenados por tamaño.

du -hs * | sort -h

Como personalizar el login de Drupal, SimpleLogin

El login de Drupal /user/login, suele ser una pagina poco retocada en la mayoria de los sitios drupal. Principalmente, porque no hay un suggestion file para personalizarla ( aunque se puede crear uno, pero hay que indicarlo en el archivo template.php )

Por ejemplo,

function your_themename_theme() {
$items = array();
// create custom user-login.tpl.php
$items[‘user_login’] = array(
‘render element’ => ‘form’,
‘path’ => drupal_get_path(‘theme’, ‘your_themename’) . ‘/templates’,
‘template’ => ‘user-login’,
‘preprocess functions’ => array(
‘your_themename_preprocess_user_login’
),
);
return $items;
}

En este caso, ya podemos crear un archivo llamado user-login.tpl.php en nuestra carpeta templates.

Sin embargo, tambien existe un modulo que nos permite configurarlo de una forma mas plugandplay. Este modulo para personalizar el login de drupal se llama simplelogin.

SimpleLogin, nos permite manejar un login ( bastante simple ) pero mucho mas estetico que el login por defecto que trae drupal

Su configuracion es bastante sencilla. Nos permite definir si queremos un background de fondo, asi como incluir algunos CSS especificos para el login.

 

Como apagar los monitores cuando se activa el screensaver en KDE

Ahora que soy usuario de KDE, tengo un pequeño inconveniente. Cuando se activa el screensaver mis monitores no se apagan.  Y la verdad tener 4 monitores prendidos cuando no los estoy usando … pues no ayuda mucho a ahorrar energia.

Para solucionarlo, usaremos el comando xset

xset dpms force off

Este comando apaga todos mis monitores. Ahora debemos asegurarnos que este comando se ejecute ( preferentemente de forma automatica ) cada vez que se inicia el screensaver.

Para eso, nos vamos a Settings => Notifications y seleccionamos la opcion Event Souce: Screen Saver

Una vez ahi, activamos la opcion Run Command e ingresamos el comando de apagar pantalla. En este caso, le doy una espera de 2 segundos antes de apagar las pantallas y listo … ahora tus monitores no se quedaran prendidos gastando energia cuando esta activo el screensaver.

 

Como ocultar archivos *.pyc en Visual Studio Code

Cuando estoy desarrollando un proyecto en python/django a veces es muy fastidioso tener en la lista de archivos fuente del proyecto a los archivos .pyc

Los archivos *.pyc son los binarios precompilados de python y no sirven para la editar el codigo. Asi que lo mejor es ocultarlos del sidebar.

Para lograrlo debes ir al menu File -> Preferences -> Settings

Y buscar la opcion “exclude”. Ahi debemos agregar el filtro **/*.pyc para ocultar dichos archivos.

Como cambiar la zona horaria desde el terminal

Si necesitas cambiar la zona horaria de tu computadora o servidor puedes hacerlo de la linea de comandos o terminal.

Para tal efecto existe el comando timedatectl.

Podemos consultar la zona horaria actual

$ timedatectl status

Este mismo comando nos sirve para cambiar nuestra zona horaria:

$ sudo timedatectl set-timezone America/Lima

Si deseas consultar la lista de zonas horarias que existentes:

$ timedatectl list-timezones

 

GIT y GIT Flow

Al trabajar con cualquier tipo de proyecto de software tenemos que resolver problemas como el guardar un backup de tu codigo, asi evitamos que una falla en disco eche a perder nuestro trabajo. Pero que sucede si en el proyecto de software que estamos trabajando llegamos a un callejon sin salida y tenemos que probar una solucion nueva ? Entonces, tendriamos que guardar muchos backups para poder volver a una version anterior. Y que sucede si creamos una copia del proyecto para una funcionalidad experimental como hacemos para integrar esas funcionalidades con la version de produccion ( sobre todo si ha seguido trabajando en paralelo en la version de produccion ). Como gestionamos que varias personas trabajen cada uno sobre una funcionalidad diferente y al final de cada una juntarlas para que funcionen adecuadamente ? Y si al momento de trabajar sobre una caracteristica nueva descubrimos algun problema en la version de produccion ? como volvemos a esa version antigua ? Y si usamos un codigo de backup como integramos esos cambios para no perderlos en la nueva funcionalidad ? Debemos volver a escribirlos ?

Para solucionar todos esos problemas ( y algunos mas ) existe GIT. Git es un sistema de control de versiones de codigo. Que nos permite volver a cualquier version del sistema.

Sin embargo, GIT es muy flexible permitiendonos trabajar en la forma que querramos. Tanta flexibilidad no es muy buena para proyectos y equipos grandes o desarrolladores novatos. Incluso para desarrolladores senior, el desorden puede causar problemas en el proyecto.

GIT FLOW es un flujo de trabajo ( recomendaciones a seguir ) para proyectos en GIT que nos permite usar herramientas simples para automatizar y organizar el trabajo usando GIT.

GIT FLOW nos indica que en todo proyecto debe existir una rama master que sera la encargada de contener el codigo de produccion y una rama develop que mantendra el codigo de desarrollo. Asi como algunas ramas auxiliares: feature, para las nuevas caracteristicas o funcionalidades del sistema, release, para preparar los cambios antes de pasarlos a produccion, y hotfix, para corregir rapidamente los bugs que se pudieran encontran en produccion.

Al iniciar un proyecto con GIT FLOW debemos iniciar la configuracion con el comando

git flow init -d

Este comando no realizara ningun cambio en tu codigo o ramas de GIT. Solo servira para configurar incialmente el proyecto.

Al ejecutar el comando, se crearan ( sino existen previamente ) las ramas master y develop. Las cuales seran usadas para contener el codigo del proyecto en produccion y el codigo del proyecto en desarrollo respectivamente.

Luego, cualquier nueva funcionalidad ( historia de usuario, caso de uso, tarea ) que queramos implementar crearemos una rama con el comando

git flow feature start <nombre de la historia>

En ese momento GIT FLOW, creara una copia del codigo de la rama develop y lo pondra en una rama feature/<nombre de la historia> donde se podra realizar los cambios necesarios. Si al final la caracteristica es desechada ( ya sea porque el codigo no funciono como se esperaba, o se prefiero no desarrollar al final esa historia ) podra eliminarse simplemente borrando la rama sin comprometer el resto del codigo

git branch -d <nombre de la historia>

Una vez termina la historia, para integrarla al resto del codigo simplemente debemos cerrar el feature.

git flow feature finish <nombre de la historia>

Al ejecutar este codigo, GIT FLOW hara un merge de la rama feature con el codigo que esta en develop y luego procedera a borrar la rama feature. En este punto si empiezas a trabajar con otra historia, al crear el feature usara el nuevo codigo en develop.

Al final del sprint cuando ya necesitar pasar todo el codigo funcionando a produccion, deberemos crear una rama release. Donde nos aseguraremos que todo este funcionando correctamente y podremos hacer los ultimos ajustes

git flow release start <version codigo>

Aca podremos hacer cambios, guardarlos en git con nuevos commits y cuando ya este todo listo indicarle a GIT FLOW que debe pasarlo ahora si a produccion.

git flow release finish <version codigo>

En este punto GIT FLOW, integra los cambios de la rama release a develop ( para que los nuevos desarrollos tengan esos ajustes ) y a master ( para hacer el pase a produccion ) y luego borra la rama release

Si en cualquier momento se detecta un bug en produccion ( puedes estar trabajando en otro feature o inclusive estar haciendo los ajustes para un release ) puedes crear una rama hotfix para hacer cambios sobre el codigo que esta actualmente en produccion.

git flow hotfix start <version codigo – numero correccion>

Una vez terminados los cambios se cierra la rama hotfix

git flow hotfix finish  <version codigo – numero correccion>

Ahi los cambios hechos en el hotfix, se copian a master para actualizar produccion y a develop para tenerlos disponibles para el desarrollo posterior.

PD: GIT FLOW es una herramienta agnostica, lo puedes usar tanto en github, en gitlab, o en tus propios repositorios de GIT.

PD2: si usas tus propios repositorios de GIT y aun no has visto el tema de permisos y seguridad, te recomiendo gitolite.