O fenômeno Twitter

Twitter é a mais nova revolução da Web 2.0. Não tão nova assim em tempo de internet, mas explosiva do mesmo jeito. É uma combinação de rede social e micro-blogging.

Você pode escrever micro-posts (o limite é 140 caracteres). Seus amigos recebem seus posts e podem respondê-los. É altamente viciante (um motivo pelo qual optei por me abster). Você pode enviar posts pela interface web, por aplicações desktop, ou via SMS. A opção de postar pelo celular e o limite de tamanho dos posts encorajam uma comunicação frequente e espontânea, parecida com a de mensagens instantâneas como MSN e Google Talk.

Um diferencial é que seus posts também vão (se você permitir, claro) para uma grande linha do tempo pública. Quando os posts de todo mundo são agregados dessa forma, muitas vezes surge um Zeitgeist instantâneo: tópicos que dominam a atenção coletiva dos Twitters em um dado momento.

No bom espírito Web 2.0, o Twitter disponibiliza uma bela API. Essa API, combinada com a linha do tempo pública, levou a diversas aplicações divertidas. Por exemplo, o Twitterverse é uma tag cloud que mostra as palavras mais frequentes na linha do tempo na última hora. Já o TwitterBuzz mostra os sites mais linkados na linha do tempo. E tem usos mais especializados. O Politweets mede a popularidade dos pré-candidatos a presidente dos EUA com base no número de posts (também chamados de tweets). E os candidatos mais antenados com a internet usam o Twitter para enviar propaganda.

O Twitter também tem utilidade pública. Os bombeiros de Los Angeles começaram a usar o Twitter para postar alertas e coordenar atividades via celular no combate aos incêndios florestais de outubro do ano passado, e ainda usam o Twitter até hoje. Outra aplicação legal (essa eu quero aqui pro Brasil com urgência) é o Commuter Feed, que recebe mensagens de motoristas e posta informações em tempo real sobre o trânsito em diversas áreas metropolitanas dos EUA.

Ah, e o Twitter é escrito em Ruby on Rails ;-)

Desenvolvimento, Inovação, Mobile, Web 2.0 4 Comentários

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Escalabilidade transparente

Escalabilidade é um conceito importante em qualquer sistema web, embora eu ache que às vezes as pessoas se preocupam demais com isso. A grande maioria das aplicações web simplesmente não precisam escalar muito. Existe, então, um trade-off entre tempo de desenvolvimento e o esforço extra necessário para planejar e implementar sua arquitetura de forma a escalar da melhor maneira possível. Quando você não precisa lidar com enormes volumes de dados e usuários simultâneos, muitas vezes a decisão correta, do ponto de vista de negócio, é minimizar o tempo de desenvolvimento e arcar com algum custo extra de hardware caso preciso. Hardware que fica mais barato a cada dia.

Existem outras alternativas, que tentam garantir que sua aplicação é escalável sem cobrar um preço caro em termos de tempo e esforço de desenvolvimento. Um ponto chave é minimizar o compartilhamento de dados entre componentes da sua aplicação. Se você não compartilha nada, fica mais fácil escalar. Esse modelo, chamado de “shared nothing”, é encorajado por diversos frameworks para desenvolvimento web, e é praticamente obrigatório quando se desenvolve com Ruby on Rails, por exemplo.

Quando sua aplicação segue o modelo “shared nothing”, você pode obter escalabilidade simplesmente usando os serviços da Amazon. Precisa de mais servidores web? Adicione instâncias à sua conta da Elastic Computing Cloud. Precisa de mais servidores de banco? A mesma coisa, mas as instâncias são configuradas de outra forma (que você pode definir, através de uma imagem de máquina virtual). Espaço em disco? Sem problema. Tudo sobe e desce de forma quase instantânea. Um grande avanço comparado ao processo tradicional de estimar suas necessidades de hardware e comprar os servidores com alguma antecedência — ou sair correndo para apagar o incêndio quando ele estoura.

