Andrews Medina

O Passenger ou mod_rails, é uma maneira de fazer deploy de aplicações Ruby/Rails de maneira simples e fácil no Apache. Nesse post não vou explicar detalhes sobre ele, mas, há esse post do Akita sobre o Passenger que é bem interessante. O Passenger suporta o padrão WSGI, e com isso é possível fazer o deploy de uma aplicação feita em Django utilizando o Passenger.

Antes de explicar sobre como fazer isso, que é algo extremamente simples e fácil. Tem um fato interessante nisso tudo. Porque uma ferramenta para deploy de aplicações Rails suportaria Django?

A resposta (segundo o Akita) é Leah Culver. Acho que se a moda pegar, veremos vários 'easy deployers' aparecendo.

Antes de voltar ao tema principal deste post, outra feliz coincidência é , no qual ele explica mais detalhadamente sobre o WSGI, que tem tudo haver com o assunto.

E agora vamos lá:

Primeiramente é necessário instalar o Passenger. Isso está bem documentado no site do próprio passenger: http://www.modrails.com/install.html por isso não vou descrever esse passo.

Para fazer o Django funcionar é necessário apenas criar um script que 'execute' o Django com o seu handler wsgi e configurar o diretório onde fica esse script, nos arquivos de configuração do Apache.

Vamos começar criando nosso arquivo que executará o WSGI. Vamos chamar ele de passenger_wsgi.py

#!/usr/bin/env python



import os, sys



sys.path.insert(0, '/home/seunome/projetos/') #diretorio onde fica seus projetos



os.environ['DJANGO_SETTINGS_MODULE'] = 'meuprojeto.settings'



import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

Feito isso vamos configurar o apache. Setando a variável DocumentRoot com o diretório onde está o seu script wsgi + 'public'. Devido a uma convenção (Rails) a pasta tem que ter esse diretório 'public'

Para exemplificar, se o seu projeto tiver o diretorio '/var/www/meuprojeto/' o DocumentRoot tem que ser '/var/www/meuprojeto/public'

<VirtualHost *>



DocumentRoot /var/www/meuprojeto/public



</VirtualHost>

Na minha conclusão, se sua hospedagem suportar o mod_wsgi use ele. Senão suportar mod_wsgi e suportar passenger, use o passenger!

Em breve falarei mais sobre o Django no passenger.

