Um dos objetivos da família 4Dev é oferecer um conjunto de ferramentas e plataformas onde profissionais de TI se encontrem e troquem informações. E é nesta linha que adicionamos mais um sistema: o news4dev.

A idéia é simples: os usuários enviam links, e o sistema permite que outras pessoas votem nas notícias favoritas e comentem. Um misto de forum com sistema de recomendação.

Quanto mais gente participar, melhor.

A Você S/A de fevereiro publicou uma artigo sobre como encontrar vagas de emprego no Twitter, e citou o job4dev como fonte, dentre outras. A materia completa pode ser lida aqui.

Só não foi perfeito porque na página ao lado havia uma matéria sobre sites de empregos, e nesta não nos citaram.

Mas tudo bem. Os pais estão bem orgulhosos! De grão em grão, vamos ganhando mercado.

E agora, rumo ao mercado internacional.

Compilação de alguns pontos relevantes sobre Erlang, feita por Odracir:

• Linguagem de programação de propósito geral, com ambiente de execução (runtime environment) implementado numa máquina virtual;
• Possui suporte “embutido” para concorrência, distribuição, e tolerência à falhas.
• É “Open-Source”, distribuído através da licença “ERLANG PUBLIC LICENSE“, que é essencialmente a Mozilla (Netscape) Public Licence, porém com algumas poucas modificações para torna-la compatível com a legislação Sueca.
• É escrito em C, e é  portável para diversas plataformas.
• Muito escalável!  Sua máquina virtual é responsável pela criação de “processos leves” de forma  rápida e barata, tanto em termos de utilização de recursos de CPU como de memória. Em outras linguagens de programação, normalmente estes serviços são delegados para o sistema operacional, o que limita  o número máximo de processos simultâneos permitidos.
• Para modelar um sistema um Erlang nós usamos: “COP – Concurrency Oriented Programming”.
• Não existe estado compartilhado…
• Variáveis podem ser atribuídas apenas uma única vez. (Single assignment variables)
• Os processos se comunicam entre si através do envio de mensagens (cópias imutáveis) assíncronas.
• Tipicamente um código escrito em Erlang faz uso dos diversos núcleos disponíveis nas CPUs modernas, praticamente sem codificação adicional. Testes mostram que clusters com 16 máquinas executam um programa 14,55 vezes mais rápido do que o mesmo programa sendo executado numa única máquina, sem codificação adicional ou específica para isto!
• Permite a interoperabilidade com C,C++, Java, Ruby, Python, Perl, etc …
• Estudos mostram que para um mesmo projeto, o código Erlang é de 4 à 10 vezes menor que seu equivalente escrito em C++.
• Possui a biblioteca  OTP (Open Telecom Platform).
• Em situações extremas de “carga”, um sistema Erlang tende a degradar seu desempenho, mas não para de funcionar.

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!