Escogiendo control de versiones (bzr, git, hg)

Es una elección difícil. Por suerte o por desgracia he usado los 3 últimamente, así que ahí van mis impresiones:

Bazaar

Empezaré por él porque es el que menos me ha gustado, y porque está muriendo, así que no lo recomendaría para proyectos nuevos.

Está muy bien que viene muy integrado con su GUI Bazaar Explorer, que si bien no es la mejor, es más intuitiva que la línea de comandos.

El principal problema que le he visto es que es muy lento al trabajar en red, al menos al usar Launchpad, que de por sí es la menos intuitivo de las plataformas online de desarrollo que he probado. También la metainformación de los repositorios tiende a ocupar más con Bazaar que con los demás.

Otro problema es que al iniciarte con él te da tantas opciones para organizarte las ramas de tu repositorio, que acabas mareándote… aunque a decir verdad esto pasa con todos al principio.

Git

Sin duda es el más popular de todos, aunque para mí ocupa el 2º puesto. Es el sistema que desarrolla y utiliza la Linux Foundation, con lo cual queda garantizada su eficiencia.

Es muy rápido, y tiene tantísimos comandos para tantísimas cosas que va a ser casi imposible que te falte uno para lo que necesitas. Lo malo es que de tanto que tiene se pasa, y para un principiante resulta algo abrumador, sobre todo teniendo en cuenta que te zambulles directamente en la línea de comandos, ya que no tiene una GUI libre multiplataforma decente (hay muchas, y trae una de serie, pero es horrible). Este es quizá el peor punto para mí. Con Bazaar y Mercurial puedes dejar para más tarde lo de la línea de comandos, si es que llegado el caso lo ves necesario.En parte se debe a que está escrito principalmente en C y Bash, lo cual ha hecho que su implementación en Windows haya sido algo complicada (de hecho es un proyecto aparte), y que algunas GUI hayan empezado por simplemente convertir los clicks de botones en comandos de consola, algo un tanto cutre si lo comparas con tener una buena biblioteca a la que llamar. Esto lo están arreglando con libgit2, pero de momento no llega al nivel de Git.Eso sí: tiene un fuerte enfoque en permitirte modificar el historial de cambios, y está presente en algunas plataformas de desarrollo fantásticas, como GitHub o Bitbucket.

Mercurial

Es mi preferido. Para empezar, en cuanto a eficiencia, cabe destacar que Facebook lo utiliza, y según dicen tienen un código más grande que el del propio núcleo de Linux, y han conseguido optimizarlo hasta niveles que Git les hubiera resultado muy difícil debido a su arquitectura. El resto de usuarios nos podemos beneficiar de los más de 500 parches que han contribuido. En definitiva, es rápido, compacto, escalable y extensible.

De hecho, su fuerte énfasis en su extensibilidad lo podemos notar al ver que viene de serie con una serie de plugins desactivados, que al activarlos nos proporcionan herramientas más avanzadas que lo que es el núcleo de funciones principales. Este enfoque me parece el mejor de los tres, ya que hace que la zambullida inicial sea menos dura, pero que no te quedes sin herramientas conforme te van saliendo necesidades más específicas. Por ejemplo, Mercurial no está muy a favor de modificar el historial, pero puede hacerse de diversas formas con extensiones, y ofrece otras alternativas como MQ.

Toda esta extensibilidad y multiplataformidad vienen en parte de haber elegido desde el principio un lenguaje como Python para escribirlo (con algunas extensiones en C), y ello permite lo que para mí es lo mejor de todo: TortoiseHg. Lo siento, me encanta la línea de comandos, pero esta GUI es sencillamente insuperable.

Reflexión final

La verdad es que, preferencias aparte, se trabaja bien con los tres. Si alguno te gusta más, úsalo y ponte a programar, y no te preocupes demasiado por las demás cosas.

Instalar OpenERP 7.0 en Fedora 19/20

Instalar los paquetes necesarios:

# yum install openerp7 openerp7-httpd-fonts-access postgresql-server

Iniciar los servicios hasta el próximo reinicio:

# systemctl start openerp postgresql

Iniciar los servicios automáticamente:

# systemctl enable openerp postgresql

Desactivar el cortafuegos hasta el próximo reinicio (deberías añadir una excepción, pero no lo explicaré aquí):

