
Essencialmente todos, ao desenvolver a primeira aplicação distribuída, assumem os 8 itens seguintes como verdade. Todos se provam falsos ao longo do tempo, e estes erros causam problemas graves e aprendizados dolorosos.
Para mais detalhes, leiam o artigo escrito por Arnon Rotem-Gal-Oz.
James Gosling em um link fala o seguinte sobre a origem desta lista:
A verdadeira origem desta lista é um pouco mítica, sendo amplamente baseada na experiência coletiva de muitos hackers nos primórdios da construção de sistemas distribuídos. Peter Deutch foi o primeiro agrupar os itens em uma lista. Ele diz o seguinte em sua página:
Eu publiquei as “8 falácias da programação em rede” internamente enquanto trabalhava para “Sun Microsystem Labs” em 1991-92. (As primeiras 4 foram originalmente listadas por Bill ou Dick Lyon; Eu adicionei as outras 4.)
Achei que vali a tradução já que muita gente comete os mesmos erros até hoje
Tags: distribuida, programação, rede, tradução

Procurei um pouco no forum.xda-developers.com e encontrei uma ROM com windows mobile 6.5 para o meu HTC Artemis, instalei a Original Microsoft Edition (sim, eu sei que não foi uma atualização oficial feita pela MS, até por que eles não liberam atualizações, apenas o fabricante do celular pode fazer isto).
Bom, o que eu tenho a dizer é que o WM 6.5 esta realmente muito melhor que o 6.0 (que eu tinha antes no celular).
A tela inicial (Chamada de Titanium se não me engano) ficou bem legal. Poderia ser mais costumizável, mas ficou legal, e com certeza é criativa e foge bastante dos dois padrões existentes atualmente (estilo iPhone com botões e estilo Android/HTC
com muitas informações, widgets e páginas).
O menu “Honey Comb” ficou espetacular, é impossível abrir a aplicação errada com este formato de menu, só não gostei do tempo que se leva para organizar manualmente as aplicações, mas pelo menos agora é possível, o que antes não era …
O Windows Marketplace é um completo fiasco, não tem nada la, deve ter no máximo umas 40 aplicações …
O Internet Explorer parece bem mais rápido, e o esquema de zoom e navegação em tela cheia desta nova versão ficou beem legal …
O Media Player Mobile também melhorou, mas não foi nada que realmente chame atenção.
O PIM melhorou bastante, mas não tem nenhum recurso novo excepcional, ja que na minha opinião o anterior não tinha nada faltando (Isto inclui os aplicativos de contatos e calendário).
Não sei se é um problema com a ROM que instalei ou com o WM 6.5, mas na configuração de o que cada botão vai fazer eu posso configurar ações para os botões 1, 2, 3, 5, 6, 6(Hold), é isto ai, ta faltando o botão 4 na lista. Mas isto não chega a ser grave.
Uma das coisas que mais gostei, é que agora o SO todo é “finger friendly”, provavelmente por causa da onda de iPhones e Androids e de todo o esforço dos fabricantes para melhorar a interface do WM. Se bem que não tem disculpa para o 6.0 não ser assim, já que já existia o iPhone quando lançaram o WM 6.0 …
No geral, a performance do PDA/celular melhorou muito com esta nova ROM, não sei o que exatamente causou isto, se foi a versão nova do windows mobile, se é a quantidade de memória livre, mas agora estou bem mais feliz com o meu smartphone
PS.: se algum usuário de windows mobile estiver com medo de atualizar a ROM, é só seguir os passo a passo encontrados no forum.xda-developers.com que fica tudo tranqüilo, tem até instruções de como fazer backup da ROM original para uma possível restauração em caso de problemas ![]()
Se quiserem um passo a passo em português aqui no blog é só pedir nos comentários …
Tags: pim, ppc, Review, windows mobile, wm 6.5
Ok, o titulo do post não ficou legal, mas a idéia é que tem tanto encurtador de URLs por ai que eu resolvi fazer um em rails também para brincar um pouco, e como a implementação ficou muito simples, vou tentar transformar isto em um tutorial bem básico de Rails.
Mas vejam bem, a idéia é só mostrar o básico, não vou colocar mais um no ar, já tem um excelente feito pelo nosso amigo Manoel Lemos, o zapt.in onde ele esta adicionando recursos muito legais. Só peguei a idéia por que achei que se tornaria um tutorial mais divertido do que o famoso blog em rails
Primeiro, você vai precisar do Rails instalado, e para ter o Rails instalado você vai precisar do interpretador Ruby instalado, tem diversos posts sobre isto por ai, mas basicamente numa maquina windows, sugiro instalar o “Instant Rails”, num linux instale o Ruby e depois o Ruby Gems e logo depois execute o comando “gem install rails”.
Deste ponto em diante vou considerar que você já tem o rails instalado e funcionando.
Agora com o Rails instalado, vamos começar a desenvolver a aplicação, vou chamar de “us” para “URL Shortener”, como qualquer projeto rails, vamos começar digitando:
1 2 | rails us
cd us |
Uma aplicação rails tem inicialmente a seguinte estrutura de diretórios:
Não vou explicar para que serve cada um deles, mas os mais importantes para este mini tutorial são:
A nossa aplicação vai ser composta de dois controladores, um model e algumas views.
O ideal seria começar escrevendo testes, mas como este é um post estilo “introdução ao rails” vou deixar os testes de lado.
A primeira coisa que vamos fazer é criar um cadastro básico de URLs, para isto vamos utilizar o gerador do rails, com o seguinte comando:
1 | ruby script/generate scaffold url_info href:string clicks:integer |
Este comando vai gerar uma série de arquivos, vamso dar uma olhada em alguns deles:
1 2 | class UrlInfo < ActiveRecord::Base end |
Este é o conteúdo do arquivo app/models/url_info.rb, toda a implementação do nosso model para um cadastro simples e, por enquanto, sem validações.
E já podemos inclusive criar o banco de dados padrão da aplicação, o rails veio configurado por padrão para utilizar o banco de dados sqlite3, mas isto pode ser facilmente alterado, mas por enquanto vamos aceitar esta configuração e executar o comando:
1 | rake db:migrate |
Isto vai executar as migrations da aplicação, uma migration foi criada no último comando, vamos dar uma olhada rápida nela:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | class CreateUrlInfos < ActiveRecord::Migration def self.up create_table :url_infos do |t| t.string :href t.integer :clicks t.timestamps end end def self.down drop_table :url_infos end end |
Esta migration possui o código para criar uma tabela de nome “url_infos”, com um campo de nome “href” de tipo “string” e um campo “clicks” de tipo “integer”, o mapeamento do tipo ruby para o tipo SQL vai depender do banco de dados, do driver que o rails utilizar para acessar o banco.
Em uma migration é importatne sempre implementar os dois métodos, o self.up cria coisas no banco de dados, e o self.down apaga coisas do banco de dados, tudo o que for criado no self.up tem que ser apagado no self.down, desta forma permitindo que voltemos a qualquer versão da aplicação para corrigir algum bug se necessário.
No exemplo estamos utilizando os métodos create_table e drop_table da migration, mais informações sobre estes métodos podem ser obtidas nesta página da documentação do Rails.
A configuração de qual banco a aplicação esta acessando fica no arquivo config/database.yml que podemos ver abaixo com o conteúdo padrão:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | # SQLite version 3.x # gem install sqlite3-ruby (not necessary on OS X Leopard) development: adapter: sqlite3 database: db/development.sqlite3 pool: 5 timeout: 5000 # Warning: The database defined as "test" will be erased and # re-generated from your development database when you run "rake". # Do not set this db to the same as development or production. test: adapter: sqlite3 database: db/test.sqlite3 pool: 5 timeout: 5000 production: adapter: sqlite3 database: db/production.sqlite3 pool: 5 timeout: 5000 |
Este arquivo tem 3 sessões, correspondentes aos ambientes de desenvolvimento, testes e produção, ou seja, já podemos deixar estes 3 bancos de dados configurados, o que pode facilitar bastante a vida, ou complicar as vezes
Mas a idéia básica é que em cada ambiente é possível configurar qual o driver do banco de dados “adapter”, e os parâmetros deste driver, neste caso apenas o nome do banco é o suficiente, não vou entrar em maiores detalhes aqui por que não é a idéia deste post, quero fazer o encurtador de URLs funcionar antes de você dormir ou cansar de ler …
Então vamos lá, o rails criou um cadastro completo, que se você digitar o seguinte comando para inicializar o servidor, já pode acessar:
1 | ruby script/server |
Agora abra o seu browser preferido e acesse o endereço: http://localhost:3000/url_infos
Você vai ver uma listagem de informações de URLs, e quantos clicks cada URL já recebeu, você já pode até cadastrar algumas URLs ai, não vamos mexer muito neste controlador que foi criado, vamos alterar só um pouquinho, não faz sentido na hora do cadastro de uma URL ser necessário informar o número de clicks, então vamos abrir o arquivo app/views/url_infos/edit.html.erb e deixe ele como o que esta abaixo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | <h1>Editing url_info</h1>
<% form_for(@url_info) do |f| %>
<%= f.error_messages %>
<p>
<%= f.label :href %><br />
<%= f.text_field :href %>
</p>
<p>
<%= f.submit 'Update' %>
</p>
<% end %>
<%= link_to 'Show', @url_info %> |
<%= link_to 'Back', url_infos_path %> |
(Dica, eu removi o parágrafo que continha o campo “clicks”)
Nesta página podemos ver alguns dos helpers do rails para a geração de formulários HTML, e para tratamento de mensagens, a idéia do helper “form_for” é que a variável passada como argumento para o bloco representa um formulário para “aquele elemento”, isto torna possível utilizar os outros helpers “formulário.text_field”.
O Rails tem diversos helpers, tanto para formulários, para options, para AJAX e diversos outros.
Agora vamos duplicar a mudança no outro formulário no arquivo app/views/url_infos/new.html.erb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | <h1>New url_info</h1>
<% form_for(@url_info) do |f| %>
<%= f.error_messages %>
<p>
<%= f.label :href %><br />
<%= f.text_field :href %>
</p>
<p>
<%= f.submit 'Create' %>
</p>
<% end %>
<%= link_to 'Back', url_infos_path %> |
Claro que estes dois arquivos são bem parecidos, e que poderíamos juntar todo o código repetido dos dois, mas vamos deixar isto para depois, por enquanto isto não nos interessa muito.
Agora vamos editar o controlador no arquivo app/controllers/url_infos_controller.rb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 | class UrlInfosController < ApplicationController # GET /url_infos # GET /url_infos.xml def index @url_infos = UrlInfo.all respond_to do |format| format.html # index.html.erb format.xml { render :xml => @url_infos } end end # GET /url_infos/1 # GET /url_infos/1.xml def show @url_info = UrlInfo.find(params[:id]) respond_to do |format| format.html # show.html.erb format.xml { render :xml => @url_info } end end # GET /url_infos/new # GET /url_infos/new.xml def new @url_info = UrlInfo.new respond_to do |format| format.html # new.html.erb format.xml { render :xml => @url_info } end end # GET /url_infos/1/edit def edit @url_info = UrlInfo.find(params[:id]) end # POST /url_infos # POST /url_infos.xml def create @url_info = UrlInfo.new(params[:url_info]) @url_info.clicks = 0 respond_to do |format| if @url_info.save flash[:notice] = 'UrlInfo was successfully created.' format.html { redirect_to(@url_info) } format.xml { render :xml => @url_info, :status => :created, :location => @url_info } else format.html { render :action => "new" } format.xml { render :xml => @url_info.errors, :status => :unprocessable_entity } end end end # PUT /url_infos/1 # PUT /url_infos/1.xml def update @url_info = UrlInfo.find(params[:id]) respond_to do |format| if @url_info.update_attributes(params[:url_info]) flash[:notice] = 'UrlInfo was successfully updated.' format.html { redirect_to(@url_info) } format.xml { head :ok } else format.html { render :action => "edit" } format.xml { render :xml => @url_info.errors, :status => :unprocessable_entity } end end end # DELETE /url_infos/1 # DELETE /url_infos/1.xml def destroy @url_info = UrlInfo.find(params[:id]) @url_info.destroy respond_to do |format| format.html { redirect_to(url_infos_url) } format.xml { head :ok } end end end |
A única alteração do código gerado foi a adição da linha “@url_info.clicks = 0″ no método create, que informa aquele parâmetro que removemos do formulário.
Neste arquivo podemos também ver alguns métodos interessantes do rails, veja na lista abaixo a explicação de alguns deles:
Acho que por enquanto já esta bom de alterações no cadastro, vamos fazer o encurtador de URLs funcionar.
Para isto vamos criar mais um controlador, execute no console o seguinte comando:
1 | ruby script/generate controller redirector index |
Como o nome diz, este é o controlador que vai fazer os redirecionamentos, depois deste comando executado, o arquivo app/controllers/redirector_controller.rb foi criado, vamos editar este arquivo para que ele fique mais ou menos assim:
1 2 3 4 5 6 7 | class RedirectorController < ApplicationController def index ui = UrlInfo.find params[:id] redirect_to ui.href if ui end end |
Isto já faz o redirecionador funcionar, mas não exatamente da maneira que gostaríamos
Por enquanto para ele funcionar precisamos acessar http://localhost:3000/redirector?id=… a idéia é que funcione acessando http://localhost:3000/[id]
Quando o id for passado o redirecionamento deve ocorrer automagicamente, quando não for passado devemos ver a lista de links conhecidos com quantos clicks cada um já teve.
Para que isto funcione vamos editar o arquivo config/routes.rb como no exemplo abaixo (vou apagar todos os comentários para facilitar a leitura do arquivo, comentários em Ruby são as linhas começadas por “#”).
1 2 3 4 5 | ActionController::Routing::Routes.draw do |map| map.resources :url_infos map.connect ':id', :controller => 'redirector', :action => 'index' end |
A linha map.resources :url_infos foi gerada automaticamente com o scaffold, ela configura todas as rotas para o cadastro de URLs.
Esta linha configura as seguitnes rotas na aplicação:
| Nome | Método HTTP | Caminho | Mapeamento |
|---|---|---|---|
| url_infos | GET | /url_infos(.:format) | {:action=>”index”, :controller=>”url_infos”} |
| POST | /url_infos(.:format) | {:action=>”create”, :controller=>”url_infos”} | |
| new_url_info | GET | /url_infos/new(.:format) | {:action=>”new”, :controller=>”url_infos”} |
| edit_url_info | GET | /url_infos/:id/edit(.:format) | {:action=>”edit”, :controller=>”url_infos”} |
| url_info | GET | /url_infos/:id(.:format) | {:action=>”show”, :controller=>”url_infos”} |
| PUT | /url_infos/:id(.:format) | {:action=>”update”, :controller=>”url_infos”} | |
| DELETE | /url_infos/:id(.:format) | {:action=>”destroy”, :controller=>”url_infos”} |
A segunda linha configura a aplicação para quando receber apenas um parâmetro passar isto para o controlador de nome “redirector” para a action “index”, agora se acessarmos o endereço http://localhost:3000/1 a aplicação vai nos redirecionar para a primeira URL cadastrada, mas ainda não esta legal, precisamos contar os clicks tabém.
Para contar o clicks vamos alterar o redirector controller que editamos antes, o código dele vai ficar assim:
1 2 3 4 5 6 7 8 9 10 | class RedirectorController < ApplicationController def index ui = UrlInfo.find params[:id] if ui ui.clicks += 1 ui.save redirect_to ui.href end end end |
Agora antes de redirecionar a quantidade de clicks é incrementada e a informação é salva no banco de dados.
Agora vamos mudar a página inicial para a listagem de URLs, temos duas formas de fazer isto, forma chinelona:
Editar o arquivo public/index.html e configurar um meta refresh, o conteúdo fica como abaixo (HTML padrão).
1 2 3 4 5 6 7 8 9 10 11 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="refresh" content="0;url=url_infos" />
<title>Mega URL Shortener Sample</title>
</head>
<body>
<a href="url_infos">Link List</a>
</body>
</html> |
Ou apagar o arquivo public/index.html, e editar novamente o arquivo config/routes.rb, verifique abaixo o conteúdo alterado.
1 2 3 4 5 | ActionController::Routing::Routes.draw do |map| map.resources :url_infos map.root :controller => 'url_infos' map.connect ':id', :controller => 'redirector', :action => 'index' end |
Foi adicionada a linha “map.root :controller => ‘url_infos’” que informa qual a ação padrão da aplicação.
E com isto já temos o encurtador de URLs quase pronto, faltam alguns detalhes, primeiro no arquivo app/views/redirector/index.html.erb vamos adicionar uma mensagem dizendo que a URL não esta cadastrada.
1 | <b>A URL informada não esta cadastrada no sistema</b> |
Isto vai funcionar por que o controlador “redirector” só chama o redirect se a “UrlInfo” for encontrada, caso contrário ele executa a ação default, que é renderizar a “view” correspondente ao método.
Agora vamos apagar alguns arquivos no diretório app/views/url_infos/, siga a lista:
Vamos editar o arquivo index.html.erb no mesmo diretório:
1 2 3 4 5 6 7 | <h1>Shortened URLs</h1> <div id="form"> <%= render :partial => 'editor_form' %> </div> <div id="table"> <%= render :partial => 'urls_table' %> </div> |
Todo o conteúdo deste arquivo foi movido para dois partials, partials são uma forma de reutilizar código de views no rails, mas neste caso estaremos utilizando partials para implementar um pouco de AJAX.
A idéia é que o formulário do topo da página seja submetido via ajax e que atualize apenas o pedaço da página que for necessário, veja abaixo como ficaram os dois partials:
_editor_form.html.erb
1 2 3 4 5 6 7 8 | <% form_remote_for(@url_info) do |f| %>
<%= f.error_messages %>
<p>
<%= f.label :href, 'URL:' %>
<%= f.text_field :href %>
<%= f.submit 'Create' %>
</p>
<% end %> |
Neste formulário estamos utilizando o helper “form_for_remote” que cria um formulário que sera submetido via AJAX, não fazendo refresh da página toda de uma só vez.
_urls_table.html.erb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | <table width="100%">
<tr>
<th>Original URL</th>
<th>Shortened URL</th>
<th>Clicks</th>
</tr>
<% @url_infos.each do |url_info| %>
<tr>
<td><%=h url_info.href %></td>
<td><%=h url_for(:controller => 'redirector', :id => url_info.id, :only_path => false) %></td>
<td><%=h url_info.clicks %></td>
<td><%= link_to 'Go To', :controller => 'redirector', :id => url_info.id %></td>
<td><%= link_to 'Destroy', url_info, :confirm => 'Are you sure?', :method => :delete %></td>
</tr>
<% end %>
</table> |
A tabela não sofreu alterações grandes, apenas foi colocado mais um campo para mostrar qual a URL no sistema correspondente a uma URL cadastrada, e para que isto ficasse dinâmico, o helper “url_for” for utilizado, com o parâmetro “:only_path” setado para false, desta forma a URL completa seria impressa.
Para que este formulário via AJAX funcione, algumas alterações precisaram ser feitas no controlados “url_infos”, como pode ser visto abaixo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 | class UrlInfosController < ApplicationController # GET /url_infos # GET /url_infos.xml def index @url_infos = UrlInfo.all @url_info = UrlInfo.new respond_to do |format| format.html # index.html.erb format.xml { render :xml => @url_infos } end end # POST /url_infos # POST /url_infos.xml def create @url_info = UrlInfo.new(params[:url_info]) @url_info.href = params[:href] if params[:href] @url_info.clicks = 0 respond_to do |format| if @url_info.save format.html do flash[:notice] = 'UrlInfo was successfully created.' redirect_to root_url end format.xml { render :xml => @url_info, :status => :created, :location => @url_info } format.js do @url_infos = UrlInfo.all @url_info = UrlInfo.new render :update do |page| page.replace_html 'form', :partial => 'editor_form' page.replace_html 'table', :partial => 'urls_table' page.alert 'UrlInfo was successfully created.' end end else format.html { render :action => "index" } format.xml { render :xml => @url_info.errors, :status => :unprocessable_entity } format.js do render :update do |page| page.alert @url_info.errors.full_messages.join '\n' end end end end end # DELETE /url_infos/1 # DELETE /url_infos/1.xml def destroy @url_info = UrlInfo.find(params[:id]) @url_info.destroy respond_to do |format| format.html { redirect_to(url_infos_url) } format.xml { head :ok } end end end |
Alguns métodos foram removidos, e o metodo create sofreu algumas alterações dentro do bloco “respond_to” adicionando suporte a respostas tipo “javascript”. E tem mais um detalhe no mesmo método, a segunda linha foi adicionada para quebrar todo o suporte “REST” do rails, como este é um encurtador de URLs eu quero que seja possível adicionar uma URL via uma chamada a uma URL do sistema, neste caso vai ser “/add/
1 2 3 4 5 6 7 | ActionController::Routing::Routes.draw do |map| map.resources :url_infos map.root :controller => 'url_infos' map.connect '/add/:href', :controller => 'url_infos', :action => 'create', :href => /http[s]{0,1}:\/\/.*/ map.connect ':id', :controller => 'redirector', :action => 'index' end |
A alteração feita foi a adição da linha “map.connect ‘/add/…”, preste atenção na utilização de uma expressão regular na especificação do parâmetro “href” no final da linha, isto permite que a URL completa seja utilizada como parâmetro, se isto não for utilizado o parâmetro vai terminar na primeira “/” da URL e o roteamento não vai funcionar corretamente.
Agora para que o AJAX funcione vamos alterar o layout gerado quando executamos o primeiro comando “script/generate scaffold …”, naquele momento foi gerado também o arquivo app/views/layouts/url_infos.html.erb.
Como este arquivo de layout tem o nome de um controlador, ele é utilizado apenas por este controlador, se o nome do arquivo fosse “application.html.erb” ele seria utilizado por todos os controladores da aplicação que não tivesse um layout próprio.
O conteúdo do arquivo é semelhante a qualquer outra view, uma coisa interessante de se reparar no nome do arquivo é que ele contem o “mime type” no nome, então se quisermos criar um “layout” para respostas XML vale a mesma lógica (application.xml.erb).
Vamos ver o conteúdo deste layout:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="content-type" content="text/html;charset=UTF-8" />
<title>UrlInfos: <%= controller.action_name %></title>
<%= stylesheet_link_tag 'scaffold' %>
<%= javascript_include_tag :defaults %>
</head>
<body>
<p style="color: green"><%= flash[:notice] %></p>
<%= yield %>
</body>
</html> |
Foi adicionada a linha “<%= javascript_include_tag :defaults %>” que adiciona na página gerada a chamada para o javascript padrão do rails (que utiliza por padrão a biblioteca prototype).
O conteúdo das views é renderizado no lugar em que se encontra “<%= yield %>” neste arquivo de layout.
A última alteração que falta é impedir que sejam cadastradas URLs duplicadas ou em branco, para isto vamos voltar ao arquivo do model app/models/utl_info.rb
1 2 3 4 | class UrlInfo < ActiveRecord::Base validates_uniqueness_of :href validates_presence_of :href end |
O suporte a validações do rails é bem flexível, e possui helpers para diversas validações, neste caso estamos garantindo que a URL seja única e esteja preenchida.
Bom, acho que era isto, temos um encurtador de URLs bem simples pronto. Esepro que o exemplo tenha sido útil para mostrar alguns dos recursos do Rails fugindo um pouco do exemplo padrão do blog.
Siga os links para a documentação do Rails, e lembre-se de programar sempre com o site da API do rails aberto em um browser.
PS.: o código completo para este exemplo esta disponível no github.
Tags: 101, rails, Ruby, tutorial, url shortener
A alguns dias atrás eu li este twitt do Martin Fowler: “you don’t want a build tool which automatically downloads unresolved dependencies before cleaning out yr build output: http://bit.ly/59Rl85“, li todo o post e ele fala de forma bastante prolixa de alguns dos motivos que me fazem não gostar do Maven.
Não me levem a mal, eu já tentei utilizar ele algumas vezes, mas eu não consigo gostar de uma ferramenta que acha que sabe mais do meu projeto do que eu mesmo (ou o cliente, ou os desenvolvedores, …).
Ou pior que isto, uma ferramenta que tem a infeliz mania de tentar fazer um backup da internet antes de cada build só para verificar se tem a última versão das dependências disponível …
Como é citado no post, não acho que alguma ferramenta vá saber exatamente o que é necessário para qualquer projeto, até por que cada projeto é um projeto, e cada projeto tem suas peculiaridades, e eu simplesmente desisti todas as vezes que precisei configurar alguma destas peculiaridades no maven e voltei para o ANT.
O ANT é uma ferramenta bastante flexível, e pelo que eu tenho visto no mercado, fora alguns teimosos que preferem usar o maven mesmo passando muito mais trabalho do que o necessário, o ANT é o “defacto standard” para builds em Java, mas algumas vezes a “linguagem de script” do ANT dificulta as coisas quando se precisa realmente de um script para fazer alguma coisa durante o build, então resolvi usar Ruby para escrever os builds, ou seja, utilizar uma linguagem de scripts de verdade.
Ai pensei, como é que vou fazer para compilar meu projeto java utilizando o Rake? A linguagem de script é muito fodastica, é Ruby, eu me sinto bem programando em Ruby, mas e como compilar?
Fui perguntar ao oraculo e descobri o BuildR e o Raven que fora o fato de não utilizarem XML e sim Ruby, conseguem repetir todos os erros do Maven, eles parecem “ports do Maven para o Rake” e eu não sei por que alguem iria fazer isto, se você gosta tanto assim do Maven, use ele mesmo …
Mas do Rake eu gosto, me acostumei com ele trabalhando com o Rails, é muito fácil de automatizar tarefas relacionadas a um projeto utilizando o Rake, e não apenas o “build”, mas algumas tarefas que as vezes precisam ser automatizadas, como um merge freqüente com algum sub projeto desenvolvido em outra parte do mundo …
Isto me criou apenas um problema, como compilar, empacotar, …
Ou seja, me faziam falta as tasks básicas do ANT que eu utilizo sempre. As outras tarefas são melhor executadas na minha opinião pelo próprio Rake ou até mesmo por um script em Ruby, mas estas tarefas básicas iriam fazer falta, e para resolver isto eu criei uma classe wrapper para os comandos do JDK, que pode ser estendida depois, não é algo 100% rake, mas eu achei que ficou legal assim, se alguem não concordar e tiver idéias para melhorar estou aceitando sugestões
O wraper para os comandos do JDK ficou assim:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 | class JavaUtil RAW_COMMANDS = %w{appletviewer apt extcheck idlj jar jarsigner java javac javadoc javah javap javaw javaws jconsole jdb jhat jinfo jmap jps jrunscript jstack jstat jstatd jvisualvm keytool kinit klist ktab native2ascii orbd pack200 packager policytool rmic rmid rmiregistry schemagen serialver servertool tnameserv unpack200 wsgen wsimport xjc} def initialize(jdk_home=nil) @commands = {} @jdk_home = jdk_home || ENV['java_home'] @default_for_command = {} @global_default = {} init_commands end def method_missing(met,*args) if RAW_COMMANDS.include? met.to_s execute_command met, *args else super.method_missing met, *args end end def respond_to?(met) RAW_COMMANDS.include?(met.to_s) || super.respond_to?(met) end def default_parameter(param,value) @global_default[param] = value end def default_parameter_for(met,param,value) params = @default_for_command[met] || {} params[param] = value @default_for_command[met] = params end private def init_commands @jdk_bin = File.join @jdk_home , "bin" RAW_COMMANDS.each do |cmd| @commands[cmd.to_sym] = File.join @jdk_bin, cmd end end def update_or_concat_with_defaults(opts,defaults) defaults.each do |key,value| param = opts[key] if !param param = value else if param.is_a? Array param << value param.flatten! end end opts[key] = param end end def execute_command(cmd, *args) actual_command = @commands[cmd.to_sym] if args opts = {} opts.update args.pop if args.last.is_a? Hash update_or_concat_with_defaults opts, @global_default update_or_concat_with_defaults opts, @default_for_command[cmd.to_sym] if @default_for_command[cmd.to_sym] opts.each do |key, value| param = value param = param.join File::PATH_SEPARATOR if param.is_a? Array actual_command << " -" << key.to_s << " " << param end actual_command = "#{actual_command} #{args.join ' '} " end puts actual_command res = %x{#{actual_command}} puts res [$?,res] end end |
A minha idéia dos parâmetros default globais tem um pequeno problema, alguns comandos não recebem os mesmos parâmetros, mas é possível setar parâmetros padrão por comando, o que ficou legal, e deixou a compilação mais limpa …
A classe pode ser utilizada com qualquer JDK, inclusive instâncias diferentes podem utilizar JDKs diferentes para o mesmo build, basta passar o “JAVA_HOME” no construtor, por padrão a variável de ambiente é utilizada …
Mas beleza, como é que eu utilizo esta tranqueira em um Rakefile agora? bom, o meu Rakefile para o projeto de exemplo ficou assim:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 | require 'lib/java_util' @java_util = JavaUtil.new task :default => :test SRC_FILES = FileList.new 'src/**/*.java' TST_FILES = FileList.new 'test/**/*.java' CLASSPATH = FileList.new "#{File.join(ENV['TOMCAT_DIR'], 'lib').gsub /\\/,'/'}/*.jar" @java_util.default_parameter_for :java, :classpath, CLASSPATH.to_a @java_util.default_parameter_for :javac, :classpath, CLASSPATH.to_a directory 'output/classes' directory 'output/tests' desc "Compile all the java files" task :compile => ['output/classes','output/tests'] do @java_util.javac SRC_FILES, :d => 'output/classes' @java_util.javac TST_FILES, :d => 'output/tests', :classpath => ['output/classes',"#{ENV['JUNIT_DIR']}\\junit-4.4.jar"] end desc "Creates the package after compilation" task :package => :compile do @java_util.jar '-cf output/target.jar -C output/classes .' cp 'output/target.jar', 'WebContent/WEB-INF/lib' @java_util.jar '-cf output/target.war -C WebContent .' end desc "Runs the tests after packaging" task :test => :package do test_classes = FileList.new 'output/tests/**/*.class' test_classes.gsub! /output\/tests\/(.*)\.class/,'\1' test_classes.gsub! /\//, '.' @java_util.java "org.junit.runner.JUnitCore #{test_classes.join ' '}", :classpath => ['output/tests','output/target.jar',"#{ENV['JUNIT_DIR']}\\junit-4.4.jar"] end desc "Clean up all the mess we created" task :clean do rm_f 'output' rm_t 'WebContent/WEB-INF/lib/target.jar' end |
O código dos testes não precisava ser tão complexo, eu poderia ter criado um wrapper para ele, a mesma coisa para a criação do jar, poderia até mesmo ter utilizado o “rubyzip” para deixar mais bonitinho, mas a idéia por enquanto é ser bem simples.
Estou utilizando este build em um projeto, se engrenar provavelmente a biblioteca vá crescendo, mas acho que por agora já serve para começar a brincar e ver o que vocês acham da idéia.
A classe “JavaUtil” precisa ser mais testável, mas isto tornou ela complexa demais para o exemplo deste post, se eu convencer o resto da equipe a continuar usando esta solução vou melhorando ela aos poucos
Acho que vou separar a montagem do comando e a execução do mesmo, ou transformar cada comando em uma classe para facilitar a expansão da biblioteca e tornar mais testável, ou até mesmo as duas coisas.
No momento a classe não é nada testável, mas já esta divertida e o meu bluid diminuiu muitas linhas depois que eu converti ele de ANT para Rake utilizando esta lib
PS.: quem quiser pegar o projeto de testes para brincar, só para olhar ou até mesmo para implementar algumas melhorias, ele esta publicado no github. Se implementarem alguma melhoria, não esqueçam de enviar um pull request para que eu possa fazer o merge das alterações

Desenvolvimento guiado pelo comportamento da aplicação é o que todos deveriam fazer sempre, de forma bastante resumida é definir com o cliente como a aplicação deve se comportar, escrever um teste automatizado para verificar este comportamento e depois escrever código suficiente para fazer o comportamento da aplicação ficar de acordo com o que o cliente deseja.
A diferença básica do Behaviour Driven Development (de agora em diante simplesmente BDD) para o desenvolvimento orientado por testes, é que o BDD coloca em foco o valor para o negócio que o software vai adicionar. Parece ser uma diferença puramente conceitual mas não é, por exemplo:
A tela inicial deve listar todos os clientes
Não é a mesma coisa que
O método HomeController.index precisa popular a variável @clientes
Claro que não são só estas diferenças, trabalhando mais com BDD percebe-se que ele poupa muito mais trabalho do que o TDD simples (Não que TDD seja simples de se adotar). BDD tem todas as vantagens de TDD e mais algumas, veja as duas listas abaixo:
Test Driven Development:
Behavior Driven Development:
Ou seja, alem de gerar um código com mais qualidade, o BDD poupa trabalho de toda a equipe e o principal, melhora a comunicação, que tanto para quem trabalha com metodologias ágeis quanto para quem não trabalha é extremamente importante e a falta dela é um problema gravíssimo que leva diversos projetos ao fracasso. Na minha opinião, só o fato de melhorar a comunicação já é motivo o suficiente para testar BDD.
Claro que alguns dos benefícios que eu citei dependem do suporte de ferramentas, para ser mais preciso, as User Stories serem o código executável dos testes de aceitação depende de uma ferramenta para ser verdade, e a ferramenta que eu escolhi para isto é o Cucumber, do qual eu vou começar a falar com mais freqüência aqui no blog.
Eu pessoalmente encaro o BDD como uma evolução do TDD, eu sempre tive dificuldades em escrever testes unitários antes do código da aplicação, claro que para bibliotecas é fácil, mas para a interface com o usuário que consome boa parte do código da aplicação é bem complicado escrever testes estilo XUnit, mas quando as user stories se tornaram o código executável dos testes de aceitação da UI (pelo menos os básicos desconsiderando o layout) um novo mundo se abriu para mim e tudo passou a fazer sentido.
para quem não percebeu este sub-titulo é uma brincadeira com a tradução da palavra cucumber que quer dizer pepino
Cucumber é uma ferramenta que torna possível executar histórias em texto puro, ele é uma ferramenta escrita em Ruby que veio para substituir o RSpec Story Runner, e tem diversas vantagens sobre este.
O Cucumber, utiliza Ruby e expressões regulares para definir o que qualquer expressão quer dizer, mas antes de entrar nestes pormenores vamos entender um pouquinho da estrutura básica que o Cucumber define para as User Stories.
Para que seja possível executar uma User Storie utilizando o Cucumber, ela precisa ter uma estrutura básica.
Esta é uma forma de definir a estrutura básica de um arquivo .feature do Cucumber, claro que explicando desta forma estas definições se encaixam em muita coisa, então vamos ser um pouco mais especificos.
O Cucumber define algumas palavras chave para cada uma destas sessões, estas palavras chave podem ser traduzidas para diversas linguas, o primeiro exemplo eu vou colocar em ingês, depois vou mostrar o equivalente em portugues, mais adiante quando entrarmos na parte de configurações do cucumber vamos ver melhor como selecionar a lingua utilizada, e como customizar isto, mas por enquanto fiquemos com as configurações padrão.
Feature: Simple math In order to avoid silly mistakes As a math idiot I want to be told the result of simple math operations Scenario: adition Given I have entered 50 into the calculator And I have entered 70 into the calculator When I press add Then I should see 120 on the screen Scenario: subtraction Given I have entered 60 into the calculator And I have entered 30 into the calculator When I press sub Then I should see 30 on the screen
Este é o exemplo de uma história bem simples que o cucumber pode interpretar, as palavras chave apresentadas são:
Estas mesmas palavras podem ser traduzidas para o portugues como:
Utilizando estas palavras chave, seria possível escrever esta história assim em portugues:
Funcionalidade: Matemática Simples Para evitar erros idiotas Como um completo ignorante em matemática Eu quero que operações simples de matemática sejam resolvidas para mim Cenário: adição Dado que eu digite 50 na calculadora E que eu digite 70 na calculadora Quando eu precionar "Adicione" Então eu devo ver 120 na tela Cenário: subtração Dado que eu digite 60 na calculadora E que eu digite 30 na calculadora Quando eu precionar "Subtraia" Então eu devo ver 30 na tela
O legal é que esta histórinha poderia ser escrita por um usuário, as únicas regras reais são:
A estrutura que utilizei na descrição da funcionalidade não esta descrita em palavras chave por que ela não é interpretada pelo cucumber, é apenas uma descrição e o formato pode variar um pouco.
Mas por que utilizar esta ferramenta para testes em vez de qualquer outra?
Por que utilizar o cucumber como ferramenta de testes vai viabilizar uma abordagem BDD no desenvolvimento do seu sistema, e que isto vai te poupar muito dinheiro.
Acho que era isto, falei um pouco de BDD, um monte de Cucumber e acho que consegui mostrar a idéia geral, mas isto vai ficar um pouco mais claro nos próximos posts sobre o Cucumber.
PS.: parabéns pela paciência se você leu até aqui

Mas atualmente tenho um windows mobile, e sinto bastante falta de algumas coisas simples que eu tinha no Symbian e até mesmo no W300i da SE que não é nem bem um Smart …
Coisas idiotas tipo poder visualizar no meu desktop os meus contatos e mensagens SMS direto no telefone …
Sim eu sei que no WM6 com Exchange server novo as mensagens SMS também são sincronizadas, mas eu não tenho um exchange server e na verdade não tenho nem um Outlook, estou usando o Thunderbird para sincronizar agenda e contatos com o meu celular.
Então resolvi catar na NET uma forma de visualizar os SMSs no computador e poder escrever e enviar SMSs do computador enquanto o celular estivesse conectado (é mais fácil digitar no computador do que no celular
)
E vagando pela net encontrei este excelente freeware, o Mobile Express da Efficasoft.
Ele permite ler e escrever SMSs direto do computador, e ainda de quebra permite a visualização e edição dos contatos direto do celular no computador (mas a edição e listagem de contatos é bem fraquinha, não permite nem ordenação).
Mas só pelo acesso aos SMSs já vale o download, achei o software excelente, deem uma olhadinha na tela dele.

Acho que era isto, fica a dica para quem estiver usando um windows mobile e sentir falta de acessar os SMSs direto do computador
Tags: desktop, windows mobile

Não lembro de nada que não fosse possível fazer, mas várias coisas eram mais difíceis do que eu gostaria que fossem, então como só tenho utilizado o computador de casa para acesso a internet, joguinhos, downloads e ver filmes resolvi voltar para o windows, mesmo reconhecendo que para desenvolvimento o linux é infinitamente superior, com exceção de desenvolvimento para windows mobile, que eu descobri ser possível mas muito difícil.
Até poucos dias eu acreditava que a unica forma de desenvolver para windows mobile no windows era comprando uma licença do Vi$ual $tudio, mas descobri uma forma gratuita, visual e muito fácil de fazer isto ![]()
Segue a lista do que você vai precisar baixar para desenvolver aplicações para windows mobile no seu desktop windows sem gastar nada mais (por que imagino eu que a sua licença do windows seja original como a minha).
Depois que eu instalei esta lista de softwares e abri o Sharp Develop, clicando em “New Solution” abaixo das linguagens C# e VB.NET aparece a opção de criar aplicações para o Compact Framework, como eu já tinha o .NET CF 2.0 aqui, posso desenvolver aplicações para as duas versões do .NET CF para o windows mobile.
Se quiserem ainda é possível baixar emuladores do site da microsoft ou testar direto no celular como eu tenho feito.


Tags: .net, compact framework, Mobile, sharp develop