Recentemente comecei a brincar com o grails e precisei implementar a funcionalidade de login usando uma conta do facebook. Na minha busca sobre autenticação conheci o plugin spring-security-core do qual eu gostei muito e comecei a usar. Para autenticação no facebook existe o plugin facebook-graph que também é muito bom.
Pensando nisso resolvi mostrar como utilizar esses dois plugins juntos para implementar autenticação no facebook com spring-security-core e facebook-graph no grails.
Pra começar vou criar o projeto facebookauth, instalar os plugins e criar as classes SecUser e SecRole referentes à autenticação e controle de acesso:

$ grails create-app facebookauth
$ cd facebookauth
facebookauth$ grails install-plugin spring-seucrity-core
facebookauth$ grails install-plugin facebook-graph
facebookauth$ grails s2-quickstart org.example SecUser SecRole

O plugin spring-security-core provê um novo comando, o s2-quickstart, que serve para criar as classes de domínio referentes ao usuário e suas permissões de acesso. Não entrarei em detalhes sobre seu funcionamento pois há um artigo explicando o básico em http://blog.springsource.com/2010/08/11/simplified-spring-security-with-grails/.
Com isso foram criadas as classes SecUser, SecRole e SecUserSecRole, os controllers LoginController e LogoutController e a view auth.gsp que contém o formulário de login.
Antes de começar a brincar é preciso efetuar algumas configurações e registar sua aplicação no facebook…

1. Crie uma conta (se não tiver) no facebook
2. Acesse https://www.facebook.com/developers/createapp.php e cadastre sua aplicação com o nome fbauth
3. Após o cadastro, vá na página de edição e clique no menu Web Site, então configure Site URL como www.localhost.com e Site Domain como localhost.com. Altere o /etc/hosts mapeando o ip 127.0.0.1 para www.localhost.com
4. Pegue sua Application ID e Application Secret e adicione as linhas no arquivo grails-app/conf/Config.groovy

   facebook.applicationSecret='sua application secret aqui'
   facebook.applicationId='sua application id aqui'
   facebook.secure=true

Agora precisamos adicionar o atributo facebookId na classe SecUser.

package org.example
 
class SecUser {
 
    String username
    String password
    boolean enabled
    boolean accountExpired
    boolean accountLocked
    boolean passwordExpired
 
    String facebookId
 
    static constraints = {
        username blank: false, unique: true
        password blank: false
        facebookId blank: false, unique: true
    }
 
    static mapping = { 
        password column: '`password`'
    }   
 
    Set<SecRole> getAuthorities() {
        SecUserSecRole.findAllBySecUser(this).collect { it.secRole } as Set
    }   
}

Quando o usuário se autenticar pelo facebook, a aplicação vai receber o facebook id desse usuário e salvar no banco de dados. Então alteramos o comportamento da aplicação passando a buscar o usuário por esse id no banco, não mais por username e password.

O próximo passo é alterar a view de login para inserir um botão para autenticação via facebook. Altere o arquivo grails-app/views/login/auth.gsp inserindo o código abaixo:

<fbg:resources/>
<script type="text/javascript">
    function facebookLogin() {
        FB.getLoginStatus(function(response) {
            if (response.session) {
                window.location ="${createLink(controller:'login', action:'facebookLogin')}";
            }
        });
    }
</script>
<fb:login-button perms="email" onlogin="facebookLogin();" size="large">
    <g:message code="Login"/>
</fb:login-button>

Esse código insere um botão que ao ser clicado vai abrir um popup do facebook para o usuário se autenticar. Se o login for efetuado com sucesso, o popup será fechado e o usuário será redirecionado para a action facebookLogin no controller login.
Lembrando que o controller login foi criado anteriormente quando executamos o comando grails s2-quickstart porém a action facebookLogin não existe. Então vamos criá-la!

// outros imports existentes
 
import org.example.SecUser
import org.example.SecRole
import org.example.SecUserSecRole
 
class LoginController {
    // outros atributos e actions existentes
 
    def facebookGraphService
 
    def facebookLogin = {
        def details = facebookGraphService.getDetails()
        def facebookId = details.id
 
        def user = SecUser.findByFacebookId(facebookId)?: new SecUser(
            username: details.email,
            password: springSecurityService.encodePassword(facebookId),
            enabled: true,
            facebookId: facebookId).save(failOnError: true)
 
        def role = SecRole.findByAuthority('ROLE_FACEBOOK')?: new SecRole(
            authority:'ROLE_FACEBOOK').save(failOnError: true)
        if (! user.authorities.contains(role)) {
            SecUserSecRole.create user, role
        }
 
        SpringSecurityUtils.reauthenticate(user.username, user.password)
        redirect(controller: 'controlPanel')
    }
}

O objeto facebookGraphService é injetado automaticamente pelo grails e ao chamar facebookGraphService.getDetails() é retornado um JSONObject com o seguinte formato:

{"location":{"id":"110200955653479","name":"Rio de Janeiro, Rio de Janeiro"},"link":"http://www.facebook.com/nomedousuario","locale":"en_US","updated_time":"2011-05-11T02:58:41+0000","id":"100000552012367","first_name":"xxxx","username":"xxxx","timezone":-3,"email":"xxxx@xxx.com","verified":true,"name":"Xxxx Xxxxx","last_name":"Xxxx","gender":"male"}

Então pegamos o facebook id e verificamos se existe algum cadastro no banco. Se não houver vai cadastrar um novo usuário usando o e-mail como username e o facebook id como senha. Para nível de acesso, foi adicionada a Role ROLE_FACEBOOK, que vai ser criada caso não exista.

Para testar, vamos criar um novo controller e apenas usuários autenticados podem acessar.
O spring security possui uma anotação para ser usada nas actions onde voce define a lista de Roles que podem acessar a action. Se o usuário não possuir nenhuma dessas Roles então será redirecionado para página de login.

Vamos criar o controller grails-app/controllers/ControlPanelController.groovy com o código abaixo:

import grails.plugins.springsecurity.Secured
 
class ControlPanelController {
 
    @Secured(['ROLE_FACEBOOK']) 
    def index = { 
        render "Olá! Você fez o login pelo facebook! \o/"
    }   
}

Se tudo deu certo, quando acessar a action index do controller controlPanel o usuário será redirecionado à tela de login. Ao clicar no botão do facebook, um popup será exibido para que o usuário se identifique usando suas credenciais do facebook. Login efetuado então será redirecionado para o controller controlPanel que dessa vez vai exibir a mensagem de boas vindas.

Links

http://www.grails.org/plugin/facebook-graph
https://github.com/chechu/grails-facebook-graph
http://blog.springsource.com/2010/08/11/simplified-spring-security-with-grails/
https://github.com/gustavohenrique/grails-facebook-auth-example

