Recentemente o Renato Carvalho teve problema com seu MBPro, após fechar a tela e hibernar a máquina simplesmente não acordava.

Depois que eu comprei um Might Mouse sem fio comecei a enfrentar o mesmo problema.

Encontrei a pouco em um forum a possível solução: Desabilite a opção: “Allow Bluetooth devices to wake up this computer” nas configurações avançadas do Bluetooth.

Aparentemente agora está tudo funcionando.

Guia expresso para instalação de um ambiente de produção RoR/Apache/Passenger no Ubuntu

sudo apt-get install rubygems
 
sudo gem install rails
 
sudo apt-get install ruby
 
sudo apt-get install ruby rdoc irb libyaml-ruby libzlib-ruby ri libopenssl-ruby
 
wget http://rubyforge.rubyuser.de/rubygems/rubygems-1.3.1.tgz
 
tar xzvf rubygems-1.3.1.tgz 
 
sudo ln -s /usr/bin/gem1.8 /usr/bin/gem
 
sudo mv /usr/bin/gem /usr/bin/gem-old
 
sudo gem update --system
 
sudo gem install rails
 
sudo apt-get install build-essential ruby1.8-dev
 
sudo gem install mongrel
 
sudo gem install capistrano
 
sudo apt-get install mysql-client mysql-admin mysql-query-browser libmysqlclient15-dev
 
sudo apt-get install sqlite3 swig libsqlite3-ruby libsqlite3-dev
 
sudo gem install sqlite3-ruby
 
echo "export RUBYOPT=rubygems" >> ~/.profile
 
sudo apt-get install build-essential apache2-mpm-prefork apache2-prefork-dev libapr1-dev
 
sudo gem install passenger
 
sudo passenger-install-apache2-module
 

O BlipBadge foi escolhido pelo Mergulhão e pela HostNet para ter um ano de hospedagem grátis!

Obrigado pela confiança e vamos que vamos dar uma melhorada no Badge e colocá-lo na casa nova!

Obrigado Mergulhão!

Obrigado HostNet!

Segue o link do resultado: resultado-da-promo-o-de-natal-da-hostnet

My Wordle.net delicious:

First:

Second:

Em um time de projetos utilizando a metodologia Scrum, seria um pouco “estranho” perguntar:

Qual o papel de XX departamento em um time de Scrum?

Afinal, em um time de Scrum o princípio é de que o time seja multidisciplinar, qual seria a dúvida por tanto?

Bom, talvez em empresas focadas em desenvolvimento de software ou em empresas de menor porte isso seja uma realidade, onde todos do time tenha suas preferências técnicas e sejam melhores em determinadas áreas que em outras, mas no final das contas todos fazem de tudo um pouco, desde html até codificação de EJBs no backend.

Em empresas cujo a herança seja o tradicional departamento/áreas, como: Qualidade (QA), Administração de Banco de Dados (DBA), Layout, Design, Usabilidade, etc….. fica praticamente impossível de se quebrar este paradigma, que na verdade está muito mais atrelado a vaidade dos departamentos (vaidade não no termo pejorativo, afinal, precisamos de especialistas) do que em quebra de paradigma propriamente dito, especialmente se a empresa for de médio a grande porte, afinal a primeira preocupação de quem não acredita/gosta de desenvolvimento ágil seria de medo, pois o status quo está sendo ameaçado. Claro!

Este post foi originado após uma conversa com um grande amigo meu, Fábio Brandão na noite do dia 01/01/2009, (pois é, viciado que é viciado só melhora após a terceira ou quarta linha de código compilado ) a respeito de alguns problemas com papéis/departamentos X Scrum, vou tratar neste post, um detalhe mais específico a respeito do Papel de QA (Qualidade) em um time de Scrum e as idéias que me perturbam a respeito.

Qualidade em Casa (QA em time de QA)

Fique claro que quando digo: papel de QA estou me referindo ao contexto que disse logo acima, onde existe um departamento de Qualidade e que o time de desenvolvedores não necessariamente faz o trabalho de QA.

Eu sempre trabalhei em empresas onde existia um time de qualidade verificando o sistema de forma manual ou automática, navegando pelo sistema, algumas vezes com uma planilha com os pontos de atenção, estes são os pontos que não poderia haver nenhuma fala, chamado risco 0 (risco zero), outra planilha com as novas features implementadas que não precisavam ter necessariamente risco 0, e uma terceira planilha com as issues, onde seria devidamente registrados os erros encontrados.

