Cansado de tener un cliente de correo en cada lugar (Oficina, Viaje, Sobremesa... ) y consiguientes editores/lectores de correo, etc.. me estoy pasando a emacs, donde lo tengo todo en uno, y que me funciona igual de bien en local como en consola en remoto. Tras luchar un poco, comento la configuración para hacer que gnus(cliente con capacidades  imap) pueda leer de gmail.

Para tenerlo sincronizado, uso un repositorio propio de git.

Archivo ~/.gnus.el
(setq user-mail-address "guillermo@cientifico.net")
(setq user-full-name "Guillermo Álvarez")
(load-library "smtpmail")
(load-library "nnimap")
(load-library "starttls")
(setq gnus-select-method '(nnimap "imap.gmail.com"
(nnimap-address "imap.gmail.com")
(nnimap-server-port 993)
(nnimap-authinfo-file "~/.authinfo")
(nnimap-stream ssl)))

(setq smtpmail-starttls-credentials '(("smtp.gmail.com" 587 nil nil))
smtpmail-smtp-server "smtp.gmail.com"
smtpmail-default-smtp-server "smtp.gmail.com"
send-mail-function 'smtpmail-send-it
message-send-mail-function 'smtpmail-send-it
smtpmail-smtp-service 587
smtpmail-auth-credentials '(("smtp.gmail.com"
587
"guillermo@cientifico.net"
nil)))
(add-hook 'gnus-topic-mode-hook 'gnus-topic-mode)

Archivo: ~/.authinfo

machine imap.gmail.com login guillermo@cientifico.net password LaPass port 993

 

DRB o Distributed Ruby es una abstracción de sockets tcp y serialización de objetos que trae integrada ruby por defecto.

Tenía ganas de jugar con drb y su abstracción superior sobre el patron tuple spaces que es una forma de implementar el paradigma de memoria asociativa (associative memory) desda linda, que es una forma de coordinar y comunicar diferentes procesos entre máquinas. Vamos: jugar con Rinda. Pero como bien dice mi amigo Jack... Vayamos por partes.

En este caso vamos a poner un caso real en rails para procesar e-mails. No es que sea necesario utilizar DRb, es que es la única forma rentable que he encontrado. Recibimos e-mails con una frecuencia indeterminada, y los procesamos desde una tarea rake. Esto está bien salvo por que levantar una tarea rake que como dependencia tiene :environment, puede suponer bastante tiempo. Si supone 10 segundos y cada instancia supone 40 o 50 megas. 10 correos por segundo... tumbarían la máquina.

Pues lejos de ir más lejos se implementa una arquitectura cliente-servidor en el que el servidor es la tarea rake y el cliente es lo que se conecta con el MTA(Mail Transfer Agent) del sistema. Al grano:

El cliente, solo necesita esto

#!/usr/bin/env ruby
require 'drb'
URI="druby://localhost:9999"

#DRb.start_service URI
server = DRbObject.new_with_uri URI
return puts server.process($stdin.read.to_s)


Mientras que el servidor se arreglaría con esto

  desc 'Start Mail Daemon'
  task :daemon => :environment do
    require 'drb'
    URI="druby://localhost:9999"
    class Processor
      def process(mail)
        ModeloActiveRecordParaMails.create(TMail.new(mail))
      end
    end

    DRb.start_service URI, Processor.new
    DRb.thread.join
  end


Con esto estaría ya todo el trabajo hecho.

Creo que el código es bastante auto-explicativo.

 De casualidad encontré una página que me es muy útil.

http://www.bgpatterns.com/

Para todos aquellos que nos gusta dedicar más tiempo a la programación que al diseño, puede ser una pequeña ayuda para dar resultados más que aceptables.

 

 

 

 

 

 

Basándonos en la teoría de que las máquinas están bien configuradas en lo que respecta el correo, yo voy a tener cientifico.net para correos personales y yolanda.cientifico.net para los correos locales de la máquina.

Esto permite que yo desde cualquier cuanta de correo envie un mensaje a guillermo @ yolanda cientifico PUNTO net.

Para que sirve esto.... pues para ser más comodón aún. Soy fiel usuario de scp (consola -> servidor) y webdav (escritorio<->servidor), pero poder enviar archivos a mi cuenta del servidor y al llegar allí, arrancar alpine y poder guardarlo, es una gozada.

Ahí queda dicho.

Pues me he decidido a publicar uns truquillos para servidores.

