Durante ocho años evité a Emacs, lo use un par de días allá en el siglo pasado y con eso me bastó para decirle adiós, se me hacía algo demasiado críptico, grande y a la vez rudimentario para lo que yo necesitaba. Por lo tanto mi editor de todos los días fue por años Jedit.org, un excelente editor.

Una de las razones por las que decidí intentar con Emacs fue una conferencia en el Hotel Sheraton del Centro Histórico que organizó Sun,  el ponente era un alemán desarrollador de Java que a todas luces se veía que era un chingón,  toda la conferencia sobre Hibernate y J2EE la dió usando Emacs, editaba y compilaba código Java, XML, CSS, HTML y todo sin salirse el editor. Pensé que alguien tan bueno debía usarlo por alguna razón.

Luego en el foro de #rubyonrails inició una discusión sobre TextMate y editores y entonces me dí cuenta que muchos de los mejores desarrolladores del channel usaban emacs.

De modo que emacs ha sido mi editor los últimos cinco meses, aunque sé que apenas aprovecho el 20% de esta multiherramienta , ya me empiezo a dar cuenta porque la gente lo recomienda tanto, es un editor super-potente, super-estable y super-fléxible y ¡va en la versión 22!.

El tema de la combinación de teclas, que a tanta gente desespera, sólo dura un par de  semanas, luego uno se acostumbra.

Lo primero que hay que hacer es instalar emacs y algunas extensiones:

$ sudo apt-get install emacs22-nox php-elisp emacs22-el

Yo prefiero la versión "nox" es decir sin soporte de X, pura consola.  Emacs se manej através de combinaciones de teclas, la tecla Control (Ctrl) se represneta con una C mientras la tecla Meta con una M, la tecla Meta en los teclados que no la poseen nativamente, es la tecla Alt en el lado izquierdo del teclado. Por ejempo:

C-v scroll-up ctrl más tecla v simúltaneamente
M-v scroll-down alt más tecla v simúltaneamente

En el caso de:

C-x C-s    save-buffer           ctrl más tecla x simúltaneamente, soltar y luego ctrl más tecla s simúltaneamente

Estos son algunos de los comandos más usados. Para seleccionar una sección que queramos copiar o cortar hay que usar C-Space, es decir Ctrl más la barra espaciadora.

 Ahora necesitamos crear el archivo .emacs con nuestra configuración, este es el mio:

;;Colores
(global-font-lock-mode 1)
;;Colores para la seleccion (mark region)
(setq transient-mark-mode t)

;;Activar el wheel del mouse
(mouse-wheel-mode)

;; Mostrar el numero de columna
(setq column-number-mode t)

;; associate ruby-mode with .rb files
(add-to-list 'auto-mode-alist '(".rb$" . ruby-mode))

