Technology is nothing. What’s important is that you have a faith in people, that they’re basically good and smart, and if you give them tools, they’ll do wonderful things with them. It’s not the tools that you have faith in — tools are just tools. They work, or they don’t work. It’s people you have faith in or not. Yeah, sure, I’m still optimistic I mean, I get pessimistic sometimes but not for long.

Steve Jobs – 1994

Diante do bombardeio diário de novidades, um computeiro deve se sentir tentado a acompanhar todas as discussões sobre os produtos e as tecnologias da moda: no último meses tivemos um ou dois iPhone killers, uma linguagem de programação “abençoada”, o estouro do Cloud Computing, um “sistema operacional“,  o fim da indústria editorial e o surgimento do computador para todos os outros.

E nós aqui, passamos boa parte do ano calados. Trabalhando. Até poderíamos ter escrito N+1 blog posts opinando sobre cada uma dessas novidades. Mas nenhuma dessas nos ajudou a entender melhor o mundo, ou a construir algo melhor. Então, passou batido. Sem contar que estávamos muito mais interessados em produzir algo de fato, ao invés de simplesmente sermos mais um palpiteiro na poltrona.

É uma revolução por minuto, que muitos tentam discutir, comparar, medir, organizar. É tudo bobagem. É tudo tecnologia, e tecnologia não é um fim em si mesmo. Por favor, saiam do Google Wave, parem de perder o presente discutindo o futuro. Construir o futuro é muito mais divertido.

Primeiro post do ano, e nada melhor do que começar com novidades (antes tarde do que nunca)!

Os assinantes de RSS do Job4Dev mais atentos devem ter percebido uma mensagem nova que passou a aparecer no rodapé de cada anúncio. Cito:

Parece que você está se cadastrando (ou prestes a se cadastrar) para o feed de todos os anúncios. Nenhum problema por nossa parte, mas tenha em mente que o volume de anúncios pode ser excessivo. Você pode se interessar em dar uma olhada em nossa página para filtrar os tipos de empregos, e obter feeds específicos, baseado na localização e nas palavras-chaves.

Alguns talvez tenham visto a mensagem em inglês. Fato é que algo parece ter mudado. E mudou: graças ao trabalho do Raphael, o Job4Dev evoluiu e chegou à versão 3.0 com grandes pretensões. Job4Dev pretende virar global, mas mantendo a qualidade local: ruído ZERO, essa é a nossa meta!

Aqueles que frequentam o site  devem ter notado que mais vagas internacionais estão sendo cadastradas, e que um versão em inglês está disponível. Acessando a URL http://www.job4dev.com.br, o site estará sempre em português, mas ao acessar http://job4dev.com, a língua irá variar com as preferências do seu navegador.

Para tentar oferecer as vagas mais próximas do visitante, adicionamos um mecanismo de georeferenciamento na página principal: o Job4Dev descobre a sua localização e mostra vagas da cidade, ou da província (estado) ou do país. Por exemplo, neste momento em que vos escrevo, estou em Sampa e ao acessar o site, vejo apenas vagas para a capital do estado. Está em Sampa mas quer procurar vagas no Rio ou em Campinas? Sem problemas: clique em no link Vagas (ou Jobs), e veja a listagem completa de anúncios, com opções de filtros por palavra-chave, tipo de contrato, localização e por aí vai.

Por falar em filtros, a partir de agora é possível agora criar feeds RSS específicos para suas necessidades. Entre no site, crie o filtro desejado e clique no link feed, que aparecerá no quadro amarelo no topo da página.

Em relação às vagas e empresas, aumentamos o nosso lado colaborativo, adicionando um mecanismo de comentários para usuários cadastrados. Gosta da empresa? Quer dar mais informações? Acha que a vaga vale a pena? Comente. Assim, estamos promovendo a criação de uma base de dados de empresas de tecnologia do mundo todo, permitindo uma escolha altamente consciente e embasada em opiniões alheias.

