O SQLite 3 é um SGBD(Sistema de Gerenciamento de Bancos de Dados) open source incrivelmente leve, e que funciona sem nenhuma configuração. Além disso, ele não possui um processo servidor, existindo assim apenas um processo responsável por ler e escrever os dados, sendo estas operações feitas diretamente no sistema de arquivos local.

Por se tratar de um SGBD sem um processo servidor, o SQLite 3 é auto contido, podendo assim ser distribuído junto com as aplicações. Na verdade, devido a sua natureza, este é um cenário de uso ideal para ele, principalmente quando a aplicação em questão não requer um SGBD mais robusto.

Instalação

A versão mais atual do SQLite 3 é a 3.5.4, sendo que a sua instalação depende do sistema operacional utilizado. Tendo isto em vista, abaixo estão as instruções para instalação nos 3 sistemas operacionais mais usados:

Windows: baixe o programa em linha de comando que acessa e modifica os bancos de dados no SQLite 3, justamente com a DLL da biblioteca do SGBD. Feito isso, descompacte os dois arquivos baixados, obtendo assim os arquivos sqlite3.exe e sqlite3.dll. Por fim, coloque estes dois arquivos no diretório bin da sua instalação do Ruby, sendo este diretório provavelmente estará localizado em C:\ruby\bin.

Linux: existem várias formas de se instalar programas no Linux, dependendo de várias fatores como distribuição utilizada. Sendo assim, irei considerar aqui apenas distribuições baseadas no Debian, como o Ubuntu. Essas distribuições possuem o gerenciador de pacotes apt-get, o que significa que basta executar o comando sudo apt-get

Mac OS X: o SQLite 3 já vem integrado ao Mac OS X desde a versão 10.4(Tiger), portanto, a menos que você esteja em uma versão anterior, não é preciso fazer absolutamente nada para ter ele instalado no seu ambiente. Mas, caso você esteja em uma versão anterior do Mac OS X, basta usar o DarwinPort, digitando o comando sudo port install sqlite3 em uma janela de comando. Dessa forma, o Daw

Instalando o gem

Embora tenhamos instalado o SQLite 3, ainda não podemos utilizá-lo em aplicações Rails, uma vez que ainda falta o adapter necessário para a conexão. Sendo assim, temos que baixá-lo através do RubyGems, o que é feito digitando o comando gem install sqlite3-ruby em uma janela de comando.

Houve um tempo em que simplesmente não haviam opções quanto a manipulação do banco de dados, tinhamos necessariamente que incluir código SQL manualmente dentro do código das aplicações. Mas, felizmente, com o passar do tempo, surgiram soluções alternativas, incluindo os famosos frameworks ORM(Object-Relational Mapping), e graças a eles passamos a ter uma excelente opção para esta questão. No entanto, conforme adianta o título deste post, essa é a melhor solução possível?

Eu sempre acreditei que sim, e em parte ainda acredito. Inserir instruções SQL dentro de uma aplicação torna, ao meu ver, o código pouco elegante como um todo, uma vez que o SQL por si só não é exatamente uma linguagem bonita. Sendo assim, acabamos tendo parte do código com um nível de abstração satisfatório e a outra parte… bem, a outra parte é SQL. E mesmo se isolarmos o código SQL apropriadamente, o que, convenhamos, é o mínimo que temos a fazer, ainda assim fica feio.

Além do fato do SQL não ser mesmo uma linguagem bonita, a raiz deste problema repousa na mistura do modelo relacional com o paradigma orientado a objetos, supondo que está sendo utilizado estes dois modelos, que são, respectivamente, os mais populares para SGBDs e para linguagens de programação.

A propósito, ao contrário do que muitos pensam, o maior benefício dos frameworks ORM é justamente abstrair o modelo relacional, permitindo assim que nós trabalhemos unicamente com objetos. É um erro comum pensar que eles foram criados primariamente para possibilitar trocas de SGBDs, já que esse tipo de coisa está longe de ser comum.

Mas, apesar do SQL inegavelmente piorar estaticamente o código de um sistema, temos que considerar que estamos falando do melhor dos cenários. Há casos em que simplesmente não é possível usar um framework como Hibernate ou ActiveRecord ou qualquer outra solução que abstraia o modelo relacional, seja por problemas relacionados a performance ou por limitações da estrutura organizacional, dentre outros fatores limitantes.

Um exemplo de um cenário com tal limitação foi apresentado no Rio on Rails. Lá, o Eduardo Rocha, criador do site O Curioso, revelou que devido a problemas que afetavam consideravelmente a performance do site, teve que incluir algumas instruções SQL diretamente, ao invés de usar o excelente suporte oferecido pelo ActiveRecord. Portanto, neste caso, foi preciso abdicar da conveniente e amigável interface oferecida pelo framework ORM, no caso o ActiveRecord, em prol de uma melhor performance no site, uma vez que isso sim afeta diretamente os usuários.

