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.

Que bom!

Veja como em http://job4dev.com/contribute

Plagiando a sessão da revista Mac+ mostro aqui um “bug” enviado por Roberto Endo (também conhecido como o rendo). O bug não é de um produto da Apple, mas sim do Google.

Os usuários assíduos dos produtos do Google reconhecerão na imagem acima um pedaço da tela de configuração. O interessante é que uma dada sequência de comandos (que o Roberto não revelou) faz aparecer a linha de javascript na barra inferior do browser. Não sei vocês, mas eu achei no mínimo curioso o if(0 != 1)….

Pelo menos por enquanto, o serviço de envio de SMSs gratuítos para usuários do Twitter no Brasil foi desativado. Motivo? A conta ficou cara. Porque, obviamente, alguém tinha que pagar a conta (there is no free lunch…).

Os usuários do Twitter cadastrados no serviço de SMS estão recebendo o seguinte email:

Hi,

I’m sending you this note because you registered a mobile device to work with Twitter over our UK number. I wanted to let you know that we are making some changes to the way SMS works on Twitter. There is some good news and some bad news.

I’ll start with the bad news. Beginning today, Twitter is no longer delivering outbound SMS over our UK number. If you enjoy receiving updates from Twitter via +44 762 480 1423, we arerecommending that you explore some suggested alternatives.

Why are we making these changes?

Mobile operators in most of the world charge users to send updates. When you send one message to Twitter and we send it to ten followers, you aren’t charged ten times–that’s because we’ve been footing the bill. When we launched our free SMS service to the world, we set the clock ticking. As the service grew in popularity, so too would the price.

Our challenge during this window of time was to establish relationships with mobile operators around the world such that
our SMS services could become sustainable from a cost perspective. We achieved this goal in Canada, India, and the United States. We can provide full incoming and outgoing SMS service without passing along operator fees in these countries.

We took a risk hoping to bring more nations onboard and more mobile operators around to our way of thinking but we’ve arrived at a point where the responsible thing to do is slow our costs and take a different approach.

No blog do Twitter, os usuários descontentes com a novidade podem encontrar algumas alternativas para receber tweets de seus contatos nos seus celulares.

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!

O Google adicionou uma nova funcionalidade ao seu Google Code: sistema de Code Review, ou revisão de código. A idéia é bem simples: permitir que colegas e pares de projeto possam revisar e comentar o seu código. Isto ajudaria a aprimorar a qualidade do código e reduzir o número de bugs, uma vez que um olhar externo atento pode captar coisas que aos olhos do desenvolvedor se tornam invisíveis (se não me engano, esta é um pouco a idéia por trás do Pair Programming preconizado pelo XP).

Eu acho este processo muito interessante, mas até hoje nunca vi aplicado de forma sistemática dentro de uma equipe. Muitas vezes, quando escrevo algum código complexo (envolvendo muita matemática, baixarias em bits ou algoritmos bisonhos), peço pra alguém dar uma olhada e ver se está tudo OK. E muitas vezes eu dou uma olhada no código dos meus colegas, sobretudo dos mais inexperientes. Ajuda muito. Gostaria de conseguir colocar isso dentro do processo de desenvolvimento da minha equipe de projetos.

Voltando ao Google Code, a interface para a revisão de código é extremamente simples e intuitiva: entre no modo de visualização do código do repositório, abra um arquivo fonte, clique na linha que deseja comentar e salve. Simples e eficiente!

Aliás, fiquei feliz em ver que a interface de visualização de arquivos do Google Code evoluiu. Deu até vontade de retomar o projeto da Juice Lib. Alguém querendo ajudar?

Hoje em dia, ter um domínio próprio é tarefa simples e barata. Inclusive no Brasil, desde que a Fapesp começou a permitir registro de domínios com CPF. Achar bons servidores de hosting também é bastante simples. No meu caso, uso e aconselho fortemente o Webfaction. Mas a lista de opções é grande.

Problema mesmo é a questão do email. As ferramentas oferecidas para este fim por estes servidores de hosting em geral são bem  limitadas, tanto em termos de interface quanto em termos de sistemas de anti-spam. Não tem jeito, o Google nos deixou muito mal acostumados com o GMail e suas incríveis funcionalidades.

Mas, espertos dos jeito que são, criaram uma solução à altura e com uma opção gratuíta: Google Apps (a não confundir com Google Apps Engine). A idéia é simples: vc pode criar uma conta para o seu domínio, e dentro dela, criar várias contas de email, acesso ao calendar, gtalk  e documents compartilhado para os membros do domínio. A opção gratuíta oferece uma conta de 6GB para cada usuário, e a paga, 25GB. As funcionalidades são exatamente as mesmas daquelas oferecida pelo Google Documents, Google Calendar e GMail.

Para fazer a configuração completa, é preciso mexer em configurações avançadas do DNS do seu servidor, como os MX Records e CNAME. Isso permite redirecionar todo o fluxo de emails para o Google e permite criar URLs personalizadas, como por exemplo mail.meudominio.com. O lado ruim é que é necessário ter um sistema de hosting que permita mexer nestes parâmetros.

