Servicios de desarrollo web, sistemas y usabilidad

Muchas veces tengo dificultades para encontrar la ayuda concreta a la instalación de un nuevo paquete para Ubuntu. Dado que en esta ocasión me ha costado horrores dar con la solución, os paso a explicar, de la forma más sencilla, cómo se instala Oppen Office 3 en español para Ubuntu mediante Consola/Terminal.

1. Desacarga Oppen Office 3.3. desde su sitio oficial en español. Esta es la ruta. Para que te sea más fácil, guarda el paquete en el directorio de Descargas/

2. Abre la consola y vete al directorio en el que te has descargado el paquete. Como hemos quedado, en Descargas/. Escribe esta orden y dale al intro.

 ~$ cd Desacargas/

3. Escribe un ls y otra vez intro. Verás, entre todos los documentos que tengas en el directorio, el siguiente paquete de OpenOffice: OOo_3.3.0_Linux_x86_install-deb_es.tar.gz

4. Descomprime el paquete en el mismo directorio Descargas/. Escribe el siguiente comando e intro.

 ~/Descargas$ tar xvzf OOo_3.3.0_Linux_x86_install-deb_es.tar.gz 

5. Una vez descomprimido, entra en el nuevo directorio llamado OOO330_m20_native_packed-1_es.9567/ mediante un cd. Si haces un ls dentro del directorio, verás que hay una carpeta que dice DBES.

Pues bien, accede a DBES mediante un cd DBES/ y ejecuta la siguiente orden:

 ~/Descargas/OOO330_m20_native_packed-1_es.9567/DEBS$ sudo dpkg -i *.deb 

Despues de pedirte contraseña sudo, comenzará el proceso de descompresión de los paquetes de OpenOffice 3.3.

6. Una vez que se han instalado estos paquetes, debes entrar en el directorio desktop-integration que se encuentra en el directorio en el que te encuentras. Recuerda, DBES/. Entra en el directorio y ejecuta la siguiente orden:

 ~/Descargas/OOO330_m20_native_packed-1_es.9567/DEBS/desktop-integration$ sudo dpkg -i *.deb 

¿Para qué hacemos ésto? Para que la instalación se integre en el escritorio y en el menú Aplicaciones/Oficina te aparezcan los accesos directos a cada una de las aplicaciones.

No hace falta que reinicies el equipo. Prueba que el nuevo OpenOffice te funciona. Y recuerda, es importante, antes de comenzar con la instalación, desinstalar el openoffice de la máquina si es que lo tenías instalado con anterioridad. Para ello ejecuta esta orden en la consola.

 sudo apt-get remove openoffice* 

En bastantes ocasiones me he encontrado con la necesidad de empaquetar código pero excluyendo ciertos ficheros/directorios. Cuando se trata de una exclusión pequeña, con unos pocos ficheros, hago lo siguiente.

$ tar -zcf backup.tar.gz --exclude='fichero1' /home/imedina/code

Cuando se trata de un número mayor, es más cómodo crear un fichero con un listado de todos aquellos ficheros que quieres excluir.

# exclude.txt
fichero1
fichero2
*.jpg

Luego, haces el tar de la siguiente forma.

$ tar -zcf backup.tar.gz -X exclude.txt /home/imedina/code

Es importante recordar que lo que hemos hecho con ficheros, lo puedes hacer igualmente con directorios (puesto que no dejan de ser ficheros).

Si sueles utilizar Apache para tus sitios, estarás acostumbrado a la magnitud de sus procesos: son grandes, muy exigentes con la memoria, y relativamente lentos hasta que son lanzados. Evidentemente, ésto no tiene por qué ser cierto en todos los casos; se puede ajustar bastante para que tenga un comportamiento más liviano, y con el tiempo han ido surgiendo alternativas al modelo tradicional de procesamiento (MPM) que consiguen reducir mucho esos puntos negativos.