Após o programador (algumas vezes eu) sinalizar no sistema ou face-2-face que o desenvolvimento estava concluído, entrava em campo o pessoal da qualidade, agora lendo o documento que utilizei para desenvolver o sistema, retestando o sistema, testando as novas funcionalidades e apontando os erros, enquanto o programador (…..eu) já estava em um novo caso de uso, esse cara algumas vezes nem se lembrava mais do código do caso de uso passado, estava com foco total no novo caso de uso.

Passado algum tempo, o produto estava todo codificado e com vários bugs, logo, hora de corrigir os bugs.

Aqueles programadores que mal se lembravam o que haviam jantado na noite passada (provavelmente pizza, pois ficou até tarde na empresa, gerando mais algumas linhas de código sem testes) deveriam começar a corrigir os erros que eles mesmos causaram, que foram levantados pelo pessoal de QA. Agora com um documento mais “enxuto” que continham os erros encontrados.

Após a maratona de correções, com alguma sorte, o pessoal de Qualidade não encontrariam os mesmos erros quando executassem os testes novamente.

Qualidade em time de Scrum?

Acho que em um time de scrum a abordagem de QA em time de QA é totalmente fora de propósito, afinal a equipe de qualidade estaria fazendo apenas o papel de apurador de erros, seria realmente este o propósito de um time de qualidade? Encontrar erros?

Pensando em uma abordagem um pouco mais prática, ágil e proporcional aos excelentes técnicos que trabalham com qualidade, a tarefa devesse ser a de garantir a qualidade de produto como um todo, assim como um programador está apto a desenvolver: frontend, backend, testes unitários, integrados, modelagem de tabelas em objetos, QA deveria minimizar os problemas relacionados ao sistema como um todo, por exemplo: erros visuais, problemas técnicos relacionados a código não performático, erros de escrita em banco de dados, arquitetura, e também negócio.

O trabalho estaria terminado, se fossem encontrados erros nestas esferas.

Mas então o trabalho de QA seria apenas de encontrar erros no sistema? Seria aquele primo chato que sempre aparece quando menos se deseja?

O programador receberia com alegria a notícia de que seu código está errado? Ou que o código recém entregue não está performático?

Eu não acredito nisso, definitivamente eu acredito que esta já é uma evolução do “QA em time de QA”, mas acredito que esteja longe de ser uma boa abordagem.

Qualidade!

Como descrito acima, QA deveria ser um supertime, com:

• Arquitetos da informação, para assegurar de que os textos estão colocados corretamente;
• Webdesigners e Webmasters, para assegurar que o layout esteja de acordo como foi desenhado e implementado por eles e requisitado pelo Product Owner.
• Arquitetos de sistema, para assegurar que a aplicação esteja performática e que todas as regras corporativa para acesso a legados estejam sendo cumpridas.
• Programadores: para assegurar que o código está bem feito, com cobertura de X% de testes unitários, funcionais
• Analistas de negócio: para assegurar que o que foi pedido pelo Product Owner esteja de acordo com o que está sendo codificado.
• Administradores de Dados: assegurando que o modelo desenhado esteja coerente com os padrões da empresa e esteja normalizado
• Administradores de Banco de Dados

Com este super time de qualidade, acho que ficaria difícil justificar financeiramente este time.

Mas se o problema é dinheiro(falta de), o que fazer então?

Eliminar a qualidade do time?

De forma alguma!

Acredito cegamente que se o time, TODOS do time estiverem motivados, balizados com o que deve e o que não deve ser feito especialmente nas áreas em que não são especialistas o time deve servir de seus próprios QA’s.

Em um ambiente propício, onde existe motivação isso acontece de forma natural, onde um programador dá palpite no código do outro programador, o administrador de dados está disposto a alterar o modelo de dados para melhorar o desenvolvimento, o webdesigner trabalha de forma parceira com o programador para definir o que será retornado no JSON da chamada Ajax, o analista de negócio está ao lado do desenvolvimento alertando para os erros cometidos (ainda em tempo de desenvolvimento)

Em um ambiente como este será que é valido se quer o questionamento sobre o papel de QA em um time de Scrum?

Acho que não, pois todos estão AGINDO de forma a assegurar a qualidade técnica e não técnica da solução que está sendo implementada.

Talvez a pergunta correta desde o início desde post devesse ser:

Como motivar um time?

Isto será uma conversa para outro post, mas acho que resposta de forma bem curta seria…………….. Paixão!

PS: Utilizei o time de QA apenas para exemplificar, fica a critério do leitor substituir QA, por AD, DBA, Business, ou qualquer outro time que achar interessante.

