Rodrigo Gomes

Testar uma aplicação web manualmente é uma coisa muita chata e trabalhosa. Por isso é muito comum nas empresas criar rotinas para automatizar esses testes, e com isso ganhar algum tempo e segurança que sua aplicação continua funcionando no decorrer do desenvolvimento.  Existem diversos frameworks para fazer esse serviço, e o Selenium é um deles, e por sinal é bastante usado não somente na comunidade Java.

Por isso resolvi pesquisar um pouco para saber como era o uso do Webdriver (selenium 2) no Python. Achei que deveria ser uma coisa simples de se fazer. E não me enganei.

Existe um python binding para usar o selenium 2, e em sua página tem um passo a passo para começar tudo.

A primeira coisa a fazer é instalar o selenium. Para isso basta digitar o comando abaixo no terminal:

sudo easy_install selenium

Se você não for azarado e tudo correr bem, você verá a mensagem

Finished processing dependencies for selenium

E pronto, selenium poderá ser usado.

Para o teste, criei um unitest do python mesmo para executar uma já manjada busca no google. Nesse exemplo, estou abrindo a página de pesquisa do Google, preenchendo o text field com o termo que quero pesquisar, no caso “selenium” (criativo hein?) e mandando ele clicar no botão de pesquisar. Depois de tudo, confiro se a palavra selenium existe na resposta. Simples assim.

import unittest
from selenium import webdriver

class TesteGoogle(unittest.TestCase):

    def setUp(self):
        self.driver = webdriver.Firefox()

    def tearDown(self):
        self.driver.quit()

    def testSearch(self):
        self.driver.get('http://www.google.com.br')
        text_field_pesquisa = self.driver.find_element_by_name('q')
        text_field_pesquisa.send_keys("selenium 2")
        botao_pesquisa = self.driver.find_element_by_name('btnG')
        botao_pesquisa.click()
        self.assertTrue("selenium" in self.driver.get_page_source())

if __name__ == "__main__":
unittest.main()

Para executar o teste, basta executar o comando:

python teste_google.py

Considerando que você nomeou seu arquivo com esse nome.

E isso é tudo.

Não sei ao certo porque razão ou por influencia de quem (desconfio que tenha sido por causa dessa palesta do Vinicius Teles), mas de uns tempos para cá, tem surgido em minha cabeça algumas idéias empreendedoras.

Mas numa época em que são lançadas dezenas de coisas diariamente, o que fazer para criar um novo produto? De onde tirar a idéia brilhante?

Durante muito tempo, somos levados a acreditar em momentos mágicos de invenção, um eureka daqui, um lampejo brilhante dali, e pronto, temos uma idéia e podemos fazer algo inovador.

Mas quando comecei a ler um pouco sobre o assunto, logo descobri que a realidade não é bem essa (para minha sorte, e de muitos outros). A realidade para quem quer produzir algo é somente uma: trabalho duro.

Não existe milagre. Arquimedes, antes de ter a idéia que gerou o Principio de Arquimedes, passou muito tempo pensando e estudando uma maneira de resolver o problema que o rei Hierão II lhe passou, sendo o seu famoso eureka o resultado final de um longo período de estudo.

Para citar um caso recente, podemos falar do Angry Birds e um ótimo post falando sobre a empresa que o fez. Como podem ver, Rovio faturou alguns milhões recentemente, mas esse sucesso não veio da noite para o dia como muitos pensavam. Eles já estão na estrada há oito anos, e já fizeram vários outros jogos de menor sucesso antes de fazerem a aplicação mais vendida da App Store.

E eles não fizeram nada de excepcionalmente novo, eles combinaram coisas existentes e persistiram no trabalho que vinham realizando.

E esse é o ponto chave para mim no momento, combinar coisas que a principio não combinam e a partir daí sim, fazer algo novo.

Mas isso não é tão simples quanto parece. Por isso sigo minha jornada em busca de coisas para combinar.

rails new curriculum -d mysql

rails generate scaffold Person name:string city:string occupation:string

rake db:migrate

gem "paperclip", "~> 2.3"

class Person < ActiveRecord::Base
    has_attached_file :resume
end

rails generate migration add_resume_file_name_to_person

class AddResumeFileNameToPerson < ActiveRecord::Migration
   def self.up
      add_column :people, :resume_file_name,    :string
   end

   def self.down
      remove_column :people, :resume_file_name
   end
end

<% form_for :person, @person, :url => people_path, :html => { :multipart => true } do |f| %>

<% if @person.errors.any? %>
   <div id="error_explanation">
   <h2><%= pluralize(@person.errors.count, "error") %> prohibited this person from being saved:</h2>

   <ul>
   <% @person.errors.full_messages.each do |msg| %>
      <li><%= msg %></li>
   <% end %>
   </ul>
   </div>
<% end %>

<div>
  <%= f.label :name %><br />
  <%= f.text_field :name %>
</div>
<div>
  <%= f.label :city %><br />
  <%= f.text_field :city %>
</div>
<div>
  <%= f.label : occupation %><br />
  <%= f.text_field : occupation %>
</div>

<div>
  <%= f.label :resume %><br />
  <%= f.file_field :resume %>
</div>

<div>
  <%= f.submit %>
</div>
<% end %>

Depois é subir o server e se tudo ocorreu bem, fazer upload dos seus currículos.