Resumindo: Google Apps é uma solução de altíssima qualidade e baixíssimo custo para oferecer um sistema de email para seu blog, grupo ou empresa.

Adobe anuncia que Google e Yahoo irão começar a indexar conteúdo de páginas com Flash. Isto porque a empresa forneceu uma versão especial do Flash Player que permite que os buscadores indexem todo o conteúdo de um arquivo SWF. Segundo o blog do Ryan Stewart, evangelizador da Adobe,

“We are giving a special, search-engine optimized Flash Player to Yahoo and Google which is going to help them crawl through every bit of your SWF file”.

É interessante notar que inicialmente, o indexador do Google irá apenas analisar textos e URLs contidas no arquivo. Imagens e vídeos ficam de fora:

How does Google “see” the contents of a Flash file?
We’ve developed an algorithm that explores Flash files in the same way that a person would, by clicking buttons, entering input, and so on. Our algorithm remembers all of the text that it encounters along the way, and that content is then available to be indexed. We can’t tell you all of the proprietary details, but we can tell you that the algorithm’s effectiveness was improved by utilizing Adobe’s new Searchable SWF library.

Mais informações podem ser encontradas no blog para Webmasters do Google.

Dizem por aí que  uma boa premissa para se criar um produto novo é partir de uma necessidade pessoal. Eu já devo ter mencionado isso em algum lugar neste blog. No caso do Job4Dev, foi assim. Na verdade, mais do que uma  necessidade, o Job4Dev teve como ponto de partida uma frustração: os sites de empregos brasileiros de empregos voltado para o mundo TI eram um amontoado de mais do mesmo.

O exercício é simples: entre nos 3 principais sites de empregos, e conte a porcentagem de vagas oferecidas por consultorias de TI, na maioria sem nome, sem projetos definido, sem plano de carreira, sem grandes desafios, cujo único objetivo é fazer outsourcing de recursos de programação. São a grande maioria.

Nada contra este tipo de trabalho. Existe a demanda, e existe gente que se interessa em desenvolver. Ótimo. O problema é que quando olhava estes sites, tinha a nítida impressão de que o mercado brasileiro se resumia a isso. E olhando à minha volta, percebia que meus colegas e outros profissionais bons em geral não passavam nem perto destes  sites, preferindo usar listas de emails, contatos pessoais e o bom e velho networking.

Job4Dev foi desenvolvido tendo como objetivo de oferecer alternativas, captando vagas de várias fontes, filtrando o material e disponibilizando apenas aquilo que julgamos interessante.

E devo confessar que, depois de alguns meses no ar, o retorno e o resultado me surpreendeu. O site ainda tem muito a crescer, mas temos conseguido um fluxo regular de vagas, feedbacks muito bons de usuários e empresas. Isso me confirma uma coisa: o mercado brasileiro talves esteja longe do ideal, mas existem sim boas opções de empresas que procuram profissionais diferenciados, que desenvolvem projetos interessantes. E estas empresas estão carentes de espaços adequados de divulgação.

Entre no Reader, digite a seguinte sequencia no teclado:

cima, cima, baixo, baixo, esquerda, direita, esquerda, direita, b, a

A palavra Ninja! irá aparece na busca, a barra a esquerda irá ter um skin diferente e todos os contadores ficarão com valor 30 (mensagens não lidas). A referência nerd da coisa (obrigado Thomas) é que existe um jogo chamado Contra, do Nintendinho, onde esta sequência dá ao jogador 30 vidas. Esse código também é chamado de Konami Code, e é bem documentado pela Wikipedia em http://en.wikipedia.org/wiki/Konami_Code.

Mais um daqueles códigos que o pessoal dava a vida para conseguir, e que eu sempre fui incapaz de aprender de cor!

Mais uma funcionalidade muito requisitada por fãs do Job4Dev da minha rua: filtro por estado. Pedido atendido: agora é possível filtrar as vagas por estado e/ou por palavra chave.

O sistema foi feito de forma a minimizar o impacto no cadastro. Assim, o formulário continua o mesmo, apenas com um campo de localização: escreva a sigla do estado em algum lugar, e o Job4Dev se encarregará de fazer o resto.

Esta funcionalidade ainda não está no RSS ainda, mas seguindo a filosofia “Release Fast, Release Often”, deverá estar disponível em breve.

Eu já divulguei aqui que o Job4Dev tem integração com o sistema de microblog Twitter, através do usuário job4dev, onde são enviadas as ofertas de emprego.

O que eu não divulguei ainda é que desde terça está no ar mais um projeto que contou com a minha participação: sigaseutime.com.br. A idéia é bem simples: utilizar o Twitter para agregar notícias e informações de jogos ao vivo do seu time de futebol favorito. Criamos contas para diversos times do Brasil e do mundo (sigaCorinthians, sigaPalmeiras, liveBarcelona, e por aí vai. Acesse o site para o obter a lista completa).