Recentemente publiquei um post com screencast a respeito de autenticação com restful_authentication, o Kadu Adu me questionou como fazer autenticação utilizando uma terceira chave como validação, por exemplo:

• Username
• Password
• Filial

Andei dando uma fuçada no código do restful_authentication e encontrei como fazer isso de uma forma bem simples, talvez não a mais correta (?!?!?!) mas consegui resolver o problema do nosso amigo Kadu Adu, segue as alterações logo abaixo.

1 - Arquivo: /app/view/sessions/new.html.erb

<%= flash[:notice] %>
<% form_tag session_path do -%>
<label for="login">Login</label>
<%= text_field_tag 'login' %>
 
<label for="password">Password</label>
<%= password_field_tag 'password' %>
 
<!-- Uncomment this if you want this functionality
<label for="remember_me">Remember me:</label>
<%= check_box_tag 'remember_me' %>
-->
 
<!-- autenticacao com terceira chave.... -->
<label for="filial">Filial</label>
<%= text_field_tag 'filial' %>
<%= submit_tag 'Log in' %>
 
<% end -%>
<%= link_to "Criar usuario",  { :controller => "users", :action => "new" } %>
 -<%= link_to "Login",  { :controller => "sessions", :action => "new" } %>
 -<%= link_to "Sair", { :controller => "sessions", :action => "logout" } %>

2 - Arquivo: app/controller/sessions_controller.rb

# This controller handles the login/logout function of the site.  
class SessionsController < ApplicationController
 
  # render new.rhtml
  def new
    #alterado....................
    flash[:notice] = "Usuario logado!" if logged_in?
    flash[:notice] = "Usuario NÃO logado!" unless logged_in?
 
  end
 
  def create
 
    #autenticacao com terceira chave......
    self.current_user = User.authenticate(params[:login], params[:password], params[:filial])
    # self.current_user = User.authenticate(params[:login], params[:password])    
 
    if logged_in?
      if params[:remember_me] == "1"
        current_user.remember_me unless current_user.remember_token?
        cookies[:auth_token] = { :value => self.current_user.remember_token , :expires => self.current_user.remember_token_expires_at }
      end
      redirect_back_or_default('/')
      flash[:notice] = "Logged in successfully"
    else
      render :action => 'new'
    end
  end
 
  def logout
    self.current_user.forget_me if logged_in?
    cookies.delete :auth_token
    reset_session
    flash[:notice] = "You have been logged out."
    redirect_back_or_default('/')
  end
end

3 - Arquivo: app/model/user.rb

Coloque este método antes da definição do último método que é protected

  #autenticacao com terceira chave.....
  def self.authenticate(login, password, filial)
    u = find_by_login_and_filial(login, filial) # need to get the salt
    u && u.authenticated?(password) ? u : nil
  end

4 - Arquivo: db/migrate/01_create_user.rb

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table "users", :force => true do |t|
      t.column :login,                     :string
      t.column :email,                     :string
      t.column :crypted_password,          :string, :limit => 40
      t.column :salt,                      :string, :limit => 40
      t.column :created_at,                :datetime
      t.column :updated_at,                :datetime
      t.column :remember_token,            :string
      t.column :remember_token_expires_at, :datetime
 
      #alteracao para terceira chave....
      t.column :filial,                    :string
    end
  end
 
  def self.down
    drop_table "users"
  end
end

Altere o seu banco de dados via rake ou alter table para que a nova coluna filial seja criada e após as alterações com a aplicação no ar, voce poderá verificar que se passado apenas um usuário e senha válidos sem que a filial seja correta o sistema não autenticará o usuário.

Fiz este código bem rápido, pode ser que esta não seja a melhor solução, se alguém tiver uma melhor saída, fell free to contribute!

Enjoy!

restful_authentication - Screencast (pt-br) from Marcio Garcia on Vimeo.

Instalação do restful_authentication

URL do plugin:

http://svn.techno-weenie.net/projects/plugins/restful_authentication/

./scrpt/plugin source http://svn.techno-weenie.net/projects/plugins/restful_authentication/
 
./script/plugin install restful_authentication

Criação dos controllers e model padrão

./script/generate authenticated user sessions

Alterações de código

routes.rb

#novas rotas....
map.signup '/', :controller => 'sessions', :action => 'new'
map.signup '/signup', :controller => 'users', :action => 'new'
map.login  '/login',  :controller => 'sessions', :action => 'new'
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

app/views/layouts/application.html.erb