Pois agora tem gente que acha que mesmo serviços como os da Amazon são muito complicados. Estão querendo transformar escalabilidade em algo totalmente transparente para o desenvolvedor. Um exemplo disso é a Heroku, que lançou recentemente um serviço de escalabilidade automática. Você registra sua aplicação (Ruby on Rails) com eles e eles cuidam de escalar usando os serviços da Amazon. Você não precisa se preocupar com a monitoração dos seus nodos de processamento, decidir quando adicionar ou remover nodos, etc. Você pode até desenvolver sua aplicação usando um IDE web que eles oferecem.

Claro que um serviço desses tem suas desvantagens. Em primeiro lugar, você perde em flexibilidade: vai ter que usar as versões de Ruby, Rails e bibliotecas que a Heroku suporta. Não há como integrar facilmente sua aplicação com sistemas legados. E assim por diante.

Mesmo assim, é mais um grande avanço em uma das tendências-chave por trás da Web 2.0: a redução de barreiras de entrada. Cada vez que um obstáculo técnico ao sucesso de um produto web é removido, fica mais fácil e barato desenvolver novos produtos inovadores. Sob essa ótica, viva a escalabilidade transparente!

Desenvolvimento, Internet, Web 2.0 0 Comentários

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Ruby On Rails

Quem trabalha com “Desenvolvimento Web” quase certamente já ouviu falar de Ruby On Rails. Assim como muitas tecnologias, RoR (pra encurtar) gerou muito hype nos últimos meses e, consequentemente, uma legião de fanboys que pregam fervorosamente que RoR é a melhor coisa que já inventaram desde o pão-fatiado. :-)

O quê

Mas em que consiste exatamente o tal “Ruby On Rails”? Traduzindo diretamente do site oficial:

Ruby On Rails é um framework web de código aberto que é otimizado para a satisfação do programador e produtividade sustentável. Ele permite que você escreva código elegante ao favorecer convenção ao invés de configuração.

E ainda:

Ruby On Rails é um framework completo para desenvolvimento de aplicações web de acordo com o padrão Model-View-Controller (ou MVC).

Até aí, nenhuma novidade. Antes da popularização de RoR, já existiam diversos outros excelentes frameworks como ASP.NET, a pilha Servlets+JSP+Struts+Hybernate e PHP/Zend, só pra citar alguns. O diferencial de RoR está justamente na adoção da metodologia de desenvolvimento de software “Ágil”, ao focar as funcionalidades do framework nas necessidades diretas dos desenvolvedores e diminuir tanto quanto possível o tempo gasto com instalação e configuração do ambiente.

Por esse motivo, RoR se tornou especialmente popular entre desenvolvedores e empresas que adotam processos semelhantes ao “Extreme Programming”, onde a elaboração rápida de um protótipo e a constante refatoração do código são essenciais. RoR realmente prima nestes casos. Chega a ser assustador a facilidade com que se gera o esqueleto e o protótipo de uma aplicação MVC, ou o número ínfimo de linhas de código que são necessárias para implementar funcionalidades relativamente sofisticadas.

Porquê

