Esteja preparado para uma enorme quantidade de gambiarras.

ELPA

A primeira coisa que faço numa nova instalação do Emacs é configurar o ELPA, ou Emacs Lisp Package Archive. Para quem não conhece, pense no ELPA como se fosse um apt-get da vida, guardadas as devidas proporções (como veremos a seguir).

As instruções para instalação podem ser vistas nesta página. Se tudo der certo, agora deve ser possível rodar o comando M-x package-list-packages <ENTER>. Leia este documento caso tenha dificuldades para usar atalhos e comandos do Emacs.

Após alguns instantes, a lista de pacotes disponíveis para instalação via ELPA deve ser exibida num buffer secundário.

Clojure-Mode

Coloque o cursor sobre a linha do pacote swank-clojure e pressione a tecla I para marcá-lo para instalação. Faça o mesmo com o pacote paredit. Se outros pacotes foram marcados acidentalmente, mova o cursor para as linhas correspondentes e pressione U para desfazer a marcação. Pressione X para prosseguir com a instalação.

Feito isso, ao rodar o comando M-x slime <ENTER>, o Emacs irá perguntar se você deseja que ele faça o download dos JARs de Clojure. Não adianta dizer que sim, pois não irá funcionar.

Para resolver isso, baixe manualmente os JARs de Clojure e os coloque no diretório ~/.clojure/. Em seguida, baixe o JAR mais recente projeto swank-clojure e o coloque no diretório ~/.swank-clojure/.

Pronto. Reinicie o Emacs e rode o comando M-x slime <ENTER> para iniciar um REPL Clojure dentro do Emacs!

Clojure no Emacs Slime

Vale lembrar que o Slime fornece vários recursos para edição de código, como auto-completion, exibição de docstrings, entre outras coisas. Consulte o site do projeto para mais informações.

Outros Lisps

Rode o comando abaixo para instalar duas das principais implementações open source do ANSI Common Lisp, CLISP e SBCL:

$ sudo apt-get install clisp sbcl

Finalmente, abra o arquivo ~/.emacs e cole o código a seguir na última linha:

;; paredit + lisp modes
(defvar *lisp-modes* '(clojure-mode-hook lisp-mode-hook emacs-lisp-mode-hook
                       lisp-interaction-mode-hook slime-repl-mode-hook))
 
;; config used in all lisp modes
(defun lisp-config ()
  (paredit-mode t)
  (show-paren-mode t))
 
(mapc (lambda (mode)
        (add-hook mode 'lisp-config)) *lisp-modes*)
 
;; other lisp implementations
(eval-after-load "slime"
  '(progn (setq slime-lisp-implementations
                '((sbcl ("/usr/bin/sbcl"))
                  (clisp ("/usr/bin/clisp"))))))

Swank

As últimas versões do Slime já trazem servidores Swank para diversas implementações Lisp, mas curiosamente essa parte do código não é baixada quando se instala o Slime via ELPA.

Certifique-se de que um cliente CVS esteja instalado e rode o comando abaixo para fazer o download da última versão do Slime:

$ cvs -d :pserver:anonymous:anonymous@common-lisp.net:/project/slime/cvsroot co slime

Em seguida, vá até o diretório slime recém-criado e copie todos os arquivos deste diretório por cima dos arquivos instalados via ELPA em ~/.emacs.d/elpa/slime-<VERSION>. Aproveite e remova o arquivo slime.elc deste último diretório, já que tal arquivo é uma versão compilada de um arquivo que acabamos de sobrescrever.

Reinicie o Emacs. O comando M-x slime <ENTER> continua servindo para iniciar um REPL Clojure. Para iniciar um REPL SBCL, por exemplo, rode o comando M-- M-x slime <ENTER>, digite sbcl e pressione <ENTER>.

SBCL no Emacs Slime

“Nunca vi tanta gambiarra num lugar só…”

