27 de set. de 2007

O Diabo está nos detalhes

O trecho do livro Caindo na Real é chocante para alguns (tipo eu)... Vale a pena refletir... Só é um Problema Quando é um Problema Não desperdice tempo com problemas que você ainda não tem Você precisa realmente se preocupar em escalar para 100.000 usuários hoje se vai levar dois anos para chegar lá? Você tem mesmo que contratar oito programadores se hoje você só precisa de três? Você precisa realmente de 12 servidores top-de-linha agora se dá para rodar em dois por um ano? Apenas se vire As pessoas costumam gastar tempo demais logo de cara tentando resolver problemas que elas ainda nem têm. Não faça isso. Poxa, nós lançamos o Basecamp sem a habilidade de cobrar os clientes! Como o produto é cobrado mensalmente, sabíamos que teríamos um intervalo de 30 dias para dar um jeito. Usamos aquele tempo para resolver problemas mais urgentes e então, após o lançamento, enfrentamos a cobrança. Deu certo (e nos forçou a adotar uma solução simples, sem firulas desnecessárias). Não esquente com uma coisa até que você tenha de fato que fazê-lo. Não desenvolva demais. Aumente hardware e software de sistema conforme necessário. Se ficar lento por uma ou duas semanas não será o fim do mundo. Apenas seja honesto: explique para os seus clientes que você está passando por dores de crescimento. Eles podem não ficar empolgados mas apreciarão a franqueza. Resumo da Ópera: Tome decisões só no momento necessário, pois aí você terá acesso à informação real de que precisa. Entrementes você estará em condições de prestar atenção às coisas que requerem cuidado imediato.

Login e Controle de Acesso em Ruby on Rails

Tempos atrás estava procurando algo que facilitasse minha vida com autenticação e controle de acesso em RoR. Passei algum tempo quebrando um galho com a engine do Goldberg. Boa, mas muito gigante para aplicações simples. Cheguei nesse tutorial rápido e espero que ajude, não inventei nada, só reescrevi a roda: 1. Crie uma nova aplicação "rails novosite" 2. "cd novosite" 3. Instale o plugin "gem install login_generator" e em seguida gere os arquivos de autenticação com "ruby script/generate login LoginSystem" onde LoginSystem será o nome do seu controller de autenticação. 4. Crie um migrate para criar a estrutura do controle de acesso "ruby script/generate migration create_acl_schema". 5. Coloque o conteudo abaixo no migrate criado
class CreateAclSchema < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.column :login, :string, :limit=>40, :null=>false
      t.column :name, :string, :limit=>40
      t.column :password, :string, :limit=>40, :null=>false
      t.column :updated_at, :datetime
      t.column :created_at, :datetime
      t.column :access, :datetime
      t.column :nick, :string
    end
    create_table :roles do |t|
      t.column :name, :string, :limit=>40, :null=>false
      t.column :info, :string, :limit=>80
    end
    create_table :permissions do |t|
      t.column :name, :string, :limit=>40, :null=>false
      t.column :info, :string, :limit=>80
    end
    create_table :roles_users do |t|
      t.column :user_id, :integer, :null=>false
      t.column :role_id, :integer, :null=>false
    end
    create_table :permissions_roles do |t|
      t.column :role_id, :integer, :null=>false
      t.column :permission_id, :integer, :null=>false
    end
  end
def self.down
    drop_table :users
    drop_table :roles
    drop_table :permissions
    drop_table :roles_users
    drop_table :permissions_roles
  end
end
6. Crie outro migrate para a entidade que iremos testar "ruby script/generate migration carro" 7. Coloque o conteudo abaixo no migrate criado
class CreateCarros < ActiveRecord::Migration
  def self.up
    create_table :carros do |t|
      t.column :user_id, :integer
      t.column :name, :string
      t.column :age, :integer
      t.column :updated_at, :datetime
      t.column :created_at, :datetime
    end
  end

  def self.down
    drop_table :carros
  end