Por padrão o grails utiliza o HSQLDB como banco de desenvolvimento, teste e produção. Saiba como configurar o banco de desenvolvimento para usar sqlite3.
O primeiro passo é instalar o jar do sqlite-jdbc junto com suas dependências. Para isso é necessário editar grails-app/conf/BuildConfig.groovy deixando conforme abaixo:

grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"
grails.project.dependency.resolution = {
    inherits("global")
    log "warn"
    repositories {
        grailsPlugins()
        grailsHome()
        grailsCentral()
        mavenCentral()
    }
    dependencies {
        runtime group:'org.xerial', name:'sqlite-jdbc', version:'3.6.16'
    }
}

Feito isso basta executar o comando grails install-dependency para o fazer o download e instalar a lib com suas dependências.

$ grails install-dependency

Depois criar o arquivo src/java/dialect/SQLiteDialect.java. Essa classe java pode ser encontrada no projeto hibernate-sqlite:

package dialect;
 
import java.sql.Types;
 
import org.hibernate.dialect.Dialect;
import org.hibernate.dialect.function.StandardSQLFunction;
import org.hibernate.dialect.function.SQLFunctionTemplate;
import org.hibernate.dialect.function.VarArgsSQLFunction;
import org.hibernate.Hibernate;
 
public class SQLiteDialect extends Dialect {
    public SQLiteDialect() {
        super();
        registerColumnType(Types.BIT, "integer");
        registerColumnType(Types.TINYINT, "tinyint");
        registerColumnType(Types.SMALLINT, "smallint");
        registerColumnType(Types.INTEGER, "integer");
        registerColumnType(Types.BIGINT, "bigint");
        registerColumnType(Types.FLOAT, "float");
        registerColumnType(Types.REAL, "real");
        registerColumnType(Types.DOUBLE, "double");
        registerColumnType(Types.NUMERIC, "numeric");
        registerColumnType(Types.DECIMAL, "decimal");
        registerColumnType(Types.CHAR, "char");
        registerColumnType(Types.VARCHAR, "varchar");
        registerColumnType(Types.LONGVARCHAR, "longvarchar");
        registerColumnType(Types.DATE, "date");
        registerColumnType(Types.TIME, "time");
        registerColumnType(Types.TIMESTAMP, "timestamp");
        registerColumnType(Types.BINARY, "blob");
        registerColumnType(Types.VARBINARY, "blob");
        registerColumnType(Types.LONGVARBINARY, "blob");
        // registerColumnType(Types.NULL, "null");
        registerColumnType(Types.BLOB, "blob");
        registerColumnType(Types.CLOB, "clob");
        registerColumnType(Types.BOOLEAN, "integer");
 
        registerFunction("concat", new VarArgsSQLFunction(Hibernate.STRING, "",
                "||", ""));
        registerFunction("mod", new SQLFunctionTemplate(Hibernate.INTEGER,
                "?1 % ?2"));
        registerFunction("substr", new StandardSQLFunction("substr",
                Hibernate.STRING));
        registerFunction("substring", new StandardSQLFunction("substr",
                Hibernate.STRING));
    }
 
    public boolean supportsIdentityColumns() {
        return true;
    }
 
    /*
     public boolean supportsInsertSelectIdentity() {
     return true; // As specify in NHibernate dialect
     }
     */
 
    public boolean hasDataTypeInIdentityColumn() {
        return false; // As specify in NHibernate dialect
    }
 
    /*
     public String appendIdentitySelectToInsert(String insertString) {
     return new StringBuffer(insertString.length()+30). // As specify in NHibernate dialect
     append(insertString).
     append("; ").append(getIdentitySelectString()).
     toString();
     }
     */
 
    public String getIdentityColumnString() {
        // return "integer primary key autoincrement";
        return "integer";
    }
 
    public String getIdentitySelectString() {
        return "select last_insert_rowid()";
    }
 
    public boolean supportsLimit() {
        return true;
    }
 
    public String getLimitString(String query, boolean hasOffset) {
        return new StringBuffer(query.length() + 20).append(query).append(
                hasOffset ? " limit ? offset ?" : " limit ?").toString();
    }
 
    public boolean supportsTemporaryTables() {
        return true;
    }
 
    public String getCreateTemporaryTableString() {
        return "create temporary table if not exists";
    }
 
    public boolean dropTemporaryTableAfterUse() {
        return false;
    }
 
    public boolean supportsCurrentTimestampSelection() {
        return true;
    }
 
    public boolean isCurrentTimestampSelectStringCallable() {
        return false;
    }
 
    public String getCurrentTimestampSelectString() {
        return "select current_timestamp";
    }
 
    public boolean supportsUnionAll() {
        return true;
    }
 
    public boolean hasAlterTable() {
        return false; // As specify in NHibernate dialect
    }
 
    public boolean dropConstraints() {
        return false;
    }
 
    public String getAddColumnString() {
        return "add column";
    }
 
    public String getForUpdateString() {
        return "";
    }
 
    public boolean supportsOuterJoinForUpdate() {
        return false;
    }
 
    public String getDropForeignKeyString() {
        throw new UnsupportedOperationException(
                "No drop foreign key syntax supported by SQLiteDialect");
    }
 
    public String getAddForeignKeyConstraintString(String constraintName,
            String[] foreignKey, String referencedTable, String[] primaryKey,
            boolean referencesPrimaryKey) {
        throw new UnsupportedOperationException(
                "No add foreign key syntax supported by SQLiteDialect");
    }
 
    public String getAddPrimaryKeyConstraintString(String constraintName) {
        throw new UnsupportedOperationException(
                "No add primary key syntax supported by SQLiteDialect");
    }
 
    public boolean supportsIfExistsBeforeTableName() {
        return true;
    }
 
    public boolean supportsCascadeDelete() {
        return false;
    }
}

Feito isso agora vem a configuração do banco em grails-app/conf/DataSource.groovy. Atente para a url utilizada, nela consta o path para o banco de dados sqlite3. Quanto a ação do dbCreate, fica ao critério de cada um.

development {
    dataSource {
        dbCreate = "create-drop" // one of 'create', 'create-drop','update'
        url = "jdbc:sqlite:/tmp/meubanco.sqlite3"
        logSql = "true"
        dialect = "dialect.SQLiteDialect"
        driverClassName="org.sqlite.JDBC"
    }
}

Agora é só criar as classes de modelo e executar o projeto com grails run-app para criar o banco /tmp/meubanco.sqlite3.

Introdução

