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?

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]

Um tempo atrás eu percebi que estava praticamente viciado em checar email. Eu estava programando com o Eclipse aberto ou coisa assim e a cada 2 ou 3 minutos eu abria rapidinho o Firefox e dava uma olhada no Gmail, passava pelo Thunderbird e verificava meu email da universidade, e daí voltava a programar. Na grande maioria das vezes nem tinha email pra mim, e na realidade eu nem tenho certeza de que acontecia alguma mudança de contexto no meu cérebro, já que eu continuava pensando no que estava programando. Era praticamente um reflexo automático e involuntário.

Bom, vicio é uma coisa muito difícil de se contornar. Quando você está realmente viciado, não tem como sair dessa facilmente. Principalmente se você não vê nenhuma conseqüência negativa muito grande no seu vicio. Então eu resolvi que o unico jeito seria gerenciar um pouco o vicio, torná-lo mais leve.

A minha solução foi instalar um daqueles ícones de painel que fica checando email periodicamente e muda de cor quando tem algo na caixa. Dessa forma, ao invés de ter o trabalho de abrir varias janelas, eu só dou uma batida de olho no canto da tela e pronto. Eu sei que isso não resolve meu vicio, mas certamente ameniza.

Eu sou usuário Linux há uns bons 10 anos, então vou falar dos leitores de email que achei interessante nessa plataforma, mas com certeza existem boas opções em Mac ou Windows, já que é um tipo de aplicação bem fácil de fazer (e existem há anos). Eu quase sempre usei KDE, mas depois de sofrer com KDE4 por 1 mês eu resolvi que não aguentava mais e mudei pro Xfce, com o qual estou mais que satisfeito. No painel do xfce, eu instalei o xfce4-mailwatch-plugin. É um plugin beeeem simples, que suporta vários protocolos e te avisa se chegou algum email. Apesar dele também suportar Gmail, eu preferi instalar o checkgmail, que não é especifico de xfce. É um leitor bem legal, que aproveita a API do Gmail pra te deixar ler o começo do email e executar algumas funções básicas, como marcar como lido, deletar, arquivar, etc. É muito bom, pois se eu vejo que o que recebi é lixo, eu simplesmente deleto ali, sem nem ir pro browser.

Bom, tem ainda o vicio do Google Reader que não tem solução simples. Mas pelo menos nesse eu não to tão viciado, já que tem tanta informação que eu reservo um horário do dia pra ler o que apareceu por lá. E em geral não é algo que eu quero saber imediatamente, como os emails.

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.

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.

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.

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.

Há meses eu tenho discutido com o editor-chefe a respeito de criarmos um site que servisse como um ponto de referência para qualquer pessoa que estivesse buscando informações mais detalhadas sobre questões e dúvidas em programação. Muita coisa pode ser encontrada em blogs, mas as informações encontradas acabam por vezes sendo incompletas ou desatualizadas. O oráculo responde por muita coisa, mas não é infalível.

Os livros técnicos também têm problemas: são caros para estudantes novos, também ficam obsoletos, são muitas vezes terrivelmente traduzidos e nem sempre contém tudo que o usuário busca.

Eu realmente gosto de sistemas como o Safari Bookshelf, da O’Reilly. Paga-se uma mensalidade e em troca o usuário tem acesso a toda a biblioteca da O’Reilly em formato eletrônico. Há busca, indexação e todas as comodidades de um meio eletrônico.

Timing é fogo. Ontem mesmo eu estava falando do Google Doctype. Ou seja, essa necessidade de um ponto atualizado de informação é não só minha, mas de muitos outros. Mas como eu não sou O’Reilly, nem Larry nem Sergei, não tenho como contratar especialistas de determinadas áreas para escrever os tais livros, não posso me aventurar a criar uma concorrente para o Safari.

Entretanto, eu posso oferecer um espaço online para que as pessoas adicionem material livremente e tentem compilar uma biblioteca, e mantenham-na atualizada. É com esse princípio que nós estamos colocando no ar o Books4Dev. O nome é terrível, mas a intenção é das melhores. Não há quase nada de material lá, e começamos oficialmente ontem a escrever e editar algumas páginas.

