Há algum tempo atrás, eu escrevi aqui sobre a nova especificação do Javascript, oficialmente conhecida como ECMAScript 4.0. Esta versão pretendia modernizar a linguagem, que estava congelada desde 1999 na versão 3.0 (também conhecida como Javascript 1.5). Na semana passada, esta versão foi oficialmente abandonada: o motivo foi uma longa batalha, que colocou em campos opostos alguns grandes players da internet mundial.

Entre as empresas que apoiavam a versão 4.0, estavam Google, Mozilla (que inclusive criou o projeto Tamarin, cujo objetivo foi criar uma implementação de um engine JS 100% compatível com esta nova especificação), e Adobe. Esta última tinha um interesse especial nesta nova especificação, já que internamente, seus engenheiros chamavam a nova versão de ActionScript 3.0.

ActionScript é, como todos sabem, a linguagem utilizada para desenvolver programas em Flash, tecnologia amplamente adotada na Internet. A Adobe tinha como planos fazer com que a nova especificação de Javascript fosse compatível com a sua própria linguagem de script. Conseguiria assim dois feitos: primeiro, rebateria as críticas daqueles que a acusavam de querer tornar a web um mundo proprietário. Segundo (e talvez o feito mais importante), unificaria as duas mais populares tecnologias  das duas tecnologias da Internet moderna: Flash e a linguagem que se tornou o pilar básico do AJAX e por consequência da tão falada Web 2.0.

Do outro lado desta batalha, estava nada menos do que a poderosa Microsoft, que luta para se firmar como uma empresa com um real poder de fogo e de influência sobre a grande rede mundial. Oficialmente, o argumento é de que a nova especificação representa uma evolução muito radical em relação à versão anterior, e que o melhor seria focar em desenvolver uma versão 3.1 inicialmente, e depois trabalhar em uma versão mais modesta da especificação 4.0. Devo dizer que concordo com a opinião de que a nova especificação era muito complexa, introduzindo uma quantidade bastante grande de conceitos e palavras chaves.

Mas a realidade é que a Microsoft, representada por Allen Wirfs-Brock, não quer ver uma outra empresa impor sua tecnologia como standard da Internet. E por enquanto conseguiu, como mostra o este trecho do comunicado oficial de Breidan Eich, membro do comitê executivo para definição da ECMAScript:

1. Focus work on ES3.1 with full collaboration of all parties, and target two interoperable implementations by early next year.
2. Collaborate on the next step beyond ES3.1, which will include syntactic extensions but which will be more modest than ES4 in both semantic and syntactic innovation.
3. Some ES4 proposals have been deemed unsound for the Web, and are off the table for good: packages, namespaces and early binding. This conclusion is key to Harmony.
4. Other goals and ideas from ES4 are being rephrased to keep consensus in the committee; these include a notion of classes based on existing ES3 concepts combined with proposed ES3.1 extensions.

Essa dica é para amantes de design em geral, e fontes e tipografia em particular. Descobri hoje, lendo a revista Mac+, o site What the Font que oferece uma ferramenta que tenta descobrir a fonte utilizada para escrever texto em um arquivo de imagem.

O processo é simples: faça upload ou passe a URL da imagem que deseja analisar, verifique se os caracteres que ele detectou estão corretos e pronto. O resultado é exibido na forma de uma lista de textos em diversas fontes, e o sistema permite a comparação das fontes obtidas com a sua fonte original mostrando a sua imagem sempre no centro da tela.

Utilizei a ferramenta para tentar descobrir as fontes utilizadas pelo Raphael para fazer o logo do job4dev (ele perdeu o arquivo PSD original…), e o resultado obtido está abaixo:

A fonte ATCapone-Light parece a correta!

Existe uma ferramenta muito legal para controle de projetos, bugs, releases e afins disponível na web: ClockingIT.

Este projeto tem uma história bem peculiar: foi desenvolvido por um casal norueguês, Erlend e Ellen Simonsen. Erlend é desenvolvedor e é responsável por toda a parte de programação. Ellen é designer e cuida de toda a parte visual.

O ClockingIT segue a mesma receita de muitos projetos de alta qualidade e valor agregado disponíveis por aí: nasceu de uma necessidade do próprio desenvolvedor. Erlend é um consultor de tecnologia independente e desenvolve projetos sob medida para vários clientes, e sentia a necessidade de ter uma boa ferramenta de gerenciamento de projetos. Seguindo a filosofia do Getting Real, resolveu por a mão na massa e começou a desenvolver o ClockingIT usando a plataforma Ruby On Rails.

O sistema permite o cadastro de diversos projetos e colaboradores. Em cada projeto, é possível criar milestones e tarefas (com diversos graus de prioridade, nível de dificuldade, tempo estimado de execução e data de entrega) e designar um colaborador para sua execução. Além disso, o sistema permite a criação de subtarefas e permite registrar o tempo levado para executar cada tarefa, gerando um log de trabalho. Com estes dados, é possível criar relatórios diversos, como timesheets que são extremamente úteis para consultores que ganham por hora. E o sistema ainda oferece vários modos de visualização de todos estes dados: timeline, schedule, lista de tarefas…

