Infelizmente, por razões de força maior eu não pude comparecer na primeira edição do evento, mas este ano eu estarei presente, e ainda por cima como palestrante.

Por isso, antes de mais nada, eu gostaria de agradecer àqueles que votaram na minha palestra. Isso mostra que Clojure anda despertando o interesse da rapazeada também no Brasil, o que é muito bom.

Update: Apresentação e códigos-fonte disponíveis para download.

Sobre a palestra

Apresentar uma linguagem de programação numa palestra de 50 minutos é sempre uma tarefa complicada, especialmente se essa linguagem de programação traz consigo uma bagagem que vai muito além da sintaxe.

Quando eu assisto uma palestra sobre linguagens de programação, existem duas coisas que me irritam. A primeira é quando o palestrante soca um monte de código e se limita à sintaxe, explicando tudo vírgula por vírgula, sem nenhum contexto. A outra é quando o palestrante fala sobre uma linguagem mas não mostra nenhum exemplo.

Para não repetir esses erros, eu optei por um estilo diferente, onde a linguagem é abordada e explorada aos poucos, mas sempre seguindo uma linha para que haja um começo, um meio e um fim.

Meu objetivo não será ensinar ninguém a programar em Clojure, e sim mostrar alguns dos recursos que eu considero importantes. Assim, quem se interessar pode pesquisar mais por conta própria. Afinal, não somos todos auto-didatas?

Quem tiver dúvidas ao final da palestra, ou quiser apenas jogar conversa fora, é só me chamar pelo Twitter. Também não irei reclamar se alguém quiser pagar meu almoço.

O “pós-evento”

Ao final, a apresentação será disponibilizada para download no GitHub, juntamente com os muitos exemplos de código. Os slides virão acompanhados de notas que poderão ser lidas como uma espécie de artigo.

Deixarei os comentários deste post habilitados para quem quiser deixar dúvidas ou mensagens sobre a palestra.

É isso aí. Nos encontramos lá!

Para mim, algumas ferramentas e distribuições são particularmente úteis:

• Clonezilla. Ferramenta muito boa para clonagem de disco/partição. Leva algum tempo para iniciantes se acostumarem com ela, mas vale o esforço. Já fui salvo por esta ferramenta mais de uma vez.
• GParted. Excelente ferramenta para particionamento de disco.
• Linux Mint. Distribuição Linux baseada no Ubuntu muito fácil de usar. Eu gosto muito da edição Live-DVD, que inclui softwares como VLC, OpenOffice e Java.
• Ubuntu. Uma das distribuições Linux mais populares hoje em dia.
• Memtest86+. Ferramenta para teste de memória incluída na maioria das distribuições Linux modernas. Indispensável.

Agora, em vez de queimar um CD/DVD com cada uma dessas ferramentas, nós iremos usar um pendrive USB multi-boot.

Preparando a pendrive

O primeiro passo é instalar um bootloader na pendrive para possamos escolher qual distribuição carregar quando bootando a partir dela. Sorte minha que a distribuição Linux que uso, Ubuntu, já vem com o Grub2 pré-instalado. Esta versão do Grub em particular é necessária, já que ela nos permite montar e bootar imagens .ISO.

Uma vez que você esteja com o Grub2 instalado, plugue sua pendrive e se certifique de que sua partição principal seja bootável, e que ela esteja formatada com FAT32 (vfat).

Então, rode este comando para instalar o Grub2 no pendrive:

$ sudo grub-install --no-floppy --root-directory=/media/PENDRIVE /dev/sdX

Lembre de fazer com que root-directory aponte para o caminho onde o pendrive está montado, e /dev/sdX para o dispositivo em si. Por favor, verifique os parâmetros duas vezes antes de rodar o comando, ou você corre o risco de fazer algo de que se arrependerá depois!

Configurando o Grub2

Agora é hora de baixar as imagens .ISO das distribuições mencionadas anteriormente e colocá-las no diretório /boot/iso dentro da pendrive. Então, crie o arquivo /boot/grub/grub.cfg com o seguinte conteúdo:

menuentry "Linux Mint 9 x86" {
  set isofile="/boot/iso/linuxmint-9-gnome-dvd-i386.iso"
  loopback loop $isofile
  linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noeject noprompt --
  initrd (loop)/casper/initrd.lz
}
 
menuentry "Ubuntu 10.04 Desktop x86" {
  set isofile="/boot/iso/ubuntu-10.04-desktop-i386.iso"
  loopback loop $isofile
  linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noeject noprompt --
  initrd (loop)/casper/initrd.lz
}
 
