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.

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!)