Este va a tratar sobre forward y alias, que hoy en día, los nuevos admin, parece que no los conocen.

Tanto sendmail como postfix e imagino que también qmail y compañeros, usan una serie de archivos de configuración.

Uno de ellos es /etc/alias donde podemos decir que todo el correo de la máquina vaya a root

El siguiente archivo es el ~/.fordward

~/.fordward es un archivo de texto, donde pondremos el correo electrónico de nuestra cuenta de verdad.

Ejemplo.

$cat /root/.fordward
guillermo@cientifico.net

Con esto, todo el correo de la máquina irá a mi correo personal, donde una pertinente regla, lo almacena. Todos los informes de paquetes desactualizados/con fallos, y todo el mailing que en general un free genera, me llegará a mi correo, así como los cron.

 

En rails, uno tiene una comodidad muy grande a la hora de hacer relaciones de tablas. Esta es activerecord. Sin embargo, hasta que no la empiezas a usar, no te das cuentas de pequeños detalles.

Por ejemplo. Un usuario pertenece a varios proyectos en calidad de participante o observador:

 class Proyecto < ActiveRecord::Base

     has_and_belongs_to_many :participantes, :conditions => "proyectos_usuarios.participante = true"

     has_and_belongs_to_many :observadores, :conditions => "proyectos_usuarios.participante = false"

... 

end

Suponiendo que la columna participante tiene como valor por defecto false, al hacer:

p = Proyecto.find(:first) u = User.find(:first) p.participantes << u

Al inspecionar p, veremos que el resultado es el esperado, pero si vemos la consulta sql o hacemos un:

p.reload

veremos que el conditions no pinta nada en un update o create.

Mirando en la página de has_and_belongs_to_many, no.nombra nada y se limita a decir que se usa en conditions.

Pensandolo bien, no está mal, ya que en un create, o update, no se usuaría el where con este cometido. Tal vez debería de existir algo como:

     has_and_belongs_to_many :participantes, :conditions => "proyectos_usuarios.participante = true", :set => "participante = true"

para que añadiese ese fragmento en el create o en el update.

¿Algún comentario o sugerencia?

Estaba yo intentando llamar a un método de un helper. Probando encontré un método que sirve para extender clases con módulos.

Sé que esto es básico, pero por desgracia no me he leído todavía ningún libro sobre ruby. He de suponer que lo que estoy haciendo es un mixin de clases con los módulos.

La palabra clave es extend

Por ejemplo, si estoy en un ./script/console de rails, solo tengo que hacer un:

self.extend CommentsHelper

Para completar, es saber que módulos están cargados en la clase actual, vamos, que mixins se presentan.

self.extended_by

Espero que nadie pierda el tiempo que perdí yo intentando hacer esto.

Pues más sencillo de lo que parece. Como es normal en ruby, la lógica aplastante por encima de todo y un simple "<<" bastará.

Por ejemplo.

En vez de hacer

def di_hola puts "hola chaval!" end

podemos hacer:

class << self def di_hola puts "hola chaval!" end end

O su manera enfuscada:

class << self; def hey; puts "hola chaval!"; end

 

El otro día, poniendo plugins de compiz, tenía que descargar de manera rápida unos 8 o 9 urls. Como el ratón me parece un dispositivo bastante práctico, pero lento, quería hacerlo desde consola (con wget, curl o fetch), y se me ocurrió esta manera, que resultó bastante buena.

cat | xargs wget

Ahora un simple copy y paste de las urls, y a descargar.

Solo queda hacer que se descarguen todas de manera concurrente.

Nota: Solo podrás descargar un número máximo de archivos. Para saber este número teclea:

getconf ARG_MAX

 

Un Saludo

Muy buenas.

Mi nombre es Guillermo, y soy una persona aficionada al mundo de lo digital. Desde el como funciona el reloj digital de al lado de la mesilla, hasta las abstracciónes más profundas del mundo digital, como Federated Identity. En este blog, intentaré poner lo poco que se o aprenda, como ejercicio personal, y por si acaso le sirve a alguien.

Otros sitios donde tengo cuenta (por si te aburres y quieres curiosear):

• www.flickr.com/photos/cientifico
• twitter.com/guillermooo
• www.lacoctelera.com/cientifico (Blog del sitio donde trabajo)

Para todo lo demás, al messenger, jabber, o por correo. Las tres son guillermo@cientifico.net

Un cordial Saludo