menuentry "Clonezilla Live 1.2.5-17 x86" {
  set isofile="/boot/iso/clonezilla-live-1.2.5-17-i686.iso"
  loopback loop $isofile 
  linux (loop)/live/vmlinuz boot=live union=aufs nolocales noprompt ip=frommedia toram=filesystem.squashfs findiso=$isofile 
  initrd (loop)/live/initrd.img
}
 
menuentry "GParted Live 0.5.2-9 x86" {
  set isofile="/boot/iso/gparted-live-0.5.2-9.iso"
  loopback loop $isofile 
  linux (loop)/live/vmlinuz boot=live union=aufs nolocales noprompt ip=frommedia toram=filesystem.squashfs findiso=$isofile 
  initrd (loop)/live/initrd.img
}
 
menuentry "Memory test (memtest86+)" {
  linux16 /boot/iso/memtest86+.bin
}

Não se esqueça de alterar o valor as variáveis isofile, se necessário.

Ressalva

Esse negócio todo é novo, e existem apenas algumas distribuições que podem ser bootadas dessa forma. Caso queira testar outras distribuições, você provavelmente terá que descobrir quais opções de Kernel usar em cada uma delas.

For me, some tools and distros are particularly useful:

• Clonezilla. Very nice disk/partition cloning tool. It takes some time for beginners to get used to it, but it’s worth the effort. This tool saved my life more than once.
• GParted. Great tool for disk partitioning.
• Linux Mint. Very easy to use Ubuntu-based Linux distro. I particularly like the Live-DVD edition, which includes useful software like VLC, OpenOffice and Java.
• Ubuntu. One of the most popular Linux distros nowadays.
• Memtest86+. Memory testing tool bundled in most Linux distros. Indispensable.

Now, instead of burning one CD/DVD for each one of these tools, we’re going to use one multi-boot USB stick.

Preparing the flash drive

The first step is to install a bootloader on the USB stick, so we can choose which distro/tool to load when booting from it. Lucky for me that my Linux distro of choice, Ubuntu, already comes with Grub2 pre-installed. This particular version of Grub is required since it allows us to mount and boot .ISO images.

Once you have Grub2 installed, plug in your USB stick and make sure that its main partition is bootable and is formated with FAT32 (vfat).

Then, run this command to install Grub2 on the stick:

$ sudo grub-install --no-floppy --root-directory=/media/USB_STICK /dev/sdX

Remember to make root-directory point to the path where the flash drive is mounted, and change /dev/sdX to the actual device. Please double-check the parameters to avoid messing with the wrong disk!

Configuring Grub2

It’s time to download the .ISO images for one or more of the aforementioned distros and put them all inside the directory /boot/iso/ inside flash drive. Then, create the file /boot/grub/grub.cfg with the following content:

menuentry "Linux Mint 9 x86" {
  set isofile="/boot/iso/linuxmint-9-gnome-dvd-i386.iso"
  loopback loop $isofile
  linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noeject noprompt --
  initrd (loop)/casper/initrd.lz
}
 
menuentry "Ubuntu 10.04 Desktop x86" {
  set isofile="/boot/iso/ubuntu-10.04-desktop-i386.iso"
  loopback loop $isofile
  linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile noeject noprompt --
  initrd (loop)/casper/initrd.lz
}
 
menuentry "Clonezilla Live 1.2.5-17 x86" {
  set isofile="/boot/iso/clonezilla-live-1.2.5-17-i686.iso"
  loopback loop $isofile 
  linux (loop)/live/vmlinuz boot=live union=aufs nolocales noprompt ip=frommedia toram=filesystem.squashfs findiso=$isofile 
  initrd (loop)/live/initrd.img
}
 
menuentry "GParted Live 0.5.2-9 x86" {
  set isofile="/boot/iso/gparted-live-0.5.2-9.iso"
  loopback loop $isofile 
  linux (loop)/live/vmlinuz boot=live union=aufs nolocales noprompt ip=frommedia toram=filesystem.squashfs findiso=$isofile 
  initrd (loop)/live/initrd.img
}
 
menuentry "Memory test (memtest86+)" {
  linux16 /boot/iso/memtest86+.bin
}

Don’t forget to change each isofile variable to match the downloaded images.

Caveat

This stuff is new, and there are only a few distros that can be booted that way. If you want to try this with other distros than the ones listed here, you’d probably need to Google for the right Kernel options to use.

Felizmente, Django é um dos poucos frameworks web que tornam este um problema simples de solucionar.

Como resolvemos este problema

Um jeito simples é criar um módulo settings.py separado para a versão “mobile”. Isso nos permite rodar dois sites diferentes reusando a mesma base de código. Além disso, cada versão pode ter seu próprio diretório de templates, configurações de URL, etc.