O formulário de cadastro agora diferencia usuários que buscam vagas daqueles que desejam cadastrar novas vagas. Um passo a mais na oferta de serviços específicos para cada um destes públicos, como por exemplo o cadastro de currículos online (já disponível também para usuários cadastrados).

Vale citar também pequenas modificações, como a simplificação do fluxo de cadastro de anúncios (com link para adição de vaga diretamente da página de empresa), e mecanismo para troca de senha (esta que já veio tarde demais….mas novamente: antes tarde do que nunca).

Resumindo, é isso! Feliz 2010 para todos.

Um dos motivos que diminuiram minha participação neste blog nos últimos meses foi o meu trabalho intenso no SigaSeuTime. Entre os sócios no projeto, sou o único desenvolvedor, e a lista de tarefas não para de crescer. Gostaria de contar aqui um problema simples que tive que resolver, e que pode interessar outros desenvolvedores.

No mês passado, colocamos no ar dois bots, um para o MSN e outro para o GTalk/Orkut, que podem ser utilizados como alternativa para o Twitter para receber notícias e jogos ao vivo. Os bots funcionam como usuários normais: você adiciona o dito cujo na sua lista de amigos (usando o email sigaseutime@siga.st) e passa a receber mensagens. Ao contrário do Twitter, onde cada canal representa um time (@sigaFlamengo, @sigaVasco, @sigaCorinthians, etc…), nos bots um usuário pode selecionar um ou mais times, enviando a mensagem siga <nomedotime>.

Internamente, eu mantenho duas versões de nomes para cada canal do sistema: o nome completo (Corinthians, São Paulo, Palmeiras, Santo André, Seleção Brasileira, etc..) e um slug (corinthians, saopaulo, palmeiras, santoandre, selecaobr). Pra quem não sabe, um slug pode ser definido como uma versão URL Friendly do nome: sem acentos, espaços em branco e caracteres não ASCII. Originalmente, os bots aceitavam o uso de um dos dois nomes no comando. Por exemplo, siga Santo André ou siga santoandre.

Obviamente, fomos recebendo feedbacks de usuários que não conseguiam cadastrar um time. Em geral, isto acontecia com times com nomes compostos e/ou acentos. Analisei o log e percebi que era muito comum alguém digitar siga sao paulo por exemplo. Como o cliente tem sempre razão, decidi que um algoritmo mais espertinho de leitura do nome se fazia necessário: criei então uma funcionalidade de conversão de nomes para slugs. A primeira parte foi fácil: colocar tudo em letras minúsculas, remover espaços e outros simbolos não conformes.

Faltava a parte mais importantes: converter caracteres acentuados em caracteres não acentuados. afinal, para efeito de comparação, são e sao deveriam ser equivalentes. Inicialmente pensei em criar uma tabelinha de conversão simples, mas desisti porque a chance de alguém digitar um caso não contemplado era muito grande. Fui então pesquisar na Internet, e descobri que o UNICODE já prevê esta funcionalidade, e já tem tudo mapeado. Ainda bem que existem cientistas da computação prevenidos no mundo!

Este recurso se chama Normalização (como não pensei nisso antes….), e oferece 4 formas distintas: NFD, NDC, NFKC, e NFKD. Cada uma tem suas particularidades, e aconselho a quem se interessar pelo assunto pesquisar no site do UNICODE: http://www.unicode.org/faq/normalization.html.

O essencial é entender que existe um mapeamento de caracteres compostos (por exemplo ç = c + cedilha, ou ã = a + ˜), e que existem bibliotecas em algumas linguagens que implementam este mapeamento e que podem ser utilizadas para fazer a conversão. Vou dar um exemplo em Java e em Python:

Java:

import java.text.Normalizer;
import java.text.Normalizer.Form;
Normalizer.normalize(string, Form.NFD);

Python:

from unicodedata import normalize
unicodedata.normalize(forma, string)#forma pode ser 'NFC', 'NFD', 'NFKC' ou 'NFKD'

