Adeus delicious. Bem-vindo diigo!

2012-01-26

Se você é um dos três persistentes que ainda me segue no delicious saiba que este é o meu último bookmark naquele serviço. Estou abandonando o deliciou e passando a manter meus bookmarks no diigo apenas. Se quiser continuar a me seguir, o feed de meus bookmarks passa a ser http://www.diigo.com/rss/user/gnustavo.

Comecei a usar o delicious em dezembro de 2004 quando ele ainda se chamava del.icio.us. Nesses sete anos cadastrei quase 8.000 links lá e por muito tempo fui um usuário satisfeito. No ano passado ele passou por uma reformulação e, coincidentemente ou não, a extensão do Chrome que eu usava para postar os links estava ficando cada vez mais lenta. Acabei encontrando o Diigo por acaso e resolvi experimentá-lo porque diziam que era mais rápido. E é, realmente. Apesar de que pra postar um link com tags você tem que dar dois cliques a mais, o que me irritou no início. Mas pelo menos eu não tinha que ficar esperando a janela do delicious abrir pra poder registrar as tags. O mais legal é que o Diigo permite que eu cadastre minha conta delicious nele de modo que a cada novo link que eu posto no Diigo ele o reposta (eta palavrinha feia!) no delicious automaticamente.

Fiquei nesse esquema por alguns meses e estava até pensando em voltar a experimentar a extensão do delicious pra ver se já tinham resolvido o problema de desempenho quando descobri que o Diigo oferece várias outras funções além do registro de tags e descrição dos links. A mais legal é a possibilidade de marcar (to highlight) trechos da página HTML que eu quero postar. As marcas aparecem com fundo amarelo pra mim e o conteúdo marcado aparece como comentários abaixo do link na página do Diigo. E eu posso até criar um shortURL específico pra um link e publicá-lo para que outras pessoas possam ver a página junto com minhas marcas.

Além das marcas eu também posso colocar comentários na página. Em pontos específicos. É muita funcionalidade por um precinho tão baratinho. (Dica: é de graça.)

É isso aí. Obrigado, delicious, por todos esses anos de bons serviços prestados. Mas é o que eu sempre diigo: não me responsabilizo caso você fuce no meu delicious. 🙂

Anúncios

Ruby on Rails

2007-11-22
Assisti ontem a uma palestra excelente sobre Ruby on Rails. É a terceira ou quarta palestra sobre RoR a que eu assisto. Descontando a do próprio David Hansson a que eu assisti no FISL 6.0 esta foi a mais detalhada e interessante. A impressão que eu tive depois de conversar com algumas das 30 pessoas que estavam lá é que o Bill Coutinho da Dextra conseguiu entusiasmar várias delas.

Além dos tutoriais tradicionais e da geração automática de código (scaffold!) o Bill apresentou uma perspectiva mais atual e mais madura sobre a utilização do framework. Alguns pontos que o Bill ressaltou na palestra:

  • A Dextra mediu um incremento de 100% na produtividade nos primeiros projetos RoR executados por programadores com experiência em Java.
  • Programadores Java têm pouca dificuldade em aprender Ruby e RoR.
  • O JRuby permite rodar
    aplicações RoR dentro de servidores de aplicação Java como o Tomcat e o
    JBoss, o que possibilita a integração de uma interface web RoR com
    bibliotecas Java.
  • RoR é ótimo para desenvolver aplicações web baseadas em bancos de dados. Fora disso, use outra coisa.
  • Programar em Ruby é muito mais legal que programar em Java. 🙂

Google Android

2007-11-13
Há um artigo interessante sobre lançamento do SDK do projeto Android do Google. Pra quem ainda não viu, o Android é uma plataforma aberta para dispositivos móveis baseada em Linux e Java.

O Google junto com outras 34 empresas formaram o Open Handset Alliance pra desenvolver esta tecnologia que parece que vai estar disponível comercialmente no segundo semestre de 2008.

O autor do artigo já está chamando o Android de tecnologia de ruptura. Será?


SGBDs orientados a colunas

2007-11-12
Semana passada assisti a uma palestra do Eduardo Sato da Sybase na qual ele explicou a tecnologia por trás do Sybase IQ, um banco de dados relacional usado em ambientes analíticos, como data warehousing e aplicações de Business Intelligence em geral.

A tecnologia em questão se chama column-oriented DBMS e é essencialmente uma forma não-tradicional de armazenar os dados das tabelas em disco. Normalmente, os dados de uma tabelas são armazenadas por linhas, i.e., todos os campos de uma linha são armazenados de maneira contígua no disco. Já num SGBD orientado a colunas os dados de uma tabela são armazenados por coluna, i.e., todos os campos de uma coluna da tabela são armazenados de maneira contígua.

Essa diferença aparentemente trivial modifica totalmente as características de desempenho do banco de dados. O armazenamento por linhas é ideal para acessos de linha inteira. Pense num insert ou num update que modifique todos os campos da linha. Ou mesmo, num select *. De fato, a forma de armazenamento por linha é a que garante melhor desempenho para a maioria das aplicações transacionais.

Agora pense num ambiente analítico, no qual os inserts e updates são quase inexistentes e a maioria absoluta das consultas são de selects. Normalmente, as tabelas usadas nestes ambientes são “tabelões”, com um grande número de colunas, resultado da agregação de várias tabelas extraídas de sistemas transacionais, planilhas e arquivos texto. Além disso, em ambientes analíticos é comum ocorrerem consultas ad hoc para as quais não se pode planejar a manutenção de índices e que acabam resultando muitas vezes na necessidade de full scans nas tabelas para executar a consulta.

O exemplo concreto que o Eduardo Sato usou na palestra pra explicar os ganhos que podem ser obtidos envolvia uma tabela com 10 milhões de linhas de 800 bytes cada uma. Considerando uma representação em disco usando páginas de 16KB, pra fazer um full scan nesta tabela seriam necessários 500 mil I/Os. Se esse full scan tivesse sido motivado por um select envolvendo apenas três colunas da tabela, usando uma representação em colunas poderia reduzir o número de I/Os para apenas 234. (Não é 234 mil. É 234 unidades!)

Além do ganho de eficiência nos selects, a representação em colunas também consegue ser mais compacta que a representação em linhas. Uma razão é que os campos NULL podem ser indicados pela mera ausência, ao passo que na representação em linhas eles precisam ser indicados por um código explícito. Outra razão é que é muito mais fácil compactar dados de um tipo único que dados de múltiplos tipos, como ocorre na representação em linhas.

Ainda outra vantagem da representação em colunas é que as alterações de esquema são muito mais fáceis e rápidas. Afinal é muito mais fácil inserir, remover ou alterar uma coluna quando ela está armazenada de forma contígua que quando seus dados estão “espalhados” pelas linhas da tabela.

O Sybase IQ não é a única implementação desta tecnologia. A página da wikipedia mostra uma lista de implementações concorrentes. Achei duas promissoras: o MonetDB e o Vertica.