Qual a fonte?

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:

whatthefont.png

A fonte ATCapone-Light parece a correta!

Code review

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!

googlecode1.png

googlecode2.png

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?

Minhas primeiras impressões sobre o LaTeX

Por Rafael Naufal

Há um bom tempo eu já queria experimentar o LaTeX. Sempre ouvi falar muito bem dele, principalmente por amigos que fazem mestrado/doutorado. Quando comecei a fazer meu curso de pós-graduação em Engenharia de Software no ITA, sabia que este era o momento de experimentar esta ferramentatão poderosa . Não via a hora de dar um basta em Word e Open-Office.

E este momento chegou.

Para quem não conhece, o LaTeX é  construído sobre a ferramenta TeX, que permite aos autores de trabalhos acadêmicos obter alta qualidade tipográfica, criado por Leslie Lamport em meados da década de 80. O TeX é um software de tipografia desenvolvido por Donald Knuth na década de 70 para a edição de textos com ótima apresentação gráfica e qualidade tipográfica, principalmente com foco em fórmulas matemáticas. Knuth, na época, desenvolveu o TeX para escrever sua mais famosa coletânea de livros  The Art of Computer Programming, pois não encontrava um sistema tipográfico decente na época. Basicamente, o LaTeX  adiciona um conjunto de comandos no texto que definem como o sistema de processamento do TeX irá formatá-lo.

O texto em LaTeX é digitado com vários comandos inseridos, como se fosse um código em alguma linguagem de programação. Estes comandos definem o tipo da fonte, a formatação do texto, capítulos, seções, caracteres especiais, tamanhos de margem, etc. Isto torna o sistema diferente da metodologia WYSIWYG, em que o texto escrito é exatamente como ele será visto no resultado final do processamento. Apenas para constar, todo comando em se inicia com uma barra invertida (\). Arquivos LaTeX são criados com a extensão .tex e o texto deve ser compilado, podendo ser em um arquivo binário de extensão DVI ou PDF. O fato de ter que compilar o texto pode representar uma quebra de paradigma para o editor do texto, mas o resultado final é muito bom, de alta qualidade tipográfica, como se o texto tivesse sido editado e diagramado em uma “editora”.

As grandes vantagens que vejo em utilizar o LATEX ao invés de um editor WYSIWYG comum, como o Word ou OpenOffice, são as seguintes:

  1. O LATEX, por meio das suas macros, permite que você defina como o texto deve ser apresentado e formatado, da mesma forma como o CSS trabalha com HTML/XHTML. A idéia é com que você se preocupe apenas com seu texto e não como ele deve ser formatado. Deixe esse trabalho para o TEX!!
  2. Fórmulas matemáticas, exibidas pelo LATEX, são extremamente elegantes.
  3. O LATEX gerencia toda e qualquer numeração de capítulos, seções, listas, figuras e tabelas, rodapés, etc. Quem nunca xingou o M$$ Word por causa de suas numerações e bullets sempre fora de lugar e com o famoso “Continuar com a numeração anterior”? :-)
  4. O TEX é portável e gratuito, isso quer dizer que funciona na maioria dos hardwares existentes.
  5. É possível informar ao LATEX bibliotecas adicionais para, por exemplo, especificar referências bibliográficas segundo uma norma vigente ( ex: NBR 6023). Um projeto interessante é o abnTEX.
  6. Não se preocupe com o layout, apenas com estrutura do documento!!

Como um rápido exemplo, teríamos a seguinte construção em LATEX:

\documentclass[a4paper]{article} \begin{document} Seu texto aqui…. \end{document}

O código acima define um arquivo LATEX mínimo, em que é definida a utilização da classe artigo em um papel de tamanho A4. Dentro das tags \begin{document} e \end{document} o texto deve ser digitado. Estas construções, ao serem compiladas pelo TEX e como opção gerarem um documento PDF, já produzem um resultado final excelente, bem diferente do Word.

Você pode encontrar boas referências sobre o pacote aqui e aqui. E deixo aqui um desafio: mesmo que seja fã do Word, tente criar um documento em LaTEX uma vez e veja o resultado final! Aposto que, depois, você não vai querer parar de escrever seus textos com ele!