Tudo seria mais fácil se o ELPA disponibilizasse versões minimamente atualizadas — e não-”capadas” — de certos pacotes, por isso creio que essa complicação deva ser temporária. Atualizarei este texto quando a coisa mudar. Para melhor, espero.

ELPA

The first thing I do on a fresh Emacs installation is configure the ELPA, or Emacs Lisp Package Archive. If you don’t know what ELPA is, think of it as an apt-get for Emacs (with some quirks though, as discussed below).

You can find the installation instructions here. If everything works, now you should be able to run the command M-x package-list-packages <ENTER>. Read this if you don’t understand how commands and shortcuts work on Emacs.

The list of packages available for installation via ELPA should be displayed in a secondary buffer after a few seconds.

Clojure-Mode

Place the cursor over the line that describes the swank-clojure package, and press I to check it for installation. Do the same thing with paredit. If other packages were checked by accident, move the cursor to the correspondent lines and press U to undo the selection. When you’re done, press X to proceed with the installation.

Then, run the command M-x slime <ENTER>, and Emacs will ask if you want it to download the Clojure JAR files for you. Unfortunately, answering yes won’t do anything.

To fix this, download the Clojure JAR files manually and put them on ~/.clojure/. Then, download the most recent swank-clojure JAR file and put it on ~/.swank-clojure/.

There you go. Restart Emacs and run the command M-x slime <ENTER> to start a Clojure REPL inside Emacs!

Clojure REPL in Emacs

Remember that Slime provides many useful features like auto-completion, docstring lookup, etc. Check the Slime website for more information.

Other Lisps

Run the following command line to install two of the most popular open source implementations of the ANSI Common Lisp standard, CLISP and SBCL:

$ sudo apt-get install clisp sbcl

Finally, open the file ~/.emacs and paste the following code at the end:

;; paredit + lisp modes
(defvar *lisp-modes* '(clojure-mode-hook lisp-mode-hook emacs-lisp-mode-hook
                       lisp-interaction-mode-hook slime-repl-mode-hook))
 
;; config used in all lisp modes
(defun lisp-config ()
  (paredit-mode t)
  (show-paren-mode t))
 
(mapc (lambda (mode)
        (add-hook mode 'lisp-config)) *lisp-modes*)
 
;; other lisp implementations
(eval-after-load "slime"
  '(progn (setq slime-lisp-implementations
                '((sbcl ("/usr/bin/sbcl"))
                  (clisp ("/usr/bin/clisp"))))))

Swank

The latest versions of Slime come with Swank servers for many popular Lisp implementations, although the package available via ELPA looks like a outdated stripped-down version of Slime. Don’t ask me why.

Let’s fix this. Make sure you have a CVS client installed and then run the following command line to get the latest Slime:

$ cvs -d :pserver:anonymous:anonymous@common-lisp.net:/project/slime/cvsroot co slime

Now, go to the newly created directory slime and copy all files from this directory over the files installed via ELPA in ~/.emacs.d/elpa/slime-<VERSION>. Also remove the file slime.elc from the latter directory as this is a compiled version of an old file.

Restart Emacs. The command M-x slime <ENTER> still starts a Clojure REPL. To start a SBCL REPL, for example, run the command M-- M-x slime <ENTER>, type sbcl and press <ENTER>.

SBCL REPL in Emacs

“Jeez, I never saw that many workarounds in a single blog post…”

Everything would be a lot easier if the packages distributed via ELPA were updated more often, so I expect things to get better eventually. I’ll update this post when that happens. (Fingers crossed)

Recently we released Licensator, a simple web application that gathers information on the most popular open source licenses and helps you choose the right license for your own projects.

The language behind Licensator is Clojure, which proved to be great to solve this sort of problem. We’ll see today how the application’s main algorithm works.

REPL: where it all begins