Descontando um pouco do exagero típico dos fanboys, é fácil notar com pouco tempo de uso porque Ruby On Rails se popularizou tão depressa.

  • Convenção ao invés de Configuração: Levante a mão quem nunca perdeu pelo menos umas 2 horas de trabalho tentando instalar ou configurar uma aplicação/sistema/etc e descobriu no fim do dia que o problema era um “;”, ou um path errado. Pois é, RoR procura acabar com essa dor-de-cabeça ao eliminar tanto quanto possível os malfadados arquivos de configuração através da adoção de uma série de convenções que permite integrar as diferenças partes do framework sem praticamente nenhuma intervenção direta do desenvolvedor.As convenções englobam todo tipo de aspecto de uma aplicação web: o nome dos modelos e tabelas relacionais associadas; o nome da colunas das tabelas que constituem chaves primárias e estrangeiras; o nome dos arquivos e das classes que implementam cada camada da estrutura MVC; o nome e identificador dos campos HTML e diversas outras.
  • ActiveRecord: Active record é um design pattern utilizado para acessar bancos de dados e fazer o mapeamento Objeto-Relacional. O padrão em si é bem mais antigo do que RoR, mas a implementação utilizada em RoR em específico prima pela qualidade e é um dos pontos fortes e mais badalados do framework. A extensa utilização de instrospeção, tanto do lado da estrutura relacional, quanto da parte das classes e objetos torna praticamente desnecessário escrever mais do que meia dúzia de linhas de código para se fazer o mapeamento de uma classe/tabela.
  • ActionView: Da mesma forma que o módulo ActiveRecord é responsável pela implementação dos modelos, ActionView é o módulo responsável pela implementação das visões. O diferencial está no fato de este módulo ser fortemente influenciado pela metodologia ágil: quase todas as funcionalidades tipicamente utilizadas para construção de uma interface web podem ser adicionadas através de uma API concisa e intuitiva. Mesmo as tendências mais recentes das aplicações Web modernas — como Javascript, DHTML e AJAX — estão fortementes integradas ao framework. Em RoR, usa-se apenas uma linha de código para adicionar funcionalidades relativamente complexas como “atualizar uma tabela/list assincronamente” ou “adicionar um campo de texto com auto-sugestão” (no estilo Google Suggest))
  • Plugins: Outra grande vantagem de Ruby On Rails é sua extensibilidade. Devido à sua crescente popularidade, existem hoje literalmente centenas de plugins (normalmente gratuitos) disponíveis para os desenvolvedores incrementarem suas aplicações conforme as necessidades individuais de cada projeto — permitindo assim que uma gama enorme de problemas sejam rapidamente resolvidos sem necessariamente tornar o core do framework demasiadamente inchado. Mas cuidado: em alguns casos, é preciso ficar atento para não se perder mais tempo escolhendo o melhor plugin que implementa uma deterinada funcionalidade do que efetivamente instalando e utilizando o plugin. :-)
  • Ruby: Flamewars discutindo qual a melhor linguagem são quase tão antigas quanto a própria computação — portanto não vou me alongar demasiadamente nesse tópico — mas é inegável que parte da atratividade de RoR advém da linguagem Ruby. Pra quem ainda não conhece, sugiro o tutorial rápido do site oficial, ou ainda o divertidíssimo“Guia Pungente”, por “Why The Lucky Stiff”.

Por que não

Nenhuma boa análise técnica estaria completa sem uma seção de “Contras”, e esse post não poderia ser diferente.

  • Performance: Um dos compromissos que precisam ser feitos para se tirar proveito da elegância e agilidade de se utilizar uma linguagem como Ruby é o desempenho. Por ser uma linguagem dinamicamente tipada que executa sobre uma interpretador (pra lá de ineficiente, diga-se de passagem), Ruby On Rails é inegavelmente um framework com overhead alto. Muita gente vai argumentar que baixa performance não é tão crítico se sua arquitetura tem boa escalabilidade, e outros ainda irão citar diversas técnicas para minimizar esse overhead, mas ainda assim, em alguns casos a recomendação é deixar de usar justamente as funcionalidades que tornam o framework interessante.Por outro lado, as comunidades por trás de Ruby e RoR estão cientes desse problema e tem trabalhado para atenuá-lo. A versão 2.0 de RoR, por exemplo, já apresenta significantes melhorias, e a próxima grande revisão da linguagem Ruby que deve ser lançada ainda nessa década também promete ganhos substanciais de performance, graças à utilização de um nova máquina virtual.
  • Código legado: Uma das máximas de RoR — “Convenção ao invés de configuração” — perde seu appeal quando consideramos sistemas legados. Nesses casos, é provável que sua base de dados ou suas classes existentes não tenham adotado as mesmas convenções utilizadas por RoR. Com isso, é necessário adicionar diversas diretrizes no código para sobrescrever os valores e padrões utilizados pelas tais convenções. Não chega a ser a mesma dor-de-cabeça de se editar um “hibernate.cfg.xml” ou um “web.xml”, mas é possível que você acabe sendo forçado a escrever alguns trechos de [gasp!] SQL. :-)
  • Documentação: Algumas tecnologias promissoras perdem momento devido à carência de documentação. Ruby On Rails sofre do problema inverso: excesso de documentação. Hoje em dia é natural utilizar a Internet para buscar por trechos de código, recomendações, receitas ou (no caso de RoR) plugins para se solucionar um problema específico ou implementar corretamente uma funcionalidade. O problema é que, frequentemente, a documentação ou plugin encontrados estão defasados por terem sido escritos/implementados com foco em uma versão do framework que já está deprecada. Como o desenvolvimento de RoR é muito dinâmico — a versão 1.0 foi lançada em Dez/05; a versão 1.1 em Mar/06; a 1.2 em Jan/07; e a 2.0 em Dez/07 — e não existem garantias de compatibilidade, muitas vezes torna-se difícil encontrar a solução correta para a versão específica do framework que você está utilizando.