[Rafael Naufal é Engenheiro de Software, Mestrando pelo ITA e autor do blog http://rnaufal.livejournal.com]

Rapidinhas sobre Python

A Sun criou um espaço dedicado ao Python dentro do Sun Developer Network.  Na página, existem links para o Dive Into Python, dicas para montar um ambiente com Django, Jython ou Python, GlassFish, etc. Vale ressaltar também que o NetBeans começou a dar suporte oficial para o Python.

A Apple começou a dar suporte para Python há algun tempo atras, permitindo que desenvolvedores criassem programas em  Python com interfaces gráficas nativas em Cocoa usando o Interface Builder e o XCode.

A impressão que eu tenho é que nos ultimos 12 meses, Python tem consistentemente ganhado espaço em blogs, sites especializados, projetos web. O futuro parece promissor.

Google + seu dominio = esquema profiça de email

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.

Flash entrando na onda de SEO

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.

Easter Egg no Google Reader

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!

Conversando com o Twitter

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

ClockingIT

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.

Nova versão do Job4Dev no ar

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.

Screenshots de IE

Quem desenvolve sites e aplicações web sabe: a coisa mais pentelha que existe é conseguir fazer com que as telas tenham exatamente a mesma aparência em qualquer browser (não, eu não faço parte daqueles que acham que um site deva ser desenvolvido para funcionar bem apenas no navegador que domina o mercado e o resto que se dane, a menos que seja para uma intranet homogênea..call center por exemplo). E para resolver isso, não tem muito segredo: é preciso testar, testar e testar.

Hoje em dia existem vários sites que geram screenshots de um site gerados a partir de vários navegadores e são uma mão na roda. No meu caso, que uso Mac para desenvolvimento de projetos pessoais (como o Job4Dev), eu sinto falta de ver o resultado gerado pelo IE. Por isso, o site http://ipinfo.info/netrenderer/index.php é uma ótima pedida: gera screenshots gerados por várias versões do IE e ainda por cima é extremamente rápido.

Livro oficial do SVN em Português

Existe no Google Code o projeto svnbook-pt-br para a tradução do livro oficial do SVN, Version Control with Subversion (http://svnbook.red-bean.com/). Existem versões parciais disponíveis para download e o projeto aceita colaboradores.

Proposta de discussão: Sobre Frameworks

Isso não pretende ser um post. Na verdade será uma pergunta aberta à comunidade leitora deste blog.

Frameworks já deram muito o que falar por aqui. Basta dar uma olhada no artigo Sobre Frameworks… escrito pelo Raphael há algum tempo atrás. Eu, ao contrário de muitos de meus colegas, não tenho opinião fechada sobre este tema. Existem frameworks que eu odeio (Hibernate), outros que eu não vejo maiores problemas no uso apesar das críticas (Struts) e alguns poucos que eu gosto muito (no momento, Django).

Fato é que frameworks, por princípio, oferecem um quadro de trabalho dentro da qual temos que nos acomodar. Estava assistindo agora a uma palestra interna da empresa sobre este tema, e o palestrante levantou uma vantagem e uma desvantagem no uso de frameworks que me chamaram a atenção.

A vantagem apresentada foi que frameworks ajudam a desenvolver 80% do trabalho repetitivo de uma aplicação (CRUD por exemplo). Basicamente, eliminando a repetição. A desvantagem é que ele engessa um pouco a criatividade e pode tornar difícil os 20% não previstos nos casos comuns. Alguém na sala acrescentou que o problema é que em muitos casos, para resolver os casos não previstos temos que contornar o framework.

Eu concordo com estes dois pontos. As porcentagens não são nenhum pouco científicas, mas pela minha pouca experiência eu diria que elas são bem aceitáveis. E pareceu ser consenso na sala de que estes 80% justificam a existência do framework. De certa forma eu também concordo com isso.

A minha pergunta, provocativa, é a seguinte: supondo que os 80% que o framework resolve são os problemas genéricos que todos os projetos têm, não seriam os 20% restantes (que frameworks tornam difícil) o que realmente agrega valor e diferencia o produto? Ou seja: no final das contas, os frameworks não atrapalhariam o desenvolvimento daquilo que é a razão de um sistema existir?

Casa de ferreiro…

A bruxa estava solta no final de semana. Passou pelo Job4Dev e apertou o botão FODA-SE SISTEMA (uma variante do botão FODA-SE Rubinho, muito usado pela Ferrari).

Na sexta, o sistema de markdown parou de funcionar. Sem mais nem menos. Nada foi mexido no sistema. Ele funcionava, e depois deixou de funcionar. Foi resolvido: era uma simples questão de path. Mas mesmo assim eu pergunto: como alguém ainda pode dizer que a computação é uma ciência exata?

Tá bom, provavelmente este vai ser mais um daqueles bugs misteriosos cujo computador é o primeiro a levar a culpa (”eu tenho certeza que funciona, não tem como não funcionar, a culpa é deste micro lazarento que não sabe nem processar um if decentemente”), e que depois a gente percebe que a culpa é do desenvolvedor. Esta constatação em geral é seguida por um “Ahhhhhhhh..”

Logo em seguida, um erro de operação (famosa problema de interface cadeira-teclado) fez com que a base de dados fosse pro beleléu. E obviamente, em casa de ferreiro espeto de pau: isto aconteceu logo depois de eu escrever um post sobre a importância do backup. E obviamente eu não tinha um backup local configurado. OBVIAMENTE.

Não querendo esperar o pessoal do webfaction encontrar o backup no meio de toneladas de arquivos, tomei duas decisões:

  1. Restaurar os anúncios mais importantes/mais recentes na mão e aproveitar pra fazer uma limpeza geral no sistema.
  2. Montar um sistema de backup local. Os mais astutos perceberão que o post sobre o pgpass foi fruto desta tarefa.

Estamos no ar novamente, e agora com um sistema muito mais rápido, estável, confiável e a prova de manipulações desastrosas.

.pgpass

Estou configurando um sistema simples de backup da base de dados do Job4Dev, usando as ferramentas crontab do linux e pg_dump do Postgres. Clássico.

Mas me deparei com um probleminha: a base de dados é criada com um usuário diferente do meu usuário no servidor. E o comportamento padrão do pg_dump (e de qualquer ferramenta relacionada ao Postgres)
é de pedir a senha em um prompt, o que é obviamente problemático em uma tarefa automatizada.

A solução é criar um arquivo chamado .pgpass, armazenado na raiz do home dir do usuário que irá executar o comando com a permissão 600 (qualquer outra permissão fará com que o arquivo seja ignorado) e contendo a seguinte informação:

hostname:port:database:username:password

Pronto, agora qualquer comando que envolva a tupla (host, port, database, username) descrita no arquivo tem acesso direto à base. Mais informações podem ser encontradas aqui.

Next Page »