Sendo assim, respondendo a minha própria pergunta, eu acredito sim que quanto menos código SQL uma aplicação tiver, melhor. Melhor para ela e para os desenvolvedores que a manterão. E se essa quantidade signigicar nenhum código SQL, melhor ainda.

Entretanto, no mundo real, como vimos acima, nem sempre isso é possível, e como desenvolvedores de software nós temos que identificar estes cenários que constituem uma exceções. Até porque, no fim das contas, o nosso foco é criar software que resolva problemas, e para isso as vezes temos que criar software feio do ponto de vista do código fonte. Até porque, o problema mais importante a ser resolvido não é o nosso, e sim aquele que originou o desenvolvimento do software em questão.

Após duas versões beta e dois Release Candidates, foi lançada hoje a versão final do Netbeans 6.0.

Para quem não sabe, o Netbeans é uma IDE bastante conhecida no mundo Java, uma vez que ela é desenvolvida nesta linguagem e é mantida pela Sun, mesma empresa que mantém o Java. No entanto, se engana quem acha que o Netbeans suporta apenas desevolvimento Java, uma vez que há um bom tempo a IDE também suporta outras linguagens, como C/C++, por exemplo.

Além disso, de uns tempos pra cá, a Sun passou a investir pesado no Ruby, o que resultou na contratação dos desenvolvedores do JRuby e no fato do Netbeans agora dar suporte ao desenvolvimento Ruby/JRuby.

Como resultado desse investimento no Ruby, o Netbeans é hoje, na minha opinião, uma ótima opção para desenvolvimento Ruby/Rails. E pelo que parece eu não estou sozinho, já que, segundo uma pesquisa realizada com desenvolvedores Ruby/Rails sobre IDE/editor preferido, ele é uma das IDEs mais utilizadas para desenvolvimento Ruby/Rails.

Sendo assim, agora só me resta testar a versão final, e ver se realmente atende as expectativas no que diz respeito ao Ruby. E caso você queira fazer o mesmo, basta baixar o instalador da distribuição do Netbeans 6.0 específica para o Ruby, sendo que ele possui apenas 19,7 MB. Em seguida, prossiga através da sua instalação no melhor estilo next->next->finish e pronto!

A pergunta acima, apesar de ser um pouco provacativa, introduz uma discussão interessante. A maioria dos desenvolvedores, ou aspirantes a desenvolvedores, afirmam categoricamente que dominam o HTML, mas será que isto é mesmo verdade?

Pois bem, é óbvio que alguns poucos realmente o dominam, eu, pelo menos, conheço dois, mas a verdade é que a grande maioria conhece superficialmente esta tão subestimada linguagem. Em geral, ou conhecem um subconjunto relativamente pequeno do HTML, ou então conhecem apenas a sintaxe da linguagem, sem saber exatamente como usá-la, o que ao meu ver é ainda pior do que o primeiro caso.

Contudo, como a maioria dos browsers é muito pouco rígido quanto a corretude do HTML, muitos erros grotescos acabam sendo ignorados, e o browser indulgentemente apresenta a página da melhor forma possível. Como consequência, os desenvolvedores, principalmente os iniciantes, acabam construindo a noção de que conhecem bem o HTML e que ele se trata de uma linguagem fácil, chegando até mesmo a estranhar o fato de alguém estudar o assunto mais profundamente.

Eu afirmo isso sem me excluir, pois, apesar de saber da importância deste tópico, posso, na mais autoindulgente das hipóteses, me considerar apenas mediano no HTML. Digo isso pois conheço uma quantidade razoável dos seus elementos, além de saber o básico sobre o seu uso, como, por exemplo, que ele só deve ser usado para estruturar o conteúdo, e não para definir a apresentação, que é tarefa do CSS.

E por falar em CSS, o que eu disse acima também se aplica a ele e ao XHTML, embora a maioria não se considera tão proficiente nestas duas tecnologias. Isso é claro considerando os que sabem da existência do XHTML.

Entretanto, o objetivo aqui não é de maneira alguma criticar os desenvolvedores que não conhecem profundamente o HTML, até porque eu faço parte desta parcela, além de sequer ser um desenvolvedor ainda. O que eu pretendo aqui é despertar em alguns de vocês a consciência recém-adquirida por mim de que o HTML é mais do que algumas poucas tags jogadas de qualquer maneira em um arquivo .html. Ele merece sim atenção, além de um estudo um pouco mais extenso do que um breve tutorial.

Eu estou fazendo a minha parte, uma vez que estou lendo no momento o Use a Cabeça! HTML com CSS & XHTML. Aliás, este é um livro excelente, e a sua tradução não compromete a compreensão do texto, portanto eu o recomendo.

Sendo assim, vamos conhecer de verdade o HTML, XHTML e CSS. Isto é um bem que fazemos a nós mesmos, pois são estas tecnologias que formam a base da Web, e se quisermos atuar neste ambiente temos a obrigação de conhecê-las. Quem sabe assim nós contribuimos para uma Web menos caótica. Não custa sonhar.