Jython é o responsável por tornar possível essa façanha. Segundo a wikipedia:
“Jython é uma implementação da linguagem Python que gera bytecode para máquinas Java (JVM – Java Virtual Machine). Com ela é possível fazer o desenvolvimento de aplicações híbridas que unem código em Java e Python. Esta ferramenta é muito útil também para embutir uma linguagem para criação de scripts em aplicações que requerem este tipo de funcionalidade. Também inclui um compilador que converte código fonte Python em Java bytecode, permitindo que programadores Python possam escrever classes que possam ser utilizadas por um programa Java.”
Nesse artigo vou usar o servidor tomcat por ser open source e fácil de instalar e configurar. Para fazer deploy no tomcat, é preciso antes criar um arquivo .war. Para isso vou instalar o django-jython que além de simplificar muito a criação do war facilita o acesso à banco de dados.
Informações detalhadas sobre o funcionamento e arquitetura das tecnologias utilizadas podem ser encontradas nos seus respectivos sites.

Instalação

Antes de instalar é preciso dizer que utilizar diferentes versões do trio jython + django + django-jython pode não funcionar corretamente. Uma combinação que deu certo pra mim foram jython2.5.2, django-1.2.3 e django-jython-1.2.0, que são as versões utilizadas nesse artigo.

O primeiro passo é instalar o jython. Faça o download em no site do projeto e instale no /opt.

gustavo@notebook ~$ java -jar jython_installer-2.5.2.jar

Detalhes da instalação básica podem ser lidos na wiki http://wiki.python.org/jython/InstallationInstructions.

Considerando que o virtualenv + virtualenv wrapper estão instalados, vou criar um novo ambiente virtual e instalar o django e o django-jython.

gustavo@notebook ~$ mkvirtualenv --python=/opt/jython2.5.2/bin/jython --no-site-packages env_jython
Running virtualenv with interpreter /opt/jython2.5.2/bin/jython
New jython executable in env_jython/bin/jython
Installing setuptools............................done.
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/predeactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/postdeactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/preactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/postactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/get_env_details
(env_jython)gustavo@notebook ~$
(env_jython)gustavo@notebook ~$ pip install django==1.2.3, django-jython==1.2

Configuração

Django-jython implementa o pacote zxJDBC do jython que permite conectividade à banco de dados usando drivers JDBC.
Para utilizar o mysql é preciso fazer o download do mysql-connector-java-5.1.15-bin.jar, adiciona-lo no CLASSPATH e alterar o DATABASE_ENGINE no settings.py do projeto. Supondo que já exista o projeto myproject criado em /var/www/django, vou criar um diretório lib e copiar o mysql-connector para dentro dele:

(env_jython)gustavo@notebook ~$ mkdir -p /var/www/django/myproject/lib
(env_jython)gustavo@notebook ~$ cp mysql-connector-java-5.1.15-bin.jar /var/www/django/myproject/lib/
(env_jython)gustavo@notebook ~$ export CLASSPATH="$CLASSPATH:/var/www/django/myproject/lib/mysql-connector-java-5.1.15-bin.jar"

Alterando o settings.py:

DATABASES = { 
    'default': {
        'ENGINE': 'doj.backends.zxjdbc.mysql',
        'NAME': 'jython_example',
        'USER': 'username',
        'PASSWORD': 'pass',
        'HOST': 'localhost',
        'PORT': '3306',
    }
}
 
INSTALLED_APPS = (
    # outras apps aqui
    'doj',
)

Se o projeto possuir alguma classe no models.py, pode executar o syncdb para criar as tabelas no mysql:

(env_jython)gustavo@notebook myproject$ jython manage.py syncdb

Para finalizar, é preciso adicionar o projeto no PYTHONPATH. Insira o trecho abaixo no arquivo manage.py na linha 3:

import os, sys 
PROJECT_ROOT_PATH = os.path.dirname(os.path.abspath(__file__))
sys.path.append(PROJECT_ROOT_PATH)

Segundo a documentação é possível utilizar um test runner específico do django-jython que permite a saída dos resultados dos testes para um arquivo xml no mesmo formato dos gerados pelo Junit.

Deploy

Tomcat é fácil de instalar e possui uma interface web que permite fazer o upload do pacote tornando o deploy ridiculamente simples. Sua documentação é bastante completa e mostra em detalhes como instalar e configurar o ambiente.
O primeiro passo é gerar um pacote war para deploy no tomcat. Ao adicionar doj em INSTALLED_APPS no settings.py, o django-jython adiciona uma task no manage.py para criação de pacotes. Essa task usa como base o diretório war_skel que por algum motivo não está presente na instalação via pip. Então… vamos criar:

(env_jython)gustavo@notebook ~$ mkdir ~/.virtualenvs/env_jython/Lib/site-packages/doj/management/commands/war_skel
(env_jython)gustavo@notebook ~$ cd ~/.virtualenvs/env_jython/Lib/site-packages/doj/management/commands/war_skel
(env_jython)gustavo@notebook war_skel$ mkdir -p WEB-INF/lib WEB-INF/lib-python
(env_jython)gustavo@notebook war_skel$ touch application.py
(env_jython)gustavo@notebook war_skel$ touch WEB-INF/web.xml

Conteúdo do application.py:

from django.core.handlers import wsgi
import os
 
def handler(environ, start_response):
    os.putenv("DJANGO_SETTINGS_MODULE", "{{ settings.SETTINGS_MODULE }}")
    h = wsgi.WSGIHandler()
    return h(environ, start_response)

Conteúdo do web.xml:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
  <display-name>{{ project_name }}</display-name>
  <description>
   {{ project_name }} through WSGI with modjy
  </description>
  <context-param>
    <param-name>files.prefix</param-name> <!-- Needed by fileservlet -->
    <param-value></param-value>
   </context-param>
  <servlet>
    <servlet-name>modjy</servlet-name>
    <servlet-class>com.xhaus.modjy.ModjyJServlet</servlet-class>
    <init-param>
      <param-name>reload_on_mod</param-name>
      <param-value>1</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
 
  <servlet>
    <servlet-name>fileservlet</servlet-name>
    <servlet-class>org.jruby.webapp.FileServlet</servlet-class>
  </servlet>
 
  {% if settings.ADMIN_MEDIA_PREFIX %}
  <servlet-mapping>
    <servlet-name>fileservlet</servlet-name>
    <url-pattern>{{ settings.ADMIN_MEDIA_PREFIX }}*</url-pattern>
  </servlet-mapping>
  {% endif %}
 
  {% if settings.MEDIA_URL %}
  <servlet-mapping>
    <servlet-name>fileservlet</servlet-name>
    <url-pattern>{{ settings.MEDIA_URL }}*</url-pattern>
  </servlet-mapping>
  {% endif %}
 
  <servlet-mapping>
    <servlet-name>modjy</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>
</web-app>

Lembram do download do mysql-connector-java? Vamos copia-lo também para o diretório war_skel/WEB-INF/lib para ser inserido no pacote war criado pelo manage.py.