Utilizando este recurso, eu consigo facilmente converter SANto André, Santo Andre, SANTOandre ou qualquer outra combinação para o formato que eu espero: santoandre.

A funcionalidade de geração automática (de qualidade) de uma área de administração em projetos Django foi talvez a grande responsável por eu preferir esse framework ao Turbogears (junto com o fato do Turbogears ser na verdade uma federação de pequenos projetos). Pode parecer bobo, mas desenvolver uma área de admin bem feita é custoso, e ter uma versão básica bem feita de graça pode ser um grande diferencial na hora de construir algo novo.

Dentre as várias funções interessantes oferecidas por este admin, o histórico de operações sobre os objetos merece destaque:  cada ação efetuada sobre todo e qualquer objeto através do admin é gravada em uma tabela de histórico gerada automaticamente (data, usuário, objeto modificado, natureza da modificação), que pode ser visualizada em uma tabela web.

Infelizmente, este histórico é gerado automaticamente apenas para ações efetuadas através do admin. Recentemente, tive a necessidade de gravar o histórico de operações efetuadas por tarefas em background no SigaSeuTime (envio de anúncios comerciais para o Twitter), que me permitissem controlar de forma unificada e centralizada o bom funcionamento do sistema.

Pesquisando um pouco, descobri como fazer isso de forma simples com um código pequeno, que vou reproduzir abaixo:

from django.contrib.admin.models import LogEntry
from django.contrib.contenttypes.models import ContentType


def gravahistorico(objeto, mensagem, usuario):
         LogEntry.objects.logaction(
                    userid         = usuario.id,
                    contenttypeid = ContentType.objects.getformodel(objeto).pk,
                   objectid       = objeto.pk,
                   objectrepr     = mensagem, # Message you want to show in admin action list
                   changemessage  = mensagem, # I used same
                   action_flag     = 4
          )

Chamando este código, ações sobre um objeto serão gravadas na tabela de histórico, e poderão ser vista na área de administração do Django. Simples e extremamente útil.

Com o advento e crescimento dos projetos Open Source, se intensificou o conceito de que em última instância a melhor documentação de um projeto é o seu próprio código fonte. Concordo plenamente com isso! Em projetos ativos, manter uma documentação sobre arquitetura completamente atualizada é uma tarefa ingrata (sobretudo se seguirmos os moldes de artefatos exigidos pelas metodologias waterfall), e documentação errada é a pior coisa que pode existir.

Em projetos Open Source, onde os recursos são muitas vezes escassos e não se pode dar o luxo de manter uma pessoa apenas para manter tudo atualizado, a necessidade de uma documentação simplificada impera. E a necessidade de um código organizado também.

O problema é que muita gente levou ao pé da letra esse conceito, e chegou-se à conclusão de que comentários são supérfluos, afinal o próprio CÓDIGO é a documentação. Resultado: tenho cada vez mais visto toneladas de linhas de código sem um puto de um comentário.

Ah, mas com nomes incrivelmente sugestivos: apagaORegistroDoUsuarioEMandeMensagemdeDesolePraEle.

Senhores e Senhoras, o código fluente!

Plagiando um exemplo que eu peguei no iMasters:

Vendedor.deNome("Abreu").
                 vende().
                 paraCliente("Rafael").
                 oProduto("Mouse Verde").
                 oProduto("Teclado de Pano").
                 comDescontoDe(20).
                 mostrandoDetalhes();

Não posso dizer que não entendo o que este código faz! Até minha avó de 92 anos entenderia. Lindo.

O problema é que por mais que se empacote todas as funções com nomes extremamente sugestivos, que se crie DSLs para se esconder a complexidade,  que as variáveis sejam extremamente bem nomeadas, alguma hora os detalhes sórdidos do código vão começar a aparecer: bases de dados, queries, estruturas de dados, rede, integrações com outra bibliotecas, etc…

(Aaaaaaaaa, você não trabalha com bibliotecas, nem com BD, nem com rede, e apenas integra código fluente? Meus pêsames, o mundo da computação é bem mais interessante e divertido do que isso. Próximo…)