Vamos fazer isso. No diretório-raíz do projeto, crie um arquivo m_settings.py com o seguinte conteúdo:

# Arquivo: myproject/m_settings.py
 
"""Configurações para a versão "mobile" do website.
"""
 
# Carrega as configurações padrão
from settings import *
 
# Domínio "m.mydomain.com"
SITE_ID = 2
PREPEND_WWW = False
 
# Usado em outras partes do código para determinar qual versão está rodando
DEFAULT_VERSION = False
MOBILE_VERSION  = True
 
# URLs para a versão mobile
ROOT_URLCONF  = 'myproject.m_urls'
 
# Templates para a versão mobile
TEMPLATE_DIRS = (
    os.path.normpath(os.path.dirname(__file__) + '/template/mobile'),
)
 
# Outras configurações...

O fato de os dois sites compartilharem a mesma base de código não significa que eles devem ter as mesmas configurações de URL. Aliás, o normal é que versões próprias para dispositivos móveis sejam mais simples, com uma quantidade reduzida de mapeamentos de URLs.

Para definir as configurações de URL da versão mobile, crie um arquivo m_urls.py com o seguinte conteúdo:

# Arquivo: myproject/m_urls.py
 
"""Mapeamentos de URL para a versão "mobile".
"""
 
from django.conf import settings
from django.conf.urls.defaults import *
# from django.contrib import admin
 
# admin.autodiscover()
 
handler404 = 'website.views.error_404_handler'
handler500 = 'website.views.error_500_handler'
 
# URLs
urlpatterns = patterns('',
    # I18N
    (r'^i18n/', include('django.conf.urls.i18n')),
 
    # Apps internas
    (r'^contact/', include('contact.urls')),
 
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')),
    # (r'^admin/', include(admin.site.urls)),
 
    # Outras configurações...
)

Perceba que, neste exemplo em particular, a app Admin não é acessível através da versão mobile. Isso apenas serve para mostrar que temos total liberdade para estruturar ambas as versões de diferentes formas, sem muitas dificuldades.

Desenvolvendo

Você certamente já sabe como rodar o servidor de desenvolvimento para a versão padrão. O que a maioria dos desenvolvedores desconhece, entretanto, é que é possível escolher qual a porta e/ou módulo settings.py deve ser usado pelo script, o que nos permite rodar um servidor para cada versão do nosso site:

# Terminal 1: versão padrão
$ python manage.py runserver 8000
 
# Terminal 2: versão mobile
$ python manage.py runserver --settings=m_settings 8001

Pronto, agora é só continuar com o desenvolvimento da forma que você já está acostumado.

Testando

Você provavelmente notou que temos duas configurações que podem ser usadas para determinar qual versão do site está rodando, DEFAULT_VERSION e MOBILE_VERSION.

Por isso, é só uma questão de checar tais configurações quando for necessário fazer coisas diferentes em cada uma das versões do site. Isso é particularmente útil quando você tem uma app usada em ambas as versões e quer criar testes para cada uma das versões:

# Arquivo: myproject/myapp/tests/__init__.py
 
"""Testes para MyApp.
"""
 
from django.conf import settings
 
if getattr(settings, 'DEFAULT_VERSION', False):
    # Testa a versão padrão
    from default_models_tests import *
    from default_navigation_tests import *
 
if getattr(settings, 'MOBILE_VERSION', False):
    # Testa a versão mobile
    from mobile_models_tests import *
    from mobile_navigation_tests import *

Você pode rodar os testes para cada versão de uma forma semelhante a que fizemos com o comando runserver:

# Versão padrão
$ python manage.py test [appname...]
 
# Versão mobile
$ python manage.py test --settings=m_settings [appname...]

Colocando em produção

Apesar do que você possa achar, esta é a parte fácil.

Uma vez que a forma recomendada de colocar Django em produção é com Apache e mod_wsgi, é possível que você já tenha um arquivo WSGI parecido com o seguinte:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Eggs de terceiros
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Tudo que precisamos fazer é configurar um outro sub-domínio WSGI no nosso servidor (ex: m.mywebsite.com) que referencia o seguinte arquivo de configurações WSGI:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Eggs de terceiros
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.m_settings' # Esta linha
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

A única diferença entre esses dois arquivos WSGI é que cada um aponta para um módulo settings.py diferente. E não, você não precisa ter uma cópia do site para cada versão, afinal estamos usando a mesma base de código para ambas as versões, lembra?

Minimizando o tráfego

Por incrível que pareça, nem todo mundo dispõe de conexões ultra-rápidas. Por isso, é muito importante que você mantenha seus sites tão leves quanto possível.

Existem vários projetos open source que podem ajudar nessa parte. Um deles é o django-compress, uma app Django que fornece um sistema automatizado para compressão de arquivos CSS e JavaScript.