(env_jython)gustavo@notebook ~$ cp mysql-connector-java-5.1.15-bin.jar ~/.virtualenvs/env_jython/Lib/site-packages/doj/management/commands/war_skel/WEB-INF/lib/

Agora vem a parte de gerar o pacote war. Entre no diretório do projeto e execute a task war do manage.py. Mas antes certifique-se de ter executado o syncdb:

(env_jython)gustavo@notebook ~$ cd /var/www/django/myproject
(env_jython)gustavo@notebook myproject$ jython manage.py war

Se tudo deu certo, foi gerado um pacote war no diretório de um nível acima do projeto (/var/www/myproject.war).
Com o tomcat rodando, acesse o endereço http://localhost:8080/manager/html, clique em “Select WAR file to upload” e depois no botão deploy.

Conclusão

Embora o jython não tenha um desenvolvimento muito acelerado, vimos que já é possível utilizar um projeto django com acesso à banco de dados com muita facilidade e poucas alterações.
Em termos de desempenho não tenho qualquer informação que possa compartilhar com vocês, e caso alguém tenha algum caso de sucesso (ou mesmo insucesso) seria legal compartilhar com a comunidade.
Lembrando que o django-jython 1.2 possui backend estável apenas para os bancos de dados oracle, mysql e postgresql.

Links

http://www.jython.org/downloads.html/
http://packages.python.org/django-jython/quickstart.html
http://tomcat.apache.org/

Introdução

Nginx foi desenvolvido inicialmente em 2002 por Igor Sysoev para servir um site russo chamado Rambler que tinha milhares de requisições por dia. Entre suas características estão o baixo consumo de cpu e memória (pois usa um processo por core para gerenciar varias conexões) e o formato dos arquivos de configuração que são mais simples de entender e modificar do que os do apache.
Entre os grandes sites que o utilizam, podemos destacar o wordpress e sourceforge.

VirtualEnv é um software que permite criar um ambiente python único e exclusivo para cada projeto. Não entrarei em detalhes sobre seu funcionamento então recomendo uma lida no artigo Gerenciando Ambientes Virtuais que explica melhor sobre o assunto.

Instalação

$ sudo apt-get install nginx
$ sudo pip install virtualenv, virtualenvwrapper

Configuração

Por padrão o arquivo de configuração é o /etc/nginx/nginx.conf. Vamos modifica-lo e deixar como abaixo:

user www-data;
worker_processes 2;
 
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
 
http {
    include     /etc/nginx/mime.types;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
 
    server {
        server_name project-1-0;
        listen 80;
 
        location /media {
            autoindex on;
            alias /var/www/project_1_0/media;
            expires 31d;
        }
 
        location /admin_media {
            autoindex on;
            alias /var/www/project_1_0/media/admin;
            expires 31d;
        }
 
        location / { 
            root /var/www/project_1_0;
            fastcgi_pass 127.0.0.2:8000;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param QUERY_STRING $query_string;
            fastcgi_param CONTENT_TYPE $content_type;
            fastcgi_param CONTENT_LENGTH $content_length;
            fastcgi_param SERVER_PORT $server_port;
            fastcgi_param SERVER_NAME $server_name;
            fastcgi_param SERVER_PROTOCOL $server_protocol;
        }   
    }
 
    server {
        server_name project-1-3;
        listen 80; 
 
        location /media {
            autoindex on; 
            alias /var/www/project_1_3/media;
            expires 31d;
        }
 
        location /admin_media {
            autoindex on; 
            alias /var/www/project_1_3/media/admin;
            expires 31d;
        }
 
        location / { 
            root /var/www/project_1_3;
            fastcgi_pass 127.0.0.3:9000;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param QUERY_STRING $query_string;
            fastcgi_param CONTENT_TYPE $content_type;
            fastcgi_param CONTENT_LENGTH $content_length;
            fastcgi_param SERVER_PORT $server_port;
            fastcgi_param SERVER_NAME $server_name;
            fastcgi_param SERVER_PROTOCOL $server_protocol;
       }
    }
}

Pode-se dizer que o arquivo de configuração do nginx é uma lista de diretivas organizadas em uma estrutura lógica. Nginx é modular e cada módulo possui um conjunto específico de diretivas. Na configuração acima, todas as diretivas fazem parte do core do nginx, exceto as diretivas fastcgi que fazem parte do módulo FastCGI. Esse módulo é incluído por padrão na compilação do nginx, sendo assim não é preciso ativa-lo.
Nginx trabalha com um sistema de blocos. Um configuração mínima requer os principais blocos: http, server e location.

O bloco http é responsável por tratar requisições desse tipo. Ele pode conter um ou mais blocos server que contém configurações para um virtual host. Cada server pode ter um ou mais blocos location. Esse por sua vez possui configurações para um determinado url pattern.
Na configuração acima foram criados dois blocos server (um para cada projeto) e cada um possui três blocos location contendo configurações para arquivos estáticos e para os projetos em django.

Algumas diretivas podem ser colocadas na raiz do arquivo, fora dos blocos. Diretivas assim são chamadas de diretivas globais e afetam as demais configurações.
Sobre algumas diretivas:

user www-data
Define o usuário do nginx. Coloquei o mesmo usado pelo apache mas nada impede de usar outro. Apenas lembre-se de atribuir as devidas permissões nos diretórios dos projetos para esse user.

worker_processes 2
Define o número de processos executados por core da CPU. No meu caso, uso uma CPU Core 2 Duo.

error_log /var/log/nginx/error.log
Caminho para o arquivo de log de erros.

pid /var/run/nginx.pid
Caminho para o arquivo contendo o PID do nginx.

include /etc/nginx/mime.types
Similar à função include usada em algumas linguagens. Insere o conteúdo do arquivo externo no trecho indicado.

access_log /var/log/nginx/access.log
Caminho para o arquivo de log de acessos.

sendfile on
Se habilitado, nginx usa sendfile kernel call para gerenciar transmissão de arquivos. Se desabilitado, ele próprio gerencia a transmissão. Dependendo da localização física do arquivo, isso pode afetar a performance.

keepalive_timeout 65
Tempo de espera do servidor para fechar conexões keep-alive.

tcp_nodelay on
Habilita ou não a opção TCP_NODELAY para conexões keep-alive. TCP_NODELAY é usado para um único propósito; desabilitar o algoritmo de buffer Nagle. Deve ser habilitado apenas para aplicações que enviam frequentemente requests sem necessidade de obter um response imediato.

gzip on
Habilita compressão gzip.

gzip_disable "MSIE [1-6]\.(?!.*SV1)"
Desabilita a compressão gzip para requests cujo o User-Agent no cabeçalho http combine com a expressão regular. Nesse caso, desabilita para o internet explorer.