E na hora que chegamos aos detalhes sórdidos, por mais que o nome do método explique o que está se fazendo, pode ficar a dúvida: porque o método faz isso desta forma? E entender o porque das coisas é essencial se você está tendo que corrigir/modificar/aprimorar/integrar/analisar código legado. Sim, porque o que torna o código legado tão infernal de se mexer é justamente entender O QUE SE PASSAVA PELA CABEÇA DO DESGRAÇADO QUE ESCREVEU AQUILO!

Exercício: pegue um código que você escreveu há 6 meses atrás, de um projeto do qual você não participa mais, e tente entender todas as minúcias….foi sofrido? Imagino que sim. Agora imagine o pobre coitado do estagiário que está tendo que resolver um bug que ocorre naquele trecho!

Muito se fala por aí que código tem que ser escrito para ser lido por seres humanos e não por máquinas. Uma máquina apenas interpreta aquilo que escrevemos, e não está nem aí se faz sentido ou não. Ao contrário de seres humanos. Todos ficamos muito felizes quando entramos no javadoc da Sun, e encontramos alguns detalhes de implementação interessantes de métodos cujos nomes muitas vezes são bem explicitos. Como por exemplo o remove(String key) de uma Collection. Ninguém tem dúvidas do que ele faz, mas o que acontece se eu passar um valor nulo? Ou se passar um objeto que não existe?

Comentários são uma ferramenta muito útil, presente em qualquer linguagem, e que fazem parte do código.  Devem ser utilizados com inteligência, para facilitar a vida de todo mundo, tornar o código realmente uma documentação completa e inteligente e poupar horas, cabelos e neurônios de desenvolvedores cansados, estressados ou que simplesmente não querem passar horas decifrando a mente alheia.

Eu já escrevi uma boa quantidade de linhas de código na minha vida. Talvez 100k, talvez mais. Não faço idéia. Com certeza este número diminuiu muito depois de eu ter começado a programar em Python .

E quando releio alguns destes códigos, considero que na média a qualidade é boa (e pelos feedbacks de colegas, outras pessoas devem concordar com isso). Mas se me perguntarem o que me incomoda no meu estilo de codificar (sim, porque codificar é muito parecido com escrever livros: requer prática, cultura geral, leitura de outros textos, etc…) eu responderei na lata: a minha total falta de padronização da língua utilizada na nomenclatura de classes, métodos, atributos. Até hoje eu não me decido por escrever 100% em inglês, ou 100% em português. E faço isso sem perceber.

Em tempos de internet, globalização, software livre e colaboração, me agrada a idéia de existir uma língua universal para desenvolvimento de código. Facilita o intercâmbio de informações com pessoas de outros países, permite que se entre em mundos diferentes, quebrando a barreira da língua.

E inglês é a língua ideal para isso, simplesmente porque ela é a lingua internacional de fato (talvez um dia tenhamos que codificar em mandarin, mas isso é tema pra outra conversa). Além disso, boa parte das linguagens hoje (perto de 100% eu diria) utilizam primitivas e bibliotecas em inglês, para não se falar dos padrões e codificação. Por exemplo, em Java é padrão usar getters e setters para se ter acesso à informações internas a um objeto. Fica razoavelmente ridículo escrever getMinhaVariavel…mas ainda assim, eu faço isso com certa frequência.

Isto porque,  pior do que ter um código não universal (escrito em português por exemplo) é ter um código escrito em inglês errado. Eu com certeza já escrevi vários métodos que soariam ridículos para um falante nativo, e já li uma tonelada que soavam ridículo até pra mim. O problema é que, apesar de ler constantemente textos de computação em inglês e me virar bastante bem na língua do Tio Sam, na hora do cansaço ou da necessidade de termos mais rebuscados, as vezes o cérebro pede arrego. E aí vai em português mesmo. Já tive casos de precisar codificar conceitos ligados ao plantio de eucaliptos para produçao de papel, e fui atrás de termos em inglês para colheita, plantio, talhão, gleba….o resultado foi bom, mas tomou um bom tempo.