Uma pergunta que frequentemente é feita na lista ou no canal (#django-br) da comunidade Django brasileira e quase sempre não é respondida é: 'Como utilizar o widget de data do admin do Django em um formulário normal?'.

O admin do Django é uma das ferramentas mais espetaculares do framework, e um dos motivos disso são seus belos widgets. Um dos principais widgets é o widget para datas. Esse campo trabalha com datas de uma forma bacana, sem contar com o calendário que vem com ele.

Mas, voltando à pergunta, é possível sim utilizar esse widget, e se estiver utilizando o branch do newforms-admin isso é muito fácil.

Para demonstrar isso através da prática, iremos precisar de um model. Para isso vamos criar um model Noticia, para um sistema de notícias onde seus campos seriam: titulo, conteúdo e data:

class Noticia:

    titulo = models.CharField(max_length=255)

    conteudo = models.TextField()

    data = models.DateTimeField()

Agora vamos criar um formulário para cadastrar as notícias. Eu geralmente gosto de criar um arquivo chamado forms.py onde eu coloco as classes responsáveis pelos meus formulários.

Eu vou criar um formulário utilizando o ModelForm que gera um formulário a partir de um model. E irei sobrescrever o campo data, configurando ele para utilizar o widget de data do newforms-admin.

É preciso também, importar as classes e métodos necessário para utilizar o newforms, ModelForm e as classes referentes ao widget que vamos utilizar.

from django.newforms import ModelForm

from django import newforms as forms

from django.contrib.admin.widgets import AdminDateWidget



from models import *



class NoticiaForm(ModelForm):



    data = forms.DateTimeField(widget=AdminDateWidget())

   

    class Meta:

        model = Noticia

Vamos então criar uma view que enviará para uma template o nosso formulário.

from django.shortcuts import render_to_response



from forms import *



def index(request):

    form = NoticiaForm()

    return render_to_response('index.html', {'form':form})

Agora vamos criar a template que exibirá nosso formulário, lembrando de importar os javascripts e arquivos css necessários para exibir o widget de data corretamente.

<html>

<head>

<link rel="stylesheet" type="text/css" href="/admin_media/css/base.css" />

<link rel="stylesheet" type="text/css" href="/admin_media/css/forms.css" />

<link rel="stylesheet" type="text/css" href="/admin_media/css/widgets.css" />

<script type="text/javascript" src="/admin/jsi18n/"></script>

<script src="/admin_media/js/core.js"></script>

<script src="/admin_media/js/dateparse.js"></script>

<script src="/admin_media/js/timeparse.js"></script>

<script src="/admin_media/js/calendar.js"></script>

<script src="/admin_media/js/admin/DateTimeShortcuts.js" type="text/javascript"></script>

</head>

<body>

{{ form.as_p }}

</body>

</html>

E finalmente vamos configurar as urls.

from django.conf.urls.defaults import *

from noticias.views import *

from django.contrib import admin



urlpatterns = patterns('',



    (r'^$', index),

    ('^admin/(.*)', admin.site.root),

)

Lembrando que para o widget funcionar corretamente é preciso que o admin esteja adicionado nas INSTALED_APPS no arquivo settings.py do seu projeto e que o admin esteja adicionado no urls.py.

Para não ter erro estou adicionando um arquivo compactado com um projeto exemplo para vocês fazerem o download.

Essa semana Jacob enviou para a lista de desenvolvimento do Django um e-mail falando sobre o que terá no Django 1.0 e qual será o seu cronograma.

A previsão do lançamento será em setembro e até lá será lançado um alpha, dois beta, um release candidate para ai sim ser lançado o tão esperado e pedido 1.0. Antes de cada lançamento serão feitos sprints para agilizar o desenvolvimento.

No e-mail Jacob falou também o que terá no 1.0, o que não terá e o que possivelmente entrará nessa versão. Ter o newforms-admin, remover definitivamente o old-forms e estar 100% conforme o WSGI são as features que essenciais para que o 1.0 seja lançado.

Nas possível features estão muitas coisas legais como: melhoria do desempenho dos signals, model-level validation, many-to-many intermediários, geoDjango e muito mais...

Vamos torcer e colaborar para que tudo ocorra bem e em setembro saia o 1.0.

Hoje dia 25 de maio é oficialmente o 'Dia da Toalha'. Um dia onde todos os mochileiros em todo universo homenageiam um dos maiores autores de ficção científica: Douglas Adams, escritor da série 'O Mochileiro das Galáxias'.

Segundo 'O Guia dos Mochileiros das Galáxias', a toalha é uma ferramenta essencial para um mochileiro, afinal é possível usar uma toalha como agasalho, cobertor, vela para uma jangada, entre outras funções. Ah, e úmida uma toalha vira uma ótima arma para lutas corpo a corpo.

Eu como um bom mochileiro levo sempre minha toalha e 'o guia' em minha mochila.

Dia 28/06/2008 será o primeiro GamesulMT (Encontro Acadêmico de Desenvolvimento de Jogos do Sul de Mato Grosso) que acontecerá na UNIR/FAIR (http://www.unir-roo.br).

O evento contará com 4 palestras e 3 mini-cursos, lembrando que as palestras são gratuitas e os mini-cursos custam R$ 15,00:

Palestras:

Projeto de jogos na UFMT - Leandro Machado, Msc. Mara Dota, Msc. Soraia Prietch

Projeto de jogos na UFMT - Modelagem de Jogos - Gustavo Xavier Santana

Desenvolvimento de jogos computacionais utilizando Software Livre - João Mendes de Oliveira Neto

Desenvolvendo jogos e maneira rápida, fácil e indolor com Python - Bel. Andrews Patrick Rocha Medina

Mini-cursos:

Desenvolvimento de um jogo do início ao fim em 6 horas - Bel. Andrews Patrick Rocha Medina

Desenvolvendo jogos usando a API ALLEGRO - João Mendes de Oliveira Neto

Treinamento Básico em GIMP - Isis e Itamar

Como podem ver vou marcar presença com uma palestra e um mini-curso. Na palestra falarei como o Python e suas apis e frameworks podem auxiliar no desenvolvimento de jogos tornando o desenvolvimento de jogos ágil, fácil e totalmente indolor. E vou comprovar essa agilidade, facilidade nomini-curso que terá o propósito de desenvolver um jogo em 6 horas, mostrando a parte do Game Design, do design e desenvolvimento do jogo. E o jogo não será um pong.

Para quem acha o desafio de desenvolver um jogo em 6 horas algo impossível, eu e a equipe do OLPyC no FISL desenvolvemos um jogo para XO em 6 horas mal programadas, provando mais uma vez que Python pode fazer diferença também no desenvolvimento de jogos.

O evento começará as 8h da manhã, espero ver todos lá.