# systemctl stop firewalld

Activar el usuario necesario de la base de datos:

$ sudo -u postgres createuser --createdb openerp

Navega a http://localhost:8069 y crea tu base de datos desde ahí.

Si necesitas cambiar la configuración:

# nano /etc/openerp/openerp-server.conf
# systemctl restart openerp

Cómo forzar el cierre de todas las sesiones abiertas en OpenERP 7.0

Accede por SSH al servidor de OpenERP y ejecuta:

$ sudo -u openerp bash -c "rm /tmp/oe-sessions-openerp/*"

Gestiona tus sesiones SSH cómodamente

Al principio está bien eso de recordar cada usuario, servidor y contraseña a los que te conectas… hasta que el número empieza a aumentar y la memoria a disminuir.

Claves SSH

El viejo truco para aumentar la seguridad y disminuir la complejidad: la clave privada y la clave pública.

  1. Genera tu juego de claves:
    $ ssh-keygen
  2. Copia tu clave pública al servidor que usas:
    $ ssh-copy-id usuario@servidor
  3. Conéctate sin contraseña de por vida:
    $ ssh usuario@servidor

Bueno, puede que te haya pedido una contraseña, pero es la de desbloqueo de la clave, y normalmente puedes usar agentes que incluyen los entornos de escritorio que te permiten desbloquearla automáticamente el resto de la sesión.

Es importante proteger tu clave privada con contraseña, porque de otro modo cualquier usuario root podría acceder a ella.

Más información:

$ man ssh-keygen
$ man ssh-copy-id

Guarda tus datos de sesión

Puesto que ya te has olvidado de las contraseñas para siempre, tener un fichero de texto plano con el resto de tus datos de acceso no es descabellado. Ese fichero está en ~/.ssh/config y tiene un aspecto similar a este:

Host 11.22.33.44
User holamellamopepito

De modo que la próxima vez que ejecutemos ssh 11.22.33.44 automáticamente usará el usuario holamellamopepito para conectarse. Pero aún puede hacerse mejor:

# Conexión al trabajo
Host trabajo
HostName 11.22.33.44
User holamellamopepito
Port 44444
ForwardX11 yes

# Conexión a casa
Host casa
HostName 44.55.66.77
User pepitoencasa
ForwardX11 yes

Como ves, puedes poner comentarios, y si indicas el servidor como HostName, puedes ponerle una abreviatura en Host, que será la que uses al conectar. El resto de parámetros hasta el siguiente Host se aplicarán automáticamente.

Más información:

$ man ssh_config

Cómo depurar __main__.py

A veces estás escribiendo un módulo Python y quieres que se pueda ejecutar como un script, para lo cual le creas un fichero __main__.py en su directorio raíz.El problema de esto es que te obliga a ejecutarlo siempre como python -m nombremodulo, y muchas veces los depuradores no son capaces de entender eso.

¿Solución? Ejecutar directamente __main__.py. Solo que esto plantea otro problema: que entonces no puedes realizar importaciones relativas.

¿Solución real? Añade siempre este código al principio de tu __main__.py:

import os
import sys
from importlib import import_module

# Emular la ejecución como módulo si se ejecuta como script
if __name__ == '__main__' and __package__ is None:
    parent_dir = os.path.abspath(os.path.dirname(__file__))
    sys.path.append(os.path.dirname(parent_dir))
    __package__ = os.path.basename(parent_dir)
    import_module(__package__)

Con eso consigues que los siguientes dos comandos sean equivalentes. Usa el 2º para depurar:

$ python -m nombremodulo
$ python ./nombremodulo/__main__.py

Corregir error “Server won’t say bye to us” al conectar por NX con Remmina

Conecta al servidor por SSH y elimina estos ficheros:

$ rm /tmp/.X*-lock ~/.Xauthority

Enki: ¿el editor de texto definitivo?

tl;dr: Ir al ganador.

No hace mucho emprendí una cruzada en búsqueda del editor de texto para programación o IDE definitivo. Supongo que todos acabamos haciendo esto alguna vez. Bueno, todos salvo los que nacen atados a Visual Studio y .NET.

Estos eran mis requisitos. No son muchos:

  1. Software libre.
  2. Multiplataforma.
  3. Soporte para todos los lenguajes con los que suelo trabajar.