Em termos de tecnologia: eu já falei do Infogami. É um wiki turbinado por algumas poucas outras features. Algo um pouco mais simples e direto do que um CMS completo. Acho que pode nos atender bem para esse projeto. Tempos atrás, chegamos a colocar o Plone para isso, mas a curva de aprendizado pareceu tão grande que se tornou um obstáculo para alguém que quer algo simples, para um projeto paralelo.

Esse é um projeto que vai precisar contar com a ajuda e o interesse de muita gente. Se você tiver trabalhando com alguma tecnologia que lhe seja nova, sinta-se livre para criar uma página e usar o wiki como um caderno de anotações. Outros usuários poderão ver, aprimorar, clarificar algumas passagens, melhorando ainda mais a biblioteca.

Passe a idéia adiante. Qualquer contribuição é válida e bem-vinda. Vou até pedir para que o “the-one-who-can’t-be-named” escreva sobre Java…

Ok. Tem coisas que a gente tem que tirar o chapéu: o Google lançou um site que contém material de referência para todas as tecnologias usadas por desenvolvedores web. Tudo que você pode vir a precisar saber sobre (X)HTML, CSS e Javascript foi juntado no Google Doctype, lavado, passado, engomado e posto em uma bela forma de apresentação e navegação. Não basta isso, eles liberaram o próprio código de Javascript que eles usam para sites como Gmail e Google Maps. Pouca coisa, né?

Mas, por favor, não seja um geek-cheerleader da empresa que aparenta ser boa-moça. Você vai ver por aí um monte de gente falando sobre o quanto eles são legais, dão coisas de graça, entregam presentes no Natal… Não caia nessa. Uma jogada assim não é altruísta. É estratégia.

Empresas inteligentes comoditizam produtos complementares aos seus.

Há um artigo de Joel Spolsky que ele mostra brilhantemente o porquê do interesse das grandes empresas pelo Open Source. Não é por benevolência ou por caridade. É estratégia, pura e simples. Consiste em fazer com que você torne produtos complementares ao seu em commodities, para que o custo de aquisição dele seja baixo, o menor possível. Quando o custo de um produto complementar ao seu é baixo, você está indiretamente tornando mais fácil a aquisição do seu produto principal.

É uma explicação para termos empresas que colocam pesadas somas em investimento em software aberto. Tomando um exemplo do artigo: a IBM é - atualmente - uma empresa que vende serviços de consultoria e desenvolvimento em TI, certo? Se você quiser contratar alguém para desenvolver uma aplicação para você, você vai ter que custear parte da infraestrutura: pessoal, máquinas, servidores, licenças de software/pacotes de desenvolvimento… tudo que seria necessário para que o produto se torne uma realidade.

Pergunta: se um cliente potencial tem um orçamento X para esse contrato, e que você sabe que esse valor terá que ser dividido entre pessoal, máquinas, servidores, IDE’s e estoque de café Pilão para os programadores, não seria melhor que o grosso desse dinheiro fosse gasto onde você tenha a maior margem de lucro possível?

Acontece que pó de café, máquinas e servidores já são commodities. Um cliente pode trocar de fornecedor sem ter grande prejuízo. Não há muito que pode ser feito aqui.

Também podemos comoditizar pessoal, sabia? Muitas das empresas de consultoria estão apenas buscando profissionais certificados justamente para que possam pensar nos desenvolvedores como peças intercambiáveis. Ao oferecer e buscar pessoas que possuam cursos e certificações, elas estão comoditizando o mercado de profissionais.

O que restaria? Diminuir o custo de aquisição de licenças de software. Ao investir em soluções Open Source, uma empresa que presta serviços de consultoria está comoditizando um produto complementar. Dessa forma, seus clientes passam a alocar mais de seus recursos naquilo que lhes interessa. Genial, não é mesmo?

Voltando ao Google…