Aliás, não importa se seus websites são para dispositivos móveis ou não; você deve sempre tentar minimizar o tráfego.

O que falta?

Ainda temos um pequeno problema: quando alguém visita a versão padrão do site através de um dispositivo móvel, ou vice-versa, eles não são redirecionados para a versão apropriada. Mas isso é assunto para um próximo artigo!

Fortunately, Django is one of the few web frameworks that makes this an easy problem to solve.

How we solved it

A simple way is to create a separate settings module for the mobile version. Doing this, we’re able to run two different webapps while reusing the existing codebase. Also, each version can have its own template directory, URL root configuration, etc.

Let’s do this. In the project root directory, create a file m_settings.py with the following content:

# File: myproject/m_settings.py
 
"""Django settings for the mobile-specific website.
"""
 
# Load the default settings
from settings import *
 
# Domain "m.mydomain.com"
SITE_ID = 2
PREPEND_WWW = False
 
# Used elsewhere to determine which version is running
DEFAULT_VERSION = False
MOBILE_VERSION  = True
 
# URLs for the mobile version
ROOT_URLCONF  = 'myproject.m_urls'
 
# Templates for the mobile version
TEMPLATE_DIRS = (
    os.path.normpath(os.path.dirname(__file__) + '/template/mobile'),
)
 
# Other settings...

These two webapps share the same codebase, but that doesn’t mean they have to use the same URL root configuration. In fact, websites suitable for mobile devices are usually simpler, with fewer URL mappings.

To define separate URL root configuration for the mobile version, create a file m_urls.py with the following content:

# File: myproject/m_urls.py
 
"""Mobile-specific URL definition.
"""
 
from django.conf import settings
from django.conf.urls.defaults import *
# from django.contrib import admin
 
# admin.autodiscover()
 
# Error page handlers
handler404 = 'website.views.error_404_handler'
handler500 = 'website.views.error_500_handler'
 
# Root URL patterns
urlpatterns = patterns('',
    # I18N
    (r'^i18n/', include('django.conf.urls.i18n')),
 
    # Internal apps
    (r'^contact/', include('contact.urls')),
 
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')),
    # (r'^admin/', include(admin.site.urls)),
 
    # Other settings...
)

Note that, in this particular example, the Admin app isn’t accessible from mobile version. This just shows that we can structure each webapp differently without too much trouble.

Developing

You already know how to run the development server for the default version. Most people don’t know, however, that it’s possible to choose a different port number and settings module, which allows us to launch one development server for each webapp version:

# Terminal window 1: default version
$ python manage.py runserver 8000
 
# Terminal window 2: mobile version
$ python manage.py runserver --settings=m_settings 8001

Just develop your stuff and see the results in both versions right away. Easy peasy.

Testing

You probably noticed that we have two settings that can be used to identify what webapp version is being run, DEFAULT_VERSION and MOBILE_VERSION.

So it’s just a matter of checking those settings when you need to do different things in each webapp version. This is particularly useful when you use an app in both versions and want to create separate tests for each version:

# File: myproject/myapp/tests/__init__.py
 
"""Unit tests module for MyApp.
"""
 
from django.conf import settings
 
if getattr(settings, 'DEFAULT_VERSION', False):
    # Tests the default version
    from default_models_tests import *
    from default_navigation_tests import *
 
if getattr(settings, 'MOBILE_VERSION', False):
    # Tests the mobile version
    from mobile_models_tests import *
    from mobile_navigation_tests import *

We can run the tests for each version in a similar way we did before with the runserver command:

# Default version
$ python manage.py test [appname...]
 
# Mobile version
$ python manage.py test --settings=m_settings [appname...]

Deploying

Despite what you may think, this is the easy part.

Since deploying Django with Apache and mod_wsgi is the recommended way to get Django into production, it’s likely that you already have a WSGI file like this:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Third-party eggs
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

All we need to do is configure another WSGI-enabled subdomain on our server, e.g. m.mywebsite.com, that refers to another WSGI file like this one:

import os, sys
 
APPS_PATH   = '/home/user/wsgi_apps'
MYPROJECT_PATH = '%s/myproject' % APPS_PATH
 
# Third-party eggs
import site
site.addsitedir('/home/user/.python/lib')
 
sys.path += [APPS_PATH, MYPROJECT_PATH]
os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.m_settings' # This line
 
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

The only difference between these two WSGI files is that each one points to a different settings module. And no, you don’t need to have a separate copy for each version. We are using the same codebase for both versions, remember?

Minimizing the traffic

Amazingly, not everyone has access ultra-fast internet connections on their devices, so it’s very important to keep your sites as lightweight as possible.