Ou seja: tenho que aprimorar meu inglês.

Em tempo: recentemente dei uma folheada em um livro sobre SCRUM, escrito em português por um brasileiro, e desisti de comprar o dito cujo quando vi um “printar” no meio de uma frase. Parece que do mesmo jeito que as vezes eu tenho preguiça de procurar termos em inglês, certas pessoas tem preguiça de escrever direito em português.

Last, but not least: a questão de escrever em inglês entrou em pauta várias vezes no Log4Dev. Temos pelo menos um expert no assunto, Lullis, tradutor nas horas vagas. Com certeza, mudar de língua tornaria nosso blog internacional, e fama e riqueza bateriam às nossas portas. Mas, por modéstia, vontade de manter uma vida calma e anônima, e falta de proficiência absoluta, decidimos manter os textos em português. Antes uma idéia bem transmitida para poucos do que mal escritas para a humanidade.

Dia desses estava eu resmungando pra minha namorada o quanto a minha pesquisa empaca quando meus colegas (principalmente meu orientador) estão muito ocupados e eu não recebo feedback. Como a gente gosta de fazer sudoku juntos, eu comecei a fazer uma analogia entre os problemas atacados em pesquisa acadêmica e sudoku pra explicar meus resmungos. Achei a analogia curiosa, então aqui vão os dois pontos principais, quem sabe alguém acha mais.

Antigamente, isso desde a idade antiga até mais ou menos a 2a guerra mundial, os pesquisadores eram aqueles seres mitológicos, geralmente um pouco malucos, excêntricos e isolados. Eles resolviam seus problemas separadamente, ficando muitas vezes anos escondendo o jogo até conseguir resultados interessantes. Por isso vemos várias vezes na história casos de descoberta simultânea por pesquisadores isolados. O grande problema desse modelo é que muitas vezes você fica empacado. É isso que acontece comigo quando eu faço sudoku sozinho, sem minha namorada. As vezes tem uma solução óbvia pra uma célula, bem na cara, e eu simplesmente não vejo (obviamente isso acontece com ela também, quando ela faz sozinha). E é exatamente assim que me sinto quando falta colaboração na minha pesquisa: eu as vezes encontro problemas que me travam ou, pior ainda, perco um bom tempo num caminho errado, o que poderia ser evitado se alguém com um “fresh look” no problema me desse um toque. Colaboração se tornou essencial em pesquisa principalmente a partir da 2a guerra, quando a complexidade dos problemas (e o preço das soluções!) começou a ficar grande demais pra um pesquisador solitário (ou um até um país sozinho, vide CERN). E com os meios de comunicação atuais, isso só está acelerando. Um bom exemplo é o My Experiment, um portal em que pesquisadores contribuem a metodologia de experimentos pra facilitar replicação.

Outro aspecto em que sudoku se parece com um problema de pesquisa é no seu lifecycle, ou ciclo de vida. Quando surge um novo problema de pesquisa, ou até uma nova área, é como um jogo de sudoku recém começado. As primeiras células são bem fáceis de serem preenchidas, assim como é bem fácil fazer progresso no problema. Você ataca antes as chamadas “low hanging fruits”, ou seja, faz antes o que é mais fácil de ser feito. Daí surgem aquelas lendas, e essa eu ouvi diretamente da boca do Alan Kay, de cientistas da computação conseguindo PhD em uma semana (nos anos 50, 60) por um algoritmo para alguma coisa que ninguém tinha feito antes (não me lembro exatamente pra que). Um outro exemplo é a invenção dos compiladores, provavelmente o desenvolvimento na área de computação que teve o maior impacto na produtividade, impacto que dificilmente vai ter equivalente no futuro. O ponto é que é mais fácil quando ninguém fez nada na área ainda. Depois a coisa começa a empacar, e tem-se uma fase de progresso incremental, em que problemas difíceis são resolvidos um a um, cada um merecendo um PhD. Depois, quando o tabuleiro já está mais cheio, fica mais fácil de completar. É nessa hora que os pesquisadores perdem o interesse na área, e geralmente os problemas que faltam sobram pra indústria. E é nessa hora que eu perco o interesse, viro pro lado e deixo minha namorada terminar o sudoku em paz!