Para mostrar um link na tela de listagem, deixe-a conforme abaixo:

<h1>Listing people</h1>

<table>
  <tr>
    <th>Name</th>
    <th>City</th>
    <th>Occupation</th>
    <th>Resume link</th>
    <th></th>
    <th></th>
    <th></th>
  </tr>

<% @people.each do |person| %>
  <tr>
    <td><%= person.name %></td>
    <td><%= person.city %></td>
    <td><%= person.occupation %></td>
    <td><%= link_to 'View Resume', person.resume.url %></td>
    <td><%= link_to 'Show', person %></td>
    <td><%= link_to 'Edit', edit_person_path(person) %></td>
    <td><%= link_to 'Destroy', person, :confirm => 'Are you sure?', :method => :delete %></td>
  </tr>
<% end %>
</table>

<br />

<%= link_to 'New Person', new_person_path %>

Para saber mais detalhes, como: onde o arquivo é armazenado fisicamente e porque,  quais outras opções de configuração, etc basta acessar a página do projeto do GitHub:

https://github.com/thoughtbot/paperclip

Esses dias precisei migrar um projeto de um servidor para o outro e quebrei um pouco a cabeça com os comandos do SVN para executar o que eu precisava.

Eu tinha uma estrutura assim:

REPO
–/SUBDIR
—-/PROJ1
—-/PROJ2
…

E eu precisava migrar apenas um projeto, no caso o PROJ1 por exemplo. Então, a primeira questão era como gerar o dump somente do meu projeto.

A primeira tentativa foi usar o comando svndumpfilter em conjunto com o svnadmin dump da seguinte maneira:

svnadmin dump /path/to/repo | svndumpfilter include /PROJ1 > repo.dmp

A intenção era que ele gerasse o dump apenas do projeto que estou pedindo. Mas pra minha surpresa ele não fez isso. Mas também não gerou de todo mundo. Na verdade não gerou de ninguém. Só gerou as revisions, sem arquiuvo algum.

Então, descobri que pra fazer o que eu queria, eu precisava passar o diretório parent do projeto que estava exportando

O comando ficou:

svnadmin dump /path/to/repo | svndumpfilter include SUBDIR/PROJ1 > repo.dmp

Aí sim, o dump foi gerado com sucesso. E para importar a lógica é a mesma. Ou seja, tem que existir aquele mesmo diretório “SUBDIR” dentro de seu repositório para que de certo.

Seu novo repositório deve ter uma estrutura como:
NOVO_REPO
—-/SUBDIR

E o comando para fazer o load é:

svnadmin load /path/do/NOVO_REPO <  /path/para/seu/repo.dmp

Depois é só fazer o relocate, e pronto!

Estou lendo novamente algumas partes do                                                                         “Pragmatic Programmer” (se ainda não leu, não perca mais tempo) e logo no começo do livro, ele da essa dica: “Não invente desculpas esfarrapadas, dê opções” (tradução livre). E tenho procurado seguir essa dica no meu dia-a-dia.

A minha estratégia é a seguinte: toda vez que vou fazer algo, ou melhor, toda vez que não vou fazer algo, ou que tenho que explicar algo que não esteja funcionando corretamente eu imagino que tem um pequenino ser em meu ombro. Então, quando faço alguma afirmação ou dou uma desculpa esfarrapada, esse serzinho cochicha “E daí?”, ou “Então o que podemos fazer a respeito?”.

Assim, eu tento me antecipar a questões que irão surgir, e além do mais, realmente contribuir para a solução de um possível problema. Já que é muito fácil falar que algo está errado ou ruim e ficar por isso mesmo.

Nem sempre funciona, nem sempre é possível dar todas as alternativas, mas é um ótimo exercício de criatividade.

Que os celulares estão ficando cada vez mais poderosos ninguém dúvida, ajudando assim, quem quer se aventurar no desenvolvimento para essa plataforma, principalmente smartphones (mais precisamente iOS e Android).

Porém, a um pequeno choque cultural quando se está acostumado a programar para desktop ou web (que é meu caso) e começa a pensar em alguma aplicação para smartphone. Quando vamos desenvolver para esses dispositivos, encontramos várias restrições que normalmente não encontramos no nosso dia-a-dia ‘enterprise’.

Algumas delas são:

• Memória: celulares não são servidores. Não são desktops. A quantidade de memória disponível é bem limitada.
• Acesso a internet: nem todo celular tem acesso a internet o tempo todo, pois isso custa caro aqui no Brasil, além de ser bem limitado. Se tiver pensando de fazer algo que acesse serviços externos, certamente isso será uma preocupação.
• Resolução da tela: a tela dos aparelhos são muito pequenas. Apesar de já serem bem maiores que os celulares mais antigos, ainda são muito pequenas se comparada a resolução dos monitores de desktops ou das telas dos notebooks.

Além disso, nas aplicações empresariais é comum termos aquele amontoado de botões e caixas de texto, um monte de funcionalidades que ninguém vai usar, etc. E é justamente isso a primeira coisa que devemos evitar. Temos que fazer aplicações focadas, com seu objetivo bem definido e nada mais! Nada de firulas, nem de coisas desnecessárias. Ninguém está disposto a baixar uma aplicação de 100MB num celular só pra usar uma pequena funcionalidade.

Objetividade é a palavra.

Ah, e outra coisa: smartphones não são notebooks! (pelo menos ainda!)