There are several open source projects that try to address this problem. One of them is django-compress, a Django app that provides an automated system for compressing CSS and JavaScript files.

In fact, doesn’t matter if your websites target mobile devices or not; you should always try to minimize the amount of traffic.

What’s left?

There’s one small problem though: when someone visit the regular website from a mobile device, or vice-versa, they are not redirected to the appropriate version. But this is a topic for another article!

Exim é um MTA open source que pode ser usado como alternativa ao Sendmail em sistemas operacionais Unix. Eu não tenho idéia de qual é a melhor alternativa disponível, mas se você procura por um servidor de relay para instalar na sua configuração de desenvolvimento, Exim é provavelmente a opção mais simples para começar.

Neste artigo, veremos como configurar o Exim para enviar mensagens através do Gmail.

Instalando o Exim

Primeiro precisamos instalar o Exim e suas dependências, o que é algo bastante trivial em distribuições Linux modernas como Ubuntu/Debian:

$ sudo apt-get install exim4

Usando Exim como servidor de relay

Existe um assistente que nos ajuda a fazer as configurações básicas; rode o comando abaixo para abrí-lo e preencha cada tela como segue:

$ sudo dpkg-reconfigure exim4-config

1. General type of mail configuration: mail sent by smarthost; received via SMTP or fetchmail
2. System mail name: seudominio.com
3. IP-addresses to listen on for incoming connections: 127.0.0.1 ; ::1
4. Other destinations for which mail is accepted: Deixe em branco
5. Machines to relay mail for: Deixe em branco
6. Host name for the outgoing smarthost: smtp.gmail.com:587
7. Hide local mail name in outgoing mail: Yes
8. Visible domain name for local users: seudominio.com
9. Keep number of DNS-queries minimal: No
10. Delivery method for local mail: mbox format in /var/mail/
11. Split configuration into small files: Yes
12. Root and postmaster mail recipient: Deixe em branco

Agora precisamos configurar as credenciais do usuário no arquivo /etc/exim4/passwd.client adicionando a seguinte linha:

# Troque [username] e [password] pelos dados corretos
*.google.com:[username]:[password]

Agora basta rodar o comando abaixo para terminar as configurações:

$ sudo update-exim4.conf

Testando o servidor

Um jeito simples — e nerd — de testar se as configurações estão corretas é usar o comando telnet:

$ telnet localhost 25
    Trying ::1...
    Connected to localhost.
    Escape character is '^]'.
    220 localhost ESMTP Exim 4.71 Wed, 23 Jun 2010 22:28:56 -0300
HELO localhost
    250 localhost Hello localhost [::1]
MAIL FROM: usuario@seudominio.com
    250 OK
RCPT TO: destino@email.com
    250 Accepted
DATA
    354 Enter message, ending with "." on a line by itself
SUBJECT: Assunto da mensagem
Testando Exim via Telnet. Massa!
.
    250 OK id=1ORbG5-0005uh-EF
QUIT
    221 localhost closing connection
    Connection closed by foreign host.

Abra os arquivos de log em /var/log/exim4 para ver se a mensagem foi transmitida sem erros. Uma tentativa bem sucedida se parece com o seguinte:

2010-06-23 22:29:47 1ORbG5-0005uh-EF <= local@seudominio.com H=localhost [::1] P=smtp S=345
2010-06-23 22:29:50 1ORbG5-0005uh-EF => destino@email.com R=smarthost T=remote_smtp_smarthost H=gmail-smtp-msa.l.google.com [74.125.45.109] ..."
2010-06-23 22:29:50 1ORbG5-0005uh-EF Completed

Caso você não receba a mensagem e os logs não acusem nenhum erro, verifique se a mensagem não foi parar na caixa de spam antes que você mude quaisquer configurações.

In this article I’ll show you how to configure Exim to send messages through Gmail.

Installing Exim

First we need to install Exim and its dependencies, which is a simple task in modern Linux distros like Ubuntu/Debian:

$ sudo apt-get install exim4

Configuring Exim as a relay server

There’s a wizard that helps us with the basic setup; run the following command line to open it and fill each screen as follows:

$ sudo dpkg-reconfigure exim4-config

1. General type of mail configuration: mail sent by smarthost; received via SMTP or fetchmail
2. System mail name: yourdomain.com
3. IP-addresses to listen on for incoming connections: 127.0.0.1 ; ::1
4. Other destinations for which mail is accepted: Leave it blank
5. Machines to relay mail for: Leave it blank
6. Host name for the outgoing smarthost: smtp.gmail.com:587
7. Hide local mail name in outgoing mail: Yes
8. Visible domain name for local users: yourdomain.com
9. Keep number of DNS-queries minimal: No
10. Delivery method for local mail: mbox format in /var/mail/
11. Split configuration into small files: Yes
12. Root and postmaster mail recipient: Leave it blank