Ahora bien, en ocasiones uno quiere o necesita seguir manteniendo Apache en su modo tradicional, en una configuración típica con PHP o Python, por diferentes razones: te puede haber convencido su estabilidad; puede que no quieras sacrificar algunos módulos clásicos (como el mod_rewrite); no encuentras la misma actividad en las comunidades de los servidores alternativos, etc. Nosotros nos hemos visto en esa situación, y hemos encontrado una forma, ya bastante popular, de reducir los aspectos negativos de Apache sin renunciar a sus cosas buenas: utilizar Nginx para servir los contenidos estáticos y dejar Apache para todo lo demás.

Si te animas a probar esta solución (y hay un montón de información en la red para implementarla), te encontrarás con: 1) una reducción sustancial del uso de memoria; 2) un correspondiente aumento de capacidad de cacheo a nivel de disco; 3) mayor consistencia en la separación de las tareas del sistema; 4) un rendimiento más ágil y rápido en el servidor y, por lo tanto, en tu sitio. ¿Se puede pedir más? :)

El tema de los editores/IDEs para trabajar con código sigue siendo algo que levanta discusiones en muchos ambientes de desarrolladores. Hay bastantes ideas preestablecidas al respecto, y nunca dejará de sorprenderme la cantidad de gente que no tiene un gusto formado al respecto, y se contentan con repetir prejuicios manoseados. :(

Mi gusto se apoya en las siguientes cosas (en este orden):

• no quiero esperar para poder tirar código
• no quiero utilizar algo que sea exigente con la máquina
• quiero utilizar casi exclusivamente el teclado
• quiero poder utilizarlo en distintos entornos y máquinas
• mi medio natural es la consola de linux

Durante mucho tiempo estuve utilizando Emacs y Vim indistintamente para diferentes cosas. Según he ido desarrollando cada vez más en PHP, me he decantado del lado de Vim, porque he encontrado más cosas listas para utilizar y una comunidad mucho más viva que en Emacs. Las siguientes son las cosas que hasta el momento he encontrado realmente útiles cuando tiro código en PHP sobre Vim:

Mapeo para correr el fichero que estoy editando a través del intérprete de PHP

Para ésto en el fichero .vimrc tengo lo siguiente:

    :autocmd FileType php noremap  :w!:!/usr/bin/php %

Mapeo para parsear la sintaxis del fichero que estoy editando a través del intérprete de PHP en modo lint

En el fichero .vimrc:

    autocmd FileType php noremap  :!/usr/bin/php -l %

Autocompletar para sintaxis PHP

En el fichero .vimrc:

    autocmd FileType php set omnifunc=phpcomplete#CompletePHP

ManPageView plugin para consultar documentación de PHP en Vim

Un plugin que siempre he encontrado muy útil; te abre un nuevo buffer con la información de lo que hayas consultado. Igual te vale para PHP que para Perl y Python, y su uso es bien sencillo. Por ejemplo, imagina que quieres consultar la documentación para la función explode:

    :Man explode

Sólo tienes que descargarte el plugin, colocarlo en tu directorio de plugins de vim, y tener instalado links (que sueles tener disponible en cualquier repositorio de una distribución de Linux).

FindFile plugin para encontrar nombres de ficheros

Te permite abrir rápidamente un fichero tecleando su nombre. Lo autocompleta y te sugiere las coincidencias. Sólo tienes que descargarte el plugin, colocarlo en tu directorio de plugins de vim, y empezar a trabajar. Lo más cómodo es situarte en el path donde se encuentre tu código y cachear el sistema de ficheros desde ahí para abajo de forma recursiva:

    :FindFileCache .

A partir de ahí puedes invocar el principal comando:

    :FindFile

y empezar a teclear el nombre del fichero. Un nuevo buffer te ofrecerá las coincidencias. Como siempre en vim, puedes organizarte la disposición de los buffers con split y temas similares.

un buen fichero de configuración con indentación, wrap de líneas, mapeos, etc.

Cosas que yo siempre tengo en mi .vimrc:

    " vim as vim
    set nocompatible
    " always syntax on, for an easier life :)
    syntax on
    " load filetype plugins/indent settings
    filetype plugin indent on
    " status line always visible
    set laststatus=2
    " show current position along the bottom
    set ruler
    " highlights things found with the search
    set hlsearch
    " 8 is the magic number, sorry for pythonists :)
    set tabstop=8
    " shows what you are typing as command
    set showcmd
    " incremental search
    set incsearch
    " path for :find
    set path=$PWD/**
    " watch for file changes
    set autoread
    " navigation tabs
    :nmap  :tabnew
    :nmap  :tabclose

Cuando trabajo con Python también lo hago con Vim, aunque Emacs para Python está en una situación bastante mejor que para PHP. Así que en otro post comentaré cómo suelo trabajar con Python sobre Vim.

:Man explode.php

$ pear install doc.php.net/pman

set keywordprg=pman

Cuando trabajas con código y manejas un sistema de control de versiones para gestionar los cambios del primero, pronto te ves tomando decisiones que tienen que ver en definitiva con cómo se va a trabajar a diario. Ésto es especialmente importante en entornos de trabajo con numerosos desarrolladores, y cobra aún más importancia cuando se tiene que manejar un ciclo de vida completo (desde la fase de desarrollo hasta la fase de release/producción).

En Grosshat utilizamos Git de una forma bastante flexible, con la intención de que nos sirva para distintos proyectos, pues hemos ido aprendiendo que realmente un proyecto siempre son varios en cuanto que lo dejas evolucionar un poco. :)

Nuestras dos reglas básicas: 1) no desarrollar en la branch master; 2) no utilizar la branch master más que para mover cambios entre el repositorio externo y las branches locales. En definitiva, mantener la branch master limpia con el fin de evitar futuros conflictos y disgustos.

¿Cómo funcionamos con esas dos reglas? Veamos un ejemplo. Imaginemos que vamos a añadir una función a un repositorio de código basado en WordPress. Esta función va a consistir en evaluar si una página es subpágina de otra (algo muy útil cuando le das uso a WordPress en plan CMS). Utilizaremos el fichero de funciones globales de WordPress para que así podamos utilizarla cómodamente desde cualquiera de los templates. Al lío.

Empezamos desde 0

    $ git checkout master
    $ git pull

Creamos una nueva branch sobre la que trabajar

    $ git checkout -b function_check_child_page

Hacemos todos los commits que hagan falta

En este caso vamos a suponer que tiramos todo el código necesario para la función (no más de 10 líneas) en un mismo commit. Posteriores commits podrían incluir mejoras, limpiezas de código, etc.

    $ git commit -am "Global function is_subpage: returns boolean value
    for checkin if the current page is child of a parent page"

Hacemos merge con la branch master

Podemos empezar por revisar todas las diferencias antes de hacer el merge, de ese modo tenemos otra oportunidad de revisar posibles errores, marcas de debug, etc.

    $ git diff master

Si todo está como queremos, vamos con el merge.

    $ git checkout master
    $ git pull
    $ git checkout function_check_child_page
    $ git rebase master

Esta forma de hacer el merge, mediante rebase, permite mantener una historia continua de cambios.

Push

Una vez que hemos integrado la branch master con nuestra branch de desarrollo, podemos volver a la primera, obtener la segunda y enviar al repositorio externo.

    $ git checkout master
    $ git merge function_check_child_page
    $ git push

Limpiamos la branch

    $ git branch -d function_check_child_page

Todo este flujo de trabajo respeta las 2 reglas que mencionamos al principio, pero también supone algunas otras cosas como las siguientes:

• pequeño mejor que grande (para commits y para merges)
• muchos mejor que pocos (para merges)
• pronto mejor que tarde (para merges)

La principal pega que se le suele plantear a este procedimiento es que da un poco de pereza, y que en entornos pequeños puede resultar algo barroco. Sin duda requiere maś pasos que trabajar directamente sobre la branch master, pero siempre se puede adoptar cuando se juzgue necesario -entran nuevos desarrolladores, hay trabajo a distancia, etc.-, y mientras tanto seguir con la master para todo.

Seguimos con la entrevista a Linus Torvalds. Si no has leído la cuarta entrega, ¿a qué esperas?.

Jim Zemlin: Una de las cosas de las que hablaste fue el incremento en la complejidad en la forma en que la interfaz interactúa con el núcleo y cómo los controladores del dispositivo son parte de ésta.

Yo me he preguntado muchas veces, algo que probablemente no te sorprenderá, ¿por qué no el núcleo tiene un controlador de dispositivo ABI estable?

Linus Torvalds: Bueno, la falta de una ABI tiene dos vertientes: una es que realmente, realmente, realmente no quiero una. Cada vez que la gente me pregunta por una ABI estable, creo que la razón principal para querer una ABI estable es que quieren tener su controladores binarios y que no quieren dar a conocer la fuente – no quieren fusionar su fuente con el Kernel o el núcleo estándar.

Esto, a su vez, significa que todas las personas que realmente trabajan en el Kernel no pueden, al mismo tiempo, trabajar con esa pieza de hardware y con los proveedores, ya que si hubiera cualquier error no podría arreglarlos.

Por lo tanto, todos los proveedores comerciales, incluso los que utilizan los controladores binarios, se están trasladando o alejando de los controladores binarios, ya que son completamente insostenibles.

Así que esta es una de las razones. Algunas personas creen que se trata de algo político. Y, probablemente, exista un aspecto político en esta decisión. Sin embargo, hay un aspecto mucho más pragmático y es que no se puede mantener.

Jim Zemlin: Esto suena como otro de esas cuestiones culturales por la que la gente parece apoyar los controladores binarios si hay beneficio sin entender, quizá, el beneficio de contribuir al soporte.

Linus Torvalds: Bueno, no se trata tanto del beneficio de la contribución al soporte como a la distribución del mismo. Quiero decir, puede que no termine teniendo el soporte de la mayoría de los dispositivos, pero acaba siendo el tipo de apoyo que necesito cuando tengo un gran problema.

Y cuando tienes ese tipo de sistema de apoyo distribuído – donde todo el mundo termina estando involucrado en algún momento -, no puedes darte el lujo de tener la situación en la que sólo unos pocos, de hecho, tienen acceso al código que puede estar causando el problema. Necesitas tener el código por ahí, no debido a cuestiones sociales, sino, simplemente, porque no sabes quién va a ser el que tiene que arreglarlo.

Así que hay una verdadera razón por la que necesitamos poder acceder al código fuente, lo que significa que para todos los desarrolladores del kernel, un interfaz binario es, básicamente, una mala cosa. No hay duda alguna.

Pero hay otra razón que es la que hace, realmente, que se desencadenen las cosas, de manera irremediable, en el interior del Kernel y que ha dado lugar al hecho de que, incluso aunque quisiéramos disponer de un interfaz binario, no podríamos. Y es que nos implicaría cambiar el cómo hacemos las cosas internamente.

Y esto es algo que ves en otros proyectos en los que, sí, tienen interfaces binarias por una u otra razón – muy a menudo debido a razones comerciales -. Esto significa que no pueden fijar un diseño fundamental. Ellos no sólo listan los interfaces binarios sino que también listan el diseño exacto tal y como se lo encontraron.

Además hay una segunda razón de peso por la que no se va a desarrollar una ABI estable; de hecho, significa que no garantizamos siquiera una API estable. Así, incluso a nivel de código fuente nosotros decimos: “Okay, este es el API, y si tú tienes drivers externos que la utilizan, te ayudaremos a corregirlos cuando tengamos que cambiar el API, pero no te garantizamos que el mismo API funcionará con todas las versiones”.