Mas o grande diferencial, aquilo que me faz ter vontade de escrever sobre o ClockingIT neste blog, é a qualidade da interface. O design gráfico é simples, limpo e extremamente intuitivo. E o site faz um uso intensivo e inteligente de scripts e recursos assíncronos. Eu destaquei a palavra inteligente porque hoje em dia vemos muitos sites usando Ajax simplesmente por usar, apenas para baterem no peito e gritar “Eu sou uebi doispontuzeru!!!”. Olhando a interface do Clocking IT, talvez muitos resolvem repensas suas visões. A interação como o site é extremamente ágil e leve, exatamente como em software desktop. Qualquer ação efetuada por algum usuário é imediatamente refletida na tela de outros usuários conectados no mesmo projeto. É possível saber em tempo real quem está conectado no sistema, o que está fazendo, a quanto tempo está fazendo. E graças ao chat embutido, é possível até conversar com outros colaboradores.

Last, but not least, o sistema oferece integração com iCal (pode ser integrado com Google Calendar ou com o calendário da Apple por exemplo), sistema de RSS, um wiki, fórum , e uma speedbar (uma janelinha pequena) que permite que o usuário marque o início e fim de uma tarefa (com botões de start, stop e pause e um cronômetro rodando em tempo real).

É, definitivamente o ClockingIT não deixa nada a desejar de ferramentas tradicionais de gerenciamento de projetos. E com certeza ele é uebidoispontuzero.

Disponibilizei ontem a mais nova versão do Job4Dev, que eu considero como sendo o segundo major release desde que o projeto entrou no ar, no dia 3 de dezembro de 2007.

Para aqueles que utilizam o  sistema apenas para buscar vagas, as diferenças são poucas: busca no site usando o motor do Google e algumas pequenas modificações no design (na maioria dos casos, correções para o IE).

A maior mudança será sentida por aqueles que cadastram vagas no sistema. Uma das grandes reclamações, recorrentes, era de que uma vez cadastrada a vaga, era impossível editar e fazer pequenas correções. O fluxo de trabalho era simplificado ao extremo, e o feedback para o usuário era mínimo. Além disso, eu não tinha controle algum de quem cadastrava vagas.

Com estes pontos em mente, resolvi adicionar um sistema de controle de usuários: todos aqueles que desejarem submeter vagas no site deverão se cadastrar no sistema. Com isto eu consigo oferecer os seguintes serviços:

• Cada usuário poderá ver suas vagas publicadas, rejeitadas, removidas ou aguardando aprovação.
• O usuário poderá editar e modificar uma vaga criada por ele. Caso a vaga já tenha sido publicada, ela será colocada em estado de espera e submetida para nova aprovação.
• Vagas removidas (com data de publicação superior a 30 dias) poderão ser republicadas pelo autor a qualquer momento.
• O usuário receberá emails notificando modificações no status de suas vagas.

Além disso, o formulário de submissão de vaga foi redesenhado e ganhou uma nova interface para adicionar palavras-chave, inspirada no site del.icio.us.

Mais uma singela porém importante novidade no Job4Dev: agora o sistema mostra um preview do anúncio para que o usuário possa validar o texto e a formatação produzida pelo markdown antes de confirmar a submissão.

Antes de mais nada tenho que dizer que não acompanho os lançamentos da Apple com muita atenção. Nada contra a Apple em si, mas acabo acompanhando outras coisas que me interssam mais. Mas parece que o maior lançamento deles feito na maior conferência sobre produtos da Apple este ano foi o MacBook Air.

Por fora, como a maior parte das coisas da Apple, o design é muito interessante. Mas confesso que não dou tanta bola pra assim para o design. É claro que gosto de ter coisas bonitas, mas prefiro ter coisas boas antes de ter coisas bonitas. E foi por isso que minha primeira impressão do MacBook Air não foi das melhores. O fato de ele não ter CD/DVD interno me deixou atônito.

Mas ai, pensando um pouco mais, quantas vezes eu uso meu drive de CD/DVD? Poucas… Então porque eu tenho um? Bom, ele de vez em quando é útil, eu diria. E já me salvou algumas vezes.

Mas pensando mais ainda, há muitos anos atrás a Apple foi a primeira fabricante que eu tenho notícia que parou de lançar computadores com drives de disquetes. E, como sabemos hoje, este foi um caminho certo. Eu não tenho drive de disquete há 4 anos. E acho que posso contar nos dedos de uma mão quantas vezes ele me fez falta. E nenhuma dessas vezes eu não consegui outra solução sem usar um disquete.

Seguindo o mesmo raciocínio, talvez as unidades de CD/DVD também estejam com os dias contados. Pelo menos em computadores portatéis.