server_name project-1-0
Associa um ou mais hostnames ao bloco server. O nginx verifica o Host no cabeçalho do request e seleciona o primeiro bloco que combina.

listen 80
Escuta na porta 80 (padrão http).

autoindex on
Exibe os arquivos do diretório.

alias /var/www/project_1_0/media
Define a location /media como um atalho para o diretório media do projeto.

expires 31d
Define o tempo de expiração do conteúdo. Nesse caso, 31 dias.

root /var/www/project_1_0
Caminho do projeto.

fastcgi_pass 127.0.0.2:8000
Endereço e porta do servidor web usado pelo django. Ex.: python manage.py runfcgi host=127.0.0.2 port=8000 pidfile=/var/run/project_1_0.pid

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name
fastcgi_param PATH_INFO $fastcgi_script_name
fastcgi_param REQUEST_METHOD $request_method
fastcgi_param QUERY_STRING $query_string
fastcgi_param CONTENT_TYPE $content_type
fastcgi_param CONTENT_LENGTH $content_length
fastcgi_param SERVER_PORT $server_port
fastcgi_param SERVER_NAME $server_name
fastcgi_param SERVER_PROTOCOL $server_protocol
Repassa os parâmetros do request recebido pelo nginx para o servidor fastcgi.

Para finalizar a configuração, vamos editar o /etc/hosts e adicionar dois virtual hosts referentes aos projetos.

$ sudo /etc/hosts
 
127.0.0.2   project-1-0.localdomain project-1-0
127.0.0.3   project-1-3.localdomain project-1-3

Notem que estou utilizando dois IPs de loopback, ou seja, visível somente na máquina local.

Criando os Projetos

Agora vem a parte mais fácil. Vamos criar dois ambientes virtuais (env-1.0 e env-1.3) e instalar o django-1.0 em um e o django-1.3 no outro.
Dentro de cada ambiente vou criar um projeto que vai exibir a versão do django em uso.
O único pacote python obrigatório a ser instalado é o flup, que é uma coleção de módulos WSGI.
Vou usar o virtualenv + virtualenv wrapper e como já havia dito não entrarei em detalhes sobre essas ferramentas.

Ambiente 1.0

Criando o ambiente env-1.0 e o projeto dentro do diretório /var/www:

gustavo@notebook www$ mkvirtualenv --no-site-packages env-1.0
(env-1.0)gustavo@notebook www$ pip install django==1.0, flup
(env-1.0)gustavo@notebook www$ django-admin startproject project_1_0

Modificando o arquivo project_1_0/urls.py para exibir a versão do django na tela:

from django.conf.urls.defaults import *
from django.http import HttpResponse
import django
 
urlpatterns = patterns('',
    (r'^version/$', lambda request:HttpResponse(django.VERSION)),
)

Executando o servidor fastcgi:

(env-1.0)gustavo@notebook project_1_0$ python manage.py runfcgi host=127.0.0.2 port=8000 pidfile=/tmp/project_1_0.pid

Agora basta testar. Abra o navegador e digite http://project-1-0/. Se tudo deu certo então será exibido na tela a versão do Django, no caso “10final”.

Ambiente 1.3

Criando o ambiente env-1.3 e o projeto:

gustavo@notebook www$ mkvirtualenv --no-site-packages env-1.3
(env-1.3)gustavo@notebook www$ pip install django==1.3, flup
(env-1.3)gustavo@notebook www$ django-admin startproject project_1_3

Modificando o arquivo project_1_3/urls.py para exibir a versão do django na tela:

from django.conf.urls.defaults import patterns, include, url 
from django.http import HttpResponse
import django
 
urlpatterns = patterns('',
    (r'^version/$', lambda request:HttpResponse(django.VERSION)),
)

Executando o servidor fastcgi:

(env-1.3)gustavo@notebook project_1_3$ python manage.py runfcgi host=127.0.0.3 port=9000 pidfile=/tmp/project_1_3.pid

Abra o navegador e digite http://project-1-3/. Deve ser exibido na tela a versão do Django, “130final0″.

Conclusão

Esse artigo mostrou uma forma simplista de servir dois projetos usando versões diferentes do django no nginx. Na configuração foram criados blocos location para servir arquivos estáticos como /media e /admin_media porém nos projetos não me aprofundei em alterar o settings.py para isso.

O Nginx possui a diretiva include que permite inserir trechos de configuração localizados em outros arquivos no arquivo de configuração principal. Sendo assim, como boa prática, é indicado colocar a configuração de cada projeto em arquivos separados. No ubuntu 10.10 o diretório /etc/nginx possui dois sub-diretórios, sites-available e sites-enabled, similar ao apache2. A idéia é colocar os arquivos de configuração referentes a cada projeto dentro de sites-available e criar um link simbólico em sites-enabled para habilitar seu uso.
Quem quiser conhecer melhor esse fantástico servidor web, recomendo a leitura do livro Nginx HTTP Server, que inclusive serviu como base para esse artigo.

Links

Nginx Project Page
Planet Nginx
Nginx HTTP Server Book

Primeiros Passos

Configurando informações sobre o autor dos commits:

git config --global user.name "Gustavo"
git config --global user.email "gustavo@gustavohenrique.net"

É possível alterar essas informações no arquivo ~/.gitconfig

Criando um repositório local:

cd meuprojeto
git init

Para ter certeza que o repositório foi criado:

git status

Áreas de Trabalho

O git possui 4 áreas de trabalho:
1. O diretório .git que é o repositório contendo todos os arquivos versionados;
2. Working Area que é um snapshot do .git dentro de um determinado momento no tempo;
3. Stage que é um local temporário que armazena a referência para arquivos a serem versionados antes de serem commitados;
4. Stash que também é um local temporário que pode armazenar e esconder arquivos que estão no Stage.

Adicionando arquivos novos ou modificados no Stage:

git add arquivo.txt
git add *.py
git add . (para add todos os arquivos)
git add -i (para modo interativo. 1-5 ou 1,2,3,4 e -3 para retirar)

Removendo arquivos não versionados do Stage:

git rm --cached arquivo.txt
git clean -fd (remove todos arquivos e diretórios)

Removendo arquivos versionados e modificados do Stage:

git reset HEAD arquivo.txt
git reset HEAD (todos os arquivos)

Desfazendo modificações de arquivos versionados no Stage:

git checkout -- arquivo.txt

Trabalhando com o Stash:

git stash (Move todos os arquivos do Stage para o Stash)
git stash save "Mensagem" (Move todos os arquivos do Stage para o Stash e os identifica com uma mensagem)
git stash list
git stash apply (Recupera os arquivos do último Stash de volta para o Stage mantendo cópia no Stash)
git stash apply <ID> (Recupera os arquivos do Stash identificado pelo ID obtido pelo git stash list. Ex.: stash@{0})
git stash pop (Faz o mesmo que apply porém apaga os arquivos do Stash)
git stash drop <ID> (Apaga completamente o Stash)
git fsck --unreachable | grep commit (Recupera arquivos apagados do Stash)