Hay 3 enfoques diferentes para abordar esto, con sus pros y sus contras:

IDE

Probé Eclipse (mastodonte heterogéneo con un hambre insaciable de RAM), NetBeans (genial pero sin soporte para Python) y jEdit (ligero pero insuficiente), y al final llegué a la conclusión de que están bien, pero su principal error es tratar de abarcar todos los campos. Sencillamente no puedes hacerlo bien todo. Quien mucho abarca poco aprieta.

Ojo, para desarrollo PHP, NetBeans me parece fabuloso. Si tuviera Python, probablemente sería el ganador.

Editores a la vieja usanza

Visto que una solución integral era poco viable, pensé en usar la filosofía Unix: que haga una cosa y la haga bien: “Si quiero control de versiones, debug, etc., puedo hacerlo con otros programas separados especializados. Necesito un buen editor. Vayamos a los clásicos.”

Probé nano (cómodo para cosas rápidas por SSH, pero insuficiente), Vim (no me acostumbro a eso de tener que activar el modo edición) y Emacs (acabas dedicándole más tiempo a tu editor de texto que a editar texto).

Tienen la ventaja de funcionar por SSH bien, pero lamentablemente nací en la era del Ctrl+C y Ctrl+V, y soy muy eficiente con mis queridos atajos de teclado estilo GUI de siempre. Tener que volver a aprender de cero me parecía una tarea costosa y, francamente, insuficientemente remunerada.

Me topé con ErgoEmacs, que es un proyecto que intenta hacer el aterrizaje en Emacs más potable. Me pareció un proyecto estupendo, pero al final acabé dedicando tantísimo tiempo a escribir lisp (un lenguaje horroroso que no me sirve para otra cosa) que me aburrí. Al menos sí me di cuenta de que saber extender tu propio editor es algo muy valioso.

Así que pensé: “probemos con los editores de texto visuales”.

Editores GUI

Probé Gedit, Kate y Notepad++, a cada cual más completo, pero no cumplían demasiado bien mi requisito de ser multiplataforma. Quiero decir que puedes usar versiones de Gedit y Kate en Windows, o Notepad++ con Wine, pero se nota que no fueron creados con esa mentalidad.

Entonces surgió la gran pregunta: ¿No habrá un buen editor de texto, multiplataforma, libre, que soporte muchos lenguajes, que no intente hacer más de lo que puede, que sea extensible… en definitiva, que tenga lo mejor de todas las opciones?

El ganador

De repente encontré Enki. La breve pero sencilla descripción de sus características principales que tenéis en ese enlace me enamoró. La traduzco aquí:

  • Fácil para el usuario. Interfaz intuitiva. Funciona bien sin configurar nada. No necesita leer toneladas de documentación.
  • Fácil para programadores. Programe lo más rápido que pueda. Sin ratón.
  • Ligero. Algunos IDE muestran una pantalla de bienvenida. Enki nunca lo hará. Simplemente arranca rápido.
  • Extensible. Los sistemas operativos están diseñados para ejecutar aplicaciones. Enki está diseñado para ejecutar extensiones.
  • Multiplataforma. Usa tu editor habitual en cualquier sistema operativo. Actualmente se ha probado en Linux, MacOS X y Windows.
  • De alta calidad. No tiene una larga lista de características maravillosas, pero lo que hace, lo hace bien.
  • De código libre. Esta es nuestra religión.

En pocas palabras, exactamente lo que buscaba, y creado expresamente para solucionar mi problema.

Hay que tener en cuenta que es un proyecto muy joven, que carece de una gran comunidad de usuarios o desarrolladores, pero es realmente digno de probar y contribuir, y tiene unas ideas fantásticas. Y si tienes que programarte tus personalizaciones, al menos aquí usas Python.

Corregir error 404 al acceder al panel de administración de Magento después de migrar

Si miras el registro de errores en MAGENTO_ROOT/var/log/system.log verás un error parecido a esto:

ERR (3): Recoverable Error: Argument 1 passed to Mage_Core_Model_Store::setWebsite() must be an instance of Mage_Core_Model_Website, null given, called in /home/website/public_html/app/code/core/Mage/Core/Model/App.php on line 624 and defined in /home/website/public_html/app/code/core/Mage/Core/Model/Store.php on line 304