end
8. Configure o config\database.yml e crie a base recomendada 9. execute "rake migrate" para criar tabelas na base de dados e depois "ruby script\generate scaffold Carro" para criar um CRUD de teste para a entidade Carro. 10. Crie os seguintes arquivos: app/models/permission.rb
class Permission < ActiveRecord::Base
  has_and_belongs_to_many :roles
end
app/models/role.rb
class Role < ActiveRecord::Base
  has_and_belongs_to_many :permissions
  has_and_belongs_to_many :users
end
lib/acl_system.rb
module ACLSystem
  include LoginSystem

  protected

  def authorize?(user)
    required_perm = "%s/%s" % [ params['controller'], params['action'] ]

    if user.authorized? required_perm
      return true
    end

    return false
  end
end
11. Em app/models/user.rb modifique adicionando os seguintes métos e relacionamento:
class User < ActiveRecord::Base
has_and_belongs_to_many :roles

  # Return true/false if User is authorized for resource.
def authorized?(resource)
    match=false
    permission_strings.each do |p|
      r = Regexp.new(p)
      match = match || ((r =~ resource) != nil)
    end
    return match
end


  # Load permission strings 
  def permission_strings
    a = []
    self.roles.each{|r| r.permissions.each{|p| a<< p.name }}
    a
  end
E em app/controllers/application.rb para:
require_dependency "acl_system" 
class ApplicationController < ActionController::Base
include ACLSystem 
model :user
E em app/controllers/carros_controllers.rb para:
class CarrosController < ActiveRecord::Base
before_filter :login_required
Obs: "before_filter :login_required" exige que o usuário esteja logado e tenha permissao de acesso. 12. Inicie o servidor e acesse "localhost:3000/login_system/signup" crie dois usuários de teste 13. Utilize o script para criar as permissões, regras e associar ao usuário:
INSERT INTO roles (id, name, info) VALUES (1, 'admin', 'Admistrador'); 
INSERT INTO roles (id, name, info) VALUES (2, 'normal', 'Usuario Comum'); 
INSERT INTO roles_users (user_id, role_id) VALUES (1, 1); 
INSERT INTO roles_users (user_id, role_id) VALUES (2, 2); 
INSERT INTO permissions(name,info) VALUES('.*/.*', 'Acesso Total'); 
INSERT INTO permissions(name,info) VALUES('carros/index', 'Acesso reduzido'); 
INSERT INTO permissions(name,info) VALUES('carros/list', 'Acesso reduzido'); 
INSERT INTO permissions_roles (permission_id, role_id) VALUES (1, 1); 
INSERT INTO permissions_roles (permission_id, role_id) VALUES (2, 2); 
INSERT INTO permissions_roles (permission_id, role_id) VALUES (3, 2); 
14. Pronto... agora é só testar Acesse "http://localhost:3000/carros/" com o segundo usuário criado e verifique que existe acesso. Mas não é possível criar um novo carro. Para o primeiro usuário criado o acesso é total. Referências: LoginGeneratorACLSystem LoginGenerator

19 de set. de 2007

Prazo, Orçamento e Escopo

Ontem escutei algo sobre “Prazo, Orçamento e Escopo”. Foi falado que devemos sempre monitorar esses três pilares, e que eles giravam/refletiam em torno da qualidade, ou seja, se você descontrola um dos pilares você compromete a qualidade.

Hoje iniciei a leitura de um livro que falava sobre o assunto. Achei a abordagem muito interessante. Então fica ai o trecho:

Fixe o Prazo e o Orçamento, Flexibilize o Escopo

Lance dentro do prazo e do orçamento

Aqui vai uma maneira fácil de lançar dentro do prazo e do orçamento: mantenha-os fixos. Nunca jogue mais tempo ou dinheiro em um problema, apenas diminue o escopo.

Existe um mito que diz o seguinte: podemos lançar no prazo, no orçamento e no escopo. Isso quase nunca acontece e quando acontece a qualidade normalmente sofre.

Se não puder encaixar tudo dentro do prazo e orçamento planejados então não aumente o tempo e o custo. Em vez disso, puxe o escopo para trás. Sempre existe tempo para adicionar coisas mais tarde – o mais tarde é eterno, o agora está voando.