“True artists ship“, artistas de verdade produzem.

Esta frase, atribuida ao Steve Jobs, me foi dita pelo Raphael. Confesso que ela mexeu comigo. Sempre admirei pessoas que desenvolvem seus projetos computacionais, e fazem deles coisas interessantes. Eu estou numa fase de tentar transformar os meus projetos em coisas reais. Se eles estão se tornando coisas interessantes, é outro papo. O primeiro foi este blog, que com muita perserverança está se transformando em um repositório de textos bem interessantes. Depois, coloquei no ar a JuiceLib, que está num processo bem lento de desenvolvimento. Falta tempo e ajuda. E eu trabalho por lotes….

Mas daí, veio a idéia do job board. O interessante neste caso é que este lance do jobboard, antes de ser um projeto de desenvolvimento, era algo que me martelava a cabeça. Me frustrava não encontrar no Brasil um jobboard que me desse prazer de visitar. E depois de um tempo de maturação, cheguei à conclusão de que se ele não existisse, eu teria que criar um. Lembrei de um cara chamado Richard Stallman que não encontrou nenhum editor de textos com os recursos que ele procurava, e daí ele escreveu o Emacs. Citando uma outra referência mais moderna, o livro Getting Real do pessoal da 37 Signals:

A great way to build software is to start out by solving your own problems. You’ll be the target audience and you’ll know what’s important and what’s not. That gives you a great head start on delivering a breakout product.

Muito bem. Eu tinha um problema a resolver. Resolvi atacá-lo de frente. E de quebra, poderia me aprofundar mais em Python. Restava definir o resto do meu ambiente. O editor seria o Emacs, por ser extremamente versátil, ter uma quantidade incrível de ferramentas úteis e poderosas, e ser bem leve. O banco de dados escolhido foi PostgreSQL, por ser um banco free, de ótima qualidade, com portes para Linux, Windows e Mac (ambiente primário de desenvolvimento) e pelo fato de eu ter trabalhado com ele por muito tempo.

O mais difícil foi definir um framework/lib de desenvolvimento web. Comecei avaliando o Turbogears. No início achei interessante, mas por vários motivos não gostei de como ele evoluiu. O Raphael tentou me convencer a me usar o web.py, uma lib bem leve de desenvolvimento web, que eu acabei não escolhendo por achar a doc bem fraquinha. Daí eu descobri o Django, que possuia uma documentação bem completa, um conceito bem legal de oferecer muitos recursos para minimizar a parte CRUD do sistema e um ótimo case de implementação: o site washingtonpost.com.

O desenvolvimento se deu em 3 grandes blocos de trabalho.

O primeiro foi a parte de design de base de dados e entidades, além de primeiros contatos com o ambiente de desenvolvimento. Demorou 3 dias mais ou menos. Boa parte da demora foi pelo fato de eu estar descobrindo o Django ao mesmo tempo que fazia o design da solução. Neste ponto, eu sabia muito bem o que eu queria obter, e sobretudo sabia o que eu NÃO queria! Citando mais uma vez o Getting Real:

Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.

O segundo bloco de trabalho foi a integração com o design gráfico. E nesta fase aconteceu uma coisa interessante. O Raphael fez um design que se encaixou perfeitamente naquilo que eu tinha em mente. E ao mesmo tempo ele tinha feito uma versão funcional do board em web.py. Rolou então uma competição saudável: roubei o design dele, e durante alguns dias desenvolvemos o mesmo sistema em ambientes diferentes e em paralelo. O que um fazia, o outro corria atrás para fazer melhor. Um impulsionou o outro. Nesta fase, foram feitas as telas principais, o sistema de submissão, e o primeiro RSS. Foram dois ou três dias de trabalho bem intenso, e confesso que fazia muito tempo que não me divertia tanto escrevendo um software. O meu deadline era segunda feira dia 26 de novembro. Neste dia tínhamos um demo rodando.

Foi aí que veio o terceiro bloco de trabalho. Chamamos amigos e conhecidos para serem beta testers. A meta: colocar o site no ar, para o público, com domínio próprio e tudo mais no dia 3 de dezembro. Nesta semana, várias pessoas testaram o sistema, acessando a listagem, as páginas de anúncios, submetendo anúncios novos e sobretudo reportando bugs e mais bugs. Este era o objetivo. Nos final de semana anterior à minha data limite de “lançamento”, passei horas e mais horas escrevendo código, debugando, testando.

No dia 3, o Job4Dev estava no ar. O Log4Dev ganhou um irmãozinho, e eu ganhei mais um filho. Como disse anteriormente, fazia muito tempo que não tinha tanto prazer em fazer algo relacionado a software. Não pela complexidade do sistema em si, mas pelo fato de ter uma meta a ser alcançada, e de produzir um sistema pequeno, leve, eficiente e útil. E sobretudo de ter a sensação de ter gerado algo que pode ser útil para resolver um problema real.