Eu ando meio ausente deste blog. Percebo que a atividade de escrever requer tempo, e sobretudo, ócio criativo. Raramente consigo escrever um texto entre uma atividade e outra, menos quando são textos com notícias breves, como este sobre o Job4Dev no UOL. E o leitor há de se perguntar: “o que toma tanto o tempo deste pobre rapaz?”.

Respondo: o SigaSeuTime, startup que vem crescendo de forma animadora e que me tem tomado todo o tempo livre fora do horário comercial (sim, porque no horário comercial eu brinco de desenvolver sistemas de controle de tráfego aéreo, que ainda é a minha fonte de renda principal…e única).

Mas, acreditem, não passa um dia sequer sem que eu pense que deveria me dedicar mais a este espaço. E não passa um dia sequer sem que eu leve sermão do Raphael por não meter mais a mão no Job4Dev (assumi o papel de captador de vagas…). Mas isto é assunto pra outro dia.

Vou aproveitar o momento de inspiração para relatar uma experiência que tive recentemente trabalhando com o SigaSeuTime, que me parece interessante.

O ditado “A grama do vizinho é sempre mais verde” se aplica a quase todas as áreas do comportamento humano: nós temos uma tendência a achar que o que os outros têm é melhor. Em termos de linguagem de programação, o fanatismo de certos grupos tende a contrariar este ditado: é muito raro algum fã de uma linguagem admitir falhas, e ver outras opções como sendo mais eficientes, modernas, seguras…

Eu já comentei em algum outro texto que o conjunto Python/Django funcionou como um catalizador da minha capacidade produtiva/criativa. Sempre tive várias idéias (não forçosamente boas) mas tinha uma grande dificuldade de colocá-las em prática em Java (que é a minha linguagem de atuação profissional), e Python me permitiu concretizar algumas de forma rápida e eficiente.

Hoje, depois de uma boa quantidade de linhas de código escritas nesta linguagem, das quais a grande maioria em produção de forma estável  no SigaSeuTime e no Job4Dev, me pego pensando em algumas características presentes em linguagens como Java que eu sinto falta. Na verdade, existe uma principal: tipagem de parâmetros de funções e métodos. Apesar dos amantes de Python me dizerem por meio de comentários que eu preciso mudar minha forma de pensar, ainda acho que tipagem de parâmetros facilita a leitura de códigos alheios, e que sobrecarga de métodos é um recurso bastante elegante e útil.

Por vários motivos, incorporei um subsistema em Java dentro do SigaSeuTime, que implementa uma das plataformas. Este subsistema foi desenvolvido por um programador freelancer, e recentemente tive que mexer no código para fazer algumas adaptações. E foi um ótimo estudo comparativo de ambientes: Java/Eclipse vs Python/Emacs (já testei Python/Eclipse, e não vi grandes vantagens…). Cheguei à conclusão de que, no quadro da minha startup, entre a rede de proteção gigantesca oferecida por Java e a rapidez de desenvolvimento oferecida por Python, eu ainda prefiro a segunda opção.

Não trabalhei em projetos com muitos desenvolvedores em Python (no máximo, eu e mais um ou dois), e tenho certeza de que a rede de proteção de Java evita muitos problemas potenciais de gente mexendo onde não devia, chamadas erradas, etc… Mas como eu sempre trabalhei com pessoas de alto nível no SigaSeuTime e no Job4Dev, a eficiência do ciclo de desenvolvimento/deploy do Python (e das linguagens de script dinâmicas em geral) me parece ser muito vantajosa em um projeto onde o importante é desenvolver rápido para colocar em produção rápido.