Si te sucede esto justo después de haber migrado a un nuevo servidor, gracias a Richard Ricketts ahora sé cómo arreglarlo. Abre tu script SQL de migración y ajústalo así:

SET FOREIGN_KEY_CHECKS=0;
SET SQL_MODE=”NO_AUTO_VALUE_ON_ZERO”;

-- Código de importacíon de MySQL aquí.

SET FOREIGN_KEY_CHECKS=1;

Vuelve a ejecutar la migración. ¡Arreglado!

Cómo localizar errores en la configuración de Apache

A veces el servidor HTTP de Apache empieza a lanzarnos errores 403 Forbidden o de otro tipo que a más de uno nos pueden volver locos. Concretamente, este tipo de errores suelen tener que ver con los permisos, pero si no logramos entender dónde está el fallo de los permisos, podemos tener en cuenta dos conceptos básicos:

  1. Apache (y muchos otros servicios) corre como un usuario específico, cuya cuenta suele estar bloqueada.
    • Usuario www-data en Debian y derivados.
    • Usuario apache en RHEL, Fedora y derivados.
  2. Ese usuario necesita acceso a los ficheros como lo necesitaría cualquier otro.

Hazte Apache

Con este simple comando nos convertiremos en Apache, y podremos ejecutar comandos y recorrer los directorios en su nombre, pudiendo dar con los errores de permiso en seguida:

$ sudo su --login --shell /usr/bin/bash apache

Instalar servidor LTSP en CentOS 6

Primero instala EPEL.

Asumo que tienes bien configurada tu tarjeta o tarjetas de red.

Ahora instala el servidor LTSP:

# yum install ltsp-server

Para evitar el error No such file or directory: /etc/sysconfig/firstboot:

# touch /etc/sysconfig/firstboot

Edita el fichero /etc/ltsp/ltsp-server.conf y cambia las líneas LTSP_DEV y LTSP_DEFAULTIP para que coincidan con los datos del servidor.

Crea el chroot para los clientes con:

# ltsp-build-client

Sigue los pasos que te indica. Ten paciencia, tarda un buen rato.

Unificaremos todos los ficheros de configuración en /etc/ltsp/lts.conf haciendo enlaces duros, porque es un rollo tener 3 diferentes y no saber cuál se usa en cada momento:

# rm -f /opt/ltsp/i386/etc/lts.conf
# ln /etc/ltsp/lts.conf /opt/ltsp/i386/etc/lts.conf
# rm -f /var/lib/tftpboot/ltsp/i386/lts.conf
# ln /etc/ltsp/lts.conf /var/lib/tftpboot/ltsp/i386/lts.conf

Seguramente más tarde tendrás que editar /etc/ltsp/lts.conf para configurar el servidor como te plazca, pero al menos solo tendrás que cambiar un fichero.

Usaremos el mismo método para compartir la configuración del teclado entre huésped y anfitrión:

# rm -f /opt/ltsp/i386/etc/sysconfig/keyboard
# ln /etc/sysconfig/keyboard /opt/ltsp/i386/etc/sysconfig/keyboard

Activa los servicios necesarios y desactiva el firewall (se hace todo solito con el siguiente comando):

# ltsp-server-initialize
# ltsp-server-initialize -y

Tal vez preferirías configurar el firewall a mano después, pero por el momento lo dejaremos así.

Si tienes otro servidor DHCP aparte, habrá que desactivar el que acabas de activar con ese comando:

# chkconfig dhcpd off
# chkconfig dhcpd6 off

Además, tendrás que configurar el otro servidor DHCP con estas directivas (asumiendo que el servidor esté en 192.168.0.9 y que usamos arquitectura i386 para los clientes ligeros):

  • 017 Ruta de acceso raíz: 192.168.0.9:/opt/ltsp/i386
  • 066 Nombre de host de servidor de inicio: 192.168.0.9
  • 067 Nombre de archivo de inicio: ltsp/i386/pxelinux.0

Modificamos un poquito el chroot para que no nos salga la pantalla de primer arranque cada vez que iniciemos un cliente ligero:

# ltsp-chroot
# chkconfig firstboot off
# exit

Configura la BIOS de otro ordenador de la red para arrancar por red, o usa una imagen de gPXE, enciéndelo, y a disfrutar de tu cliente ligero.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.