10 razones por las que “el compilador” debería ser “la compiladora”

1. Bastante susceptibles a mostrar avisos.
2. Escuchan lo que dices, pero no lo que tratas de decir.
3. Cuando notas algo erróneo y les preguntas qué anda mal, casi siempre responden: “Nada”.
4. En otras ocasiones, pueden reportar sin previo aviso incontables errores a una velocidad alarmante.
5. A menudo pequeñas declaraciones se acaban convirtiendo en trabajos muy complejos.
6. Charlar (smalltalk) se considera importante.
7. Puedes estar haciendo algo que se da por bueno durante años, y de repente es totalmente incorrecto.
8. Te piensas que se van a encargar de sacar la basura, pero al final la tienes que sacar tú.
9. Olvidarte de una regla te puede meter en un lío bastante gordo.
10. Tener la clase y el método apropiado a menudo es la clave del éxito.

(Traducido/inspirado de un anónimo que circula por ahí en inglés)

Firefox 3.0b5 en español en Ubuntu Hardy Heron (microapunte)

Llevaba unos días buscando donde estaba el dichoso .xpi por fin hoy lo he encontrado, abrirlo, instalarlo, reiniciar el explorador y listo.

Eclipse PDT+XDebug en Hardy Heron 64bits

Estos días he estado probando el sistema Eclipse, y la conclusión final es que es una plataforma interesante, eso sí me ha requerido pasar de 512MB de RAM a 2GB, algo que me parece completamente desmedido para un IDE, pero Java es un devorador de recursos. Bueno el motivo de este artículo es un curioso quick-hack, cómo usar Eclipse PDT (PHP Developer Tools) en sistemas de 64 bits (actualmente estoy usando Ubuntu Hardy Heron Beta). He probado a instalarlo como plugin, pero la instalación siempre me fallaba al no encontrar algunas librerías en formato x64, el caso es que este método es aún más sencillo:

1. Descargar Eclipse edición PDT
   (sólo está para 32 bits)
2. Descargar Eclipse edición Classic (Nos llevará esta vez sí, a la versión para 64 bits. Debe ser la versión 3.3 [Europa], para la versión 1.0.3 de PDT; buscar la versión correspondiente de Eclipse Classic en caso de actualización de PDT)
3. Descomprimir ambas ediciones, y copiar sobreescribiendo los ficheros de la Classic sobre los de la edición PDT.
4. Voilà!

Adicionalmente he instalado XDebug, y funciona bastante bien, breakpoints, vistas de variables, etc, en Hardy por ser beta supongo el paquete venía sin el módulo dentro (había un bug al respecto) por lo que lo he instalado a través de pecl directamente con los siguientes comandos:

• sudo apt-get install php-dev
• sudo pecl install xdebug

Luego en /etc/php5/conf.d/xdebug.ini he puesto esta configuración (supongo que se deberá ajustar el path para otras distribuciones):

# XDEBUG
zend_extension=/usr/lib/php5/20060613/xdebug.so
zend_extension_ts=/usr/lib/php5/20060613/xdebug.so
zend_extension_debug=/usr/lib/php5/20060613/xdebug.so
#xdebug.auto_trace=on
xdebug.remote_enable=1
xdebug.remote_port=9000

Tras comprobar con un fichero de prueba con phpinfo() que se estaba cargando bien el módulo, he seleccionado el perfil de XDebug en Eclipse y, hecho, funcionando.

Aquí una captura:

PD. Aunque ha sido un experimento interesante, en los últimos días he estado muy activo com Vim, y he comprobado que prácticamente todo lo que puedo hacer en este entorno tan exigente de requerimientos, lo puedo hacer igual o mejor en este potentísimo (aunque quizás un poco críptico para novatos) editor, requiriendo tan sólo unos pocos megas de RAM, incluyendo el debugging en PHP, todo esto, ¡sin salir de la terminal!. Pronto una entrada hablando del tema…

…y el premio al editor para programación perfecto es…

… ¡ para un terminal con Vim !

Quien me lo iba a decir, después de tantos años personalizando mi querido Emacs… Llevo unos días estudiando las funcionalidades del editor de moda, Textmate, e integrándolas en mi Emacs, que ya está prácticamente “mimetizado” con muchas nuevas funciones, que iba a explicar por aquí…

El tema es que, a la hora de estudiar el Vi/Vim, me parecía un editor muy eficiente para cambios rápidos en ficheros, pero para emplearlo en sesiones de programación, siempre me había echado para atrás lo de la dualidad de modos y la navegación, que reconozco que esto último no la había terminado de entender hasta hace poco; tras estudiarlo más profundamente en las últimas semanas, y especialmente con un “truco” para este editor que he leído hoy (en realidad es casi una obviedad pero hasta que no te la cuentan no caes en ello como suele pasar),  me he terminado de convencer: al pulsar <Alt> + [tecla] se genera la secuencia <ESC> + [tecla] con lo que no hace falta pulsar <ESC> para pasar de un modo a otro, basta con acompañar con <Alt> el comando que queramos introducir DIRECTAMENTE.. funcionalidad que se pierde, si nos salimos del terminal eso sí…

En fin, nunca te acostarás sin saber una cosa más… fuera sombreros, este editor es una absoluta genialidad.

PD. Esta conclusión sólo es relativa al sistema de navegación y edición en Vim. Tengo que ver ahora si los complementos que existen y la documentación que los acompaña, para lo que yo necesito, están a la altura de Emacs, que en este sentido me parece aún lo mejor que conozco…

Continuando con el sftp

Desde hace un tiempo tengo un slug pegado a mi mesa, este mini-servidor con linux (una vez “unslugeado“) me viene estupendamente, por ejemplo (entre otros muchos usos) para dejar descargando durante días grandes backups de mis servidores, un problema que ha veces he tenido que afrontar es el corte de una transferencia sftp, para continuar con la transferencia, ya que sftp no contempla retomar la descarga en un punto extacto, la utilidad rsync viene en nuestra ayuda (que debe estar instalada tanto en el servidor como en el cliente):

# nohup rsync --partial --progress \
  --rsh=ssh usuario@servidor:directorio/fichero_remoto fichero_local & > fichero_info_salida

Notas:

1. Se requiere especificar el fichero local
2. nohup es una utilidad aparte que evita que un comando se corte al abandonar nuestra sesión en el slug.

Si tenemos que introducir contraseña, para dejar el proceso en segundo plano no poner el umpersand (&), tras escribir nuestra clave, pulsar Control+Z y luego introducir la orden:

# bg %[número de trabajo, se ve el número con el comando jobs]

Fuente: ubuntuforums.org