<html>
<head>
  <meta http-equiv="content-type" content="text/html;charset=UTF-8" />
  <%= stylesheet_link_tag 'scaffold' %>
</head>
<body bgcolor="#1471B7">
<center>
<p>&nbsp;</p>
<table width="90%"  bgcolor="#FFFFFF">
	<tr>
		<td align="center">
		<%= yield%>			
		</td>
	</tr>
</table>
</center>
</body>
</html>

app/controllers/application.rb

include AuthenticatedSystem

app/controllers/sessions_controller.rb

def new
  #alterado....................
  flash[:notice] = "Usuario logado!" if logged_in?
  flash[:notice] = "Usuario NÃO logado!" unless logged_in?
end

app/controllers/users_controller.rb

#alterado......................
before_filter :authentication
def authentication
  redirect_back_or_default('/') unless logged_in?
end

Código fonte

rademo.zip

No último dia 28 ministrei uma palestra para os alunos da UNIARARAS no II Encontro de Profissionais de TI foi muito legal mostrar para o pessoal um pouquinho de como trabalhamos com JEE e Scrum lá no UOL.

Para todos que se interessarem, a apresentação se encontra publicada no Slideshare e aqui no blog, fiquem a vontade de baixá-lo e replicá-lo!

Today I’m creating my first open source project, actually it’s not my first, but this is the first that I’m opening in GitHub.

After following the GitHub instructions:

$ mkdir stage
$ cd stage
$ git init
$ touch README
$ git add README
$ git commit -m 'first commit'
$ git remote add origin git@github.com:mangar/breshop.git
$ git push origin master

and some instructions about to create the ssh credentials:

[~]$ cd .ssh
[~/.ssh]$ ls
config        id_rsa.pub
id_rsa        known_hosts

and

[~/.ssh]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/tom/.ssh/id_rsa): <enter>
Enter passphrase (empty for no passphrase): <enter>
Enter same passphrase again: <enter>
Your identification has been saved in /Users/tom/.ssh/id_rsa.
Your public key has been saved in /Users/tom/.ssh/id_rsa.pub.
The key fingerprint is:
50:43:77:c6:97:af:61:82:dc:ea:9b:6b:67:d4:1b:61 tom@volcano</enter></enter></enter>

I have got a mysterious: “Permission denied” message on the git push origin master command:

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: failed to push to 'git@github.com:mangar/breshop.git'

So, the way that I found to solve that was, after all the git commands and ssh-keygen done, was:

1. Get the fingerprint generated by ssh-keygen command by doing: cat mangar.pub | pbcopy (mangar was the name that I put into the first question of the ssh-keygen command)
2. Open on the browser: github > account, click on “add another public key” link and paste the contend copied by the pbcopy on the textbox.
3. Save it
4. Back to the command line into .ssh dir type: ssh-add
   
5. Finish! now you are ready to push your very first README file into GitHub!

É isso mesmo, eu não gosto de problemas, assim como eu não gosto de debugar aplicação, assim como eu nao gosto de ser acordado de madrugada porque o sistema parou de rodar o faturamento da empresa, assim como eu não gosto de ficar finais de semana corrigindo problema no sistema porque na segunda feira o pessoal da contabilidade tem que rodar o faturamento!

Não sou daqueles que acorda pela manhã e pensa:

Uau! qual será o problema do dia? Problemas de rede? Problemas com banco de dados? Problemas com a JVM?, hum……. bom mesmo se ocorresse todos eles de uma só vez!

Me lembro de algumas entrevistas, em que meus entrevistadores diziam:

Temos um ambiente desafiador, excelente para pessoas pró-ativas, determinadas a resolver os problemas, auto-motivadas…..

Bom, com o passar do tempo agente vai aprendendo ficando mais maduro quanto as promessas e passamos a interpretar algumas frases como a dita anteriormente como algo do tipo:

Temos vários sistemas cujo o pessoal que desenvolveu não está mais na empresa, os sistemas foram pouco testados por motivo de prazo e temos o caos na terra, precisamos de gente que tenha motivação suficiente para continuar levando o sistema até o fatídico dia em que já tenha ocorrido a depreciação por completo do sistema, e quem sabe se você ainda estiver na empresa quando isso acontecer, quem sabe, você possa utilizar tudo que aprendeu na manutenção deste sistema em um novo projeto.

Não sei para a maioria, mas pelo menos para mim, esta segunda frase soa menos amigável, mas muito mais sincera que a primeira.

Outra forma de “motivar” as pessoas nestas empresas são:

Fique tranquilo, com a quantidade de problemas que temos no sistema, temos emprego garantido para pelo menos 3 anos!

Acredito eu que algumas pessoas lendo este post já possa ter passado por uma situação dessas.

A triste notícia para os que não sao OP (orientados a problemas) é que pessoas que lideram os times OP tendem a investir tempo de menos em testes unitários, funcionais ou integrados e tempo demais em resolução de problemas quando o aplicativo já estiver em produção.

Dificilmente será possível se antecipar a problemas de produção, mas algumas dezenas deles já pode ser antevisto e em tempo de desenvolvimento da aplicação e mais, além de antevisto, podemos testar o comportamento da aplicação quando ( e se ) este problema ocorrer.

O recado aqui é simples:

Teste, Teste, Teste, Teste, Teste, Teste

Não se canse de testar, não se canse de criar cenários de teste para os de integração e aceitação, faça dos testes parte do desenvolvimento, algum tempo será consumido no desenvolvimento de teste, sim isto é verdade no entanto algo que é facilmente mensurável, é quanto de tempo será economizado em debugs, quanto será economizado na redução dos problemas em produção que podem acarretar em um prejuízo financeiro para empresa se isto ocorrer?

Motivação (Mais) para Testes

Faça dos testes unitários um exercício para o desenvolvimento, em um próximo post eu vou detalhar melhor os testes unitários, mas por hora, algo muito válido para ter uma boa motivação a respeito de testes unitários é que UT (unit tests) é tão interessante para o sistema quanto para você mesmo (desenvolvedor), com eles é possível modelar a estratégia de desenvolvimento da classe, serve como um exercício de barreiras para saber exatamente o escopo de onde a funcionalidade chega e onde é sua fronteira, mantendo o desenvolvimento KISS.

Faça com que a criação de testes faça parte do desenvolvimento, me lembro da frase do treinamento que tive de Scrum:

Done means…..

complete a frase com algo do tipo:

• …. não ser incomodado nos finais de semana
• …. não ter que acordar (ou não durmir) nas madrugadas para resolver problemas de sistemas

E a maneira mais simples de completar a frase é:

Teste! Teste! Teste! Teste! Teste! Teste!

English Version:

I don’t like problems! (EN)

It’s truth, I don’t like problems, I don’t like to debug application, I don’t like to wake up early (2AM or 3AM) because the billing application stops to process records. Like I don’t like to stay during all weekend solving problem becaus next mondey guys from billing will send invoice.

I’m not like that people who wake up morning and think:

Wow, what will be big problem today? Infrastructure? Database? Memory and JVM?….. that’s will be great if all those things happen together!

I remember som interviews, when the interviewers said:

We have a very motivated environment, excellent for who likes to solve problems and self-motivated….

Well, passing time we learn about this kind of “promisse”, it it automatic transformed to something like:

We have a system that the guy who created it are no longer on the company, the application was not well tested because we had a small time to develop and now we have a chaos on the earth. We need people who are self-motivated to continu to solve the problems on the application until the day that the company will says: The application is self-payed, we will invest on a new one. And maybe on this day, will could, use all your knowledge earned from mistakes on the application to develop the new one.

It is more sincere than the first phrase don’t you think?

Another way to “motivate”people is:

Stay calm, with all these bugs in the application, we have job for at least 3 years more!

The bad news for who are not PO (problem oriented) is that people who leader teams PO have tendency to inves less time on unit tests, functional tests and integrated tests and too much time in silving the problems (not the cause) when the application already be on production environment.

It’s not simple to foresee problems on production environment but, dozens of them we can foresee during development and more than that, we can test the behavior of the application if it happens in production env!

The message is simple:

Test, Test, Test, Test, Test, Test.

Don’t be tired to test, don’t be tired to create scenarios test for integration and acceptance. Some time will be consumed during development, yes this is truth but this is easy to calculate the cost, just to don’t let the application die during day, when it couldn’t stop.

Motivation (More) for Tests.

Make the creation of the unit test and exercise for development, use it for determinate the scope of the class, the development scope fof that functionality. Use it to discover if the functionality will not broken if you are the one who are changing some lines of code, and even if the functionality is following the KISS method.

I remember a training that I had with Boris Gloger about Scrum, and he said:

Done means….

complete the phrase with some like:

• …. don’t be bothered on the weekends
• …. don’t wake up dawn (or even don’t sleep) to solve problems on the application

And the best way to get it is:

Test! Test! Test! Test! Test! Test!