Poderia passar dias e dias apenas mencionando a longa lista de Heróis que foram pioneiros do mundo da tecnologia moderna e abriram as portas para que pessoas como nós pudéssemos continuar seus trabalhos. Mas, antes de ser uma lista de Heróis, são uma lista de grandes curiosos.
Uma geração de curiosos leva à próxima e a mais recente nos trouxe mais grandes hackers como Linus Torvalds e seu Linux, Guido von Rossum e seu Python e, claro, dentro de nossos próprios interesses, Yukihiro Matsumoto com seu Ruby e David Hansson com seu Ruby on Rails.
Frameworks. Essa é a palavra da moda. Apreciamos Ruby on Rails, um framework que é importante não por ser inovador, não por ser revolucionário, mas por afirmar mais uma vez que o legado dos gigantes do passado continuam ecoando até hoje. MVC, Active Record, Design Patterns, Orientação a Objetos, HTTP, todos os componentes que formam a fundação de Rails.
No meu artigo Um Desabafo falei sobre a fadiga dos programadores, sobre a falta de interesse, sobre a banalização da área. Não sou o único com o privilégio da reclamação, existem milhares espalhados por aí loucos para fazer a diferença, para empurrar mais ainda os limites. Rails também representa a renovação dessa busca, uma volta às raízes necessária para refletir nossa condição.
Frameworks. Apesar das diferentes definições técnicas eu prefiro enxergar um Framework como a expressão de um conjunto. Uma forma de tornar grandes pedaços um único coeso. HTTP e SQL nasceram separados, mas graças ao encanamento de ActiveRecord e ActionPack finalmente encontraram um caminho coeso. Rails é apenas a escultura mais recente neste museu.
Programadores de verdade querem ser artistas. Nossos pincéis são todas essas tecnologias e conceitos. Por que existem tantos frameworks no mercado? Struts, Zend, CakePHP, Symphony, TurboGears, Struts, Velocity, Spring, Guice, Hibernate apenas para citar alguns. Existem muitos de nós que não nos adaptamos a nenhum deles: queremos criar o nosso.
Num mercado voltado apenas a “cadastros e mais cadastros”, parece que estamos fadados à fatigante rotina de especificações funcionais, usuários indecisos, gerentes incompetentes, salários atrasados, projetos fracassados. Qual o sentido de uma carreira na tecnologia apenas para ser mais um puxa saco da corporação? Dentro dessa espiral negativa, muitos de nós – que realmente apreciam a arte – buscam refúgio em frameworks.
É como um amante de mecânica: saber como funciona um pistão, um virabrequim, uma injeção eletrônica até, quem sabe, construir seu próprio carro. É mais emocionante e recompensador do que apenas comprar o carro do ano e ficar esquecendo de trocar o óleo. É a diferença do codificador de cadastro e dos Programadores, com “P” maiúsculo.
O que não precisamos, obviamente, é de mais um framework seduzindo empresas e criando mais e mais hordas de codificadores. Não precisamos criar arrasa-quarteirões. Qual o objetivo de todo esse discurso: incentivar a curiosidade, a arte de ser hacker, de pintar seu próprio quadro.
Dentro de nosso mundo, só enxergamos Rails. Rails isso. Rails aquilo. Claro, é um framework magnífico. Tenho certeza que todos estamos nos divertindo muito com Rails, descobrindo mais e mais coisas novas, diferentes e desafiadoras. O suficiente para atiçar nossa curiosidade. Tenho mais certeza que a melhor parte da diversão está nas mãos de pessoas como David Hansson, Thomas Fuchs, Marcel Molina Jr., Sam Stepherson e outros do Core Team.
E não digo isso simplesmente por causa de seus 15 minutos de fama. Digo isso porque são eles que conhecem cada parafuso, cada rebinboca da parafuseta. Mas eles não são os únicos privilegiados. Vejamos um exemplo: _WhyTheLuckyStiff.
O que faz _Why para suprir sua própria curiosidade? Escreve, codifica, se comunica, pergunta e responde. Ele é famoso por trabalhos como Why’s (Poignant) Guide to Ruby que já é quase uma mitologia no mundo Ruby. Se não for um dos melhores guias da linguagem Ruby provavelmente é um dos mais criativos.
Não vim sugerir um momento literário. Não, vim sugerir que todos tentem – apenas por pura diversão e auto-conhecimento – criar um framework, não importa a linguagem. Para programadores web esta é a melhor maneira de aprender a fundação dos conceitos e tecnologias que simplesmente aprendemos a aceitar. Muitos praticamente acreditam que HTML existe desde a Idade da Pedra. Alguns não imaginam que outrora houve uma época em que computador era praticamente uma ficção científica. Rede mundial de comunicação? Conto de fadas.
Aprofundem-se. _Why nos dá o exemplo: não precisamos todos sentar e começar a escrever um novo Spring, ou um novo Rails. Nada necessariamente grande, nada monumental. Espero que todos tenham, pelo menos, ouvido falar de Camping.
Como o próprio _Why define, Camping é um ‘micro-framework’. É um conjunto mínimo, o suficiente para criar pequenas aplicações Web. Um pequeno Wiki para organizar suas idéias pessoais, uma pequena agenda para compromissos pessoais, um pequeno Blog para um diário pessoal. Nada gigantesco. Camping não é o próximo Rails. Camping não será a próxima ferramenta do mundo empresarial. Camping não veio revolucionar o mundo. Suas pretensões são muito menores e nem por isso menos nobres: uma maneira de aprender.
E quão pequeno é Camping? Míseros 4.1kb . Exatamente isso, não mais do que 4 mil letras formando versos em Ruby, um pequeno trecho de um soneto se comparado a uma Ilíada ou Odisséia que é Rails. Claro, ele também cresceu sobre o ombro de gigantes. Dentre algumas dependências ele se utiliza do mesmo Active Record e Active Support do Rails. Tira proveito de Markaby.
Camping pode ser um primeiro passo ao entendimento de um framework maior como Rails. Assim como o pequeno Minix de Tanenbaum um dia incentivou o Linux de Torvalds.
E para instalar Camping:
gem install camping-omnibus --source http://code.whytheluckystiff.net
Isso deve instalar tudo que você precisa: SQLite3, ActiveRecord, Mongrel, RedCloth e acts_as_versioned. O framework inteiro é apenas um arquivo, camping.rb. E como é uma aplicação Web que rodaria em Camping? Do próprio website de _Why, veja uma aplicação completa e documentada:
#!/usr/local/bin/ruby -rubygems
require 'camping'
Camping.goes :HomePage
module HomePage::Controllers
# A "/" da raíz mostra a view 'index'
class Index < R '/'
def get
render :index
end
end
# Qualquer outro nome de página leva à view
# de mesmo nome.
#
# /index -> Views#index
# /sample -> Views#sample
#
class Page < R '/(\w+)'
def get(page_name)
render page_name
end
end
end
module HomePage::Views
# Se tiver um método 'layout' como esse
# ele vai encapsular o HTML no outro método.
# O `self << yield' é onde o HTML é inserido.
def layout
html do
title { 'Minha HomePage' }
body { self << yield }
end
end
# A view de `index'. Dentro de suas views, você expressa
# o HTML em Ruby. Veja http://code.whytheluckystiff.net/markaby/.
def index
p 'Hi my name is Charles.'
p 'Here are some links:'
ul do
li { a 'Google', :href => 'http://google.com' }
li { a 'Uma página de amostra', :href => '/sample' }
end
end
# A view `sample' ('amostra').
def sample
p 'Uma página de amostra'
end
end
Simples, prático, não muito poderoso mas sem dúvida eficaz e econômico. Já disse no meu blog que alguns estão tentando levar aplicativos Rails para rodar como aplicações de Desktop. Uma maneira de poder usar aplicações offline. Temos iniciativar como RubyScript2Exe e Joyent Slingshot , para citar alguns. Camping pode se encaixar perfeitamente nisso.
Ruby on Rails pode ser excelente para criar aplicações como Basecamp ou mesmo algo mais simples como Ta Da List. Mas em vez de matar uma mosca com um canhão, para controlar uma pequena lista pessoal de To-Do (tarefas a fazer), talvez Camping seja mais adequado.
Mas mais do que criar aplicações sobre Camping. Por que não aprender o próprio Camping? Para ser pequeno, o código de camping.rb não é exatamente legível (_Why tirou todos os espaços em branco, tabulações e quebras de linha para economizar ainda mais espaço). Qualquer programador iniciante deve ser capaz de entender como ele funciona em poucas horas. E daí poderá ter idéias de como fazer o próprio. Ninguém começa desmontando a injeção eletrônica de um carro, talvez seja mais sensato começar trocando seu primeiro pneu.
Desmontar rádios, desmontar televisões, desmontar ferros de passar. Era o hobby dos hackers da era pré-informática. Thomas Edison, Benjamin Franklin. Todos precisamos ser curiosos, todos precisamos querer – e não apenas fazer porque eu ou alguém está dizendo – descobrir, aprender, refletir e, quem sabe, ter a próxima grande idéia? Ser o próximo Herói desta lista de curiosos célebres?
Todos os diretos reservados a RubyOnBr. Copyright RubyOnBr .
This site is powered by Radiant CMS.