Now we have to configure the user credentials in the file /etc/exim4/passwd.client by adding the following line:

# Replace [username] and [password] by your account's credentials
*.google.com:[username]:[password]

Let’s finish the configuration by running the following command line:

$ sudo update-exim4.conf

Testing the setup

Here’s an old-school way to test if our setup is working — with telnet command:

$ telnet localhost 25
    Trying ::1...
    Connected to localhost.
    Escape character is '^]'.
    220 localhost ESMTP Exim 4.71 Wed, 23 Jun 2010 22:28:56 -0300
HELO localhost
    250 localhost Hello localhost [::1]
MAIL FROM: username@yourdomain.com
    250 OK
RCPT TO: destination@email.com
    250 Accepted
DATA
    354 Enter message, ending with "." on a line by itself
SUBJECT: Message subject
Testing Exim via telnet. w00t!
.
    250 OK id=1ORbG5-0005uh-EF
QUIT
    221 localhost closing connection
    Connection closed by foreign host.

Open the log files at /var/log/exim4 to see if the message relayed correctly. This is how a successful attempt looks like:

2010-06-23 22:29:47 1ORbG5-0005uh-EF <= local@yourdomain.com H=localhost [::1] P=smtp S=345
2010-06-23 22:29:50 1ORbG5-0005uh-EF => destination@email.com R=smarthost T=remote_smtp_smarthost H=gmail-smtp-msa.l.google.com [74.125.45.109] ..."
2010-06-23 22:29:50 1ORbG5-0005uh-EF Completed

If the log looks good and you didn’t get the message, it’s a good idea to check the spam box of the destination email before you change any configuration.

And with the World Cup comes the sweepstakes. Lots of.

Although the rules might change from one place to another, these are the ones we use the most here in Brazil:

1. Everyone try to predict the score of a particular match, paying a fixed amount for each guess (eg $1.00).
2. At the end, the ammount collected is divided equally among the winners. If there are no winners: (a) the sweepstake “accumulates”¹, or (b) everyone get their money back, or (c) you-crazy-rule-here.

I like this kind of sweepstake, but it could be better in some respects.

First, not everybody has the habit of carrying small bills around, so the sweepstakes manager (a.k.a. YOU) loses a lot of time chasing change. Besides, I think the fixed-valued bet is kind of boring since the amount collected is divided equally among the winners. I think things get more exciting when people can choose how much to pay for each guess, so the amount collected is divided proportionally among the winners. In this case, when several people win, earns more who bets more.

Since I don’t like to do the math myself, here’s the challenge: create a program that receives a list with all guesses and returns the list of winners along with the proportional amount to be paid to each one of them.

So, shall we?

Solving the problem… with Clojure

Write more code than necessary is going out of style these days, so I decided to code a solution in Clojure, a functional programming language that makes this sort of “problem” really easy to solve. Just launch the REPL and profit!

The first thing to do is define how to represent each guess:

(defstruct bet :name :amount :guess :rate)

All guesses has the same information. That’s why we defined a StructMap with the keys :name, :amount, :guess, and :rate.

A list of possible guesses might be:

(def pool
     [(struct bet "Daniel" 2.0 [2 0]) ;; Daniel bets $2.00 on score 2x0
      (struct bet "John"   4.0 [0 0]) ;; John bets $4.00 on score 0x0
      (struct bet "Maria"  1.0 [2 0]) ;; Maria bets $1.00 on score 2x0
     ])

Okay, we already know how each guess is represented. Now, how to find the sweepstake’s total amount? Simple, all we have to do is to sum the amount of all guesses:

(defn pool-amount [poolseq]
  (reduce + (map :amount poolseq)))
 
;; testing
(pool-amount pool)
=> 7.0

Great, but how much each guess represent in relation to the whole, that is, what’s the proportion of each guess? All we have to do is to divide the amount of each guess by the sweepstake’s total amount:

(defn pool-rates [poolseq]
  (let [sum (pool-amount poolseq)]
    (map #(assoc % :rate (/ (:amount %) sum)) poolseq)))
 
;; testing
(map :rate (pool-rates pool))
=> (0.285 ..., 0.571 ..., 0.142 ...)
 
(reduce + (map :rate (pool-rates pool)))
=> 1.0

Note that, if everyone wins, the amount earned by John would be the double of the amount earned by Daniel, which would be the double of the amount earned by Maria. Justice, finally!

To finish the code, we just need a function that filters the winners and calculates how much to pay to each winner:

(defn pool-winners [poolseq result]
  (let [sum (pool-amount poolseq)
        winners (filter #(= (:guess %) result) poolseq)]
    (map #(assoc % :amount (double (* (:rate %) sum))) (pool-rates winners))))
 
;; testing
(pool-winners pool [1 0]) ;; no winners
=> ()
 
(pool-winners pool [0 0]) ;; just one winner
=> ({:name "John", :amount 7.0, :guess [0 0], :rate 1.0})
 
(pool-winners pool [2 0]) ;; several winners
=> ({:name "Daniel", :amount 4.66 ..., :guess [2 0], :rate 0.66 ...}
    {:name "Maria", :amount 2.33 ..., :guess [2 0], :rate 0.33 ...})

A major advantage of this solution is that it allows you to bet on anything. Want to bet on the sex of a baby shortly after the good news (or bad news, whatever)?

(def pool [(struct bet "Daniel" 3.0 :male)
           (struct bet "John"   5.0 :female)
           (struct bet "Maria"  1.0 :female)])
 
(pool-winners pool :female)
=> ({:name "John", :amount 7.5, ...} {:name "Maria", :amount 1.5, ...})

There you go, a simple solution for a simple problem.

The code

Although it’s possible to solve this problem in Lisp/Clojure with a one-liner (the Reader works with data structures after all), I decided to write a code that is as readable as possible for those who are starting with Clojure:

(defstruct bet :name :amount :guess :rate)
 
(defn pool-amount [poolseq]
  (reduce + (map :amount poolseq)))
 
(defn pool-rates [poolseq]
  (let [sum (pool-amount poolseq)]
    (map #(assoc % :rate (/ (:amount %) sum)) poolseq)))
 
(defn pool-winners [poolseq result]
  (let [sum (pool-amount poolseq)
        winners (filter #(= (:guess %) result) poolseq)]
    (map #(assoc % :amount (double (* (:rate %) sum))) (pool-rates winners))))

Your turn

Do you program in Haskell? Python? Ruby? Brainfuck? How would you solve such problem in your favorite programming language?

E com a Copa do Mundo vem os bolões. Muitos bolões.

Todo mundo já sabe como funciona um bolão, embora a mecânica possa mudar de um lugar para outro:

1. Cada palpite tem um valor fixo (ex: R$2,00).
2. Cada um pode dar quantos palpites quiser.
3. No final, o montante arrecadado é dividido igualmente entre os vencedores. Se não houverem vencedores: (a) o bolão “acumula”¹, ou (b) todo mundo recebe seu dinheiro de volta, ou (c) sua-regra-maluca-aqui.

Esse tipo de bolão é interessante, mas ele podia ser melhor em alguns aspectos.

Primeiro, o organizador acaba perdendo muito tempo correndo atrás de troco, afinal não é todo mundo que anda com dinheiro trocado na carteira. Além disso, valor fixo de palpite é muito chato, pois o valor arrecadado é dividido por igual entre os ganhadores. O bolão fica muito mais interessante quando o valor do palpite é variável e o valor arrecadado é dividido proporcionalmente entre os ganhadores. Assim, no caso de vários ganhadores, ganha mais quem apostar mais.

O problema de se fazer bolões com palpite variável é ter que ficar calculando o valor proporcional a ser dado a cada ganhador. Portanto eis o desafio: criar um programa que receba uma lista com todos os palpites e retorne uma lista com os palpites vencedores juntamente com o valor proporcional a ser pago a cada ganhador.

E aí, topa?

Resolvendo o problema… em Clojure

Como escrever mais código do que necessário está saindo de moda, optei por codificar uma possível solução em Clojure. Por ser uma linguagem funcional, Clojure é excelente para esse tipo de tarefa. Basta iniciar o REPL e mãos à obra!

Primeiramente, devemos definir como um palpite deve ser representado:

(defstruct bet :name :amount :guess :rate)

Todos os palpites possuem o mesmo conjunto de informações, por isso definimos um StructMap com as chaves :name, :amount, :guess e :rate.

Abaixo, uma possível lista de palpites:

(def pool
     [(struct bet "Daniel"  2.0 [2 0]) ;; Daniel aposta R$2,00 no placar 2x0
      (struct bet "Antônio" 4.0 [0 0]) ;; Antônio aposta R$4,00 no placar 0x0
      (struct bet "Marcela" 1.0 [2 0]) ;; Marcela aposta R$1,00 no placar 2x0
     ])

Certo, já sabemos como os palpites são representados. Agora, como saber o montante total de uma lista de palpites (a.k.a. bolão)? Simples, basta calcular o somatório dos valores de todos os palpites:

(defn pool-amount [poolseq]
  (reduce + (map :amount poolseq)))
 
;; testando
(pool-amount pool)
=> 7.0

Beleza, mas quanto cada palpite representa em relação ao total arrecadado? Afinal, precisamos calcular o valor proporcional a ser pago a cada ganhador.

Sem problemas, basta dividir o valor de cada palpite pelo montante total:

(defn pool-rates [poolseq]
  (let [sum (pool-amount poolseq)]
    (map #(assoc % :rate (/ (:amount %) sum)) poolseq)))
 
;; testando
(map :rate (pool-rates pool))
=> (0.285 ..., 0.571 ..., 0.142 ...)
 
(reduce + (map :rate (pool-rates pool)))
=> 1.0

Repare que, se todos os participantes ganhassem um bolão, o valor recebido pelo Antônio seria o dobro do valor recebido pelo Daniel, que seria o dobro do valor recebido pela Marcela. Justiça, finalmente!

Pronto, agora só falta uma função para filtrar os ganhadores da lista de participantes e calcular o valor proporcional a ser pago a cada um deles:

(defn pool-winners [poolseq result]
  (let [sum (pool-amount poolseq)
        winners (filter #(= (:guess %) result) poolseq)]
    (map #(assoc % :amount (double (* (:rate %) sum))) (pool-rates winners))))
 
;; testando
(pool-winners pool [1 0]) ;; sem ganhadores
=> ()
 
(pool-winners pool [0 0]) ;; apenas um ganhador
=> ({:name "Antônio", :amount 7.0, :guess [0 0], :rate 1.0})
 
(pool-winners pool [2 0]) ;; vários ganhadores
=> ({:name "Daniel", :amount 4.66 ..., :guess [2 0], :rate 0.66 ...}
    {:name "Marcela", :amount 2.33 ..., :guess [2 0], :rate 0.33 ...})

Uma grande vantagem dessa solução é que ela permite que você aposte em qualquer coisa. Quer apostar no sexo de um bebê logo após a boa notícia (ou má notícia, sei lá)?

;; :male = masculino, :female = feminino
(def pool [(struct bet "Daniel"  3.0 :male)
           (struct bet "Antônio" 5.0 :female)
           (struct bet "Fran"    1.0 :female)])
 
(pool-winners pool :female) ;; testando
=> ({:name "Antônio", :amount 7.5, ...} {:name "Fran", :amount 1.5, ...})

Aí está, uma solução simples para um problema simples. Como deveria ser sempre.

Minha solução, na íntegra

Embora seja possível resolver isso com um one-liner em Lisp/Clojure (afinal o Reader não trabalha com linhas, mas com estruturas de dados), eu optei por escrever um código que fosse o mais legível possível para quem não conhece ou está aprendendo Clojure:

(defstruct bet :name :amount :guess :rate)
 
(defn pool-amount [poolseq]
  (reduce + (map :amount poolseq)))
 
(defn pool-rates [poolseq]
  (let [sum (pool-amount poolseq)]
    (map #(assoc % :rate (/ (:amount %) sum)) poolseq)))
 
(defn pool-winners [poolseq result]
  (let [sum (pool-amount poolseq)
        winners (filter #(= (:guess %) result) poolseq)]
    (map #(assoc % :amount (double (* (:rate %) sum))) (pool-rates winners))))

Levando adiante

Você programa em Haskell? Python? Ruby? Brainfuck? Qual seria a sua solução para este problema de extrema importância para o desenvolvimento da raça humana?

Sim, eu disse que o Django 1.2 traz incluso um framework de “mensagens”. Bom, né? Django realmente precisava vir acompanhado de uma app para resolver essa questão. Isso não significa, no entanto, que Django-Flash será descontinuado ou abandonado.

Então, se você usa Django-Flash em seus projetos, não se preocupe! Nada mudará. Django-Flash já é compatível com Django 1.2, e nós ocontinuaremos a mantê-lo por algumas razões.

A primeira delas é que nos importamos com quem usa nosso software. Nós não quebraremos seus projetos se você decidir fazer o upgrade para uma versão mais recente do Django – ou se decidir continuar usando uma versão anterior.

A outra é a liberdade de escolha. Você sabe, não existe uma única forma de se resolver todos os problemas. As pessoas devem ser livres para escolher a ferramenta apropriada a uma determinada situação.

Por exemplo, baseado nas minhas primeiras impressões, existem algumas coisas que eu realmente não gostei no novo framework de “mensagens”:

1. Ele é verboso mesmo nos casos de uso mais simples
2. Ele associa mensagens a números de prioridade, encorajando os usuários a usá-lo como um framework de logging/debugging. Quero dizer, um framework de “mensagens” não é um framework de logging/debugging, certo?

Mas essa é apenas a minha opinião. Talvez seja isso que faz do open source algo tão formidável!