Pra finalizar

Se você se é desenvolvedor Web, mora em Belo Horizonte, se interessou por Ruby On Rails e gostaria de saber mais a respeito, o Instituto Turing está oferencendo um curso intensivo à partir do dia 14 de abril. Para maiores informações, mande e-mail para cursos@institutoturing.org.

Desenvolvimento, Internet, Web 2.0 3 Comentários

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Levando o Firefox 3 Beta 4 pra passear

Eu nunca fui um usuário freqüente do Microsoft Internet Explorer; do Mosaic (no longínquo 1995) eu passei pro Netscape Navigator, depois para o Mozilla (cuja base de código inicialmente era a mesma) e finalmente para o Firebird (que mais tarde seria renomeado Firefox e viraria um tremendo sucesso).

Com isso acompanho de perto o desenvolvimento das novas versões, mas normalmente não uso a mais recente disponível, por uma razão simples: não consigo viver sem umas duas dúzias de extensões (como GreaseMonkey, WebDeveloper, TabMixPlus, AdBlock, e várias outras – depois escrevo sobre isso), e muitas delas não funcionam nas versões beta.

Só que eu ouvi falar tão bem do Firefox 3 Beta 4, que dessa vez não resisti. A promessa era a de um browser muito mais rápido e com consumo de memória bem mais baixo (o que é fundamental quando se mantém 20-30 tabs abertas), e devo admitir que acertaram em cheio – aplicações Javascript pesadas como o GMail estão bem mais ágeis, e os famigerados memory leaks que me obrigavam a reiniciar o Firefox de vez em quando sumiram (ou foram drasticamente reduzidos).

Firefox

A maioria das extensões funcionou com o Firefox 3; para continuar usando algumas como a TabMixPlus eu precisei de baixar versões alpha do site do desenvolvedor. Algumas poucas (e simples, como a ColorfulTabs) eu forcei o funcionamento usando a excelente NightlyTester (que permite instalar extensões mesmo que as informações de versão indiquem incompatibilidade).

Nem tudo correu bem, entretanto: a caixa de edição de texto do GMail, por exemplo, vai mostrando lixo enquanto eu digito (linhas horizontais finas aparecem misturadas no texto, ao digitar e ao fazer scroll, acho que relacionadas ao verificador ortográfico). Curiosamente isso não acontece, por exemplo, na caixa de entrada de texto do WordPress.

Ainda assim, depois de um dia inteiro usando, decidi que os benefícios do novo Firefox superam os pequenos problemas que ainda existem (ainda se trata de uma versão beta, afinal de contas). O upgrade vale a pena, mesmo para usuários casuais.

Web 2.0 0 Comentários

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Microcrédito com ares de web 2.0

Microcrédito, de acordo com a Wikipedia, é emprestar quantias bem pequenas para pessoas que não têm como obter crédito no sistema financeiro tradicional. Pobres, desempregados, “empreendedores” de economia informal não têm como dar garantias bancárias e o sistema tradicional de crédito via bancos ou financeiras não os atende.

Microcrédito é uma idéia razoavelmente antiga, que se tornou popular depois de casos de sucesso no Bangladesh na década de 70, principalmente o do Grameen Bank. Em 2006 o banco e seu fundador receberam o Prêmio Nobel da Paz em reconhecimento ao profundo poder de transformação social do microcrédito.

