O propósito do Rails é tornar mais fácil desenvolver, instalar e mantes aplicativos Web, utilizam a arquitetura MVC, alé disso, quando se cria um projeto Rails, ele automaticamente cria todo o “esqueleto”, relacionei essa estrutura, quando utilizamos um framework tipo Code Igniter pro PHP, após “deszipar” o arquivo do Code Igniter, surge toda uma estrutura, a única diferença é que no Rails essa estrutura é criada em tempo real. O Rails cria automaticamente programas temporários de testes “stubs”para as novas funcionalidades que vão sendo adicionadas.

Rails utiliza também alguns outros conceitos: DRY – Don’t Repeat Yourself – Não se Repita – que emprega que todo conhecimento de um sistema deve ser escrito em um único determinado local, ORM – Object-Relational Mapping, que utiliza as tabelas do banco de dados para definir os models, não há a necessidade de escrever um model, eles automaticamente são mapeados para as classes, suas linhas para objetos e suas colunas para atributos, portanto quando modificamos um banco automaticamente isso é refletido para a aplicação, Convention over configuration – essa convenção diz basicamente que deve-se assumir valores padrão onde existe uma convenção.

Uma coisa que achei bem interessante são os migrations, todas as modificações no banco de dados são documentadas pelo Rails, na verdade as modificações são escritas no Rails e ele mesmo as executa no banco de dados, há um controle sobre as modificações no banco, podendo ser aplicadas em outro banco com por exemplo a deploy da aplicação ou até mesmo desfazer uma modificação.
Suporte integrado ao AJAX e RESTful.

Tudo isso e muito mais é resultado da combinação de 5 componentes:

• Active Record – mapeamento objeto-relacional (Model do MVC);
• Action Pack – compreende o Action-view e o Action-Controller (Visão e Controller do MVC);
• Action Mailer – suporte a envio de recebimento de e-mails;
• Active Support – coleção de classes e extensões;
• Action Webservices – implementa WSDL e SOAP;

O discurso dos evangelistas do Rails me lembra muito os designers da Apple, a história do “Estado da Arte”, que é a busca constante pela simplicidade, praticidade, design, perfeição, facilidade. Até onde estão os meus estudos o Rails está suprindo muito bem essas espectativas, é claro que como qualquer outra linguagem de programação é possível escrever um código sujo, mas garanto que ela facilita muito as boas práticas, ela dá suporte a diversos gems que automatizam determinados processos e diversos plugins que expandem as funcionalidades da sua aplicação sem muito esforço.

Caso esteja interessado em iniciar seus estudo também segue algumas dicas:

Livro: Desenvolvimento Web Ágil com Rails – Link Saraiva – foi o livro que comprei.

Podcast: Podcast Ruby on Rails Brasil com Fábio Akita e Carlos Eduardo Brando – só não espere escutar somente coisas sobre Rails, os caras são sinistros, os assuntos vão de Cloud Computing a Compiladores, de Jruby a Rails! Muuuito bom mesmo (Open Your Mind). Estou fazendo uma sessão Rails Podcast Brasil, escutando todos desde o início.

Blogs em pt-BR: http://akitaonrails.com do Fábio Akita e http://www.nomedojogo.com Carlos Brando – estão sendo as minhas referências de Ruby on Rails.

Bom sobre Rails hoje é só, vou postar mais coisas com o desenrolar dos estudos.

Com relação ao Streaming, estamos finalizando outra etapa do projeto, estou preparando um Screencast junto com o pessoal que está participando do projeto comigo.

Abraços e fico devendo um post sobre o evento da empresa, que aconteceu em setembro, falando de Streaming.

O que é um banco de dados?
Como saber identificar um banco de dados?
Não tem a mínima idéia? Então esse post é pra você.

Entendemos como banco de dados, um conjunto de dados organizados, é planejado e construído para um propósito específico possuindo assim um conjunto de usuários e aplicativos pré-definidos, tem como base de seu projeto o mundo real, onde é chamado de mini-mundo, qualquer modificação nas características do mini-mundo refletem diretamente no banco de dados.
O banco de dados é mantido por aplicativos desenvolvidos especialmente para esse fim, são chamados de SGBD – Sistema Gerenciador de Banco de Dados ou em inglês DBMS – Database Management System, sua função é possibilitar aos usuários criar, consultar, editar e excluir dados do banco de dados, para as mais diversas aplicações. Alguns dos SGBD`s mais conhecidos são:

Comerciais
Oracle: http://www.oracle.com
DB2: http://www-306.ibm.com/software/data/db2/
Sybase: http://www.sybase.com.br/
MS SQL Server: http://www.microsoft.com/sql/default.mspx

Open Source
MySQL: http://www.mysql.com
Postgre SQL: http://www.postgresql.org
Firebird: http://www.firebirdsql.org/

Banco de dados vs. Gerenciador de arquivos (SGBD`s vs. GA`s)
Algumas características são necessárias para que um sistema de manipulação de dados seja considerado um SGBD. Caso alguma das características abaixo não for um atributo do sistema de manipulação de dados avaliado, o mesmo não pode ser classificado como um SGBD, resumindo, para ser um SGBD o software deve necessáriamente ter as características abaixo, caso não tenha ele pode ser classificado como um gerenciador de arquivos.

• Auto-contenção: um SGBD armazena mais que os dados em sí (dados do mini-mundo) como também toda a descrição dos dados, seus relacionamentos, e formas de acesso. Esta regra é conhecida como Dicionário de Dados.
• Independência dos dados: nenhuma definição dos dados poderá estar contida na aplicação que utiliza o SGBD para armazenar os dados. Portanto modificações na forma de acesso aos dados, novos indices não podem afetar a aplicação.
• Abstração dos dados: um SGBD fornece ao usuário apenas uma representação conceitual dos dados, normalmente é utilizado um Modelo de Dados para fornecer essa abstração, sendo assim um SGBD não fornece informações sobre a criação dos indices, ou como serão mantidos, ou qual relação entre as tabelas que deverá ser mantida íntegra.
• Visões: um SGBD deve permitir que cada usuário visualize os dados de uma forma diferente daquela existente fisicamente no banco de dados.
• Transações: um SGBD deve gerenciar completamente a integridade referencial dos dados definida em seu esquema, sem precisar em nenhum momento da ajuda do aplicativo para executar essa tarefa. Sendo assim um SGBD deve possuir pelo menos uma instrução que permita a execução de instruções simultâneas (execuções de vários comandos, um em seguida do outro) e um único comando que desfaça todas essas execuções, em outras palavas, ou executa todos os comandos ou não executa nenhum.
• Acesso automático: um SGBD deve gerenciar o acesso aos dados com o intúito de evitar DEADLOCKS sem a necessidade de auxílio da aplicação. Um exemplo de DEADLOCK é, um usuário A está esperando a liberação de um registro que está sendo acessado por um usuário B e usiário B espera a liberação de um registro que está sendo acessado pelo usário A, esse bloqueio mútuo é chamado de “abraço mortal” pois o usuário A e o B não vão conseguir acessar os registros.

Abraços….. até a próxima…

Fábio Tomio