O que eu não contei também é que fazer integração via software com o Twitter é extremamente simples, graças à API REST de acesso. REST? REpresentational State Transfer, termo criado por Roy Fielding, computeiro americano e um dos principais autores da especificação do protocolo HTTP, em sua tese de PhD.

O próprio REST tem como pilar o protocolo HTTP. A idéia básica é definir que existem recursos (fontes de informação) que podem ser acessados através de um identificador global (que no caso do HTTP, é conhecido como URL), e que retornam uma representação da informação (XML, JSON, etc). Os recursos são considerados objetos, e o REST utiliza as ações do protocolo HTTP para agir sobre estes objetos: GET, POST (as mais famosas, para quem trabalha com sistemas web e com ajax), PUT e DELETE.

• GET URI corresponde à operação de leitura de um objeto
• POST URI correponde à operação de criação, atualização ou remoção de um objeto, utilizando dados enviados pelo comando.
• DELETE URI corresponde à operação de remoção de um objeto.
• PUT URI corresponde, assim como POST, à operação de atualização ou criação de um objeto.

Assim como no HTTP, o REST não armazena sessão: o acesso tem que ser feito sem que o recurso precise ter conhecimento de requisições passadas, proxys, caches e outros recursos utilizados em sistemas web. Ou seja: qualquer serviço REST pode ser acessado apenas com a URI apropriada e a ação desejada.

A API REST do Twitter permite acesso a todas as funcionalidades do sistema, de forma extremamente simples. Por exemplo: caso eu queira listar as mensagens recebidas pelo usuário job4dev em formato xml, basta acessar a URL http://twitter.com/statuses/friends_timeline/job4dev.xml. O sistema retorna informações também em JSON (neste caso, bastaria mudar o xml do final por json).

A maioria dos comandos requer autenticação, que no caso do Twitter é feita usando o Basic Auth: a informação de usuário e senha é enviada em um header chamado Authorization, cujo conteúdo é uma string na forma Basic <dados em base 64>, onde <dados em base 64> é usuario:senha codificado em base64 (formato muito utilizado para transmissão de dados na web).

Vou colocar aqui um exemplo em Python para enviar uma mensagem nova para uma conta no Twitter. A função encodestring é responsável por converter para base64, e a função urlencode gera uma string no formato correto para colocar na requisição HTTP:

auth = encodestring('%s:%s' % (user, password))[:-1]
header["Authorization"] = 'Basic %s' % self.auth
encoded_post_data = urlencode({"status":status})
req = Request(TwitterSender.url, encoded_post_data, header)
url_data = urlopen(req)

O mais interessante desta API é que além de ser simples, ela é muito bem documentada: http://groups.google.com/group/twitter-development-talk/web/api-documentation

Acabei de configurar o domínio job4dev.com.br, que irá funcionar em paralelo ao domínio job4dev.com. Com isso espero melhorar os resultados nas pesquisas Google (afinal, agora temos um domínio genuinamente brasuca). Ajudem a divulgar a nova marca!

Na sexta feira entrou no ar uma nova funcionalidade do Job4Dev: integração com o Twitter. Para quem não conhece o Twitter, acho que a melhor explicação que eu posso dar é o texto da página inicial do próprio site:

Twitter is a service for friends, family, and co–workers to communicate and stay connected through the exchange of quick, frequent answers to one simple question: What are you doing?

Resumindo tudo: é um microblog. E qual o interesse do Job4Dev por um microblog? Simples: mais formas de divulgação. O Twitter permite o envio de mensagens através de Google Talk, Jabber, Live Journal, RSS e SMS, além do próprio site.

Temos agora um usuário job4dev no twitter, que pode ser acessado através da URL http://twitter.com/job4dev: para onde todos os anúncios de vagas aprovados serão enviados a cada meia-hora, e divulgadas em tempo real para todos os usuários do Twitter que cadastrados na nossa rede de contatos. Simples e eficiente!

PS: Gostaria de aproveitar para dizer que o RSS do Job4Dev no Google Reader anda meio problemático ele não é atualizado desde o início de abril. Estamos tentando corrigir isso o quanto antes.

Até pouco tempo atrás, para se registrar um domínio .com.br, era necessário possuir um CNPJ. Ou seja, apenas donos de empresa podiam registrar domínios .com.br. O resultado é que das duas uma: ou pessoas físicas compravam domínios .com, ou utilizavam serviços de empresas que compravam o domínio em seu nome.

Mas isto mudou. Acabei de receber o seguinte email do registro.br, orgão responsável pelo controle dos domínios brasileiros:

Por decisão do CGI.br, o domínio COM.BR, destinado a atividades comerciais genéricas na Internet, também poderá ser registrado sob um CPF. Ou seja, pessoas naturais com atividades comerciais e afins poderão registrar domínios COM.BR.

Esta modificação terá efeito a partir do dia 01/05/2008.

Inicialmente, somente o domínio COM.BR estará disponível nesta nova categoria, genérica, que permite registro tanto com CNPJ quanto com CPF. Lembramos que, para manter a transparência do registro de domínios .br, pessoas físicas responsáveis por domínios COM.BR estarão sujeitas aos mesmos procedimentos das entidades cadastradas previamente.