Hoje em dia há milhares de organizações no mundo todo dedicadas ao microcrédito, inclusive no Brasil, embora o país ainda tenha muito a fazer no amadurecimento dessa idéia. A maior parte das organizações se divide em dois grupos: ONGs sem fins lucrativos e que recebem doações de capital para emprestar e bancos especializados, muitas vezes braços de bancos maiores tradicionais. As ONGs de microcrédito enfrentam o problema comum a todas as ONGs: levantar fundos.

Em 2005, um casal do Vale do Silício resolveu criar uma startup de microcrédito. Nascia a Kiva. Sem fins lucrativos, a Kiva permite que qualquer pessoa se registre e empreste pequenas quantias usando seu cartão de crédito ou conta no PayPal. Uma rede de organizações associadas mundo afora cadastra e seleciona as pessoas que receberão os empréstimos. O valor típico de um empréstimo é de algumas centenas de dólares, e cada usuário da Kiva participa com uma cota fixa de US$25. Dessa forma, cada empréstimo é um esforço colaborativo, bem dentro do paradigma Web 2.0.

E funciona? Sim, funciona. A Kiva explodiu e continua crescendo de forma exponencial. Em pouco mais de dois anos, ela emprestou mais de US$25 milhões. Foram mais de 37 mil empréstimos em 42 países, financiados com cotas de mais de 250 mil pessoas.

E isso não é tudo. De todos esses empréstimos, 99.9% foram pagos integralmente. Não existe banco tradicional no mundo que chegue perto disso. Só pra comparar, no Brasil a taxa de inadimplência de empréstimos bancários para pessoa física é de 7%, segundo o Banco Central.

Há quatro meses eu entrei na onda. Fiz dois empréstimos. O primeiro para a Sra. Selina John, que tem uma barraca de vender cerveja e refrigerantes em Dar Es Salaam, Tanzânia. O segundo para o Sr. Angel Peralta, do Equador. Confesso que escolhi pelo nome, mas depois vi que o Sr. Peralta já contraiu e pagou outros empréstimos anteriormente.

Selina já pagou todo o seu empréstimo. Com o dinheiro ela aumentou seu estoque e seus lucros mensais. Quando você empresta dinheiro, só o recebe de volta depois que todas as prestações (em geral mensais) são pagas. O dinheiro é creditado na sua conta da Kiva e você pode sacá-lo ou reemprestar.

A sensação de ajudar diretamente essas pessoas é viciante. A Kiva cria perfis de cada pessoa, com fotos e historinhas, o que cria um vinculo emocional. Ou seja, assim como a grande maioria dos outros usuários, nem pensei em sacar minha grana. Já estou à procura do próximo empréstimo. E torcendo pra que logo alguma organização de microcrédito do Brasil esteja madura o suficiente para atender aos critérios de cadastramento da Kiva :-)

E isso não é tudo. De todos esses empréstimos, 99.9% foram pagos integralmente. Não existe banco tradicional no mundo que chegue perto disso. Só pra comparar, no Brasil a taxa de inadimplência de empréstimos bancários para pessoa física é de 7%, segundo o Banco Central.

Há quatro meses eu entrei na onda. Fiz dois empréstimos. O primeiro para a Sra. Selina John, que tem uma barraca de vender cerveja e refrigerantes em Dar Es Salaam, Tanzânia. O segundo para o Sr. Angel Peralta, do Equador. Confesso que escolhi pelo nome, mas depois vi que o Sr. Peralta já contraiu e pagou outros empréstimos anteriormente.

Selina já pagou todo o seu empréstimo. Com o dinheiro ela aumentou seu estoque e seus lucros mensais. Quando você empresta dinheiro, só o recebe de volta depois que todas as prestações (em geral mensais) são pagas. O dinheiro é creditado na sua conta da Kiva e você pode sacá-lo ou reemprestar.

A sensação de ajudar diretamente essas pessoas é viciante. A Kiva cria perfis de cada pessoa, com fotos e historinhas, o que cria um vinculo emocional. Ou seja, assim como a grande maioria dos outros usuários, nem pensei em sacar minha grana. Já estou à procura do próximo empréstimo. E torcendo pra que logo alguma organização de microcrédito do Brasil esteja madura o suficiente para atender aos critérios de cadastramento da Kiva :-)



--> Inovação, Web 2.0 0 Comentários

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Next Entries »