Lançar alguma coisa grande que está um pouco menor em escopo do que o planejado é melhor do que lançar alguma coisa medíocre e cheio de buracos porque precisou atingir uma janela mágica de prazo, orçamento e escopo. Deixe a mágica para Houdini. Você tem um negócio de verdade para administrar e um produto real para entregar.

Aqui vão os benefícios de fixar o prazo e orçamento e manter o escopo flexível: Priorização: Precisaremos descobrir o que é realmente importante. O que vai chegar ao lançamento inicial? Isso força uma restrição que o pressionará a tomar decisões difíceis em vez de ficar hesitando. Realidade: Configurar expectativas é a chave. Se tentar fixar o prazo, orçamento e escopo, não será capaz de entregar com um alto grau de qualidade. Claro, provavelmente poderá entregar alguma coisa, mas “alguma coisa” é o que realmente quer entregar? Flexibilidade: A habilidade de mudar é a chave. Ter tudo fixado torna as mudanças difíceis. Injetar flexibilidade de escopo apresentará opções baseadas em sua experiência real de construir o produto. Flexibilidade é seu amigo.

Nossa recomendação: abaixo o Escopo. É melhor fazer meio-produto do que um produto meia-boca (mais sobre isso depois).

Um, dois, três ...

Como um projeto chega a estar um ano atrasado? Um dia de cada vez.—Fred Brooks, engenheiro de software e cientista da computação

18 de set. de 2007

Processos Ágeis de Desenvolvimento

A contínua busca por melhoria tem levado a equipe onde trabalho a encontrar novos rumos e retirar dos anos já vividos, experiências que nos façam refletir e agir/reagir. Em setembro, participei de uma palestra junto com alguns gerentes da empresa (Ricardo Fonseca e o Leonardo) que falava sobre "Gestão Ágil de Projetos com Scrum" e isso deu um ponto de partida a um diálogo sobre essa crescente tendência na área de desenvolvimento de software. Atualmente estamos com a mão na massa introduzindo alguns passos/técnicas que são pregados por algumas metodologias.

Hoje tivemos o primeiro diálogo aberto para contaminar toda a equipe de desenvolvimento com a visão de técnicas de desenvolvimento ágil. O Bruno Pedroso, da Sea Tecnologia esteve ministrando uma palestra sobre “Metodologias Ágeis e Extreme Programming” que envolveu pessoas de diversos papéis (Analistas de Negócios, Programadores, DBA´s e Gerentes de Projeto) na Search Informática.

Essas são as fotos do encontro e ficam aqui alguns pontos para se manter em mente: Valores: Comunicação, Coragem, Feedback, Respeito, Simplicidade. Práticas Primárias: Ambiente Informativo, Ciclo Semanal, Desenvolvimento Orientado a Testes, Design Incremental, Equipe Integral, Folga, Histórias, Integração Contínua, Programação em Par, Sentar-se Junto, Trabalho Energizado. Endereço do Fórum AgilDF: http://groups.google.com/group/AgilDF?hl=pt-BR

3 de set. de 2007

WebMobile TechWeek 2007

Estive em São Paulo nos dias 31/08 e 01/09 junto com o Luciano Costa, participando do WebMobile TechWeek, um evento organizado pela DevMedia. Os assuntos em que estive presente giravam em torno de JEE e JME. Posto aqui duas coisas que achei de grande interesse:

Primeiro, o mercado para JME está gritando por gente que entre para trabalhar, e pode apostar faturar bastante. O Luciano escreveu alguns números sobre o mercado no blog dele, e quem quiser dá uma olhada é só conferir no http://lucianovc.blogspot.com/. Deu para perceber que ainda há muito problema na compatibilidade entre Sistemas Operacionais que dizem que implementam jsr’s, mas nem sempre estão na sua totalidade. Os emuladores também ainda são outra problemática, ou seja, é comum um desenvolvedor implementar no emulador e não funcionar do dispositivo, ou até mesmo o contrário, e o pior de tudo, funcionar em um dispositivo e no outro nem dá sinal de vida. Ai a tal da compatibilidade passa bem longe.