;;php and CakePHP
(add-to-list 'auto-mode-alist '(".thtml$" . php-mode))
(add-to-list 'auto-mode-alist '(".ctp$" . php-mode))
(autoload 'cyclebuffer-forward "cyclebuffer" "cycle forward" t)
(autoload 'cyclebuffer-backward "cyclebuffer" "cycle backward" t)
(global-set-key "\M-N" 'cyclebuffer-forward)
(global-set-key "\M-P" 'cyclebuffer-backward)

;;;;;;;;;;;;;;;;;;;;
;; set up unicode
(prefer-coding-system       'utf-8)
(set-default-coding-systems 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)

(put 'set-goal-column 'disabled nil)

Asi ya tenemos soporte para PHP en las vistas de CakePHP con extensión .ctp pera además tenemos otras ventajas como hacer switch entre buffers con C-M-n y como mostrar la selección de texto para copiar o cortar:

CakeHP es una framework que sigue el patrón de diseño Modelo-Vista-Controlador.

La Vista es la interfase al usuario, es decir en el URL http://myserver.com/news/display quiere decir que hay un controlador app/controllers/news_controller.php con un método display() que se procesa y pasa el resultado a la vista que está en app/views/news/display.ctp, todo este proceso genera una variable llamada $content_for_layout que se integra al layout, casi siempre en la parte central de la página.
 
No obstante un sitio de internet por lo general tiene muchos elementos laterales: cajas de búsquedas, los útimos diez comentarios, los últimos posts, la publicidad, las noticias más votadas, encuestas, una pequeña aplicación con el clima, etcétera, etcétera.

Estos elementos pueden ir integrados directamente en el layout, pero ese crearía un problema: supongamos que tenemos cinco diseños de layouts entre los cuales el usuario puede elegir. Si más adelante queremos cambiar algo en la encuesta o en alguna parte del sitio tendríamos que abrir los cinco layouts para cambiarlo. Como CakePHP motiva mucho el DRY (don't repeat yourself), esta no sería una buena aproximación. Lo mejor sería "desmenuzar" el sitio en partes, para eso son los elementos.       

Un elemento es simplemente una mini-vista que se coloca en el directorio app/views/elements/ con la extensión .ctp , por ejemplo suponiendo que tuviese un elemento podcasts.ctp, se renderiza asi en los cinco diseños de layout:

 echo $ this -> renderElement('podcasts'); 

Los elementos pueden estar conformados por puros helpers, es decir, producir xhtml estático, pero también podemos pasarle un array para hacer loops dentro de ellos: 

 echo $ this -> renderElement('podcast's, $ data["Podcast"]); 

En la mononeurona, en la portada y en los blogs, hay un montón de elementos para mostrar las secciones:


En CakePHP los elementos se usan en conjunción con los componentes para crear secciones dinámicas en el sitio. Es importante usar el archivo .css del layout  para definir el diseño dentro de los elementos, nunca hay que poner diseño directamente dentro de los elementos.

Para cambiar la apariencia general de nuestra aplicación CakePHP usa layouts, los cuales están colocados en el directorio app/views/layouts/.  Un layout mínimo sería como este:

< ? php
  echo $html->docType();
  echo '< html>< head >';
  echo $html->css('styles');   // carga los estilos CSS
  echo '<  title >'.  $title_for_layout . '< /title >';
?>
< /head >
< body >
  < ? php echo $content_for_layout; ?>
< /body >
< /html >

Este archivo lo guardamos como app/views/layouts/portal.ctp, la extensión ctp es por "cake template". La variable más importante aquí es $content_for_layout, que contiene el resultado de la vista. En este caso, como se indica, debe existir un archivo  /app/webroot/css/styles.css con el diseño del layout.

Si queremos usar este layout debemos indicarlo en  la acción del controlador:

$this->layout = 'portal';

por omisión el valor de $this->layout es 'default' y por eso ese es el layout que CakePHP busca por default, pero yo prefiero tener un layout default.ctp  simple y sin  mucho CSS porque cuando CakePHP manda errores el default.ctp muchas veces tiene demasiadas cosas.

Este es un ejemplo elemental, por supuesto los layouts de la vida real son más complejos, como éste.
 
 

Empezando rápido con CakePHP

Necesitamos subversion e ir por la última versión de CakePHP:

$sudo apt-get install subversion

me coloco en /home/manuel/devs/ y voy por el código:

$svn co https://svn.cakephp.org/repo/trunk/cake/1.2.x.x  cake

Necesitamos el Webserver, PHP5 y PostgreSQL:

$sudo apt-get install libapache2-mod-php5 php5-pgsql postgresql

Habilitamos el modulo rewrite de apache2:

$sudo a2enmod rewrite

Editamos el site por default de apache2:

$sudo emacs /etc/apache2/sites-enabled/000-default

Asegúrate que la indicación AllowOverride es "All" y no "None"  donde dice /var/www cambiarlo por /home/manuel/devs/cake/app/webroot y reiniciar apache2. Dar permisos al directorio temporal de CakePHP:

$chmod -R 777 /home/manuel/devs/cake/app/tmp

Crea la base de datos:

$createdb -E UNICODE DBTEST

Creamos una  tabla:

CREATE TABLE bookmarks (
  id serial PRIMARY KEY,
   name VARCHAR(150) NOT NULL,
   url VARCHAR(255) NOT NULL,
   created date
);

Salva el archivo app/config/database.php.default como database.php, debe estar configurado asi 

class DATABASE_CONFIG {
        public $default = array(
                'driver' => 'postgres',
                'persistent' => false,
                'host' => 'localhost',
                'port' => '',
                'login' => 'postgres',
                'password' => '1234',
                'database' => 'DBTEST',
                'schema' => 'public',
                'prefix' => '',
                'encoding' => 'utf-8'
        );
        public $test = array(
                'driver' => 'mysql',
                'persistent' => false,
                'host' => 'localhost',
                'port' => '',
                'login' => 'user',
                'password' => 'password',
                'database' => 'test_database_name',
                'schema' => '',
                'prefix' => '',
                'encoding' => ''
        );
}

Creamos el model:

< ? php
// file: app/models/bookmark.php
class Bookmark extends AppModel
{
public $name = 'Bookmark';
}
? >

Creamos el controlador:

< ? php
// file: app/controllers/bookmarks_controller.php
class BookmarksController extends AppController
{
   public $name = 'Bookmarks';
   public $scaffold;
}
? >

Y eso es todo, si nos colocamos en http:localhost/bookmarks ya podemos manejar nuestra información:

Estoy haciendo un desarrollo en el que se necesita que el administrador del sitio pueda habiltar/deshabiltar aspectos gadgets del portal del sitio. Es decir hay un gadget del clima que puede configurarse para que se vea el clima actual con el solecito o la nubecita o lo que sea, y ese gadget debe poder deshabilitarse si asi lo quiere el administrador.

Estoy pensando crear un directorio específico que contenga pequeños archivos XML con los tags de cada gadget y parsearlo para que se presenten en el panel de control del sitio. Esto tiene la ventaja de que si alguien desarrolla un gadget lo puede instalar simplemente subiendo el .tgz através del navegador y descomprimiéndolo.  Un botón crearía las tablas en Postgresql  que ese gadget necesita y con eso ya estaría disponible. Además traducir el gadget  sería muy fácil porque sólo se agregarían los tags al XML para un lenguaje específico:  fr, en, es, de, sk, etcétera.

Por el momento por la interfase no me preocupo: que el diseñador ponga  echo  $ gagdet- > ('gadget_t'); en el layout xhtml y con eso tiene.

Como me suele suceder, pensar en esto me entusiasma y me divierte y hasta cuando voy empujando el carrito del super voy pensando en cómo chingados le haría para desinstalar el gadget y y qué pásaría cuando un "Gadget K" tenga como dependencia un "Gadget B". Como sea, voy a estar ocupado los próximos diez años lo cual se oye muy bien.

Recuerdo que los de Jaws.com.mx ya tenían implementado un algoritmo para esto y si está chido lo adapto.

Últimamente he leido diferentes noticias sobre PHP, sobre todo porque varias personas muy respetadas han escrito posts en su blog diciendo (o reconociendo) que PHP no es tan malo y hasta señalan que Ruby, Java o Python podrían aprender algunas cosas de este lenguaje. Y yo también meto mi cuchara.

Empecé a programar en Perl y Java, y actualmente desarrollo una aplicación de buen tamaño en Ruby on Rails pero personalmente me considero phpero, en parte elegí este lenguaje porque nunca en mi vida he tomado una clase de computación o cosa parecida y PHP3 parecía sencillo, pero también porque hay muchos más trabajos de PHP en el mercado laboral que en cualquier otro lenguaje.

Desde el principio encontraba mucha gente que le desagradaba PHP y se burlaba de él, primero fueron los perleros, luego los pythoneros y últimamente los rubieros. Parece ser todo un deporte entre ellos y esta actividad crea una gran reputación en sus comunidades.

Como ya he escrito en otra parte, para conocer un lenguaje, para sentirte cómodo con él, debes haber trabajado al menos unos cuatro años dia a día con él (cuatro años se pasan rápido). Como yo ya tenía más de cuatro años con PHP decidí quedarme ahí y profundizar hasta donde fuese posible.

Por supuesto que estaba consciente que muchas de las críticas al lenguaje eran válidas. PHP es un lenguaje sin pedigree y muy parcheado, en eso se parece a MySQL y a Apache. Su creador, Rasmus Lerdorf, era muy jóven cuando lo creo y de ninguna manera se puede comparar su experticia contra los maduros creadores de Python (Von Rossum) y Ruby (Matsumoto). De hecho ni siquiera pensaba en desarrollar un lenguaje sino simplemente hacer un módulo de apache para generar html más cómodamente. De este nacimiento surgen muchas de sus ventajas y desventajas.

Pero hay tener en cuenta que PHP va en la versión 5.2 y ya hay una versión alpha de la 6 y muchas de las críticas que se le hacían eran para la versión 4 y anteriores. A lo largo de los años he visto como las quejas sobre PHP pasaban a ser cada vez más rebuscadas, por ejemplo mucha gente hace trampa y olvida mencionar el comparador de tipos ($b === $B) cuando habla de la tipificación en PHP. Además el soporte para objetos está maduro y permite hacer muchas cosas que antes sólo Java permitía.

Todo esto sin olvidar que muchas veces la escalabilidad y la implementación de Python y Ruby son un dolor de cabeza mientras PHP escala como ningún otro lenguaje pues todo es C dentro de un proceso único.

Para mi lo más importante en la carerra de desarrollador de software es dejar de ser un mero programador (el clásico picateclas) para convertirte en arquitecto de Clases y Componentes, en diseñar la aplicación en el papel antes de teclar algo. Este objetivo se puedo lograr usando Python , PHP o VisualBasic, porque no hay malos lenguajes, hay malos desarrolladores: he visto pésimo código en Java y excelente código en PHP. En general la gente que habla demasiado sobre su lenguaje de programación, es gente que no sabe programar.

Claro que hay cosas que me gustaria ver en PHP: que remuevan el semicolon (;) y los corchetes {}, que hubiese name spaces. Algo que lamento de PHP es que, ha diferencia de Python y Ruby, no recibío la benéfica influencia de SmallTalk. Me gustaría que los tipos fueran objetos y acceder a sus métodos: $nombre.length(parameter1, parameter2).

En conclusión: PHP te da las herramientas y conceptos para ser un buen desarrollador, es rápido, sencillo de configurar y potente, pero hay que reconocer que facilita que exista mal código por todo internet... pero eso no es culpa del lenguaje. Lo mismo pasó con Perl en los 90, cuando era el lenguaje de internet y todo mundo (incluyéndome) hacíamos terribles CGIs.

Debian Sid con WindowMaker, Gnome-Terminal y Audacious. Rápido, estable, potente y todo manejado con keyboard shortcuts:

1) Bueno uno de los asuntos que he encontrado en el cibercafé con GNU/Linux es que muchas personas quieren imprimir su CURP.

Comos los desarrolladores del gobierno son bien pendejos la madreola sólo funciona en Explorer. Es evidente que deberìa existir una opción de "Descargar CURP" si es que no quieres imprimirlo pero si llevártelo en tu USB. El caso es que en Firefox u Opera o Konqueror aparece una pantalla en blanco. Navegando por ahí me entero que el tip está en llegar a la parte donde pones los datos para imprimir y luego hacer un copy&paste en esta liga:

http://curp.emexico.gob.mx:8080/CurpSP/pdf/TU_CLAVE_CURP.pdf

y obviamente poner tu clave.

2) El segundo problema es que Evince, el lector de PDF de Gnome no interpreta bien los caracteres del mentado CURP al enviar a impresiòn, o al menos no lo hace bien con la impresora que yo tengo. La solución fue descargar el Adobe Reader de la pàgina de Adobe, el cual por cierto está muy bonito y se integra a Firefox. Adobe reader imprime usando el comando "lpr" de modo que asegúrate de tener el paquete cupsys-bsd instalado.

3) Otro asunto es que al montar una memoria USB y dar doble click en un archivo de MS Office con un nombre raro, es decir, caracteres no ASCII, Nautilus envia el mensaje "Archivo no encontrado". La solución es copiar el archivo  al papel tapiz  y desde allí abrirlo.

Esto último no me lo explico porque según yo linux tiene las tablas UNICODE más completas que hay y debería leer los archivos incluso con caracteres chinos o árabes. Nunca me había pasado pero yo nunca uso espacios ni acentos en los nombres de archivo.

Están presentando el documental "Soneros del Tesechoacán". Lo están pasando por TvUNAM y no tiene pierde, México está lleno de gente y tradiciones chingonas.