Commits

Apenas arquivos no Stage podem ser commitados.

git commit -m "Mensagem"
git commit -a -m "Mensagem" (commita também os arquivos versionados mesmo nao estando no Stage)

Refazendo commit quando esquecer de adicionar um arquivo no Stage:

git add arquivo.txt
git commit -m "Mensagem" --amend

O amend é destrutivo e só deve ser utilizado antes do commit ter sido enviado ao servidor remoto.

Voltando commits anteriores:

git reset --hard HEAD~1 (volta ao último commit)
git reset --soft HEAD~1 (volta ao último commit e mantém os últimos arquivos no Stage)
git reset --hard XXXXXXXXXXX (Volta para o commit com a hash XXXXXXXXXXX)

Recuperando commit apagado pelo git reset:

git reflog (Para visualizar os hashs)
git merge <hash>

Logs

Visualizando logs:

git log
git log --stat (Mostra o que foi modificado em cada commit)
git log --graph (Mostra gráfico do log)
git log --pretty=oneline (Mostra os commits linha por linha)
git log --pretty=format:"%an %ad %h %s" (Exibe o autor, data, sha1 abreviado e texto do commit)
git log --since=30.minutes ou 1.hour ou 2.hours (Exibe commits dos últimos 30 minutos, 1h ou 2h)
git log --since=10.hours --until=2.hours (Exibe commits entre as últimas 10h e últimas 2h)
git log --before="2010-12-25" (Exibe commits antes do dia 25/12/2010)
git reflog (Mostra commits apagados pelo git reset)

Branches

Cada branch deve ter uma única funcionalidade. É recomendado criar um novo branch a partir do master e aplicar os merges nele para efeito de simulação.

git branch (Lista os branches)
git branch -a (Mostra também os branches do repositório remoto)
git branch -d novobranch (Apaga o branch)
git branch -D novobranch (Força a remoção do branch)
git checkout -b novobranch (Cria um branch contendo os mesmos commits do branch de origem)
git checkout -b novobranch origin/outrobranch (Cria novobranch a partir do outrobranch no repositório remoto)
git checkout -b [branch, tag, sha1]
git checkout -b <branch> v1.0 (Cria um branch a partir da tag v1.0)
git checkout master (Retorna ao branch master)
git rebase master (Atualiza um branch com o que há de novo no master)
git merge novobranch (Faz um merge do que foi feito em novobranch)
git merge novobranch --squash (Permite definir uma nova mensagem em vez das mensagens de todos os commits do novobranch)

Conflitos

Quanto mais tempo demorar para atualizar um branch a partir do master (git rebase), maior será a chance de haver conflitos depois.
O rebase é destrutivo, se estiver trabalhando em um servidor remoto deve usar o merge.

git rebase --skip (Perde o arquivo novo)
git rebase --abort (Cancela o rebase)
git rebase --continue (Para continuar após lidar com o conflito manualmente)

Repositórios

Clonando repositórios:

git clone repo1 repo2 (Clona um repositório e add o repo1 como orign no repo2)
git remote show origin (Origin é uma convenção para o primeiro remote)
git push origin (Envia o commit local para o repositório remoto)
git push origin outrobranch (O mesmo acima mas para um determinado branch)
git remote add origin repo (Adiciona um repositório como remoto)
git pull (Atualiza a partir do repositório remoto)
git pull origin outrobranch (O mesmo acima mas a partir de um determinado branch)
git remote rm origin (Remove o repositório remoto)

Trabalhando como repositórios remotos:
Antes de dar um git push, dar um git fecth e um git rebase para não criar conflitos para outros usuários.

git init --bare (Cria um repositório sem área de trabalho)
git fetch origin (Puxa novos commits do repositório remoto)
git fetch remote <branch> (Puxa novos commits do repositório remoto para o branch)
git push origin <branch> (Envia o que está no branch atual para o branch no repositório remoto)
git push origin v1.0 (Envia a tag v1.0)
git pull (Atualiza o repositório local a partir do remoto. Similar a usar "fecth" + "merge")
git pull origin <branch> (Atualiza o branch local a partir do branch remoto)

Github

Criando seu próprio projeto:
Crie um projeto pelo site do github. Em seguida, na máquina local, crie um par de chaves pública e privada, copie e cole no campo apropriado no github.

ssh-keygen -t rsa

Depois copiar o conteudo de ~/.ssh/id_rsa.pub e colar na página do github.

Fazendo um fork de um projeto:
Faça um fork de um repositório, um clone para sua máquina, altere o código, commit e no site clique no link “pull request”. O dono do repositório original deve adicionar a URL do repositório fork com git remote add usuario urlfork. Depois executar um git fecth para trazer os branches do fork. Usar git diff usuario/ para ver as alterações. Para aceitar, git merge (resolver conflitos caso apareça), criar um novo commit e enviar com o git push. O usuário que fez o fork deve executar o mesmo procedimentos para manter o fork sincronizado com o repositório original.

Patches

Trabalhando com patches:

git format-patch <branch> --stdout > patch.diff (Cria um patch)
git am patch.diff (Aplica o patch)

Tags

Uma tag é utilizada para criar uma versão de lançamento.

git tag v1.0 (Cria a tag v1.0)
git push origin v1.0 (Envia a tag v1.0)
git push --tags (Envia todas as tags)
git checkout -b <branch> v1.0 (Cria um branch a partir da tag v1.0)

git-svn

Lidando com svn:

git svn clone svn://repo (Clona um repositorio svn)
git svn dcommit (Envia commit para o repositório svn)
git svn fecth (Atualiza a partir do repositório svn)

Links

http://git-scm.com/
http://www.kernel.org/pub/software/scm/git/docs/

Apache Wicket é um framework web baseado em componentes utilizando a linguagem java. Entre suas características destaca-se o uso de XHTML puro para templates e ausência de arquivos XML para configurações.

Instalação

Há várias maneiras de instalar o Wicket mas vou abordar a mais simples que é através do Maven.

$ sudo apt-get install maven2
$ mvn archetype:create \
-DarchetypeGroupId=org.apache.wicket \
-DarchetypeArtifactId=wicket-archetype-quickstart \
-DarchetypeVersion=1.4.16 \
-DgroupId=net.gustavohenrique \
-DartifactId=introwicket \
-DinteractiveMode=false
$ cd introwicket
$ mvn eclipse:eclipse

Os comandos acima servem para fazer o download a partir dos repositórios do Maven e criar a estrutura do projeto compatível com o eclipse.
Depois é preciso importar o projeto no eclipse (File\Import\General\Existing Projects into Workspace).