E quando eu digo rápido, significa eventualmente resolver um bug no código em produção, através de um Vi ou Emacs rodando em um terminal SSH. Sim, eu já fiz isso mais de uma vez, para o desespero de muitos dos leitores deste blog e defensores de CMMIs da vida.

Grandes empresas precisam implementar processos e mecanismos de controle para organizar o crescimento (muitas vezes desordenado) de pessoas, muitas vezes acompanhado pela redução da qualidade média dos desenvolvedores.

Em ambientes pequenos de startup, onde é possível imaginar uma equipe apenas composta por boas pessoas, os controles e processos são desnecessários e muitas vezes indesejáveis. Neste contexto, todas aquelas preocupações enterprise padrões devem ser deixadas de lado, e os participantes do projeto devem focar suas energias em apenas duas coisas: tornar o projeto uma realidade e trabalhar para que ele seja viável economicamente. O resto é resto…

Existem projetos pessoais que tem a vocação de ficarem para sempre gravados em uma pasta obscura do seu HD. Todo nerd que se preze tem pelo menos um desses: códigos de prova de conceito, brincadeiras escritas em um sábado a noite quando todos os seus amigos cools estavam na balada, e os do orkut estavam offline.

Existem outros escritos com a esperança de darem certo, e de se tornarem o próximo empreendimento de bilhões de dólares. Pouquíssimos chegam lá, mas muitos crescem, começam a ser reconhecidos, criam uma base de usuários, constroem uma marca. E seus desenvolvedores agem exatamente como pais: ficam orgulhosos em ver o filho ficando forte, bonito.

O Job4Dev nasceu como um Pet Project, e foi ganhando consistência. Não, não estamos nem perto de ficarmos ricos, mas estamos construindo uma marca. Vibramos com as primeiras empresas que cadastraram vagas espontâneamente, com os primeiros seguidores no Twitter, com os primeiros usuários do RSS.

E hoje, estamos vibrando muito com a nossa primeira aparição em um grande veículo de mídia, o UOL. Cito:

A Ubisoft divulgou por meio do site Job4Dev, especializado em anúncios de empregos na área de tecnologia da informação, novas vagas para programadores na filial brasileira da produtora no Rio Grande Sul.

Estão disponíveis vagas para programadores especializados em artes 2D e também 3D. O estúdio em questão fica localizado na cidade de Porto Alegre e é o antigo Southlogic, adquirido em janeiro deste ano pela produtora francesa.

O site não revela para quais projetos especificamente são necessários os programadores, mas exige-se domínio de diversos softwares e conhecimento de inglês. A descrição da vaga para programador 2D diz que o foco é em “criação de interfaces e gameplay”, ao passo que o programador 3D fica responsável por “trabalhar na criação, adaptação e manutenção de tecnologia 3D para jogos”.

As descrições completas das vagas e instruções para se candidatar a elas pode ser vista no site Job4Dev.

E neste momento, só posso dizer o seguinte: É nóis na grande mídia, mano!!!!

Semana passada eu estava buscando material de referência para algumas configurações do Git e achei um livro muito bom, chamado Pro Git. O livro foi escrito por Scott Chacon e publicado pela Apress. Como o livro foi publicado sob a licença do Creative Commons, está aberto para traduções e até mesmo adaptações.

No verdadeiro espírito de eating your own dog food, o autor do livro colocou o código-fonte do livro no GitHub e qualquer pessoa pode fazer um fork, para fazer modificações no material. Vi que a tradução para pt_br foi iniciada, mas ainda estava tímida. Ato contínuo, fiz um fork do projeto e comecei a fazer a tradução.

A minha idéia é completar a tradução e colocar aqui no site, em uma seção separada. Obviamente, não é algo que vai ficar pronto em uma semana, ainda mais se eu fizer sozinho. Então, fica a dica: se você quer aprender a mexer com o Git, ajudar a fazer a tradução do livro enquanto usa o Git é o casamento perfeito entre teoria e prática.