Conforme foi anunciado pelo representante da Nokia no Brasil a febre lá fora é Localidade! GPS vai ser o arroz do momento, ou seja, ninguém vai querer ficar sem ele no seu prato. Alguns exemplos foram mostrados para termos idéia da dimensão da porta de mercado que está se abrindo para que investir nisso. Participei de alguns "mini-cursos" para tentar aprender alguma coisa sobre o funcionamento da tecnologia e já dá até para aventurar algumas linhas de código agora. Passando para a área de EE, se eu fosse definir a guerra dos frameworks em uma frase seria a seguinte: “Struts 1 chegou o fim do seu reinado, Struts 2 ainda tem muito o que melhorar, e Jsf está tomando conta cada vez mais do mercado”.

Fiquei contente com o que vi sendo citado de tecnologia de ponta, e em vê que na Search Informática (onde trabalho atualmente) estamos indo no caminho certo. Trabalhei em um projeto que foi envolvido em muitos conflitos com a questão da adoção de uma tecnologia nova e pouco conhecida ainda. Mas quando a gente vê uma platéia entusiasmada com uma coisa que a gente já trabalha no dia a dia é fantástica a sensação de aprovação. Em resumo, Jsf junto com “JBoss RichFaces”, “JBoss Ajax4jsf” foi o que mais empolgou o pessoal, pela facilidade e praticidade nos componentes. Outra coisa em que temos investido também, é na utilização de Hibernate 3.2 com as anotações do javax.persistence também já bastante adotada pelos desenvolvedores que estavam presentes.

E claro, não posso deixar em branco o RubyOnRails (HEHEHEHE acredite num evento de Java ele não deixou a desejar, com os 10 minutos de apresentação fez sucesso!)

Passei um tempo mínimo dentro de uma sala escutando um pouco sobre o JavaFx (guerra ao flash), parece que até agora temos muito marketing da Sun e pouca realidade no desempenho. Ou seja, estão investindo muito na definição da linguagem ainda para depois investir no desempenho da tecnologia.

Para não deixar passar, não vi ninguém utilizando Eclipse para as demonstrações, não faço idéia o porquê disso, mas que usa NetBeans deve entender um pouco. A pesar de o NetBeans ter dado algum trabalho para alguns palestrantes (aquelas famosas travadas de 3 minutos) todos mantiveram a calma e superaram. Já que falei de IDE muita gente falou que vale apena pagar pela “IntelliJ IDEA”. Pelo que vi parece ser produtiva... NetBeans dominou e nem se ouve falar em eclipse para desenvolvimento em ME e para EE desde Servlet ao EJB3 foi mostrado os recursos no NetBeans. Detalhe, dessa vez não foi evento patrocinado pela Sun!

Gestão Ágil de Projetos com Scrum

Scrum é um processo ágil que está centrado na entrega de maior valor de negocio no menor tempo, ou seja, a cada período curto (duas a quatro semanas) espera-se ter software funcionando e pronto para ser entregue. Para isso são definidas prioridades para a evolução do software e a equipe se organiza para determinar qual é a melhor forma de entregar a funcionalidades de maior prioridade. Aos poucos o software é aprovado pelo cliente e conseqüentemente várias iterações são feitas até o final do processo.

A idéia é fugir de um planejamento exacerbado e trabalhar de forma “Just-in-Time”, onde só se planeja na hora em que se realiza, e se documenta somente o necessário. Isso evitaria milhares de documentos que dão muito trabalho e quase sempre não são utilizados em nada, sem contar com funções que custam caro e em sua maioria nunca são utilizadas.

É um assunto que merece nossa atenção para melhorar essa tão demorada forma de trabalho, onde passamos por um ciclo monstro e um tempo enorme para entregar simples módulos aos clientes.

Tem bastante informação em http://teamware.com.br/ e vai rolar curso aqui em Bsb sobre o assunto.
Google