Uma vez importado, nos deparamos com um erro na IDE acusando que não foi possível encontrar o diretório M2_REPO. Para corrigir basta criar a variável M2_REPO em Java Build Path apontando para o repositório local do Maven (geralmente $HOME/.m2/repository).

Configuração Inicial

Nosso exemplo criado através do Maven possui 3 arquivos: WicketApplication.java, HomePage.java e HomePage.html.
O primeiro é uma classe que extende de WebApplication, responsável pelas configurações do Wicket tal como diretório dos HTMLs, montagem de URLs, etc. Os outros 2 constituem um exemplo simples de página.

Uma página é uma classe que extende de WebPage e define via construtor quais os componentes inseridos via java. O nome do arquivo HTML deve ter o mesmo nome da classe java.
Por padrão, o Wicket procura o html da página no mesmo pacote da classe. Manter os .html junto aos .java é horrível e deixa o projeto desorganizado. Felizmente há como mudar isso.
Abra o WicketApplication.java e vamos fazer alguns ajustes na configuração:

package net.gustavohenrique;
 
import java.net.MalformedURLException;
import java.net.URL;
 
import org.apache.wicket.WicketRuntimeException;
import org.apache.wicket.protocol.http.SecondLevelCacheSessionStore;
import org.apache.wicket.protocol.http.WebApplication;
import org.apache.wicket.protocol.http.pagestore.DiskPageStore;
import org.apache.wicket.session.ISessionStore;
import org.apache.wicket.util.resource.IResourceStream;
import org.apache.wicket.util.resource.UrlResourceStream;
import org.apache.wicket.util.resource.locator.ResourceStreamLocator;
import org.apache.wicket.util.string.Strings;
 
public class WicketApplication extends WebApplication {
    public void init() {
        getMarkupSettings().setDefaultMarkupEncoding("UTF-8");
        getResourceSettings().setResourceStreamLocator(new MyOwnStreamLocator());
    }  
 
    public Class getHomePage() {
        return HomePage.class;
    }
 
    private class MyOwnStreamLocator extends ResourceStreamLocator {
        public IResourceStream locate(Class<!--?--> clazz, String path) {
            String extension = path.substring(path.lastIndexOf('.') + 1);
            String simpleFileName = Strings.lastPathComponent(clazz.getName(), '.');
            // "/" is webapp dir
            String location = "/" + simpleFileName + "." + extension;
 
            try {
                // try to load the resource from the web context
                URL url = WebApplication.get().getServletContext().getResource(location);
                if (url != null) {
                    return new UrlResourceStream(url);
                }
            }
            catch (MalformedURLException e) {
                throw new WicketRuntimeException(e);
            }
            // resource not found; fall back on class loading
            return super.locate(clazz, path);
        }
    }
 
}

O WicketApplication.java agora está configurado para usar UTF-8 como padrão e procurar os arquivos HTML dentro de src/main/webapp.

Brincando com Páginas

Uma página geralmente tem um contrutor que recebe os parâmetros via GET agrupados numa classe PageParameters similar à Map. É no construtor que adicionamos os componentes na página.

Vamos modificar o arquivo HomePage.java para adicionar um link externo e exibir o nome do autor e seu blog na tela de acordo com os parâmetros passados pela URL.

package net.gustavohenrique;
 
import org.apache.wicket.PageParameters;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.link.ExternalLink;
import org.apache.wicket.markup.html.WebPage;
 
public class HomePage extends WebPage {
    public HomePage(final PageParameters parameters) {
        String author = parameters.getString("author", "Gustavo Henrique");
        add(new Label("author", author));
 
        String blog = parameters.getString("blog", "http://gustavohenrique.net");
        add(new ExternalLink("blog", blog));
    }
}

Agora é necessário alterar HomePage.html:

        Introducao ao Wicket
 
        <span>Texto aqui sera substituido</span>
 
        <a>Clique aqui para acessar</a>

O componente Label pode ser convertido para vários elmentos HTML, não apenas um span. O texto no código HTML que estiver dentro de um Label gerado pelo wicket será ignorado no momento da renderização.
Quando se adiciona um componente, obrigatoriamente é preciso usar a propriedade wicket:id="id_do_componente" caso contrário será lançada uma Exception.
Em modo de produção, o termo wicket:id some (fica apenas id) e as Exceptions lançadas são exibidas como erro 500.

Lidando com Formulários

Em Wicket quase tudo é componente. Para tirar melhor proveito do framework e evitar repetição de código é preciso entender como “componentizar” as coisas.
Imagine que você tenha 10 formulários e todos eles têm em comum os campos telefone, celular e email. A idéia de componentizar seria 1. Criar um form com esses componentes e todos os outros herdariam dele 2. Criar um componente (Panel) agrupando esses componentes e todos os forms adicionariam um único componente (1 Panel contendo 3 TextFields) ou 3. Juntar as duas soluções.
Conseguiram entender a idéia de componentização? Abaixo um exemplo sobre o que estou falando:

public class ContactPanel extends Panel {
    public ContactPanel(String id) {
        super(id);
        add(new TextField("phone"));
        add(new TextField("mobile"));
        add(new TextField("email"));
    }
}
 
public class CustomerForm extends Form {
    public CustomerForm() {
        add(new ContactPanel());
    }
}

Continuando nossa brincadeira com o framework…
Vamos criar um formulário para entrar com nome, idade, site e e-mail do autor.

package net.gustavohenrique;
 
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.RequiredTextField;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.model.Model;
 
public class AuthorForm extends Form {
 
    private RequiredTextField name;
    private TextField site;
    private TextField email;
    private TextField age;
    private Label result;
 
    public AuthorForm(String id) {
        super(id);
        add(name = new RequiredTextField("name", new Model("")));
        add(age = new TextField("age", new Model("")));
        add(site = new TextField("site", new Model("")));
        add(email = new TextField("email", new Model("")));
        add(result = new Label("result", new Model("")));
        add(new FeedbackPanel("errors"));
    }
 
    protected void onSubmit() {
        String message = "Olá " + name.getValue() +
                         ", você tem " + age.getValue() +
                         ", seu site é " + site.getValue() +
                         " e seu e-mail é " + email.getValue();
        addOrReplace(result = new Label("result", new Model(message)));
    }
}

E é claro, precisamos incluir o form no HTML:

        Introducao ao Wicket
 
        <span>Texto aqui sera substituido</span>
 
        <a>Clique aqui para acessar</a>
<form method="POST">
<fieldset>
                <label>Nome</label>
<input type="text" />
                <label>Age</label>
<input type="text" />
                <label>Site</label>
<input type="text" />
                <label>E-mail</label>