One of the strengths of dynamic languages is how easily we can transform ideas into working code, and Clojure is no exception. In fact, I decided to write Licensator in one of these coding sessions in the REPL, Clojure’s interactive shell. After a few minutes playing with it I saw the problem was indeed easy to solve.

Despite the huge number of licenses, we can easily extract information common to all of them, i.e., if it’s copyleft, or if a licensed work can be used by closed source software, etc.

Let’s take the Apache v2.0 license:

(def *licenses*
     [{:id :apl-v20
       :long-name "Apache License v2.0"
       :short-name "Apache v2.0"
       :url "http://www.opensource.org/licenses/apache2.0.php"
       :copyright true
       :patent true
       :closed-source-linking true
       :derivative-work true
       :affero false
       :copyleft false
       :charge-for-distribution true
       :charge-for-use true
       :compatible-with [:apl-v20 :afl-v30 :cddl-v10 :epl-v10 :freebsd
                         :new-bsd :mit :mpl-v11 :public-domain]}])

You can see the remaining licenses here.

Considering all licenses have the same set of information, how can we find the licenses that are not reciprocal and have explicit copyright terms?

(map :id
  (filter #(and (:copyright %) (not (:copyleft %))) *licenses*))
=> (:afl-v30 :apl-v20 :epl-v10 :freebsd :mit :new-bsd :bsd)

If you know a little bit about functional programming, this code should be easy to follow. In any case, what this code does is return the :id of all licenses where :copyright is true and :copyleft is false.

Another example: which licenses are compatible with Apache v2.0 and CDDL v1.0?

(use 'clojure.set)
 
(map :id
  (filter #(subset? (set [:apl-v20 :cddl-v10])
                    (set (:compatible-with %))) *licenses*))
=> (:apl-v20 :cddl-v10 :epl-v10)

Here we used the clojure.set namespace, which provides a few useful functions to deal with relational algebra. The code is very similar to the previous one; the only difference is that now we used the subset? function to get the licenses compatible with [:apl-v20 :cddl-v10].

One last example: which reciprocal licenses are compatible with Apache v2.0?

(map :id
  (filter #(and (subset? (set [:apl-v20]) (set (:compatible-with %)))
                (:copyleft %)) *licenses*))
=> (:cddl-v10 :agpl-v30 :gpl-v30 :lgpl-v30 :mpl-v11)

At this point we can see that there is no magic behind the algorithm; what it does is to filter the list of licenses based on a function.

The solution

The code we saw up until now works fine, but it’s not appropriate to solve the problem since the matching logic is spread all over the place.

It would be better to express the search criteria as a map object…

(def cmap
     {:patent true, :closed-source-linking true, :compatible-with [:mit :new-bsd]})

…so we need a function to filter the licenses based on that input, like this:

(defn find-matches [cmap data]
  (filter (where cmap) data))

Here we have where, yet to be coded, that returns a function that filters the elements (licenses) in data according to the criteria map cmap.

First things first. Which conditions of cmap match the Apache v2.0 license?

(defn criteria-matches? [license [kval cval]]
  "Checks whether the criteria condition centry is true for license."
  (let [lval (kval license)]
    (if (nil? cval)
      true
      (if (coll? lval)
        (subset? (set cval) (set lval))
        (= cval lval)))))
 
(map (partial criteria-matches? apl-v20) cmap)
=> (true true true)

A license can only be considered compatible with the given criteria if the list only yields true. Therefore, in this case, the Apache v2.0 license is considered to be compatible:

(every? true? (map (partial criteria-matches? apl-v20) cmap))
=> true

Given all this, a possible implementation of the where function might be:

(defn where
  "Returns a function that checks whether all conditions in cmap match for license lentry."
  [cmap]
  (fn [lentry]
    (let [res (map (fn [centry]
		     (let [cval (val centry)
			   lval ((key centry) lentry)]
		       (if (nil? cval)
			 true
			 (if (coll? lval)
			   (subset? (set cval) (set lval))
			   (= cval lval))))) cmap)]
      (every? true? res))))

This code is a combination of the previous two snippets; where gets the criteria map cmap and returns a second function, which in turn gets a license entry lentry and checks whether all criteria conditions match.

Since where is used along with filter in find-matches, all licenses compatible with the criteria map cmap are returned:

(map :id (find-matches cmap *licenses*))
=> (:afl-v30 :apl-v20 :cddl-v10 :epl-v10 :lgpl-v30 :mpl-v11)

What I like about Clojure — and functional programming languages in general — is the ridiculous amount of code it takes to solve certain problems. This algorithm, for example, has only 15 (really short) lines of code. Where is your God now?!

You can see the whole thing in Github.

Para quem não viu, recentemente colocamos no ar o Licensator, uma aplicação web que, além de reunir informações sobre as licenças open source mais populares, é capaz de indicar as licenças apropriadas para cada caso.

A linguagem escolhida para implementar o projeto foi Clojure, que se mostrou excelente para resolver esse tipo de problema. Veremos hoje como o principal algoritmo da aplicação funciona.

REPL: onde tudo começa

Um dos pontos fortes das linguagens dinâmicas é a facilidade em transformar idéias em código funcional, e com Clojure não é diferente. A idéia por trás do Licensator surgiu justamente em uma dessas sessões de codificação no REPL, o ambiente interativo da linguagem. Após alguns minutos brincando, vi que o problema era simples de resolver.

Apesar do elevado número de licenças, podemos facilmente extrair informações comuns a todas elas, como: se a licença é copyleft, se pode ser usada por código fechado (proprietário), entre outras coisas.

Por exemplo, vamos pegar a licença Apache v2.0:

(def *licenses*
     [{:id :apl-v20
       :long-name "Apache License v2.0"
       :short-name "Apache v2.0"
       :url "http://www.opensource.org/licenses/apache2.0.php"
       :copyright true
       :patent true
       :closed-source-linking true
       :derivative-work true
       :affero false
       :copyleft false
       :charge-for-distribution true
       :charge-for-use true
       :compatible-with [:apl-v20 :afl-v30 :cddl-v10 :epl-v10 :freebsd
                         :new-bsd :mit :mpl-v11 :public-domain]}])

A lista completa de licenças pode ser vista aqui.

Considerando que todas as licenças têm esse mesmo conjunto de informações, como podemos saber quais licenças não são recíprocas e possuem cláusulas explícitas de copyright?

(map :id
  (filter #(and (:copyright %) (not (:copyleft %))) *licenses*))
=> (:afl-v30 :apl-v20 :epl-v10 :freebsd :mit :new-bsd :bsd)

Se você conhece um pouco sobre programação funcional, este código deve ser fácil de acompanhar. De qualquer forma, o que ele faz é retornar o :id de todas as licenças onde :copyright é verdadeiro e :copyleft é falso.

Outro exemplo: quais licenças são compatíveis com Apache v2.0 e CDDL v1.0?

(use 'clojure.set)
 
(map :id
  (filter #(subset? (set [:apl-v20 :cddl-v10])
                    (set (:compatible-with %))) *licenses*))
=> (:apl-v20 :cddl-v10 :epl-v10)

Aqui usamos a namespace clojure.set, que conta com algumas funções úteis para álgebra relacional. O código é muito parecido com o anterior; a mudança é que agora usamos a função subset? para buscar as licenças compatíveis com [:apl-v20 :cddl-v10].

Último exemplo: quais licenças recíprocas são compatíveis com Apache v2.0?

(map :id
  (filter #(and (subset? (set [:apl-v20]) (set (:compatible-with %)))
                (:copyleft %)) *licenses*))
=> (:cddl-v10 :agpl-v30 :gpl-v30 :lgpl-v30 :mpl-v11)

Neste ponto já se pode perceber que não existe mágica nenhuma por trás do algoritmo; o que ele faz é filtrar as licenças com base numa função.

A solução

O código que acabamos de ver funciona, mas não é apropriado para resolver o problema uma vez que a lógica de consulta se encontra fixa no código.

O ideal seria se os critérios de busca fossem expressados como um map…

(def cmap
     {:patent true, :closed-source-linking true, :compatible-with [:mit :new-bsd]})

…portanto precisamos de uma função que faça a filtragem das licenças com base nesse mapa, algo como:

(defn find-matches [cmap data]
  (filter (where cmap) data))

No caso, essa função where, que ainda não definimos, deve retornar uma função que filtre os elementos (licenças) em data de acordo com o mapa de critérios cmap.

Vamos por partes. Quais condições em cmap são verdadeiras para a licença Apache v2.0?

(defn criteria-matches? [license [kval cval]]
  "Verifica se o critério 'centry' é verdadeiro para a licença 'license'."
  (let [lval (kval license)]
    (if (nil? cval)
      true
      (if (coll? lval)
        (subset? (set cval) (set lval))
        (= cval lval)))))
 
(map (partial criteria-matches? apl-v20) cmap)
=> (true true true)

Uma licença só pode ser considerada compatível com os critérios se a lista retornada contém apenas valores verdadeiros. Portanto, neste caso, a licença Apache v2.0 é considerada compatível com os critérios informados:

(every? true? (map (partial criteria-matches? apl-v20) cmap))
=> true

Logo, uma possível implementação para a função where seria:

(defn where
  "Retorna função que diz se todos os critérios em 'cmap' são verdadeiros para a licença 'lentry'."
  [cmap]
  (fn [lentry]
    (let [res (map (fn [centry]
		     (let [cval (val centry)
			   lval ((key centry) lentry)]
		       (if (nil? cval)
			 true
			 (if (coll? lval)
			   (subset? (set cval) (set lval))
			   (= cval lval))))) cmap)]
      (every? true? res))))

Este código é uma junção dos dois anteriores. A função where recebe o mapa cmap com os critérios de pesquisa, e retorna uma segunda função. Esta função recebe uma licença lentry e verifica se todos os critérios informados são verdadeiros para esta licença.

Como where é usada em conjunto com filter na função find-matches, isso fará com que todas as licenças compatíveis sejam retornadas:

(map :id (find-matches cmap *licenses*))
=> (:afl-v30 :apl-v20 :cddl-v10 :epl-v10 :lgpl-v30 :mpl-v11)

Uma das coisas legais de Clojure — e outras linguagens funcionais — é a quantidade ridícula de código necessário para resolver certos problemas. Este algoritmo, por exemplo, tem apenas 15 linhas (muito curtas) de código. Onde está seu Deus agora?!

O código da aplicação está no Github para quem tiver interesse em ver o restante do código.

Pois bem. Após quase três anos de serviços prestados e vários projetos desenvolvidos ao longo desse tempo, chegou a hora de me despedir de meu principal cliente, a GSP, uma das maiores loteadoras do Brasil. Um abraço aos amigos que ficaram, e aos que já não estão mais lá. Foi um prazer!

A principal tecnologia com que eu trabalhei nesse período foi Java, com uma pitada de Python aqui e ali. Mas, como irremediável curioso que sou, não pude deixar de brincar com outras coisas também.

Agora, no entanto, é hora de pensar no futuro. Se você precisa de um profissional com o meu perfil, ou conhece alguma empresa que precise, entre em contato comigo ou passe o link deste post adiante. Busco trabalhar com empresas ou pessoas que:

1. Tenham projetos não convencionais;
2. Tratem a tecnologia com a devida atenção;
3. Contem com equipes multi-disciplinares, com gente que ama o que faz e que busca melhorar a todo instante.

Apesar de morar no interior de São Paulo, estou aberto a propostas de outras cidades, de preferência em tempo integral.

Valeu!

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!