Tudo que o pessoal do Google deseja é dominar a web como plataforma de desenvolvimento. Para isso, o que eles precisam é de mindshare. Quanto mais gente desenvolvido aplicações para web, mais o Google fica próximo do seu sonho do Cloud Computing. Quanto mais desenvolvedores trabalhando com web, mais barato fica o custo de desenvolvimento de aplicações web. Quanto mais baratos os serviços oferecidos pela web, mais o Google pode obter de faturamento em produtos como o AdWords e AdSense.

Uma empresa como a Google oferecer de graça informação que facilita o desenvolvimento de aplicações web é a mesma coisa que uma empresa como a IBM investir no Linux e oferecer ferramentas gratuitas como o Eclipse.

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

Essa vida de blogueiro “4Dev” é dura. Os planos de dominação mundial do editor-chefe dão dor de cabeça para os tais “colaboradores”. Ter que trabalhar de ghost-writer é pouco. Agora a gente tem que bancar o ghost-developer. Já não basta ter a cara de pau de pedir pra gente escrever 32 artigos por semana, ele ainda me pediu na semana passada para que eu fizesse um site que fosse um banco de banco de dados de várias empresas de tecnologia. Parece que ele está querendo expandir os recursos e funcionalidades de certo site de empregos, e um recurso que pode ser interessante para o usuário é ter um link que contenha informações relevantes a respeito da empresa.

Enquanto eu limpava as feridas causadas pelas chicotadas recebidas durante tal singelo pedido, perguntei de onde viriam os dados sobre as empresas. A resposta não poderia ter sido mais brilhante:

Seu imbecil! Todo mundo sabe que a onda do web2.0 é o crowdsourcing. Deixe que os próprios usuários do sistema coloquem os dados sobre as empresas que já conhecem. Pra que pagar por algo quando alguém pode fazer por você, de graça?

Foi aí que eu percebi que o editor-chefe não queria um banco de dados, mas ele queria um sistema parecido com um wiki, onde os usuários pudessem criar novas entradas e editá-las posteriormente. Deu certo com a Wikipedia, pode dar certo para uma compilação de informações sobre empresas, não é mesmo?

Sistemas “wiki” existem aos milhares. Permitem que você crie novos documentos livremente, que edite e mantenha um histórico de alterações, protegem contra usuários maliciosos que vandalizam o site, etc, etc, etc. É uma proposta simples e eficiente para facilitar a captação de dados vindos de vários usuários.

Por outro lado, um simples wiki serve apenas como repositório de documentos. Arquivos simples de texto. Não há forma de estruturar a informação de maneira consistente, a não ser que você obrigue cada usuário a seguir um padrão de documento que possa ser processado por um programa.

A alternativa seria um sistema que usasse os princípios do wiki, mas que pudesse ser aplicado a outros “tipos” de dados além de blocos de texto. Para alegria do editor-chefe e salvação de meu lombo, tal alternativa existe: Infogami.

O Infogami permite que você defina tipos estruturados. Depois, pode-se indicar qual é o tipo de cada recurso (uma URL pode ser a representação de um tipo “documento”, outro pode ser do tipo “usuário”, outra pode ser do tipo “Foto com legenda”, etc), e esses recursos podem ser adicionados, editados e removidos livremente, como num wiki.

Existe também a possibilidade de alterar a representação visual para cada tipo: a página que mostra um documento pode ser totalmente diferente da página que mostra os dados de um usuário, por exemplo. E também podemos estender o sistema com plugins e macros para automatizar ações e operadores que atuam nos tais tipos.

Se você quiser ter uma idéia do potencial desse sistema dê uma olhada na OpenLibrary, que é um site que é “Powered By Infogami”, além do Jottit, que é o sistema mais simples que eu conheço para colocar uma página online.

É praticamente certo que eu vá usar o Infogami como plataforma para o desenvolvimento dessa base de dados de empresas. Só não está pronto pelo fato do editor-chefe, em Sua Infinita Benevolência, ter permitido que eu me dedique a outro trabalho nos últimos dias… tipo assim, um que seja capaz de pagar as minhas contas…