<input type="text" />
<input type="submit" value="Go" /></fieldset>
</form>

A novidade é o uso do RequiredTextField, onSubmit, Model e FeedbackPanel.
Wicket possui recursos para validações simples como preenchimento obrigatório (required), apenas números, número máximo e mínimo de caracteres, etc. No caso o RequiredTextField requer preenchimento obrigatório.
Mensagens de erro validação podem ser personalizas e definidas em um arquivo de properties a parte. Quando ocorre um erro de validação, é chamado o método onError() em vez do onSubmit(). O FeedbackPanel é um componente que automaticamente exibe as mensagens de erros de validação.
É de boa prática usar Models Objects para guardar valores em componentes. Model é class que implementa IModel que por sua vez é uma interface que abstrai o tipo de dado que o componente recebe como valor. Varia de acordo com a implementação de cada componente. Em componentes Label e TextField, o Model pega o toString() do objeto passado. Já em um ListView é preciso que o objeto implemente uma lista (java.util.List).

Conclusão

Wicket é um framework baseado em componentes e talvez e, IMHO, esse seja seu maior defeito ou qualidade, depende de cada um. Essa foi uma apresentação básica bem superficial com o intuito de ser um ponto de partida para estudos mais aprofundados a quem achar que vale a pena investir tempo nesse framework.

Links relacionados:

http://wicket.apache.org
http://wicketstuff.org/wicket14/
https://cwiki.apache.org/WICKET/

Após alguns meses de abandono e alguns comentários não respondidos (sorry, wordpress mal configurado não me notificou por e-mail), pretendo (de novo) voltar a blogar.

2010 foi incrível. Conheci muita gente, fui em encontros/eventos de várias comunidades de software do RJ e tive uma grande evolução técnica principalmente em java e agile. Investi em ações, vi o final horrível de Lost e também comprei um playstation 3. Tinha três objetivos para o ano passado: dobrar meu salário, ganhar experiência em java e participar mais de projetos open source. A parte boa é que consegui os dois primeiros e a ruim é que eles atrapalharam o terceiro.

Em 2011 pretendo ler mais no kindle, trabalhar menos com java (j2ee) e quem sabe iniciar ou me juntar à alguma startup. Blogar vai ser meu termômetro. Enquanto estiver blogando, sinal de que estou seguindo pelo caminho que tracei. Eu acho.
Àqueles que visitaram esse humilde blog desatualizado, feliz ano novo!!!

Essa semana foi lançado o site tipsforlinux.com, meu projeto pessoal open source desenvolvido em Django. O site é um blog, cuja função é ser um repositório de dicas e truques sobre GNU/Linux. Possui um visual simples e leve possibilitando uma navegação agradável até mesmo nos navegadores em modo texto. O site não chega a ser uma idéia inovadora, na verdade ele surgiu da vontade de programar novamente em Django.
O projeto utiliza as apps django-tagging, django-pagination, django-socialauth, django-contact-form, python-twitter, comments e sitemaps e o codigo está disponibilizado no github.

Site:
http://tipsforlinux.com

Código:
http://github.com/gustavohenrique/TipsForLinux

Django é o framework ideal para os que buscam agilidade e simplicidade. Um dos recursos que mais gosto é o Admin, uma poderosa interface para produzir conteúdo. Simples de usar, bastante customizável e com um visual agradável, bastante útil durante a fase de desenvolvimento e ideal para pequenos projetos com ausência de um designer na equipe. Outras caracteristicas interessantes são:

• API para autenticação de usuários com suporte à grupos e níveis de acesso, que permite a criação de permissões personalizadas para cada página, classe ou método;
• Sistema de cache que torna mais rápido o carregamento das páginas e o acesso ao banco de dados;
• Sistema de templates utilizando HTML, com suporte a herança e Template Tags – uma linguagem de templates para manipulação de conteúdo dinamicamente. É possível criar suas próprias com código Python e utiliza-las em qualquer parte do projeto;
• Trabalhar com formulários e extremamente simples e há diversos tipos de validações disponíveis como por exemplo e-mail, cpf e endereço IP;
• ORM compatível com os bancos de dados mais utilizados no mercado;
• Paginação é uma tarefa trivial;
• Incrível suporte à internacionalização;
• É multiplataforma;
• Documentação bem completa e de fácil entendimento;
• Comunidade altamente ativa.

Por utilizar Python, é compatível com uma grande variedade de bibliotecas para trabalhar com xml, json, webservices, restful, graficos, relatorios, imagens e etc. Sem dúvida uma ótima escolha para quem procura agilidade com produtividade.

Essa foi minha opinião expressada no debate Django vs. Ruby on Rails, matéria da revista TiDigital (edição 16 de junho/2010).

Cada vez mais há um distanciamento de computadores isolados para uma tecnologia mais ampla, conectando dispositivos móveis em redes distribuídas. Tal arquitetura computacional traz grandes vantagens como a Continuidade de Serviços, que garante o funcionamento de serviços básicos, e o Armazenamento Distribuído, que torna dados e informações acessíveis em caso de desastres. Isso se deve ao avanço da Computação nas Nuvens, uma evolução da Computação Móvel, cujo conceito é compartilhar dados e serviços através da interligação de sistemas, sempre disponíveis, não mais locais, mas nas nuvens . Os dispositivos, como um computador ou um celular, apenas solicitam os serviços e apresentam os resultados. Mas não pára por aí. Um professor chamado Mark Weiser, cientista chefe do centro de pesquisas da Xerox, por meio de um artigo chamado “O Computador do Século 21”, introduziu um novo conceito chamado Computação Ubíqua, cuja idéia principal é focar a atenção do usuário na tarefa e não na ferramenta.
Considerada uma evolução da computação em nuvem, a Computação Ubíqua, também conhecida como Ubicomp, é uma visão de que humanos estejam cercados por computadores interligados rodando sistemas inteligentes capazes de captar variações no ambiente e entender, de acordo com gestos e expressões dos usuários, qual tarefa deve executar, de forma que as pessoas sequer percebam que estão dando comandos a um computador. Resumindo, é a união entre a Computação nas Nuvens e a Computação Pervasiva (sistemas distribuídos e imperceptíveis ao usuário).
O grande desafio para tornar a Ubicomp uma realidade, de forma mais natural possível, é o desenvolvimento de Interfaces Naturais como reconhecimento de voz e escrita, ambientes inteligentes, realidade aumentada e etc. Os computadores estão se integrando cada dia mais na vida das pessoas e a tendência é que consigam interpretar, e não traduzir, os comandos dos usuários.
Aos mais interessados, há um artigo mais completo escrito pelo Fabiano Domingues no Guia do Hardware.net que pode ser acessado pela URL http://www.guiadohardware.net/artigos/computacao-ubiqua/.