El único problema que tengo con GitHub es que en su versión gratuita todos los repos tienen que ser públicos. Si queremos tener repositorios privados tenemos que pasar por caja, y creo que son unos 7$ al mes, que me parece cojonudo, pero en mi caso necesito minimizar al máximo el coste de mis sistemas, principalmente porque no me da dinero.

Así que estuve investigando que alternativas tenia para instalar un servidor de Git privado. Lo primero que me vino a la cabeza fue GitLab, porque lo he utilizado durante una buena temporada en el trabajo con equipos relativamente grandes y nos ha dado muy buen resultado. En mi actual empresa estamos usando Bitbucket de Atlasian, y prácticamente es lo mismo que teníamos con GitLab, pero al ser de pago no es una opción para mi.

Así que después de dar algunas vueltas e investigar un poco, acabé encontrando Gogs:

https://gogs.io/

Gogs logo

Usando Drush podemos actualizar nuestro sitio Drupal tranquilamente desde la línea de comandos. El comando es:

drush pm-update

O podemos usar su alias, mas cómodo.

drush up

Drush en este caso va a hacer unas cuantas cosas:

  • Actualizar core de Drupal, descargando los archivos necesarios de la última versión.
  • Actualizar todos los módulos contrib a su ultima versión, descargando sus archivos.
  • Ejecutar los cambios de base de datos pendientes de todos los módulos actualizados.

A partir de aquí, tenemos varias opciones que nos permitirán hacer estas tareas por separado. Vamos a ver las mas comunes.

Con las últimas actualizaciones el indexador de Baloo se esta volviendo loco y se lleva la CPU como un salvaje.

Como no se puede desactivar con un servicio o por medio del /etc/init.d, y no quería que siguiese activo, he estado buscando como desactivarlo. Al final lo que he hecho es editar el fichero de configuración

$HOME/.kde/share/config/baloofilerc

y añadir esto:

Indexing-Enabled=false

Después maté el proceso baloo_file_extractor con un kill y se acabó el problema.

En este hilo de los foros de Ubuntu teneis mas info.

 

Primero vamos a probar la versión rápida y sencilla, que es con el paquete de Debian, que instalamos como root:

# apt-get install node-less

Esto nos instalará el paquete principal de node.js y el compilador de less.

IOWait es la medida del tiempo que los procesos de la CPU pasan sin hacer nada, en espera de poder hacer una operación de IO, es decir, leer o escribir en el disco.

Generalmente es un indicador claro de un cuello de botella en el sistema, y se produce cuando alguno de los discos (o todos) no dan a basto con operaciones de lectura y/o escritura.

Los síntomas suelen ser bastante claros, en forma de bajada general de rendimiento, largas esperas, etc.

La forma más sencilla y estándar de comprobar la carga de iowait que tenemos es usar el comando top, que tenemos disponible en cualquier sistema GNU / Linux, y en muchos casos no es necesario ni siquiera tener permisos de root. En la primera parte de la salida del top es donde tenemos esta información en la línea de %Cpu(s), marcada como wa.

Los organizadores de la DrupalCamp 2014 en la que tuve la oportunidad de dar una charla han colgado todos los videos de las conferencias en Vimeo.

Este es el enlace de mi charla:

http://vimeo.com/98215221

Y aquí podeis ver todos los vídeos:

http://vimeo.com/channels/drupalcampspain2014

Merece la pena perder un poco el rato si estás metido en esto del Drupal, hay verdaderos cracks de ponentes.

Este año tengo el placer de poder dar una conferencia en la Drupalcamp de Valencia el dia 17 de mayo, a las 10 de la mañana.

Será un placer veros por alli a los que podais asistir. De momento, para ir abriendo boca, dejo aquí un enlace a la presentación que utilizaré para dar la charla.

http://carloscarrascal.com/drupalcamp2014/

También teneis todo el código de la prensentación empaquetado en unas features que podeis bajar de mi repositorio de GitHub:

Podemos modificar los datos de un usuario por codigo usando las funciones de la API de Drupal, user_load y user_save.

$edit = array();
$user = user_load($uid);

$edit['field_nombre_del_campo']['und'][0]['value'] = "nuevo valor que yo quiera";


user_save($user, $edit);

De esta forma realizamos todos los cambios que necesitemos en una estructura aparte ($edit), sin tocar el objeto $user original, lo que nos permitirá realizar cuantas comprobaciones y validaciones necesitemos sobre el valor original de los campos, y realizar todos los cambios al final de una vez.

En la documentación original de la función esta explicado, y teneis unos cuantos comentarios útiles sobre su uso, eso si, en inglés.

https://api.drupal.org/api/function/user_save/7

Con los años mi colección de mp3 no para de crecer, hace años que no utilizo otro soporte para la música, pero como las fuentes son muy variadas, siempre hay cambios de volumen entre las distintas canciones cuando uno esta reproduciendo distintos álbumes o artistas. Esto es especialmente molesto en el coche, o a las tres de la mañana, susto incluido.

Hace tiempo descubrí una herramienta para normalizar el volumen de audio en los mp3, que me viene funcionando de maravilla, llamada mp3gain.

Cuando hablamos de Drupal, el espectro de productos desarrollados con el es amplísimo. Me refiero a que podemos encontrar desde pequeños portales montados con lo justo y desplegados en un pequeño servidor, hasta completos sites empresariales con varios nodos frontales, balaceadores de carga, cluster de bases de datos, etc.

Normalmente en proyectos grandes se dispone de copias de seguridad de ficheros y bases de datos, por cuenta de los chicos de sistemas, pero este tipo de backups suelen ser complicados de restaurar, por afectar a mas componentes del sistema opertivo ademas de nuestro querido Drupal que se nos acaba de romper. Además, muchas veces ni siquiera pueden ser restaurados por el equipo de desarrollo, con lo que en la práctica no suele ser recomendable fiarnos solo de este tipo de respaldos.

Si queremos estar tranquilos, lo mejor es verlo de esta manera: hoy en día, el espacio en disco es barato.