Up until now I have almost 900 blog posts written over a period of 7 years. Some of those posts already "expired" as the piece of information got obsolete. Many of those are still very relevant and useful today.

People that have been following my blog for the past 7 years had the chance of reading most of those articles. But what about the new people? It's very hard to explore old good articles around a pool of almost 900.

Every blog still follows the very same structure: they are sorted by date in descending order, they show up one at a time in a long stream. Only new posts (or those manually chosen) show up at the top. As soon as I post a new article, the previous one become less relevant. If the blog is paginated, last month's posts will be buried and hidden in previous pages. Most people don't navigate to previous pages nor go through tags (which only help so far).

People looking for some specific pieces can search them through Google (or internal Search if I implement one).

A blog is structured in a way that old posts must remain less relevant and more difficult to find. It's a good enough structure for a news feed. If you write columns, opinions, research, timeless material in general, it's a horrible structure.

We've seen a plethora of blog engines around but they are all exactly the same: a post has many comments, new posts go first in the feed, old posts go to hidden pages in a precarious pagination system.

Several other things have been tried already, none of them succeeded in solving this issue. Tags, featured articles, hierarchical categories, random visualizations of old posts in the main page. None solve the problem of discoverability of old still-relevant posts for new readers.

Maybe this is an unsolvable problem and I don't have a good idea to move forward with this structure. So I'm interested in seeing if anyone else tried to tackle this problem with a different perspective or if new approaches are emerging in this field. Please comment below if you've seen new ideas coming out.

Post.order("created_at DESC").page(params[:page]) is history. What's next?

Atualizado 7/5/2013: adicionado procedimento que não existe na documentação oficial para conseguir fazer deployments "corretamente" no Appfog.

Como disse antes comecei a usar o AppFog pra várias coisas. Mas tem um problema, diferente do Heroku ele não é bom pra executar assets:precompile (primeiro porque pode estourar memória, segundo porque dá timeout se o processamento demorar muito).

O processo de deployment não é via git push mas via o comando af update. Ele simplesmente faz um upload dos arquivos no diretório do projeto ao servidor (se entendi direito). Portanto o melhor a fazer é executar o assets:precompile localmente antes do deploy (lembrar de colocar turbo-sprockets pra ir mais rápido).

O problema é que agora em modo de desenvolvimento o servidor local vai começar a puxar os assets direto da pasta public/assets em vez de processar dinamicamente da pasta app/assets que é o que você precisa em desenvolvimento. Vide meu artigo Asset Pipeline para Iniciantes caso ainda não esteja bem familiarizado com o processo.

Independente de Appfog, se quiser precompilar os asset e deixá-los na sua máquina local sem interferir com seu desenvolvimento (precompilar local é a forma mais rápida para fazer deployment), basta editar o arquivo config/environments/development.rb e adicionar o seguinte:

  config.assets.prefix = "/assets_dev"

Agora o Rails local em modo de desenvolvimento vai ignorar completamente a pasta public/assets e usar /assets_dev como pasta de assets. Como não existe public/assets_dev, ele vai compilar dinamicamente os assets da pasta app/assets, que é o que queremos.

Fonte: Stackoverflow

Problemas no deployment

Existe um problema que considero grave tanto na documentação quanto no processo em si. Como já reclamei ao @appfog o updateé interrompido por erros mal explicados diversas vezes. Depois de muito tentar, descobri que o problema é em como lidar com a gem libv8 que não consegue ser compilada nos servidores da Appfog.

A libv8 é necessária pelo Asset Pipeline que a usa para compilar coffeescript em javascript. Por alguma razão a gem less depende dele que, por sua vez, é dependência do Twitter Bootstrap que eu uso. Não deveria ser necessária em produção, mas acho que a rotina de deployment do Appfog/CloudFoundry tenta compilar os assets depois de subir a atualização dos arquivos, ela tenta instalar as gems do grupo assets e quando tenta instalar a libv8 ela é interrompida por erro de compilação, causando confusão no estado do deployment.

Depois de muitas horas de tentativas frustradas parece que o que funciona é o seguinte: olhe seu arquivo Gemfile.lock. Cheque a versão do libv8:

libv8 (3.11.8.17)

A forma que o libv8 é versionado é o seguinte: 3.11.8é a versão do libv8 propriamente dito. A versão menor .17é a versão da Gem. Versões pares da Gem vem somente com o código-fonte, versões ínpares vem já embutidas com os binários. Se você tentar executar num OS onde esses binários não são compatíveis, você pode "chumbar" a versão par no Gemfile. No caso do Appfog é preciso garantir que você tem a versão ímpar, ou seja, que já tem o binário, evitando o processo de compilação que dá problemas.

Além disso, nas minhas tentativas precisei adicionar as gems do grupo assetsà production na Gemfile:

group :assets, :productiondo
  gem 'jquery-ui-rails'
  gem 'sass-rails',   '~> 3.2.3'
  gem 'coffee-rails', '~> 3.2.1'# See https://github.com/sstephenson/execjs#readme for more supported runtimes
  gem 'execjs', :platforms => :ruby
  gem 'therubyracer', :platforms => :ruby
  gem 'uglifier', '>= 1.0.3'

  gem 'less-rails'
  gem 'twitter-bootstrap-rails'
  gem 'turbo-sprockets-rails3'end

Também segundo a documentação, precisa existir o seguinte no config/environments/production.rb:

# Disable Rails's static asset server (Apache or nginx will already do this)
config.serve_static_assets = true

E o procedimento é, antes de executar o deployment, precompilar os assets localmente e vendorizar as gems (importante especialmente se depender repositórios git privados):

rake assets:precompile
bundle package 

Mesmo assim, ao final do processo pode vir uma mensagem de erro, mas pelas tentativas se a fase de Staging passar parece que a aplicação sobe até o fim mesmo o comando dando o seguinte erro:

af update app
Uploading Application:
  Checking for available resources: OK
  Processing resources: OK
  Packing application: OK
  Uploading (48K): OK
Push Status: OK
Stopping Application 'app': OK
Staging Application 'app': OK
Starting Application 'app': .................Error:
Application 'app's state is undetermined, not enough information available.

O Appfog ainda precisa melhorar muito esse procedimento para não dar problema.

Muitos instalam e mantém seu próprio servidor num VPS. Uma aplicação web hoje é formada por diversos componentes como o web server (NGINX), banco de dados (PostgreSQL, Redis), workers de fila (Resque ou Sidekiq), serviços agregados (como SOLR).

Como já disse antes, fazer "rodar", é simples. Agora e se o processo der crash por alguma razão ou o servidor reiniciar?

Se você usar NGINX com Passenger, já está coberto (apesar de muitos gostarem de Unicorn, não vejo nenhuma vantagem num VPS a usar o Passenger). Se instalar o banco de dados via pacotes (sudo apt-get install postgresql redis-server) ele vai instalar corretamente os init script em /etc/init.d/.

E os workers de Resque e Sidekiq? Para isso uma das formas que inventaram foi o Bluepill. Sinceramente não entendi porque isso foi inventado. Ele é uma mistura de Init Script e Monit ou God. Um trecho da configuração do Bluepill é assim:

rails_env   = ENV['RAILS_ENV']  || "production"
rails_root  = ENV['RAILS_ROOT'] || "/var/rails/my_app"

user = ENV['USER'] || 'www-data'
group = ENV['GROUP'] || 'www-data'
num_webs = ENV["NUM_WEBS"].to_i > 0 ? ENV["NUM_WEBS"].to_i : 4Bluepill.application("your_app") do |app|
  app.gid = group
  app.uid = user
  app.process("sidekiq-worker") do |process|
    pidfile = "#{rails_root}/tmp/pids/sidekiq-worker.pid"
    process.start_command  = "/usr/bin/env PIDFILE=#{pidfile} RAILS_ENV=#{rails_env} bundle exec sidekiq"
    process.pid_file = pidfile
    process.start_grace_time = 30.seconds
    process.stop_grace_time = 10.seconds
    process.restart_grace_time = 10.seconds
    process.uid = user
    process.gid = group
    process.daemonize = trueendend

Agora veja a ironia: o Bluepill cuida de gerenciar seu processo de Sidekiq. Agora quem cuida do Bluepill? Tem que ser o sistema operacional, e nesse caso precisamos de um Init Script para carregar o Bluepill quando o sistema reinicia e precisamos de um Monit para monitorar o Bluepill caso ele se comporte de forma incorreta.

Se vamos fazer Init Script e Monit para o Bluepill, porque não cortamos o Bluepill e fazemos diretamente um Init Script e Monit para os serviços que precisamos? Com o Bluepill estamos apenas adicionando mais uma peça móvel e um bom sysadmin sabe que quanto menos peça móveis existirem, melhor.

A única "vantagem" que vejo é poder usar uma DSL Ruby para escrever a configuração. Mas se for somente esse o motivo, continuo não vejo vantagem nenhuma. Concordo que escrever um bom Init Script no formato LSB (Linux Standard Base), instalar nos run levels corretos é consideravelmente chato. Se nunca viu um Init Script LSB veja este exemplo para o postgresql. É tão comprido que não vou adicionar neste post.

Felizmente existem novidades nesse setor. Se você usa um Mac OS X, temos o Launchd que usa um formato em XML para configurar os daemons do sistema. Não é exatamente "simples" mas comparado ao formato LSB é muito melhor.

E no caso de VPS como a maioria utiliza Ubuntu Server podemos usar o novo Upstart. Para todo serviço que você precisa iniciar automaticamente num reboot, crie um arquivo com extensão .conf no diretório /etc/init do servidor, como root. Um exemplo para Resque numa máquina com RBENV e com deployment via Capistrano, podemos criar o arquivo /etc/init/resque.conf:

description "Resque worker configuration"

start on (local-filesystems and net-device-up IFACE=eth0)
stop on shutdown

respawn
respawn limit 5 20

script
  HOME_DIR=/home/www
  APP_ROOT=$HOME_DIR/apps/rails/current
  PIDFILE=$HOME_DIR/apps/rails/shared/pids/resque.pid
  LOGFILE=$HOME_DIR/apps/rails/shared/log/resque.log
  echo $$ > $PIDFILE
  chown www:www-data $PIDFILE
  chown www:www-data $LOGFILE
  exec su -c "export PATH=$HOME_DIR/.rbenv/shims:$HOME_DIR/.rbenv/bin:$PATH; cd $APP_ROOT; bundle exec rake environment resque:work QUEUE=* RAILS_ENV=production PIDFILE=$PIDFILE >> $LOGFILE 2>&1" www
end script

Está vendo a opção respawn? Ela garante que se o processo der crash e cair por alguma razão, ele vai automaticamente carregar novamente até o limite descrito no respawn limit. Só isso já é suficiente para a maioria das suas necessidades. Leia toda a documentação do Upstart.

Uma coisa é recarregar quanto cair, outra coisa é não cair e consumir mais memória do que deveria. Para monitorar isso usarmos o bom o velho Monit. Basta um simples sudo apt-get install monit e editar o arquivo /etc/monit/monitrc adicionando ao final:

check process resque_worker
  with pidfile /home/www/apps/rails/shared/pids/resque.pid
  start program = "start resque" as uid www and gid www-data
  stop program = "stop resque"
  if totalmem is greater than 400 MB for 10 cycles then restart  # eating up memory?
  group resque_workers

Como temos o Resque configurado via Upstart um simples start e stopé suficiente para iniciar ou matar o processo do Resque. E o Monit faz a checagem de recursos como total de memória consumida, total de CPU sendo utilizado por quantos ciclos. O Monit pode monitorar dezenas de aspectos sob diversos cenários, leia toda a documentação para aprender mais.

Recomendações

Não use Bluepill

Pelo menos eu não vi vantagens. Se existir alguma vantagem sobre Upstart Monit, por favor comentem. Se for pra iniciar Bluepill via Upstart, use direto o Upstart

Não use God

Novamente, alguém precisa monitorar o God, se for pra colocar o Monit olhando o God, remova o God completamente e use direto o Monit

Não suba processos num shell e largue

Obrigatoriamente todo processo que precisa ficar de pé (daemon) deve estar declarado num Init Script LSB ou Upstart

Teste Tudo!

Depois de configurar tudo, faça um reboot na máquina para simular uma falha e veja se tudo se carrega automaticamente. Toda vez que fizer um init script, execute os comandos 'start' e 'stop' e cheque com 'ps -a' para ver se o processo morreu mesmo, cheque se o Pidfile tem o número correto do processo depois de reiniciar, cheque se o processo está escrevendo os logs no arquivo correto. Não existe isso de "copiar" e "colar" um script como esse e "confiar" que vai funcionar. Teste cada aspecto do script antes de começar a confiar nele. E mesmo assim não confie passe algumas horas e dias monitorando manualmente, refinando o script de Monit (ele pode acabar criando comportamentos estranhos), e adicionando monitores externos

Esta semana estava organizando meu blog e finalmente adicionei ao menu principal o ítem "Iniciante". Logo se tornou o ítem mais acessado do meu blog. É um sintoma de um problema que sempre acontece: muitos dos Rubistas que iniciaram 5 anos ou mais atrás e hoje são reconhecidos escreveram muitos posts, partipavam dos foruns. Muita de nossa inspiração veio de blog posts de outros grandes Rubistas de fora. Ryan Bates, o próprio DHH, Jamis Buck, Dave Thomas e muitos outros que também estavam ainda aprendendo e postando sobre as coisas que aprendiam.

Essa geração passou, uma nova surgiu, os blog posts agora tendem a ser mais avançados e, pior, existe uma abundância de material e pouca sequência. A vantagem de iniciar a aprender junto com o nascimento de qualquer plataforma é que você nunca se sente "ficando para trás" pois literalmente vimos absolutamente tudo que foi feito até então.

Mas o "Iniciante" (não importa se iniciante em programação em geral, ou avançado em outra plataforma e iniciante nesta) não tem o histórico, acabou de chegar e se vê perdido numa montanha de informação e discussão. O que é mensageria assíncrona? O que são APIs RESTful? Que diabos é um MongoDB? Pra que serve Capistrano? Por que não posso colocar meus sites numa Dreamhost e preciso ir pra Heroku? Travis, isso é de comer???

Eu frequentemente tento escrever artigos mais introdutórios, como os recentes que escrevi sobre hospedagem, mas mesmo eles já pressupõe um leitor não tão iniciante assim. Hora de voltar às raízes: se eu olhar meu histórico, o artigo mais lido do meu blog de todos os tempos foi escrito em 31 de Janeiro de 2008 e se chama Rolling with Rails 2.0 - O Primeiro Tutorial Completo - Parte 1.

Rubistas, lembram da sensação quando assistiram o Blog em 15 minutos pela primeira vez? Óbvio, é brincadeira de criança, mas teve um enorme impacto na nossa geração, nos inspirou, nos motivou. Eu me empolguei e embarquei depois disso, o resto é história.

E onde está o "Blog de 15 minutos" que vai inspirar a nova geração?

Pensei muito sobre esse assunto, já comecei a escrever um novo material sobre isso mas nunca acabei. Dica: o "Blog de 15 minutos" não é mais um Blog :-) Ainda precisa ter a velocidade de no máximo 15 minutos mas sem ser acelerado demais e com a missão de expor as principais boas práticas de hoje. Screencast, tutoriais, eBook. Não é uma missão pequena mas está lançado o desafio.

E se você é iniciante, comece seu próprio blog. Todos os grandes nomes de hoje começaram escrevendo sobre suas próprias experiências de aprendizado, esses posts se tornaram as primeiras referências para nossa geração. Existe um novo público ávido para ter acesso a essa experiência e ninguém pode explicar melhor o processo de "iniciar" do quem está "iniciando".

Incentivo: um blog post toda sexta voltada aos iniciantes. Twittem com a hashtag #IF. Vamos fazer algo mais útil do que um mero #FF

Original de 27/4/2011: Gestão 2.0

Meu último artigo de tradução sobre “Padrões: Excelência vs. Mediocridade” gerou uma discussão separada interessante especificamente sobre “Design Patterns”.

Para quem não é de programação, nos anos 70 (e foi reforçado nos anos 90 pelo “livro do Gang of Four”) surgiu um termo chamado “Design Pattern” que, segundo a Wikipedia, em engenharia de software, um “design pattern” é uma solução reusável geral para um problema que ocorre comumente em design de software. Um design pattern não é um design fechado e acabado que pode ser transformado diretamente em código. É uma descrição ou template para como resolver um problema que pode ser usado em muitas situações diferentes.

Para nós, no Brasil, existe um enorme problema que só me caiu a ficha por causa da discussão nos comentários do meu artigo que mencionei acima. A reclamação foi que traduzi “Design Patterns Standards” como “Padrões de Design”. O Ronald, que fez a reclamação, levantou o ponto correto, as palavras em inglês: “default”, “standard” e “pattern” todas traduzem para a mesma palavra “padrão” em português.

Mas as 3 palavras tem significados muito diferentes:

Default– uma opção pré-selecionada adotada por um programa de computador ou outro mecanismo quando nenhuma outra alternativa é especificada pelo usuário ou programador. Exemplo: o “default” é 50 linhas

Pattern– 1) um design decorativo repetitivo (como em “patterns” de cor numa roupa). Um arranjo ou sequência regular em objetos comparáveis ou eventos. Uma forma regular e inteligível ou sequência discernível em certas ações ou situações. 2) um modelo ou design usado como um guia em bordado ou outras atividades artesanais.

Standard– 1) um nível de qualidade ou realização. Um nível requerido ou concordado de qualidade ou realização. 2) uma idéia ou coisa usado como medida, norma, ou modelo em avaliações comparativas. Princípios de conduta informado por noções de honra e decência. Uma forma de linguagem que é amplamente reconhecida como a forma correta. Resumindo:

Default– uma escolha pré-selecionada quando nenhuma outra é selecionada.

Pattern– um modelo que pode ser observado como recorrente, sem valor de certo ou errado.

Standard– uma norma, algo que todos concordam como base de comparação ou requerimentos mínimos a serem seguidos. O problema é que a palavra “padrão”, em português, é usado muito mais com o sentido de “standard”. E muitas vezes o que estamos traduzindo é a palavra “pattern”.

Ou seja, quando alguém fala “Design Pattern” estamos falando somente que existe uma “forma” que é usada com mais frequência do que outras na resolução de problemas de software. Ela não é necessariamente a mais correta, não existe afirmação dizendo que é a forma conclusiva. Apenas a observação de que ela é frequente, regularmente usada. A imagem a seguir são padrões, no sentido de “patterns” (“mais patterns”):

Mas traduzindo para “Padrões de Design”, fica a impressão do sentido em português da palavra “padrão” no sentido de que é a forma mais correta ou minimamente correta e que, sendo uma “norma”, deveria ser a seguida. A tradução “padrão” fica parecido com “obrigação de seguir o padrão Portaria nº 288/2005″, no sentido de “obrigação de seguir a norma ou regulamento Portaria nº 288/2005″ e aí “Design Patterns” ganha conotação de norma ou regulamento, que é exatamente o sentido errado! Pattern é Pattern, Standard é Standard, são coisas completamente diferentes.

E esse é o problema que muitos de nós discute em termos de entendimento. Quem entendeu corretamente Design Patterns no sentido de “Pattern” reclama de quem entendeu no sentido de “Standard”. Ambos traduzem como “padrão”. E então fica claro porque uma discussão entre essas duas pessoas fica parecendo conversa de louco: “Mas isso é só um padrão (pattern), não é pra ser seguido obrigatoriamente.”– “Não! Isso é um padrão (standard), por isso precisa ser seguido obrigatoriamente!”

Observação: notei que algumas pessoas não gostaram muito do título, mas eu coloquei deliberadamente assim para realmente chamar a atenção ao assunto. Claramente não estou afirmando que a língua portuguesa é essencialmente ruim e outras são melhores, toda língua sempre tem nuances e diferenças que dependem do contexto, da cultura local, dos coloquialismos, neologismos, moda e assim por diante. Justamente por isso temos que estar sempre atentos para não entender as coisas ao pé da letra e aplicar sem pensar partindo de premissas falsas.

Alguns anos atrás escrevi diversos artigos num outro blog fora daqui entitulado "Gestão 2.0".

Na época me faltou tempo para escrever lá então ele ficou parado. Como ficou parado todo esse tempo, decidi transferir os posts que eu mais gostei para cá para garantir que meus textos estão (quase) todos num lugar só. Atualmente estou colaborando como colunista na Startupi, então não deixe de visitar lá também.

Separei uma dúzia de posts do Gestão 2.0 que já estão programados para aparecer na homepage e nos feeds toda sexta-feira perto das 20h. Quem assina meu feed vai recebê-los automaticamentte. Eles tem a tag Gestao20 e a primeira linha diz a data original de quando foram publicados. Como o @gabaiel já descobriu há um pequeno bug no meu blog que permite já ver todos esses posts programados.

Daqui a 18min o @AkitaOnRails vai postar alguma coisa no blog dele... algo sobre traduções erradas (patterns, standards). Sou vidente!

Fica como um easter egg para quem for curioso (ou não tiver paciência pra esperar) :-)

O primeiro post já está no ar, chama-se A Língua Portuguesa-Brasileira é Péssima: Standard vs Pattern. Divirtam-se!

Uma das gems que eu mais uso em projetos é o ActiveAdmin, de todas as opções de admin para Rails que surgiram até hoje, esta foi a que melhor se adaptou na maioria dos projetos. Longe de ser perfeita, mas o suficiente para atender bem as necessidades de uma simples coleção de CRUDs.

Outra vantagem é que pouco a pouco um pequeno ecossistema surgiu em torno do framework, adicionando funcionalidades como granularidade de permissões com CanCan, e eu já bloguei sobre sua excelente integração com o Best in Place. Desta vez experimentei outra extensão que gostei muito, o ActiveAdmin-WYSIHTML5.

Essa extensão foi criada pelo italiano Stefano Verna que também fez diversas outras extensões, incluindo um com o Globalize 3, e um para fazer upload de imagens que utiliza uma outra gem chamada Dragonfly.

Um parêntese, o Dragonfly é um concorrente de Carrierwave e Paperclip. Uma vantagem em relação aos anteriores é que ele herda somente de ActiveModel em vez de ActiveRecord, o que o torna naturalmente compatível com MongoMapper para usar com MongoDB.

Se somar com o Best In Place, CanCan, um versionador como o PaperTrail, já é possível fazer um CMS (Content Management System) bastante capaz rapidamente e, melhor, com boa qualidade, bons testes, facilidade de adicionar novas funcionalidades.

Num novo projeto podemos criar um model Page que terá o HTML:

rails g model Page title body:text

Agora adicionamos o que precisamos no Gemfile:

gem 'activeadmin'
gem 'activeadmin-dragonfly', github: 'stefanoverna/activeadmin-dragonfly'
gem 'activeadmin-wysihtml5', github: 'stefanoverna/activeadmin-wysihtml5'

Execute o comando bundle para instalar. Agora precisamos criar os arquivos de configuração básicos:

rails generate active_admin:install
rake activeadmin_wysihtml5:install:migrations 

Finalmente, basta criar a configuração normal para o ActiveAdmin para expor o model Page criando o arquivo app/admin/page.rb com o seguinte:

ActiveAdmin.register Pagedo
  form do |f|
    f.inputs do
      f.input :title
      f.input :body, as: :wysihtml5end

    f.buttons
  endend

A opção :wysihtml5 pode ser customizada para definir que tipos de controle o editor vai possuir. Com o Dragonfly ele automaticamente já ganha o modal para galeria de imagem com suporte a uploads (em outro artigo mostro como migrar o Carrierwave para Dragonfly e como configurar para fazer uploads para S3. Dica: leia a documentação e o código fonte do Dragonfly).

Não esqueça de adicionar os assets do ActiveAdmin no seu config/environments/production.rb para que a tarefa de pré-compilação do Asset Pipeline compile corretamente (muita gente esquece de fazer isso no começo):

config.assets.precompile += %w(active_admin.js active_admin.css active_admin/print.css)

Por causa de opções como essas é que provavelmente não temos um CMS "canônico" no mundo Rails. É mais fácil (e muito mais prático e limpo) incorporar funcionalidades de CMS à sua aplicação do que tentar "estuprar" um CMS limitado para fazer mais do que sua função original.

Em particular, a categoria Rails Admin Interfaces já evoluiu muito nos últimos anos. Uma recomendação: nunca vai existir um Admin que satisfaça tudo e todos. Se tentar fazer algo customizável e dinâmico demais o projeto pode facilmente sair do controle. Já passamos por isso com o ActiveScaffold e mesmo com o atual Rails Admin. O ActiveAdmin é mais "quadrado" nesse sentido mas é mais simples e explícito no que faz. Alguns não gostam porque para customizá-lo você precisa usar Formtastic. Existem facções que gostam, outras que preferem SimpleForms, e outras que preferem não usar nenhum deles, mas novamente é uma questão de preferência já que ambos tem prós e contras.

O objetivo de mostrar esta gem é demonstrar como o ActiveAdmin pode ser estendido para funcionalidades interessantes sem tanto trabalho e/ou necessidade de criar "yet-another-clone" do ActiveAdmin.

Caso ainda não saiba, o bom e velho Ruby 1.8 desempenhou seu papel muito bem nos últimos anos e chegou a hora de aposentá-lo. Ele não receberá mais manutenção ou mesmo correções de segurança a partir de Junho deste ano (2013). Significa que seu irmão-gêmeo, o venerado Ruby Enterprise Edition 1.8.7, que nos apresentou a funcionalidade de Copy-on-Write e a possibilidade de refinar os parâmetros do garbage collector, também ser tornará obsoleto em breve.

O que acontece hoje é que existem muitos aplicativos ainda rodando em Ruby MRI ou REE 1.8.7, desenvolvido em Ruby on Rails 2.3, em produção, que ninguém sabe o que deve fazer. A resposta mais comum, caso pergunte aleatoriamente a um desenvolvedor, será "reescrever" em Ruby 2 e Ruby on Rails 3.2 (ou já arriscando para o Rails 4.0 que sairá em breve).

Minha resposta é diferente: se seu aplicativo está hoje em produção, com usuários acessando, minha primeira opção sempre será explorar a possibilidade de realizar o que chamamos de "migração técnica". Uma migração técnica:

• não envolve mudar funcionalidades ou criar novas;
• no máximo retirar funcionalidades desnecessárias;
• e apenas realizar a atualização para as versões mais recentes de Ruby e Rails.

Reescrever sempre é mais arriscado e - normalmente - representa um custo/benefício inferior. Isso porque reescrever significa:

• precisar atingir "paridade de funcionalidades", ou seja, ter no mínimo as mesmas funcionalidades principais do seu aplicativo atual;
• se conseguir fazer isso (e a maioria não consegue), haverá um momento com dois aplicativos rodando em produção onde você precisará tentar uma migração dos dados (com regras de negócio possivelmente diferentes) para uma nova base e "virar a chave";
• haverá um bom período de "estabilização". Um aplicativo reescrito significa retornar à versão 1.0, com muito mais bugs do que o antigo, e até ele se estabilizar - com uma base de usuários ativa - vai demorar;
• durante todo esse período você provavelmente não vai conseguir lançar novas funcionalidades - pois significaria implementar duas vezes, no antigo e no novo - isso pode causar sérios problemas de competitividade de mercado (onde outros menores podem começar a lançar o que você já deveria ter lançado, na sua frente).

Portanto a resposta automática nunca deverá ser reescrever. Analise os impactos que mencionei e diversos outros que dependem do seu negócio. Isso tudo dito, porque a maioria dos desenvolvedores respondem automaticamente "reescrever"?

• porque ninguém gosta de assumir código de outro programador, especialmente código "velho", que não é esteticamente atualizado. Em diferentes níveis, todo programador sofre da síndrome de NIH (Not Invented Here);
• porque o código tem pouco ou nenhum teste automatizado, e portanto o risco de mudar código é alto e poucos programadores se sentem confortáveis em assumir a responsabilidade de um código desconhecido.

Se for resumir, a raíz do problema costuma ser dois sentimentos que se contradizem: Ego e Insegurança. Se contradizem porque Ego pressupõe uma confiança nas próprias habilidades de conseguir fazer melhor que o anterior, e Inssegurança pressupõe falta de confiança nas próprias habilidades de conseguir fazer melhor que o anterior. Se você é programador, reflita sobre isso.

Por outro lado eu considero que um programador que tem pouco Ego e muita Segurança é sempre o que tem mais chances de poder se chamar um sênior de verdade. Afinal o que parece mais "fácil" qualquer um sabe fazer, no mundo do "difícil" existe pouca concorrência, pois poucos sobrevivem.

Muitos já me consultaram sobre o que fazer para atualizar um aplicativo Ruby 1.8 com Rails 2.3 para as versões mais novas.

Minha resposta é sempre a mesma:

"Um Passo de Cada Vez"

O primeiro erro básico que TODOS os desenvolvedores de todos os níveis cometem logo de cara é tentar atualizar diretamente do Ruby 1.8 para 1.9 ou 2.0 e do Rails 2.3 para 3.2 ou 4.0. Está errado, isso é um passo maior do que você vai conseguir administrar.

Eu pessoalmente participei na atualização de uma aplicação antiga exatamente nessas condições e fui bem sucedido. O aplicativo não era super complicado mas estava longe de ser trivial. Ao mesmo tempo que subimos de Ruby 1.8 para Ruby 2.0 e de Rails 2.3 para Rails 3.2; subimos a cobertura de teste de zero para mais de 50% (e isso sem ignorar as diversas configurações de ActiveAdmin no app/admin que conta como arquivo Ruby não coberto por teste).

Além disso, em paralelo, otimizamos a performance da aplicação, da infraestrutura, e conseguimos um ganho de performance ridículo onde as requisições mais pesadas, que antes faziam o usuário esperar até 15 segundos (!!), agora não ultrapassam 400ms (segundos para milissegundos, exatamente isso). E veja que qualquer coisa acima de 200ms eu ainda não considero rápido o suficiente. No mundo perfeito, total abaixo de 100ms por requisição é o ideal. "Tempo total" é o tempo de processamento mais o overhead da infraestrutura e internet.

Isso foi um processo que, não trabalhando tempo integral me custou pouco menos de 3 semanas de trabalho. Obviamente seu tempo vai variar dependendo da complexidade da sua aplicação e da estratégia da sua empresa (que deve ser levada em consideração o tempo todo).

Antes de mais nada, se você nunca usou os Rails mais atuais do que 2.3, pelo menos tenha uma noção lendo os Release Notes que está no Guia oficial:

• Ruby on Rails 2.3 Release Notes
• Ruby on Rails 3.0 Release Notes
• Ruby on Rails 3.1 Release Notes
• Ruby on Rails 3.2 Release Notes
• Edge - Ruby on Rails 4.0 Release Notes

Todos os Rails, da versão 2.3 até a 3.2 suportam Ruby 1.8.7, portanto você pode escolher mudar o Ruby só no final. Por outro lado se quiser arriscar a série 1.9, até o Rails 3.1 use apenas até o Ruby 1.9.2. Só mude para Ruby 1.9.3 no Rails 3.2.

Em particular, neste momento (Maio de 2013) recomendo ficar no Ruby 1.9.3 com Rails 3.2. Se chegar até esse ponto, você vai, no mínimo, ter uma sobrevida até 2014. Só depois que tiver certeza que está tudo estável nessas versões, mude para Rails 4.0.

Rails 2.3 para Rails 3.0

Nesta primeira etapa você praticamente não vai precisar alterar nada pois o Rails 3.0 mantém um alto nível de compatibilidade com o anterior. Coisas como as APIs novas de Routing, ActiveRelation, nada disso é obrigatório. O resto é o mesmo: views ERB vai funcionar igual, seus assets no /public funcionam normalmente.

O maior impacto para quem nunca foi para a versão 3.0 é aprender a usar o Bundler que inclusive você já pode adicionar a um projeto 2.3 antes de tentar migrar para 3.0.

Um dica válida para toda atualização significativa de Rails: crie um projeto novo na versão para onde está mudando e compare todos os arquivos da pasta /config, todos. Muitos dos erros que aparecem é por falta das novas configurações.

Sobre configurações ainda, antigamente existiam as gems chamadas "mysql" e "postgres", elas devem ser atualizadas para as gems mysql2 e pg, respectivamente. Elas são o que chamamos de drop-in replacements, ou seja, apenas troque e tudo deve continuar funcionando sem que você precise mudar nada.

Para quem não se lembra, o Ruby on Rails 3.0 foi o primeiro (e felizmente bem sucedido) "HUMONGOUS REWRITE" do framework. Isso foi amplamente divulgado, centenas de blog posts foram escritos, muita polêmica foi levantada, quase 2 anos foram gastos nesse assunto. Até o Rails 2.3 foi uma evolução do antigo código que o próprio David Hansson escreveu em 2004. As versões atuais são derivadas da nova arquitetura que nasceu no Rails 3.0. Em resumo, não estaríamos hoje falando de Rails se a versão 3.0 tivesse fracassado.

Isso justifica porque migrar do Rails 2.3 para o 3.0 exige um volume de esforço não tão grande. Você só terá problemas se escreveu código extremamente mal feito ainda na versão 2.3, fugindo completamente das convenções aceitas até então. Exemplo disso são monkey-patches feitos diretamente sobre o framework. Como no 3.0 as APIs internas mudaram, gambiarras vão necessariamente quebrar. Se você tem consciência que fez muita gambiarra e brigou contra o framework, agora o preço será devidamente cobrado, e com juros.

As principais APIs que você precisará saber que mudou (mas que a versão antiga ainda funciona no 3.0), em ordem do mais simples até o mais complicado de mudar:

• Novo Mailer. Na maior parte será apenas um caso de alterar nomes de métodos. Aproveite para adicionar specs. Será uma atualização razoavelmente mecânica de uma API para outra.

• Novo Router. Novamente, na maior parte será uma modificação praticamente toda mecânica de uma API para outra. Onde haverá mais complicações será em rotas com constraints. Um passo muito importanteé obrigatoriamente fazer pelo menos um Routing Spec que cobre suas rotas atuais. Seja cuidadoso, cubra todas as rotas e só depois que tiver essa cobertura comece mudar para a nova API.

• ActiveRecord - esta foi outra parte que mudou muito: as APIs que abstraem o banco de dados. Novamente, a sintaxe antiga continuará funcionando, mas é outra parte que você precisará dedicar muito tempo para entender cada nuance. A regra é a mesma: se seu código seguia as convenções haverá poucos pontos onde a mudança será difícil. Estude todo material sobre ActiveRelation que puder.

• Rails RJS - se sua aplicação foi feita com muito Ajax e usando as antigas helpers RJS em vez de usar Javascript não-obtrusivo, certamente essa pode ser a parte onde você terá mais trabalho para migrar. Eu já escrevi um artigo sobre isso 3 anos atrás. Para começar helpers como link_to_remote não funcionam mais. Para facilitar a migração neste ponto você ainda pode carregar as seguinte gems antigas no Gemfile:

# gem 'jquery'
gem 'prototype'
gem 'prototype-ujs'
gem 'prototype_legacy_helper', :git => 'git://github.com/rails/prototype_legacy_helper.git'

Isso vai fazer tudo funcionar como era antes. Mas não se engane, se sua aplicação tiver um volume grande de RJS você terá realmente que reescrever praticamente metade da sua aplicação na parte mais visível para o usuário: as telas. Vale a pena gastar um tempo avaliando esse aspecto.

No geral, o procedimento é o mesmo: crie specs para a parte do código que usa a API 2.3 ANTES de migrar o código para a API 3.0. Não faça todas as specs do projeto todo de uma vez só: como eu disse antes, faça um passo de cada vez. Faça uma spec, mude a API, repita o ciclo. Passo a passo será muito mais rápido e o risco será muito menor.

A mudança do Rails 2.3 para 3.0, do ponto de vista técnico, não é complicado. Seu maior trabalho num primeiro momento será começar a entender a nova arquitetura, entender o Bundler, ver se a maioria das dependências externas ainda funcionam. Em particular vasculhe cuidadosamente seu diretório vendor/plugins, faça o possível para retirar TODOS os plugins e encontrar suas versões em Rubygems para acrescentá-las na Gemfile.

Substitua um plugin de cada vez: ache a gem, declare no Gemfile, rode o comando bundle para ver se nada quebra na instalação, execute a aplicação, veja se o comportamento ainda é o mesmo, e repita. Novamente, adivinhe onde dará problemas? Adivinhou: se alguém alterou o código do plugin depois de adicionar no projeto e você não sabe disso.

Uma forma de garantir que o plugin não foi "estuprado" indevidamente: ache o Github do projeto, faça um clone na sua máquina (de preferência dando checkout num commit da época em que o plugin foi instalado no seu projeto). Agora pegue o código do plugin que está no seu projeto e copie os arquivos por cima do clone. Agora use o comando git status, git diff para ver onde eles diferem.

Na época o pessoal do Peepcode lançou um eBook e screencast que ainda vale a pena dar uma olhada.

Rails 3.0 para 3.1

A imagem a seguir resume esta etapa:

Relembrando, antigamente todos os seus assets ficavam no diretório /public. Era caos. Agora fica tudo em /app/assets e passa pelo Asset Pipeline que foi inaugurado no Rails 3.1. E até você aprender as nuances desta funcionalidade você irá odiá-la. Confiem em mim: depois da primeira dor (que vocês vão passar), será bem mais fácil.

Lembram o que eu disse sobre RJS na seção anterior? Agora é a hora de começar a trocar os helpers antigos pelos novos. Na prática não é muito complicado, por exemplo:

# Rails 2.3
link_to_remote "Delete this post", :update => "posts",:url => { :action => "destroy", :id => post.id }# Rails 3.x
link_to "Delete this post", post_path(post), :method => :destroy, :remote => true

Leiam com muito cuidado meu tutorial sobre como usar Asset Pipeline, Parte 1 e Parte 2. Assumindo que você já leu, praticou e entendeu o básico, os passos são "simples" embora sejam manualmente trabalhosos e exijam atenção e concentração para não se perder:

• mova tudo da pasta /public para as respectivas pastas em /app/assets;
• crie os arquivos /app/assets/javascripts/application.js e /app/assets/javascripts/application.css para declarar as dependências - retire tudo que você carregava individualmente no /app/views/layouts/application.html.erb;
• garanta que seu Gemfile tem as bibliotecas jquery-rails. Se por acaso você usava Prototype para mais do que o Ajax padrão do Rails antigo, vai precisar do protototype-rails, e nesse caso seu application.js deverá ter:

//= require prototype//= require prototype_ujs//= require effects//= require dragdrop//= require controls//= require menu

• agora modifique toda URL que não é gerada por helpers e que tem caminhos como /images para /assets;
• para facilitar renomeie todos os stylesheets para serem .css.scss e agora substitua toda URL para assets como url("../images/glyphicons.png") para image-url("glyphicons.png") e o SASS fará o resto por você;
• os helpers de ActionView que são blocos precisam explicitamente ter "=" no ERB, troque em todas as views. Ou seja:

<!-- Rails 2.3 --><% form_for :contato do |f| %>
...<!-- Rails 3.x --><%= form_for :contato do |f| %>

Existem muito mais passos, por isso a recomendação é realmente entender os princípios por atrás do Asset Pipeline. No meu caso ainda tive que retirar do código antigo uma coisa que poderia ser chamado de "primeira tentativa de um Asset Pipeline" que foi o Bundle-fu. No final minha sequência ficou assim:

A boa notícia é que esta será possivelmente a parte mais dolorida da migração, se conseguir passar por esta etapa as próximas tendem a doer menos. E eu digo que vai doer porque tudo que mexe no front-end dói muito pois estamos mexendo em javascript, em helpers, em tudo que pode quebrar drasticamente a usabilidade da sua aplicação. Se não tiver testes automatizados como com Selenium, recomendo colocar uma pessoa responsável por realizar o Q&A (Quality Assurance) da aplicação antes de colocar em produção.

Além disso algumas das gems que você ainda pôde manter até agora precisam ir embora, especialmente se você investigar o repositório no Github e ver que elas não tem atualizações há alguns meses. Eis um exemplo que você talvez tenha:

Isso vai dar um pouco de trabalho, felizmente mudar para Devise não é complicado (embora trabalhoso, mas neste ponto você já deve estar acostumado) só que em particular esta gem não é compatível com Rails 3.1 então precisa ser atualizada já que o projeto original ficou parado. E lembre-se que existem diversas alternativas de autenticação. Devise é um dos mais conhecidos mas não é a única opção e dependendo da sua aplicação talvez nem seja a melhor, por isso pelo menos dê uma lida na página dos 5 mais usados.

No seu Gemfile você vai precisar das seguintes gems:

gem 'devise'
gem 'devise-encryptable'

Leia a documentação do Devise mas além das gems, transportar as views, os mailers, nos controllers você vai trocar as rotas e a API antiga pela nova:

# Restful Authentication
before_filter :login_required# Devise
before_filter :authenticate_user!# Restful Authentication
before_filter :login_required# Devise
before_filter :authenticate_user!# Restful Authenticationif logged_in?# Deviseif signed_in?# Restful Authentication
redirect_back_or_default("/")# Devise
redirect_to root_url# Restful Authentication
include Authentication
include Authentication::ByPassword
include Authentication::ByCookieToken# Devise
devise :database_authenticatable, :registerable,:recoverable, :rememberable, :confirmable, :validatable, :encryptable, :encryptor => :restful_authentication_sha1

Esses são alguns exemplos. A vantagem nessa migração é que o Devise é compatível com o esquema de SHA1 que o Restful Authentication usava e por isso você não vai precisar mudar a senha dos seus usuários. Tecnicamente tudo deve funcionar sem problemas. O que vai mudar são as rotas antigas.

Rails 3.1 para 3.2

Agora é a hora e realizar o que era opcional na migração técnica para 3.0. Mudar as APIs de mailers, routes e, principalmente, focar na Query Interface do ActiveRelation. Aproveite para ver esta lista dos 10 métodos menos conhecidos, e menos usados, do ActiveRecord::Relation.

Se você fez passo a passo, como disse antes, neste ponto o projeto já deve estar bem mais organizado, com gems mais novas, com mais specs cobrindo o que você foi mudando.

Um teste que você pode fazer é trocar para Ruby 1.9.3, executar bundle e rodar as specs que criou até agora. Teoricamente, se isso passar você deve estar muito próximo de poder retirar o Ruby 1.8.7. Quando uma gem velha dá problema ou se seu código possui algum trecho incompatível o comando rake spec ou mesmo rails s para subir o servidor vai falhar imediatamente por erros de sintaxe. Já é um bom sinal se minimamente executar. Caso contrário LEIA AS MENSAGENS DE ERRO, elas dizem claramente o que está dando errado.

Cansei de receber emails e mensagens me perguntando porque alguma coisa estava dando errado. Bastava copiar a mensagem de erro no Google e a resposta sempre aparece. Aprenda: o erro que você está tendo dificilmente é inédito e já existem soluções documentadas. Se você não encontrou a possibilidade mais óbvia é que você não soube procurar direito. Portanto procure antes de perguntar, não tenha preguiça.

Neste ponto você deve estar ainda corrigindo bugs relacionados à migração técnica. Não se preocupe: até você cobrir o aplicativo todo com specs, vai continuar recebendo reclamações de coisas que funcionavam antes e pararam de funcionar. Mas se foi esperto, a cada passo dado até aqui você foi adicionando specs.

Sobre o Rails 3.2 fica uma dica: neste momento (Maio de 2013) use o Rails versão 3.2.12 ou acima da 3.2.13 mas não use a 3.2.13. O post já está longo mas fica o link para entender os problemas que essa versão causou.

Se você fez a migração como recomendado para a versão 3.1 agora com a 3.2 terá um bônus. Adicione o seguinte na sua Gemfile, no grupo :assets:

gem 'turbo-sprockets-rails3'

Isso vai acelerar muito a pré-compilação dos seus assets (coisa que provavelmente já estava te deixando irritado até agora).

Na versão 3.2 você tem a opção de tornar Mass Assignment mais rígido adicionando o seguinte em todos os arquivos de ambiente em /config/environments/:

# Raise exception on mass assignment protection for Active Record models
config.active_record.mass_assignment_sanitizer = :strict

E apesar de ter sido opcional até agora, você DEVE ligar essa restrição e tratar de adicionar attr_accessible em todos os seus models. Coloque na lista apenas os campos que efetivamente precisam ser populados via hash no construtor da classe. Caso contrário mantenha escondida. Esse é um erro de segurança muito comum que deve ser consertado o quanto antes.

Se segurança nunca foi sua preocupação, este é o melhor momento para considerar isso. Durante a vida da série 3.2 diversos bugs de segurança foram expostos. Leia o Guia Oficial de Segurança. Conheça a gem Brakeman, conhecido como o Rails Security Scanner, para avaliar seu código por buracos conhecidos de segurança. Lembre-se: se são buracos conhecidos e você não se preocupou com isso, alguém vai eventualmente entrar no seu sistema. Depois disso não importa mais o que fizer, segurança é uma coisa que uma vez estourada não se recupera se forma trivial.

Para o Futuro: Ruby 2.0 e Rails 4

Se você seguiu até aqui, trocar para Ruby 2.0 não deve ser um problema. Existem várias novas funcionalidades nele que você não precisa implementar agora. Ele é "quase" um drop-in replacement para o Ruby 1.9.3 então não deve dar dores de cabeça. Existem dezenas de artigos na internet sobre Ruby 2.0 mas para uma introdução segue os slides de uma palestra que dei a respeito:

Já o Rails 4 ainda não é versão final, está em Release Candidate 1 e isso ainda vai dar dores de cabeça num futuro próximo até que todas as principais gems do ecossistema se atualizem. Muitas já foram como o Devise. Ano passado palestrei em Israel sobre o Rails 4, eis os slides:

Agora no Rails 4 preparem-se para o seguinte: tudo aquilo que você veio trazendo do Rails 2.3 porque ainda era compativel se tornará incompatível no Rails 4. Um exemplo são as APIs de rotas ou o ActiveRelation. Nem pense em instalar a nova versão até ter migrado tudo para as APIs novas. Veja as mensagens de "deprecation" que vão aparecer no Rails 3.2 e migre aos poucos.

Meu conselho é simples: se você está perguntando a alguém "Posso usar Rails 4?" então significa que você não deve usar. Mantenha-se no Rails 3.2 com tudo atualizado, adicione mais specs para cobrir a maior parte da sua aplicação. A chave para uma migração tranquila é ter uma boa suíte de specs prontas. Se fizer isso o processo tende a ser razoavelmente indolor, muito menos do que o que resumi neste artigo.

Original de 24/4/2011: Gestão 2.0

O texto a seguir é uma tradução do excelente artigo Standards: excellence vs mediocrity, escrito por Jason Yip, consultor da Thoughtworks, que tive o prazer de conhecer pessoalmente ano passado.

Antes de iniciar o texto traduzido, uma pequena introdução: todos sabemos como muitos conceitos que temos como fundação no mundo ocidental podem ser radicalmente diferentes no mundo oriental. Um desses conceitos difíceis de transpor do mundo oriental para o ocidental é justamente o de “padrões”. No mundo ocidental “padrão” é um denominador comum, estático, rígido, difícil de mudar, o status quo. No mundo oriental, a idéia de “padrão” é “o melhor”. Se amanhã aparece outro “melhor”, este deve ser considerado o novo padrão. Não é algo inatingível, que admiramos de baixo para cima sabendo que dificilmente vamos alcançar, como um “recorde”.

Imagine um mundo onde o “recorde” é o “padrão”. Eu falei sobre isso em outro artigo chamado Padrões, Commodities e Inovação, recomendo ler. Agora sim, segue a tradução do artigo do Jason:

Alguns anos atrás, eu participei de um tour de estudos de Lean no Japão. Como esperado, fizemos uma visita à uma fábrica da Toyota. De forma não esperada, essa visita foi conduzida por um gerente da fábrica que também nos acompanhou no tour. Em um ponto, estávamos olhando para uma área de demonstração de treinamento de capacidades fundamentais – desenvolvendo capacidades básicas necessárias para ser um membro produtivo na linha de montagem. A maioria era sobre coordenação de mãos com olhos e capacidades motoras. Por exemplo, teve um exercício onde você pega uma corda finha e a conduz ao redor de pregos seguindo uma sequência conhecida na direção do relógio ou contra o relógio. Eu rascunhei um exemplo do que isso poderia parecer:

Eu fui capaz de fazer o exercício em 8 segundos. Então olhamos um vídeo mostrando o campeão da fábrica fazendo em 4 segundos. Então perguntamos ao gerente da fábrica qual era o padrão, esperando que a resposta seria algo entre 5 e 6 segundos. Sua resposta? 4 segundos, claro. Se alguém é capaz de fazer em 5 a 6 segundos, eles o treinariam para atingir 4 segundos, mas mais lento que isso, e eles provavelmente encontrariam outra coisa para o candidato fazer.

Nossa premissa básica era que “padrão” deveria ser alguma coisa fácil o suficiente que qualquer um poderia fazer. Às vezes esse “padrão” vem com a expectativa de treinamento mas muitas vezes acaba sendo sobre o menor denominador comum de forma a obter consistência. Obviamente, não podemos obter consistência se nossos padrões só podem ser atingidos por um subconjunto de pessoas. A consequência dessa forma de pensar é que “padrões” inevitavelmente empurram a organização em direção à mediocridade.

A premissa da Toyota é que o melhor deveria ser o padrão. Ainda existe a expectativa que as pessoas podem atingí-la (com treinamento) e uma expectativa de consistência mas é um padrão de excelência em vez de um menor denominador comum. Isso cria uma expectativa muito maior de performance e desafio. A consequência desse jeito de pensar é que “padrões” inevitavelmente empurram a organização em direção à excelência, especialmente à medida que as capacidades das pessoas continuam a se desenvolver com o tempo.

Em um dos casos, padrões são uma âncora; no outro caso, padrões são um motor.

E isso é diferente em nosso mundo de tecnologia da informação e desenvolvimento de software? Eu acho que não. Pense sobre o último padrão que você encontro (ex. padrões de código, padrões de design, etc.) Ele foi desenvolvido como uma âncora ou um motor? E como seria se todos os padrões fossem desenvolvidos para serem motores?

Original de 3/4/2011: Gestão 2.0

Depois de tanto tempo falando de metodologias, processos, procedimentos, existe uma coisa que já deveria ser óbvia mas que a maioria das empresas ignora: metodologias nunca vão substituir bons profissionais.

Se eu disser isso a qualquer um, todos vão dizer: “mas isso é óbvio”. E minha vontade é retrucar: “então porque diabos você está tentando implantar essa metodologia?”

Antes de mais nada, vamos a algumas definições:

• Metodologia: um sistema de métodos usados em uma área particular de estudo ou atividade.
• Processos: uma série de ações ou passos tomados para atingir um determinado objetivo.
• Procedimento: uma maneira estabelecida ou oficial de se fazer alguma coisa.

Notem que em desenvolvimento de software sempre falamos em processos ou metodologias, nunca em procedimentos. Isso porque não existe uma maneira estabelecida ou oficial de se fazer software. O problema é que a maioria das pessoas confunde processos e metodologias com procedimentos e tenta aplicá-los como se fosse a maneira “oficial” de fazer software. E não são. Por isso mesmo disputas do tipo Ágil vs PMI, por exemplo, não faz sentido. O PMI chama seu conjunto de processos de PMBOK, onde BOK significa Body of Knowledge, ou “Corpo de Conhecimento” justamente porque não é um procedimento, é apenas um conjunto de conhecimento que pode ou não ser útil dependendo do seu setor de atividade. Ágil não é diferente disso: um conjunto de metodologias e técnicas que pode ou não ser útil na sua empresa. Nenhuma delas e de outras são procedimentos. Entenda isso primeiro.

Entendendo isso vem o segundo erro: as pessoas não-praticamentes de desenvolvimento de software identificam que o software sendo gerado é de baixa qualidade. Os indicadores são óbvios: reclamações de clientes, reclamações internas, percepção de demora excessiva para se concluir qualquer trabalho de software e assim por diante. Vendo isso, a primeira conclusão que chegam é: “faltam procedimentos”. E começa a procura pelo elo perdido. Encontram vários processos e metodologias e tentam institucionalizá-las. Por um pequeno período parece que o resultado é o esperado, mas não demora muito para ver que as coisas não mudaram tanto assim e então culpam as metodologias por “não funcionarem”.

Desenvolvimento de Software é uma atividade de “prática”– aliás, cuidado, “praticar” e “ser prático” não são a mesma coisa. E aí cabe mais uma definição:

Prática: 1. a aplicação ou uso real de uma idéia, crença, ou método em oposição a teorias sobre sua aplicação ou uso. 2. exercício repetitivo em ou performar em uma atividade ou capacidade de forma a adquirir ou manter proficiência nisso. (Leia definição mais apurada na Wikipedia). Repitam comigo: se você não pratica software, você não entende software. Da mesma forma que não adianta dizer que você era bom de futebol 10 anos atrás, mas não pratica mais mas mesmo assim quer acreditar que continua bom. Não, se você não pratica há 10 anos, é ruim há 10 anos, não há o que discutir. E em software, não praticar continuamente, diariamente, deliberadamente, há 5 anos, é o mesmo que um engenheiro civil dizer que não pratica engenharia há 50 anos. 5 anos em idade de software é uma eternidade.

E se você não pratica software, não tem nada a dizer a respeito, por definição. Então vai a dica: processos e metodologias não vão ajudá-lo, justamente porque não são procedimentos. Se software tivesse procedimento, não seria uma prática. Basta seguir mecanicamente a série de passos e no final se teria software de qualidade. Mais do que isso, se fosse procedimento, já seria possível ter software que gera software sozinho, sem nenhuma ajuda humana. Mas isso não existe, e nem vai existir.

Se um restaurante tem comida ruim, processos não vão ajudá-lo, trocar de cozinheiro sim. Se sua orquestra toca mau, não é processo que vai ajudá-la, trocar os músicos sim. Se seu time de futebol joga mal, não é processo que vai ajudá-lo, trocar os jogadores sim. Trocar talvez seja drástico, antes disso eu diria que “praticar”, “treinar”, certamente vai ajudar. Mas aí é que está: se seu jogador de futebol acredita que só precisa jogar depois que bate o cartão de entrada, e pode parar quando bate o cartão de saída, ele não é um bom jogador. Então forçá-los a treinar não vai ajudar e por consequência, processos e metodologias definitivamente não vão ajudá-lo.

Com um bom programador é a mesma coisa. Você não precisa obrigá-lo a colocar seu código num repositório versionado: ele mesmo vai sentir falta disso e fazer algo a respeito. Você não precisa obrigá-lo a testar seu código, ele mesmo vai sentir falta disso e fazer algo a respeito. Você não precisa obrigá-lo a refatorar seu código, ele mesmo vai sentir que está ruim e vai fazer algo a respeito. Um bom profissional de prática não precisa que outros lhes digam o que fazer: ele sabe o que constitui um bom trabalho e irá performá-lo de acordo ou irá procurar o que lhe falta e treinar até se tornar proficiente nisso.

Um bom profissional de prática tem como realidade que ele tem que ser hoje melhor do que era ontem e continuar nesse ritmo todos os dias. Um profissional de procedimento sabe que seu trabalho de hoje é igual ao seu trabalho de ontem. Essa é a diferença: se sua empresa fabrica parafusos, ela segue procedimentos. Hoje existem pessoas montando esses parafusos, seguindo procedimentos, amanhã você provavelmente os substituirá por máquinas que farão o mesmo trabalho melhor e mais rápido. É o destino de todo profissional de procedimento.

Se sua empresa é da área de gastronomia, música, esporte, literatura, arte, software, etc você quer profissionais de prática. Caso não tenha, lembre-se: processos e metodologias não são procedimentos. Processos e metodologias não podem ser instalados como procedimentos. Processos e metodologias nunca vão transformar pessoas com mentalidade de procedimento em profissionais de prática. E sem profissionais de prática, seu resultado sempre será ruim.

Nós desenvolvemos software faz mais de 70 anos. Se a solução fosse tão simples assim, não acham que todo mundo já teria feito dessa forma décadas atrás com resultados continuamente, por décadas, de excelência? Não seja ingênuo achando que você encontrou o “elo perdido”: isso não existe.

A única coisa que podemos fazer, sempre, é tentar amanhã ser melhor do que hoje. Mas isso não se faz com reuniões, comitês, procedimentos, receitas mágicas, gurus ou palestras. Se faz com prática. Quer ser melhor em software? Pratique software. Agora, você tem uma boa equipe, bons profissionais que realmente se importam com a prática? Agora sim, refinar os processos e aplicar boas técnicas e táticas vai melhorar ainda mais. Mas a ordem é esta: bons profissionais, depois boas metodologias. Repetindo: boas metodologias não criam bons profissionais, mas bons profissionais com certeza saberão tirar vantagem de boas metodologias.

Estou abrindo alguns backups realmente antigos, trabalhos que eu tenho guardado desde 1995 até 2001, meia década de história. Se ver minha página no Facebook vai encontrar alguns exemplos que acabei de publicar. Em particular quando estava na faculdade comecei a escrever um livro (que nunca acabei nem nunca publiquei) sobre computação em geral e sobre os primórdios da Internet.

O texto a seguir está exatamente como deixei num arquivo Word, em 3 de Agosto de 1996, 9:52AM, entitulado "CAP12.DOC". Vejam como eu via a internet 17 anos atrás.

Vendas pela Internet

Forewords

A verdadeira Guerra Fria, nos anos 60, não estava sendo travada em campo, com soldados e aviões, e sim nos laboratórios de pesquisa, financiados pelo governo e universidades já estavam equipados com os melhores recursos computacionais disponíveis. Achava-se que a habilidade de criar e manter vantagens tecnológicas sobre o adversário determinaria o vencedor do conflito.

A idéia de conectar esses centros, objetivando a troca de informações começou a ser desenvolvida. Porém, foi atribuído um fator determinante na escolha da tecnologia de rede que viria a viabilizar a conexão dos centros estratégicos: a informação deveria continuar a fluir, mesmo sob as piores condições, tal como um ataque nuclear.

Foi delegada à ARPA ( Advanced Research Projects Agency ) e ao DoD ( Departament of Defense ) a responsabilidade de desenvolverem a melhor alternativa para a integração dos centros de informação.

Alguns anos depois, a ARPA mudaria de nome para DARPA ( Defense Advanced Research Projects Agency ) iniciando um plano denominado Internetting Project, para investigar as formas possíveis de conexão entre redes de pacotes comutados. Como resultado desse projeto e dos estudos do INWG ( InterNetwork Working Group ), foram desenvolvidos e apresentados os dois protocolos básicos da Internet. Em 1974, Vinton Cerf e Robert Kahn apresentaram o IP ( Internet Protocol ) e o TCP ( Transmission Control Protocol ). Estes dois protocolos especificavam a forma pela qual as mensagens ( arquivos ou comandos ) seriam transferidos entre os computadores na Internet.

Números

Para entender a importância da Internet em todos os sentidos : sociais, políticos e financeiros, é preciso ver quem navega pela Internet. Vamos nos basear nas pesquisas de John Quarterman, um provedor de acesso, consultor e publisher de Austin, Texas, que pesquisa a composição da população da Internet na sua Internet Demographic Survey.

Uma das coisas que Quarterman tem feito é definir várias Internets de acordo com os tipos de aplicações que rodam nos servidores e as atividades dos usuários. O "núcleo da Internet" é constituído por computadores que oferecem serviços interativos como FTP, Telnet ou aplicações WWW. A "Internet de consumo" inclui pessoas que usam os serviços interativos oferecidos pelo núcleo - por exemplo, usuários que navegam no World Wide Web. O total do ciberespaço, que rotula como a "matriz", são todos os usuários que trocam e-mail com outros usuários. Essas categorias se encaixam uma na outra: a matriz inclui a Internet de consumo, que inclui a Internet Núcleo.

Um dos problemas que Quarterman tem que enfrentar envolve hosts virtuais. Um provedor de acesso à Internet tem que registrar os nomes de domínio para os usuários, mas os endereços, na verdade, residem nas máquinas do provedor. Isso pode levar a equívocos, fazendo parecer que as pessoas têm máquinas conectadas à Internet. Esse grupo pertence à categoria de Internet de consumo, e todo o correio que Quarterman envia para os postmasters em vários endereços é no final englobado por um host.

"O problema dos hosts virtuais cresceu enormemente no ano passado ( 1995 )", disse Quarterman. "Você pode acessar um site Web, realmente existe informação lá, e realmente corresponde à organização. Está de fato em um computador na Internet, mas pode ser o mesmo computador de outros domínios."

A pesquisa mais recente, para 1995, foi publicada em janeiro de 1996. Do universo de 45.091 domínios, 2,9% ( 1.293 ) responderam. No mundo da estatística, mais de 1.000 respostas é um número grande de dados e essas respostas representam organizações inteiras, e não usuários apenas. Nessa pesquisa, Quarterman estima que havia 16,9 milhões de usuários da Internet nuclear ( mais do que o dobro do ano passado ) e 26,4 milhões de usuários da Internet de consumo ( novamente o dobro ); 39 milhões de usuários ( um aumento de 50% ) já dispunham de e-mail. Quarterman atribui o aumento aos usuários de Internet nas redes de consumo ( America Online, Compuserve, Prodigy, e outras ).

Na pesquisa de 1995, Quarterman contou 45 mil máquinas conectadas à Internet. O número real de domínios registrados excedeu este número porque nem todos os domínios registrados são usados e alguns são domínios em outras redes, como a UUCP, onde você pode enviar correio, mas não pode usar serviços Internet interativos.

__O Web é quente, mas o FTP ainda supera a navegação. Quarterman também percebe que o uso do sistema operacional Windows está caindo e que os Macintoshes ( apesar do uso do Internet Protocol e não do MacOS ) e as máquinas Unix estão aumentando sua fatia no controle de domínios.

Os resultados são anunciados e veiculados no site Web da MIDS( que publica as revistas mensais Matrix News e Matrix Maps Quarterly, ambas em papel e on-line, e vende mapas e outras informações sobre hosts Internet, sobre usuários e outros dados demográficos ). "O que disponibilizamos aos que responderam aos questionários, e à Internet como um todo há quase um mês, é um resultado das respostas para cada questão. Também conseguimos traçar níveis de detalhes entre as respostas individuais ( que nunca são reveladas ) e os resumos. É com isso que conseguimos alguma renda".

Falando sobre o Brasil, o secretário de Política de Informática e Automação do Ministério da Ciência e Tecnologia, Ivan Moura Campos, diz que o Brasil ostenta um dos crescimentos mais espantosos rumo ao cyberspace - estamos crescendo 50% ao mês. Com isso chegamos à uma população de 260 mil cibernautas no início do mês de maio deste ano. Para se ter uma idéia, se a taxa de adesão continuasse nessa velocidade, até o final do ano o número de cibernautas brasileiros seria de 16 milhões. Mas as previsões do Secretário, mais realistas, estimam um milhão de usuários na virada do ano.

Publicidade

Depois da revolução dos microcomputadores na década de 80 e da disseminação da informática com "um micro em cada mesa e em cada casa", tivemos uma das maiores evoluções já vistas na história onde a humanidade evoluiu em 10 anos o que não conseguiu evoluir desde a Idade Média, entrando na Era da Informação.

Com os microcomputadores e a Internet as fronteiras físicas foram apagadas, num lugar onde "países" e "oceanos" não têm mais significado e onde as distâncias físicas não fazem mais sentido. A virtualização evoluiu a tal ponto que uma pessoa que mora num país como o Brasil já pode conhecer a fazer amizade com pessoas de qualquer parte do mundo, como da Austrália, por exemplo. Ferramentas como o CoolTalk da Netscape Inc. que substitui o telefone ou o TimedVideo Grabber que possibilita a transmissão de imagens em real-time com o uso de câmera, torna possível pessoas se conhecerem sem nunca precisarem realmente se encontrarem em "carne-e-osso".

E falando em evolução, depois de 500 anos de reinado absoluto das mídias impressas como difusor de informação, esta está sendo rapidamente sendo substituído por publicações digitais na World Wide Web, a parte da Internet que mais chama a atenção atualmente.

Com trabalhos pioreiros como a Enciclopédia Britannica, que foi absolutamente abalada depois que as enciclopédias impressas caíram em total desuso depois do surgimento das enciclopédias digitais como a Encarta da Microsoft, e também de serviços de procura do tipo "páginas amarelas" como as oferecidas por sites como o Yahoo! ou Lycos, tornaram a Internet também o maior repositórios de dados já feito, o melhor lugar para pesquisas que se pode encontrar.

Revistas mundiamente famosas como a PC Magazine da Ziff Davis Publishing ou a Playboy já tem suas publicações exibidas e atualizadas periodicamente na WWW.

A World Wide Web ou WWW foi concebida para dar uma "cara" à Internet, possibilitando a edição de sites gráficos ao contrário da até então interface baseada em texto ( algo semelhante à passagem do DOS para o Windows, por exemplo ). Uma nova linguagem de script foi criada, a HTML ( Hyper Text Mark-Up Language ) e um protocolo específico, a HTTP ( Hyper Text Transfer Protocol ). E para a navegação por essas pages foram criados os browsers, programas feitos para interpretar o HTML. Logo de início, duas se sobressaíram, a Netscape com seu Netscape Navigator e a SpyGlass com seu Mosaic. A Netscape se tornou mais difundida e a SpyGlass vendeu os direitos do Mosaic para a Microsoft que hoje distribui o maior concorrente da Netscape, o Internet Explorer, numa das maiores campanhas de distribuição de softwares já vistas.

A possibilidade de se editar praticamente tudo que existe em mídias impressas, rapidamente chamou a atenção do mundo para a Internet. Novos conceitos começaram a surgir como o de publishing on-line. Um dos exemplos mais recentes é sobre as Olimpíadas de Atlanta onde o trabalho de informática ficou a cargo da IBM que montou um esquema grandioso de máquinas e redes e distribuição de informação via Internet que pode ser conferido na homepage das Olimpíadas, onde os dados são atualizados tão logo são obtidos, assim, ao fim de cada jogo, a homepage pode ser atualizada e o mundo todo tem acesso a elas, não precisando esperar até o dia seguinte para lê-los nos jornais.

Falando em jornais, estes também não ficam atrás, colocando na WWW, muito das suas publicações diárias como o The Gate um produto baseado em Internet de dois jornais da Costa Oeste dos Estados Unidos, o San Francisco Chronicle e o San Francisco Examiner com direito a áreas de conferência com fóruns de discussão como Comunidade, Mídia, Esportes, Filmes, etc.

A Agência Estado, que publica jornais famosos como o Estado de São Paulo, também já distribui seu jornal via internet com as principais chamadas do dia e informações diversas, incluindo seu classificados e, num período de olimpíadas, com áreas especiais para os esportes em Atlanta.

Outro conceito que se tornou famoso com a Internet é a dos serviços on-line como as gigantes Compuserve e America On-line que atendem a pessoas do mundo todo e tem aliados como Netscape e Microsoft. Esse tipo de organização é baseada em "serviços" que incluem fóruns de discussão; bibliotecas com informações atualizadas; revistas, jornais e outros periódicos; lojas virtuais que vendem desde CDs a roupas; dicas de lazer e negócios; e também serviços comuns à Internet como e-mail e WWW.

No Brasil também começou a se disseminar tais tipos de serviço, com destaque para a Folha de São Paulo e o Grupo Abril que lançaram, respectivamente, o Universo Online e o Brasil Online. Tais serviços brasileiros ainda são experimentais e de graça, sem projeções quanto a custos. A título de ilustração, o The New York Times cobra US$ 30,00 por mês e a America Online cobra US$ 9,95 por 5 horas ou US$ 19,95 por 20 horas.

Tais serviços tem faturamentos muito altos principalmente por causa da empolgação atual do mundo em torno da virtualização de serviços e pelo aluguel do espaço digital para empresas que se interessam em colocar "out-doors virtuais" ou mesmo acrescentar outros serviços como lojas digitais nas páginas principais, visto que o número de pessoas que trafegam pelas linhas digitais todos os dias é muito grande. Para ver isso basta entrar na página do Brasil Online, por exemplo, e se deparar com chamadas de publicidade de empresas como a Sun ou a Credicard. Essas chamadas são links que levam às homepages das respectivas empresas.

E falando em propaganda, alguém deve estar confeccionando tais pages e anúncios. Essas empresas estão se especializando em desenhar páginas específicas e criativas para um tipo de mídia que sai das limitações do papel e possibilita coisas como Hypertext ( palavras dentro de um texto que levam a outras páginas ), Marquees ( frases que se movimentam na linha ), músicas ( através de arquivos WAVE ou da nova tecnologia Real Audio ), animações ( via imagens GIF animadas ou então utilizando recursos da linguagem Java ) ou ainda ambientes totalmente tridimensionais ( utilizando a tecnologia VRML - Virtual Reallity Markup Language ) e muito mais. Nesse filão mercadológico estão empresas como a Vivid Studio que tem como clientes as gigantes Silicon Graphics e Microsoft ou a Razorfish que desenha para a Time-Warner e a Pepsi.

Comércio

O principal ponto de atrito quando se fala em comércio digital é a segurança. O protocolo TCP/IP é o ponto de partida para a Internet, concebido como um protocolo universal mas que peca no aspecto segurança, onde, ao contrário dos seus irmãos IPX/SPX ou NetBIOS por exemplo, não possui transmissão de dados encriptados. Uma vez sendo o protocolo padrão de transmissão de dados, teria sido conveniente estipular um protocolo também padrão de segurança de dados. Uma vez que este não existe, o impasse fica em torno de empresas que brigam para desenvolver o padrão do que causaria a arrancada inicial rumo ao fim do dinheiro impresso e o desenvolvimento do crédito digital.

Um dos mais antigos é o cybercash com mais ou menos um ano de idade. Por enquanto, a empresa só trabalha com serviços de cartões de crédito, mas em breve promete oferecer serviços de pagamentos monetários. Atualmente, com um browser ligado à rede pode-se comprar com segurança em shoppings virtuais. Através do protocolo SIPS ( Secure Internet Payment Service ), segundo a empresa, é tão fácil quanto apontar e clickar. Nesse tipo de transação, compra-se quantos cybercashes quantos desejados e debita-se no cartão de crédito.

O padrão do Cybercash suporta todos os tipos de cartão de crédito. Usa os padrões de encriptação 768-bit RSA e a 56-bit DES. Todas as transações são autenticadas com as assinaturas MDS e 768-bit RSA. A primeira providência para quem se interessou é baixar o programa gratuito que a empresa oferece. O servidor da Cybercash está ligado às redes privadas de vários bancos. Os serviços iniciais da empresa incluem cartões de crédito e de débito e um sistema de pagamentos eletrônicos. Pelos serviços, os usuários pagam uma quantia módica, comparável ao valor de um selo. Para os fornecedores, o sistema representa uma economia nas taxas cobradas pelas transações de cartões de crédito, em função do risco ainda existente nas transações por telefone e e-mail.

Nesse tipo de desenvolvimento ainda encontram-se empresas como a Digicash, com os serviços centrados no site da First Digital Bank, utilizando sistema de e-cash ( dinheiro real convertido em dinheiro virtual em contas virtuais ). A Visa ( que também já é parceira da Sony - no desenvolvimento de um ambiente multifacetado de entretenimento, informações e transações comerciais ) e a Microsoft possuem o STT ( Secure Transaction Technology ), o padrão dessas duas poderosas quer se tornar uma versão eletrônica do cartão de crédito. A Mastercard está em parceria com a IBM, Netscape, GTE e Cybercash, com o padrão SEPP ( Secure Eletronic Payment Protocol ). Trata-se de um protocolo aberto para transações on-line seguras.

A Netscape desenvolve o protocolo aberto de segurança SSL ( Secure Sockets Layer ) e contribui no desenvolvimento da interface SSL do W3C( World Wide Web Consortium ), consórcio europeu que se dedica a criar um padrão para o Mercado Comum Europeu. Desse consórcio fazem parte cerca de 50 companhias de todo o mundo. A empresa irá licenciar a tecnologia SSL a seus parceiros para uso comercial. A lista de parceiros inclui MCI, Bank of America, Mastercard, First Data Corporation, Novell, Digital e Silicon Graphics.

Praticamente todas as empresas do setor financeiro vem investindo muito no desenvolvimento de uma plataforma segura e confiável suficiente para transações financeiras de todos os níveis de importância. Hackers à parte, os negócios via Internet não diferem muito dos efetuados fora dela. Ou seja, a melhor forma de estar livre de problemas é confiar na credibilidade das empresas sérias. Dificilmente alguém vai querer comprometer seu bom nome deixando de entregar a mercadoria no prazo ou "negociando" o número do cartão de crédito.

No Brasil, o Mappin foi a primeira grande empresa a entrar no ramo das vendas por computador. Também é possível escolher doces e tortas na Confeitaria Brunella de São Paulo ou fazer reservas ao Marcellu's Bar do Rio de Janeiro. O consumidor escolhe o doce ou torta que quer comprar através das fotos e descrições na homepage da Brunella, depois a loja telefona para confirmar o pedido e encaminha a mercadoria. No caso do Marcellu's Bar, a reserva é feita por e-mail.

Se há alguém de mudança para os Estados Unidos ou precisando simplesmente comprar preços, poderá consultar o For Sail By Owner Connection. Trata-se de umsite especializado em vendas de casas, com fotos e especificações. Se na verdade você precisa vender a sua casa, também poderá anunciar nesta page.

Pensando em viagens, a Cruisiné a primeira agência de turismo especializada em cruzeiros que atende exclusivamente pela Internet. Mas já existem muitos hotéis e agências na rede. Realmente há alternativas para todos os limites bancários: de castanhas do Ceará por menos de R$ 3,00 até uma casa na Flórida por US$ 329 mil. Hoje em dia é virtualmente possível se comprar de tudo na Internet.

Afterwords

Criado para fins militares, depois expandido para os meios acadêmicos e, finalmente, atingindo o público em geral, a Internet caminha em evolução acelerada cobrindo praticamente todos os setores da sociedade onde se constrói as bases do que pode ser considerado um mundo virtual.

Quando a Internet evoluir o suficiente, as novas tecnologias irão construir a esperada Information Super Highway onde, aí sim, se constituirá uma rede verdadeiramente mundial, utilizando-se não somente os computadores da forma como os conhecemos mas também qualquer equipamento eletrônico, como os set-top-boxes ( os substitutos dos video-cassetes e video-lasers ).

Nessa próxima geração, "passear" será vestir uma roupa de realidade virtual e visitar locais virtuais com amigos de outros continentes num encontro digital. E isso não se trata de delírios de ficção científica: tanto estamos perto disso que tais tecnologias são reais e já existem, tudo que resta é o tempo para torná-las acessíveis e operacionais a nível de distribuição em massa.

Vendas pela Internet

Forewords

A verdadeira Guerra Fria, nos anos 60, não estava sendo travada em campo, com soldados e aviões, e sim nos laboratórios de pesquisa, financiados pelo governo e universidades já estavam equipados com os melhores recursos computacionais disponíveis. Achava-se que a habilidade de criar e manter vantagens tecnológicas sobre o adversário determinaria o vencedor do conflito.

A idéia de conectar esses centros, objetivando a troca de informações começou a ser desenvolvida. Porém, foi atribuído um fator determinante na escolha da tecnologia de rede que viria a viabilizar a conexão dos centros estratégicos: a informação deveria continuar a fluir, mesmo sob as piores condições, tal como um ataque nuclear.

Foi delegada à ARPA ( Advanced Research Projects Agency ) e ao DoD ( Departament of Defense ) a responsabilidade de desenvolverem a melhor alternativa para a integração dos centros de informação.

Alguns anos depois, a ARPA mudaria de nome para DARPA ( Defense Advanced Research Projects Agency ) iniciando um plano denominado Internetting Project, para investigar as formas possíveis de conexão entre redes de pacotes comutados. Como resultado desse projeto e dos estudos do INWG ( InterNetwork Working Group ), foram desenvolvidos e apresentados os dois protocolos básicos da Internet. Em 1974, Vinton Cerf e Robert Kahn apresentaram o IP ( Internet Protocol ) e o TCP ( Transmission Control Protocol ). Estes dois protocolos especificavam a forma pela qual as mensagens ( arquivos ou comandos ) seriam transferidos entre os computadores na Internet.

Números

Para entender a importância da Internet em todos os sentidos : sociais, políticos e financeiros, é preciso ver quem navega pela Internet. Vamos nos basear nas pesquisas de John Quarterman, um provedor de acesso, consultor e publisher de Austin, Texas, que pesquisa a composição da população da Internet na sua Internet Demographic Survey.

Uma das coisas que Quarterman tem feito é definir várias Internets de acordo com os tipos de aplicações que rodam nos servidores e as atividades dos usuários. O "núcleo da Internet" é constituído por computadores que oferecem serviços interativos como FTP, Telnet ou aplicações WWW. A "Internet de consumo" inclui pessoas que usam os serviços interativos oferecidos pelo núcleo - por exemplo, usuários que navegam no World Wide Web. O total do ciberespaço, que rotula como a "matriz", são todos os usuários que trocam e-mail com outros usuários. Essas categorias se encaixam uma na outra: a matriz inclui a Internet de consumo, que inclui a Internet Núcleo.

Um dos problemas que Quarterman tem que enfrentar envolve hosts virtuais. Um provedor de acesso à Internet tem que registrar os nomes de domínio para os usuários, mas os endereços, na verdade, residem nas máquinas do provedor. Isso pode levar a equívocos, fazendo parecer que as pessoas têm máquinas conectadas à Internet. Esse grupo pertence à categoria de Internet de consumo, e todo o correio que Quarterman envia para os postmasters em vários endereços é no final englobado por um host.

"O problema dos hosts virtuais cresceu enormemente no ano passado ( 1995 )", disse Quarterman. "Você pode acessar um site Web, realmente existe informação lá, e realmente corresponde à organização. Está de fato em um computador na Internet, mas pode ser o mesmo computador de outros domínios."

A pesquisa mais recente, para 1995, foi publicada em janeiro de 1996. Do universo de 45.091 domínios, 2,9% ( 1.293 ) responderam. No mundo da estatística, mais de 1.000 respostas é um número grande de dados e essas respostas representam organizações inteiras, e não usuários apenas. Nessa pesquisa, Quarterman estima que havia 16,9 milhões de usuários da Internet nuclear ( mais do que o dobro do ano passado ) e 26,4 milhões de usuários da Internet de consumo ( novamente o dobro ); 39 milhões de usuários ( um aumento de 50% ) já dispunham de e-mail. Quarterman atribui o aumento aos usuários de Internet nas redes de consumo ( America Online, Compuserve, Prodigy, e outras ).

Na pesquisa de 1995, Quarterman contou 45 mil máquinas conectadas à Internet. O número real de domínios registrados excedeu este número porque nem todos os domínios registrados são usados e alguns são domínios em outras redes, como a UUCP, onde você pode enviar correio, mas não pode usar serviços Internet interativos.

__O Web é quente, mas o FTP ainda supera a navegação. Quarterman também percebe que o uso do sistema operacional Windows está caindo e que os Macintoshes ( apesar do uso do Internet Protocol e não do MacOS ) e as máquinas Unix estão aumentando sua fatia no controle de domínios.

Os resultados são anunciados e veiculados no site Web da MIDS ( que publica as revistas mensais Matrix News e Matrix Maps Quarterly, ambas em papel e on-line, e vende mapas e outras informações sobre hosts Internet, sobre usuários e outros dados demográficos ) em http://www.mids.org. "O que disponibilizamos aos que responderam aos questionários, e à Internet como um todo há quase um mês, é um resultado das respostas para cada questão. Também conseguimos traçar níveis de detalhes entre as respostas individuais ( que nunca são reveladas ) e os resumos. É com isso que conseguimos alguma renda".

Falando sobre o Brasil, o secretário de Política de Informática e Automação do Ministério da Ciência e Tecnologia, Ivan Moura Campos, diz que o Brasil ostenta um dos crescimentos mais espantosos rumo ao cyberspace - estamos crescendo 50% ao mês. Com isso chegamos à uma população de 260 mil cibernautas no início do mês de maio deste ano. Para se ter uma idéia, se a taxa de adesão continuasse nessa velocidade, até o final do ano o número de cibernautas brasileiros seria de 16 milhões. Mas as previsões do Secretário, mais realistas, estimam um milhão de usuários na virada do ano.

Publicidade

Depois da revolução dos microcomputadores na década de 80 e da disseminação da informática com "um micro em cada mesa e em cada casa", tivemos uma das maiores evoluções já vistas na história onde a humanidade evoluiu em 10 anos o que não conseguiu evoluir desde a Idade Média, entrando na Era da Informação.

Com os microcomputadores e a Internet as fronteiras físicas foram apagadas, num lugar onde "países" e "oceanos" não têm mais significado e onde as distâncias físicas não fazem mais sentido. A virtualização evoluiu a tal ponto que uma pessoa que mora num país como o Brasil já pode conhecer a fazer amizade com pessoas de qualquer parte do mundo, como da Austrália, por exemplo. Ferramentas como o CoolTalk da Netscape Inc. ( http://www.netscape.com ) que substitui o telefone ou o TimedVideo Grabber ( http://www.avernus.com/~allan ) que possibilita a transmissão de imagens em real-time com o uso de câmera, torna possível pessoas se conhecerem sem nunca precisarem realmente se encontrarem em "carne-e-osso".

E falando em evolução, depois de 500 anos de reinado absoluto das mídias impressas como difusor de informação, esta está sendo rapidamente sendo substituído por publicações digitais na World Wide Web, a parte da Internet que mais chama a atenção atualmente.

Com trabalhos pioreiros como a Enciclopédia Britannica ( http://www.eb.com ), que foi absolutamente abalada depois que as enciclopédias impressas caíram em total desuso depois do surgimento das enciclopédias digitais como a Encarta da Microsoft ( http://www.microsoft.com ), e também de serviços de procura do tipo "páginas amarelas" como as oferecidas por sites como o Yahoo! ( http://www.yahoo.com ) ou Lycos ( http://www.lycos.com ), tornaram a Internet também o maior repositórios de dados já feito, o melhor lugar para pesquisas que se pode encontrar.

Revistas mundiamente famosas como a PC Magazine ( http://www.pcmag.com ) da Ziff Davis Publishing ( http://www.ziff.com ) ou a Playboy ( http://www.playboy.com ) já tem suas publicações exibidas e atualizadas periodicamente na WWW.

A World Wide Web ou WWW foi concebida para dar uma "cara" à Internet, possibilitando a edição de sites gráficos ao contrário da até então interface baseada em texto ( algo semelhante à passagem do DOS para o Windows, por exemplo ). Uma nova linguagem de script foi criada, a HTML ( Hyper Text Mark-Up Language ) e um protocolo específico, a HTTP ( Hyper Text Transfer Protocol ). E para a navegação por essas pages foram criados os browsers, programas feitos para interpretar o HTML. Logo de início, duas se sobressaíram, a Netscape com seu Netscape Navigator e a SpyGlass com seu Mosaic. A Netscape se tornou mais difundida e a SpyGlass vendeu os direitos do Mosaic para a Microsoft que hoje distribui o maior concorrente da Netscape, o Internet Explorer, numa das maiores campanhas de distribuição de softwares já vistas.

A possibilidade de se editar praticamente tudo que existe em mídias impressas, rapidamente chamou a atenção do mundo para a Internet. Novos conceitos começaram a surgir como o de publishing on-line. Um dos exemplos mais recentes é sobre as Olimpíadas de Atlanta onde o trabalho de informática ficou a cargo da IBM ( http://www.ibm.com ) que montou um esquema grandioso de máquinas e redes e distribuição de informação via Internet que pode ser conferido na homepage das Olimpíadas ( http://www.atlanta.olympic.org ), onde os dados são atualizados tão logo são obtidos, assim, ao fim de cada jogo, a homepage pode ser atualizada e o mundo todo tem acesso a elas, não precisando esperar até o dia seguinte para lê-los nos jornais.

Falando em jornais, estes também não ficam atrás, colocando na WWW, muito das suas publicações diárias como o The Gate ( http://sfgate.com ) um produto baseado em Internet de dois jornais da Costa Oeste dos Estados Unidos, o San Francisco Chronicle e o San Francisco Examiner com direito a áreas de conferência com fóruns de discussão como Comunidade, Mídia, Esportes, Filmes, etc.

A Agência Estado, que publica jornais famosos como o Estado de São Paulo, também já distribui seu jornal via internet ( http://www.agestado.com.br ) com as principais chamadas do dia e informações diversas, incluindo seu classificados e, num período de olimpíadas, com áreas especiais para os esportes em Atlanta.

Outro conceito que se tornou famoso com a Internet é a dos serviços on-line como as gigantes Compuserve e America On-line que atendem a pessoas do mundo todo e tem aliados como Netscape e Microsoft. Esse tipo de organização é baseada em "serviços" que incluem fóruns de discussão; bibliotecas com informações atualizadas; revistas, jornais e outros periódicos; lojas virtuais que vendem desde CDs a roupas; dicas de lazer e negócios; e também serviços comuns à Internet como e-mail e WWW.

No Brasil também começou a se disseminar tais tipos de serviço, com destaque para a Folha de São Paulo e o Grupo Abril que lançaram, respectivamente, o Universo Online e o Brasil Online. Tais serviços brasileiros ainda são experimentais e de graça, sem projeções quanto a custos. A título de ilustração, o The New York Times cobra US$ 30,00 por mês e a America Online cobra US$ 9,95 por 5 horas ou US$ 19,95 por 20 horas.

Tais serviços tem faturamentos muito altos principalmente por causa da empolgação atual do mundo em torno da virtualização de serviços e pelo aluguel do espaço digital para empresas que se interessam em colocar "out-doors virtuais" ou mesmo acrescentar outros serviços como lojas digitais nas páginas principais, visto que o número de pessoas que trafegam pelas linhas digitais todos os dias é muito grande. Para ver isso basta entrar na página do Brasil Online, por exemplo, e se deparar com chamadas de publicidade de empresas como a Sun ou a Credicard. Essas chamadas são links que levam às homepages das respectivas empresas.

E falando em propaganda, alguém deve estar confeccionando tais pages e anúncios. Essas empresas estão se especializando em desenhar páginas específicas e criativas para um tipo de mídia que sai das limitações do papel e possibilita coisas como Hypertext ( palavras dentro de um texto que levam a outras páginas ), Marquees ( frases que se movimentam na linha ), músicas ( através de arquivos WAVE ou da nova tecnologia Real Audio ), animações ( via imagens GIF animadas ou então utilizando recursos da linguagem Java ) ou ainda ambientes totalmente tridimensionais ( utilizando a tecnologia VRML - Virtual Reallity Markup Language ) e muito mais. Nesse filão mercadológico estão empresas como a Vivid Studio ( http://www.vivid.com ) que tem como clientes as gigantes Silicon Graphics e Microsoft ou a Razorfish ( http://www.razorfish.com ) que desenha para a Time-Warner e a Pepsi.

Comércio

O principal ponto de atrito quando se fala em comércio digital é a segurança. O protocolo TCP/IP é o ponto de partida para a Internet, concebido como um protocolo universal mas que peca no aspecto segurança, onde, ao contrário dos seus irmãos IPX/SPX ou NetBIOS por exemplo, não possui transmissão de dados encriptados. Uma vez sendo o protocolo padrão de transmissão de dados, teria sido conveniente estipular um protocolo também padrão de segurança de dados. Uma vez que este não existe, o impasse fica em torno de empresas que brigam para desenvolver o padrão do que causaria a arrancada inicial rumo ao fim do dinheiro impresso e o desenvolvimento do crédito digital.

Um dos mais antigos é o cybercash ( http://www.cybercash.com ) com mais ou menos um ano de idade. Por enquanto, a empresa só trabalha com serviços de cartões de crédito, mas em breve promete oferecer serviços de pagamentos monetários. Atualmente, com um browser ligado à rede pode-se comprar com segurança em shoppings virtuais. Através do protocolo SIPS ( Secure Internet Payment Service ), segundo a empresa, é tão fácil quanto apontar e clickar. Nesse tipo de transação, compra-se quantos cybercashes quantos desejados e debita-se no cartão de crédito.

O padrão do Cybercash suporta todos os tipos de cartão de crédito. Usa os padrões de encriptação 768-bit RSA e a 56-bit DES. Todas as transações são autenticadas com as assinaturas MDS e 768-bit RSA. A primeira providência para quem se interessou é baixar o programa gratuito que a empresa oferece. O servidor da Cybercash está ligado às redes privadas de vários bancos. Os serviços iniciais da empresa incluem cartões de crédito e de débito e um sistema de pagamentos eletrônicos. Pelos serviços, os usuários pagam uma quantia módica, comparável ao valor de um selo. Para os fornecedores, o sistema representa uma economia nas taxas cobradas pelas transações de cartões de crédito, em função do risco ainda existente nas transações por telefone e e-mail.

Nesse tipo de desenvolvimento ainda encontram-se empresas como a Digicash ( http://www.digicash.com ), com os serviços centrados no site da First Digital Bank ( http://bank.digicash.com ), utilizando sistema de e-cash ( dinheiro real convertido em dinheiro virtual em contas virtuais ). A Visa ( http://www.visa.com ) ( que também já é parceira da Sony - http://www.sony.com - no desenvolvimento de um ambiente multifacetado de entretenimento, informações e transações comerciais ) e a Microsoft possuem o STT ( Secure Transaction Technology ), o padrão dessas duas poderosas quer se tornar uma versão eletrônica do cartão de crédito. A Mastercard ( http://www.mastercard.com ) está em parceria com a IBM, Netscape, GTE e Cybercash, com o padrão SEPP ( Secure Eletronic Payment Protocol ). Trata-se de um protocolo aberto para transações on-line seguras.

A Netscape desenvolve o protocolo aberto de segurança SSL ( Secure Sockets Layer ) e contribui no desenvolvimento da interface SSL do W3C ( World Wide Web Consortium ), consórcio europeu que se dedica a criar um padrão para o Mercado Comum Europeu - http://www.w3.org ). Desse consórcio fazem parte cerca de 50 companhias de todo o mundo. A empresa irá licenciar a tecnologia SSL a seus parceiros para uso comercial. A lista de parceiros inclui MCI ( http://www.mci.com ), Bank of America ( http://www.bankamerica.com ), Mastercard, First Data Corporation, Novell ( http://www.novell.com ), Digital ( http://www.dec.com ) e Silicon Graphics.

Praticamente todas as empresas do setor financeiro vem investindo muito no desenvolvimento de uma plataforma segura e confiável suficiente para transações financeiras de todos os níveis de importância. Hackers à parte, os negócios via Internet não diferem muito dos efetuados fora dela. Ou seja, a melhor forma de estar livre de problemas é confiar na credibilidade das empresas sérias. Dificilmente alguém vai querer comprometer seu bom nome deixando de entregar a mercadoria no prazo ou "negociando" o número do cartão de crédito.

No Brasil, o Mappin ( http://www.mappin.com.br ) foi a primeira grande empresa a entrar no ramo das vendas por computador. Também é possível escolher doces e tortas na Confeitaria Brunella ( http://www.ams.com/brunella ) de São Paulo ou fazer reservas ao Marcellu's Bar ( http://www.marcellus-bar.com.br ) do Rio de Janeiro. O consumidor escolhe o doce ou torta que quer comprar através das fotos e descrições na homepage da Brunella, depois a loja telefona para confirmar o pedido e encaminha a mercadoria. No caso do Marcellu's Bar, a reserva é feita por e-mail.

Se há alguém de mudança para os Estados Unidos ou precisando simplesmente comprar preços, poderá consultar o For Sail By Owner Connection. Trata-se de umsite especializado em vendas de casas, com fotos e especificações. Se na verdade você precisa vender a sua casa, também poderá anunciar nesta page : http://www.cracker.com/byowner.

Pensando em viagens, a Cruisin ( http://www.cracker.com/cruisin ) é a primeira agência de turismo especializada em cruzeiros que atende exclusivamente pela Internet. Mas já existem muitos hotéis e agências na rede. Realmente há alternativas para todos os limites bancários: de castanhas do Ceará por menos de R$ 3,00 até uma casa na Flórida por US$ 329 mil. Hoje em dia é virtualmente possível se comprar de tudo na Internet.

Afterwords

Criado para fins militares, depois expandido para os meios acadêmicos e, finalmente, atingindo o público em geral, a Internet caminha em evolução acelerada cobrindo praticamente todos os setores da sociedade onde se constrói as bases do que pode ser considerado um mundo virtual.

Quando a Internet evoluir o suficiente, as novas tecnologias irão construir a esperada Information Super Highway onde, aí sim, se constituirá uma rede verdadeiramente mundial, utilizando-se não somente os computadores da forma como os conhecemos mas também qualquer equipamento eletrônico, como os set-top-boxes ( os substitutos dos video-cassetes e video-lasers ).

Nessa próxima geração, "passear" será vestir uma roupa de realidade virtual e visitar locais virtuais com amigos de outros continentes num encontro digital. E isso não se trata de delírios de ficção científica: tanto estamos perto disso que tais tecnologias são reais e já existem, tudo que resta é o tempo para torná-las acessíveis e operacionais a nível de distribuição em massa.

Original de 24/11/2010: Gestão 2.0

Se você acompanha as discussões sobre metodologias de gerenciamento de projetos de software Ágeis, já deve ter ouvido falar sobre o hype a respeito de Kanban. Eu já conversei com algumas pessoas da área explicando que eu não discordo do conceito em si, mas que acho confuso chamá-lo de “Kanban”.

Para os que não entenderam, Kanban é uma técnica derivada do processo “Lean” que é uma generalização do Sistema Toyota de Produção, o famoso processo industrial criado pela Toyota décadas atrás e que ajudou a revolucionar a Toyota. Criar hype sobre a técnica Kanban não é novidade e a área de Engenharia de Produção já passou por isso antes.

Um dos problemas de se usar o nome “Kanban” é que ela se associa com “Lean” e isso leva a toda uma discussão sobre Agile-Lean que eu particularmente desgosto, especialmente porque o Kanban aplicado a software não tem muito a ver com o Kanban de produção e, portanto, também não tem a ver com Lean.

Para realmente entender o Sistema Toyota de Produção é importante ir às raízes, estudar sobre Taiichi Ohno, W. Edward Deming. Também recomendo a leitura do livro “O Sistema Toyota de Produção do Ponto de Vista da Engenharia de Produção“, escrita por Shigeo Shingo, que atuou como consultor externo e ensinou cursos de engenharia industrial desde 1955. Desse livro, quero parafrasear um trecho do Prefácio da Edição Japonesa:

O maior problema encontrado enquanto estudava o Sistema Toyota de Produção do ponto de vista da Engenharia de Produção é o fato de ser frequentemente considerado como sinônimo de sistema Kanban. O sr. Ohno escreve:

Sistema Toyota de Produção é um sistema de produção. O método Kanban é uma técnica para sua implementação.

Muitas publicações são confusas nessa questão e oferecem uma explicação do sistema, afirmando que o Kanban é a essência do Sistema Toyota de Produção. Uma vez mais: O sistema Toyota de produção é um sistema de produção e o método kanban é meramente um meio de controlar o sistema.

Análises superficiais do Sistema Toyota de Produção dão especial atenção ao método Kanban devido às suas características únicas. Consequentemente, muitas pessoas concluem que o Sistema Toyota de Produção é equivalente ao método Kanban. No cerne desse método tem-se que:

Ele é aplicado somente à produção de natureza repetitiva. Os níveis totais de estoque são controlados por um número de cartões Kanban. É um sistema administrativo simplificado

Um método Kanban deve ser adotado somente depois que o sistema de produção em si tenha sido racionalizado. Esse é o motivo pelo qual esse livro insiste repetidamente no fato de que o Sistema Toyota de Produção e o método Toyota são entidades separadas.

(…)

Devo acrescentar que 90% do excelente desempenho gerencial da Toyota foi atribuído ao Sistema Toyota de Produção em si, e apenas 10% ao método Kanban – uma clara demonstração da maior importância do Sistema Toyota de Produção.

Além disso o mais importante é entender que o método Kanban foi criado para engenharia de produção em ambientes industriais. Como própria definição, Shigeo resume:

Os sistemas Kanban são extremamente eficientes na simplificação do trabalho administrativo e em dar autonomia ao chão-de-fábrica, o que possibilita responder a mudanças com maior flexibilidade. Uma das vantagens dos sistemas Kanban é que, ao dar instruções no processo final, eles permitem que a informação seja transmitda de forma organizada e rápida.

Os sistemas Kanban podem ser aplicados somente em fábricas com produção repetitiva. A natureza repetitiva da produção pode não exercer muita influência, contudo, se houver instabilidades temporais ou quantitativas.

Os sistemas Kanban não são aplicáveis em empresas com produção sob projeto não repetitivo, onde os pedidos são infrequentes e imprevisíveis.

Finalmente, uma das essências do Sistema Toyota de Produção é minimização dos desperdícios e operação com estoque mínimo ou, idealmente, zero, de acordo com a idéia de just-in-time (ou melhor definido como “just-on-time”). Porém, no mundo físico de produção, é impossível operar com estoque zero. Para isso existem os Kanbans cujas quantidades são definidas pela quantidade de material dividido pela capacidade dos paletes. O objetivo dos Kanbans é que eles diminuam de quantidade, se aproximando sempre do nível ideal de estoque zero. Portanto, uma definição “filosófica” minha é que o objetivo do Kanban é acabar com o Kanban.

Se for para pegar aleatoriamente um dos aspectos do Sistema Toyota de Produção, que seja entender um dos mais importantes, o conceito de melhoria contínua, ou “Kaizen“. No mundo ocidental, quem já estudou produção ou conceitos de qualidade total com certeza já esbarrou com isso, na forma da idéia do ciclo PDCA (Plan, Do, Check, Act) de Deming.

Aliás, já notaram que toda “metodologia” é muito parecida em seu processo? Se olharem bem vão ver que todos são basicamente derivados do ciclo PDCA de Deming. Apenas variações com nomes diferentes da mesma idéia básica de melhoria contínua.

Associar histórias de software com “estoque”, um backlog contínuo como “kanban” não torna seu processo necessariamente Ágil e muito menos Lean se embutido a isso não existir no mínimo o entendimento de melhoria contínua, Kaizen. É muito fácil fazer um processo desses virar rotina e procedimento e, com isso, perder toda a essência, assim como já está acontecendo com implementações de Scrum.

Se quiserem aprender, recomendo que leiam ao menos os seguintes livros:

• The Toyota Way– Jeffrey K. Liker
• The Machine that Changed the World– James P. Womack
• A Study of the Toyota Production System– Shigeo Shingo
• Theory of Constraints– Eliyahu M. Goldratt

Original de 10/10/2010: Gestão 2.0

Por incrível que possa parecer, não existe uma boa definição, simples, clara e curta que pode definir o que é ser um “gerente”. Gerente não é uma profissão. Você não pode “aprender” a ser um gerente numa escola ou curso. A única forma de aprender é tentando, errando, melhorando, continuamente e indefinidamente.

Uma das melhores definições que encontrei é de ninguém menos que o professor Henry Mintzberg, em seu recente livro “Managing”, publicado em 2009. Uma leitura madura e leve.

Recomendo a leitura desse livro. Se você é um gerente iniciante ou quer ser um gerente, talvez este livro lhe dê alguma visão do que vai enfrentar à frente. Se você já é um gerente, vai ficar surpreso pois muitos livros teóricos pintam cenários que você nunca viu na prática – fazendo-o se questionar se você está fazendo a coisa certa ou não – e este livro talvez defina melhor os problemas reais que você enfrenta.

Quero trazer alguns trechos da primeira metade do livro.

Gerenciamento Não é uma Profissão

Depois de anos procurando por Santos Graal, é hora de reconhecer que gerenciar não é nem ciência nem profissão; é uma prática, aprendida primariamente através de experiência, e enraizada em contexto.

Certamente não é uma Ciência. Ciência tem a ver com o desenvolvimento de conhecimento sistemático através de pesquisa. Isso nem de longe é o propósito de gerenciamento, que tem a ver com ajudar a conseguir realizar coisas em organizações. Gerenciamento não é nem mesmo uma ciência aplicada, porque isso ainda é ciência. Gerenciamento certamente aplica ciência: gerentes precisam usar todo o conhecimento que conseguir. E eles certamente usam análise, enraizada no método científico (que significa aqui mais prova científica do que descoberta científica).

Mas gerenciamento efetivo é mais dependente na arte e é especialmente enraizada em ofício. Arte produz o “insight” e “visão”, baseado em intuição (Peter Druker escreveu em 1954 que “os dias do gerente ‘intuitivo’ estão contados”. Meio século depois, ainda estamos contando.) E ofício tem a ver com aprendizado a partir de experiência – trabalhando nas coisas à medida que o gerente avança.

Portanto, vale repetir o que Mintzberg costuma dizer: é impossível formar gerentes na escola. Não é um “talvez”, é uma certeza. Na escola você pode aprender técnicas de contabilidade, de marketing, conhecimento técnico repetitível. Nada disso gera um gerente e muito menos um líder. Se uma escola, um curso de MBA diz “Formamos Líderes”, isso é mentira. Essas escolas formam técnicos; técnicos que vão trabalhar em atividades técnicas até crescerem para começar a acumular responsabilidades e, talvez, um dia conseguirem realmente gerenciar alguma coisa.

Gerenciamento é uma Prática

Coloque junto uma boa porção de ofício com o toque correto de arte junto com algum uso de ciência e você acaba com um trabalho que é, acima de tudo, uma prática. Não existe “uma melhor maneira” de gerenciar; tudo depende da situação.

Nem mesmo é uma Profissão. Já foi apontado que engenharia também não é uma ciência ou uma ciência aplicada tanto quanto uma prática em seu próprio direito. Mas engenharia aplica uma boa porção de ciência, codificada e certificada quanto à sua eficiência. E portanto ela pode ser chamada de profissão, que significa que ela pode ser ensinada antes da prática, fora de contexto. De certa maneira, uma ponte é uma ponte, ou pelo menos ferro é ferro, mesmo que seu uso tenha que ser adaptado para a situação do momento. O mesmo pode ser tido sobre a medicina. Mas não sobre gerenciamento:

Muitas capacidades médicas de diagnóstico, inferência e tratamento … assumem que uma doença pode ser decomposta em problemas separados que não diferem muito entre pacientes e podem ser tratados por remédios razoavelmente padrões … Em contraste, muito do trabalho gerencial envolve lidar com problemas que são muito interdependentes com outras partes da organização, são específicas a esta firma, mercado e indústria em particular e não facilmente reduzíveis para uma síndrome padrão geral que pode ser tratada por técnicas específicas.

Gerenciar é um trabalho de negociação, de trocas, de ceder, de conquistar. Não existe um procedimento, não existe uma metodologia, não existe um corpo de conhecimentos rígido que define esse papel. Não dá para saber “qual é o nível” de um gerente porque não existe um “padrão” de comparação. Existem bons gerentes e maus gerentes, apenas isso. Os “maus gerentes”, na realidade, sequer poderiam ser chamados de “gerentes” porque de fato não estão gerenciando.

Gerenciamento Real

Já foi dito que um expert é alguém que sabe mais e mais sobre menos e menos até que finalmente ele ou ela sabe tudo sobre nada. O problema do gerente é o oposto: saber menos e menos sobre mais e mais até finalmente ele ou ela saber nada sobre tudo.

Muitos acham que fazendo diversos cursos, pós-graduação, MBAs, etc vão necessariamente torná-lo um bom gerente. E não existe essa correlação. Sim, existem excelentes gerentes que tiveram uma boa formação, mas não foi a formação que o tornou um bom gerente. Não confundir, correlação com causalidade. No caso geral, essa pessoa simplesmente está postergando aquilo que realmente lhe daria chance de se tornar um bom gerente: a prática.

Gerentes que não fazem e lidam, e então não sabem o que está acontecendo, podem se tornar incapazes de surgir com decisões sensíveis e estratégias robustas.

Também existe a idéia de que gerentes não devem colocar a mão na massa. Claro, porque ou ele gerencia ou ele executa. O que não significa que o gerente deve ser ignorante quanto à área onde atua. Muito pelo contrário, um gerente que tem um excelente conhecimento técnico de sua área tem mais chances de conseguir entender o contexto.

Pensar é pesado – pensar demais pode cansar demais um gerente – enquanto agir é leve – agir demais pode fazer o gerente não conseguir parar.

Da mesma forma, liderança demais pode resultar em um trabalho sem contexto – sem mira, sem foco, sem ação – enquanto muito relacionamento pode produzir um trabalho desconectado de suas raízes internas – relações públicas em vez de conexões tangíveis. O gerente que somente comunica nunca termina nada, enquanto o gerente que somente “faz” termina fazendo tudo sozinho. E o gerente que somente controla riscos termina controlando uma casca vazia de homens e mulheres “sim”. Nós não precisamos de gerentes orientados-a-pessoas, orientados-a-informação ou orientados-a-ação; precisamos de gerentes que operam nesses três planos. Somente juntos todos esses papéis em todos os três planos fornecem o balanço que é essencial à prática de gerenciamento.

O que Mintzberg coloca, e que é óbvio, é que se você quiser ser um autor renomado de gerenciamento, escrevendo livros, dando palestras, deve focar em um e apenas um aspecto e exaltá-lo como a “peça que falta”. Porém, a realidade é que um gerente que foca apenas em um aspecto da prática de gerenciamento com certeza está fazendo a coisa errada. Um bom gerente sabe equilibrar os diferentes papéis em diferentes situações, mas usa todos sempre que precisa.

Enfim, como podem ver, o papel do Gerente é muito mais amplo do que parece. Apenas estudar procedimento não o torna um gerente, assim como estudar uma tabela de cores não o torna um pintor, ou saber ler uma partitura não o torna um compositor.

Arte, Ofício, Técnica e Prática. Esta é a definição de Gerenciamento. Um gerente que não entende isso sempre será um péssimo gerente.

Como adendo, cuidado, às vezes vemos – não somente gerentes – mas profissionais muito ativos, que parecem que fazem muita coisa porque falam com muitas pessoas, agem bastante, estão sempre acelerados. Porém este sempre parece ser o sintoma do “profissional-herói”. E na minha definição significa justamente o indivíduo que está fazendo seu trabalho da forma errada: parecendo que está fazendo muito mas na realidade está apenas sendo ineficiente e, pior, corrigindo os próprios erros que gera no caminho, parecendo que está resolvendo muita coisa mas, na realidade, está apenas correndo atrás do próprio rabo.

Original de 13/7/2010: Gestão 2.0 - este artigo está ultrapassado na interpretação, depois de mais pesquisas, aplicações práticas, cheguei à conclusão que expliquei nestes outros doisartigos. Quando escrevi o artigo ainda não compreendia todos os aspectos e contexto. Não entendam errado: a história da Semco é extremamente interessante e as idéias são muito sedutoras. Mas considerem o contexto.

Quem me conhece há algum tempo sabe que um dos cases que mais me interessa é o grupo brasileiro Semco. É difícil definir essa empresa que existe desde a década de 50 e passou as últimas décadas se reinventando, passando desde fornecedor da indústria naval, passando por serviços imobiliários com a Cushman & Wakefield, serviços e consultoria ambiental com a ERM, informatização de inventário com a RGIS, investimentos com a Tarpon, soluções de gerenciamento postal de documentos com a Pitney Bowes. Ela acredita em diversificação de negócios, fez diversas joint ventures, já revendeu várias delas. Em seu pico chegou a ter mais de 5 mil colaboradores.

Hoje, fiz minha primeira visita à sede da Semco, em Santo Amaro. O vídeo abaixo foi feito durante o horário do almoço, por isso parece tão vazio Espero poder retornar e inclusive visitar as outras filiais e fábricas.

A Semco se tornou destaque mundial por causa de sua inusitada forma de gestão, iniciada pelo visionário Ricardo Semler, autor dos livros Virando a Própria Mesa e Você Está Louco. Semler foi vice-presidente da FIESP, articulista da Folha de S.Paulo, professor visitante da Harvard Business School. Já viajou o mundo explicando como implementou Gestão Participativa em suas empresas e depois de tudo isso atualmente prefere se manter mais reservado.

Quando a Semco começou esse processo de Gestão Participativa no começo dos anos 80, poucos poderiam imaginar que daria certo e até hoje muitos preferem imaginar que foi mais uma questão de sorte do que de técnica, já que eles praticam o contrário do que é conhecido hoje como “senso comum” em gestão e administração de empresas.

Para começar, os números da empresa são abertos a todos os funcionários, lucros, fluxo de caixa, gastos, etc. Todos tem remuneração variável onde o variável é proporcional às metas da empresa como um todo, metas do departamento e metas individuais, negociadas entre cada um e seu gestor. O gestor, diferente da figura autoritária tradicional, não pode ter mais esse papel, servindo como um “líder servil”. Existe um GPS – Grupo Participativo Semco – formado por funcionários não-gestores e que ajuda a orientar e representar os demais. Esse grupo é eleito pelos funcionários a cada dois anos e é fundamental no bom funcionamento da empresa.

O processo de contratação sempre foi diferente, onde não só RH e gestor entrevistam os candidatos, como de costume, mas seus futuros pares também participam da entrevista. Aliás, os funcionários participam da entrevista de seus futuros gestores também. As avaliações são de baixo para cima, onde os funcionários avaliam seus gestores e não o contrário. O sistema se sustenta na premissa de autonomia das pessoas, no incentivo para que eles procurem sempre melhorar (metas individuais) e que as metas da empresa sejam atingidas de forma coletiva em vez da forma autoritária tradicional e, principalmente, que dadas as condições básicas, as pessoas sempre querem fazer o melhor.

Esta visita foi possível graças à Flordelice Bassanelli, responsável pelo RH desde 1986. Ela se envolveu em todo o processo desde o começo. Estávamos conversando como isso foi difícil, especialmente se considerar que se tratava de uma empresa familiar muito tradicional desde a década de 50. Mas o pai do Ricardo fez uma excelente escolha ao colocar seu filho na presidência, mesmo muito jovem, em seus 20 e poucos anos. Ele desfez a diretoria familiar e profissionalizou a empresa.

Mais do que isso, ele entendeu que tanto o modelo de negócios (pouco diversificado) e o modelo de gestão (autoritário) não eram bons. Tão logo conseguiu um bom Chefe de RH, Clóvis Bojikian, eles começaram a transição e isso no meio de uma crise iminente no setor naval mais a turbulência na aquisição de outras empresas com diferentes culturas. Em meio a isso a Flordelice foi contratada para implementar esse plano. Eu conheci o Clóvis por intermédio do Caio Túlio (um dos fundadores do UOL), na época eu queria implementar algumas dessas idéias na Locaweb, então levei o Clóvis até lá para apresentá-lo à diretoria e ele nos recomendou que teria sido seu braço direito, a Flordelice.

Como curiosidade estávamos justamente discutindo sobre o bom e velho assunto da folha de ponto (o timesheet), que a Semco – e qualquer empresa moderna – não usa há décadas mas que o Ministério do Trabalho, tornou obrigatório através de uma portaria (!) Na Semco cada funcionário faz o seu horário, não há cobrança de presença ou coisa parecida. Inclusive não há cobrança para aparecer na empresa.

Quando os escritórios estavam no auge da sua capacidade, inclusive, não havia mesas para todos – de propósito. As pessoas deviam reservar as mesas e o sistema não permitia que ele escolhesse a mesma mesa mais do que dois dias seguidos, como um incentivo realmente para que não se caísse em rotina. E quem ficasse sem mesa poderia escolher trabalhar em outros escritórios, como os da Faria Lima, ou mesmo trabalhar de casa.

Mais do que isso, nem mesmo nas Fábricas, onde funcionam turnos e escalas, onde normalmente os processos são mais espartanos e regulados, os próprios operários decidem entre si quem vem em que horário, como deveriam trabalhar e tudo mais.

Enfim, ainda vou explorar muitos dos temas da Semco nos próximos posts e eu recomendo fortemente ler os dois livros do Ricardo Semler que contam a trajetória da Semco e como ele implementou esse modelo. Aliás, uma das frases dele que eu mais gosto é a seguinte:

Se quiser adultos trabalhando na sua empresa, os trate como adultos. Se os tratar como crianças, elas vão agir como crianças.

Outra curiosidade adicional à quem é da área de Internet, provavelmente já ouviu falar na 37signals e no seu sucesso com produtos Web 2.0 e justamente uma nova forma de empreendedorismo. Pois Ricardo Semler e seu livro Maverick (a versão americana do Virando a Própria Mesa), é leitura obrigatória e um dos livros preferidos de Jason Fried e David Hansson, fundadores da 37signals.

Original de 24/6/2010: Gestão 2.0

O cérebro humano é uma máquina fantástica, e dizer isso é basicamente uma redundância do termo. Porém existem muitas anedotas e misticismo quando se fala sobre ela.

Todos já discutiram alguma vez a separação da “Emoção” do “Raciocínio”. Desde os tempos de Platão, as emoções são vistas como algo que atrapalha o pensamento lógico. Pior ainda: a maioria das pessoas realmente acredita que, pelo menos nas decisões mais importantes, nós somos capazes de deixar as emoções de lado e pensar de acordo com o pensamento de economia clássica: baseados em fatos, evidências e custo-benefício.

Porém, a verdade é que na grande maioria das vezes não é assim que nos comportamos. Em uma situação cotidiana, quando vamos a um supermercado, dificilmente ficamos fazendo aritmética, considerando os ingredientes de cada produto, o valor nutricional. Normalmente olhamos para um produto e decidimos se compramos ou não baseados no que sentimos. No meio de dezenas de marcas diferentes para um mesmo tipo de produto, escolhemos baseado em experiências passadas, em algum acontecimento marcante, nas lembranças e assim por diante, e tudo em frações de segundos. Nós preferimos levar um produto “80% light” do que levar um “20% gorduroso”, apesar de ambas as frases dizerem a mesma coisa.

Antonio Damasio é um conhecido neurologista que estuda o cérebro e nosso comportamento. Ele estudou pacientes que literalmente perderam a capacidade de ter emoções por causa de danos cerebrais, seja por tumor, por problema genético. Poderíamos pensar, assim como o grande filósofo Platão, que uma pessoa sem emoções seria capaz de tomar as melhores decisões o tempo todo, uma vez que não seria influenciado por elas.

Porém, o que acontece é que sem as emoções essas pessoas não conseguem aprender. Qualquer decisão trivial se torna uma análise de custo-benefício. Decisões cotidianas como que roupa vestir, que canal de televisão assistir, tomar chá ou tomar café, todas as coisas mundanas que decidimos quase instantaneamente, esse tipo de paciente pode demorar até horas para chegar a uma conclusão.

Um fato que já sabemos é que todas as emoções, tristeza, compaixão, alegria, depressão, prazer, etc são reações químicas no cérebro, todas elas. Inclusive já sabemos como influenciar ou controlar muitas dessas emoções. Usuários de drogas sabem a sensação de prazer. Pessoas que tomam antidepressivos também. Todos químicos que atuam no cérebro e modificam nossas emoções. Esquizofrenia e Parkinsson, por outro lado, são danos nesse sistema químico.

Outro fato é que nosso cérebro foi feito – ou melhor dizendo, evoluiu – para aprender. Aprendemos com tentativa e erro. Aprendemos observando e inferindo padrões. As emoções fortemente influenciam nossas decisões. E isso não é ruim. Quando aprendemos algum padrão, dopamina é liberada no cérebro, criando uma sensação de prazer. Gostamos de descobrir o padrão das coisas, tentar prever eventos futuros.

Em um experimento com macacos, onde tocamos um sino e depois damos uma banana, o macaco aprende o padrão “depois do sino vem a banana”. Ele aprende isso e podemos medir a dopamina sendo liberada já quando o sino é tocado, porque o macaco aprende a prever esse acontecimento. Se acendermos uma luz, tocarmos o sino e depois dermos a banana, o macaco aprende que o evento “luz” dá sequência ao sino e depois à banana. Isso pode ser repetido com diversas etapas e o macaco aprende o padrão. Porém, se seguirmos o padrão e a banana não vier no final, o macaco efetivamente fica triste, porque a previsão não funcionou.

Nós também funcionamos assim.

Para muitos eventos simples, com poucas variáveis, isso vai funcionar bem. Talvez por isso muitos gostem de rotina, onde os resultados são bem definidos. Nosso cérebro, no entanto, tem um defeito: na ânsia de encontrar padrões, o cérebro tentará encaixar padrões onde eles não existem. É como nascem as superstições. Antes de entendermos meteorologia, as tribos primitivas achavam que o fato “chover” estava relacionado à uma dança que eles acabaram de fazer. Portanto imaginavam que repetindo a dança choveria novamente.

Traduzi no meu outro blog um artigo da Scientific American demonstrando como somos “matematicamente ignorantes”. Tentamos achar um padrão para tudo. Um trecho que ilustra nossas superstições e explicações sobre coincidência é este:

Sempre é possível combinar dados aleatórios e encontrar alguma regularidade. Um exemplo muito bem conhecido é a comparação das coincidências nas vidas de Abraham Lincoln e John Kennedy, dois presidentes com 7 letras em seus últimos nomes, e eleitos com 100 anos de diferença, 1860 e 1960. Ambos foram assassinados numa sexta-feira na presença de suas esposas, Lincoln no teatro Ford e Kennedy num automóvel feito pela Ford. Ambos assassinos tem 3 nomes: John Wilkes Booth e Lee Harvey Oswald, com 15 letras em cada nome completo. Oswald atirou em Kennedy de um armazém e correu para um teatro, e Booth atirou em Lincoln em um teatro e correu para um tipo de armazém. Ambos os sucessores vice-presidentes eram Democratas sulistas e ex-senadores chamados Johnson (Andrew e Lyndon), com 13 letras em seus nomes e nascidos com 100 anos de diferença, 1808 e 1908.

Mas se compararmos outros atributos relevantes falhamos em encontrar coincidências. Lincoln e Kennedy nasceram e morreram datas (dia e mês) e em estados diferentes, e nenhuma das datas é separada de 100 anos. Suas idades eram diferentes, assim como os nomes das esposas. Claro, se alguma dessas fosse correspondente estariam na lista de coincidências “misteriosas”. Para qualquer pessoa com vidas razoavelmente cheia de eventos é possível encontrar coincidências entre elas. Duas pessoas se encontrando numa festa normalmente encontram coincidências chocantes entre elas, mas o que são – aniversários, cidades natais, etc – não são previstos de antemão.

O mundo real é cheio de aleatoriedades. Não é difícil encontrar padrões nelas. Na realidade é muito fácil. No mundo real, situações complexas tem muitos aspectos aleatórios. O mundo real é muito mais aleatório do que se imagina. E nosso cérebro ainda não evoluiu o suficiente para se sentir realmente confortável num mundo totalmente aleatório.

Um exemplo são pessoas de sucesso. Imagine um mega-investidor como Warren Buffett. Livros e mais livros são impressos, com análises, biografias, teorias, tentando explicar o processo que leva uma pessoa ordinária a ganhar bilhões na bolsa de valores. Apenas por especulação e se Warren Buffett for nada mais, nada menos, do que um acidente estatístico?

Nassim Taleb explica isso num artigo de Malcolm Gladwell:

Suponha que existem 10 mil gerentes de investimento por aí, o que não é um número tão irreal assim, e que a cada ano metade deles, totalmente por acaso, ganharam dinheiro e a outra metade perdeu dinheiro, também totalmente por acaso. E suponha que todo ano os que perderam dinheiro saem do mercado, e esse jogo é repetido todos os anos com os que sobraram. Ao final de 5 anos, ainda existiriam 330 pessoas que ganharam dinheiro seguidamente em todos os anos. E depois de 10 anos ainda existiriam 9 pessoas que ganharam dinheiro todos os anos, seguidamente, totalmente por acaso, por pura sorte da aleatoriedade. E quem pode dizer que Buffett não é um desses 9?

Nosso cérebro, no entanto, tem prazer em tentar encontrar padrões em tudo. Especialmente em casos de sucesso. Queremos encontrar a receita, a fórmula mágica. Algumas vezes ficamos com aquela sensação de “o que ele tem que eu não tenho?” E às vezes duas pessoas são tecnicamente igualmente capazes, mas uma é mais rica e outra não. A diferença pode ser simplesmente aleatoriedade. “Mas isso não é justo!” você pode reclamar, porém o mundo não foi feito para ser justo. Justiça é um conceito humano. A realidade não tem senso de moralidade humana, ela apenas “é”.

A ciência, felizmente, tem um procedimento certo para evitar essa armadilha de nosso cérebro: o método científico. Tudo pode começar justamente com um desses enganos do nosso cérebro, achando que encontrou um padrão, gerando uma teoria. Agora essa teoria tem que ser colocada à prova. Para que se torne uma boa teoria precisamos não só tentar comprová-la mas, principalmente, tentar desprová-la. Mesmo se não encontrarmos uma forma de desprovarmos a hipótese, nem por isso ela pode ser considerada uma “Lei”. A ciência toma muito cuidado nas afirmações que faz. Mesmo que uma determinada teoria tenha funcionado bem mil vezes, basta um único caso de fracasso para que essa teoria seja rejeitada. É graças a essa maneira de pensar que nós temos fundações muito sólidas e confiáveis na ciência. Livre de superstições e misticismo.

Processos, Metodologias e Superstições

Eu dei toda essa explicação para chegar ao assunto principal no caso deste blog: gerenciamento de projetos e de pessoas. Se vocês estão acompanhando meus posts até agora, notaram que em nenhum momento eu tento pregar nenhuma metodologia, nenhum processo, nenhum procedimento, nenhuma receita de bolo. Coisas do tipo “como fazer estimativas corretas”, “como prever o sucesso de um projeto” e coisas desse tipo.

Se você é bem atualizado também deve saber que existe todo um mercado de indivíduos e empresas que tentam justamente isso: lhes vender processos e metodologias. Seja a Engenharia de Software tradicional, PMI ou até mesmo as chamadas “metodologias Ágeis”.

Antes de fazer isso preciso deixar um alerta: todas essas metodologias foram inicialmente pensadas com a melhor das intenções. A idéia era compartilhar os fatores que levaram determinado projeto ao sucesso. Porém, minha explicação é mais ou menos assim: os líderes desses projetos, ou melhor, seus cérebros, incansavelmente começam a tentar encontrar padrões. Talvez seja o post-it na parede. Talvez seja o tipo de documento usado. Talvez seja a forma das pessoas se sentarem na mesa. Isso tudo forma um conjunto de “pseudo-verdades” que nosso cérebro entende que são as “luzes” e os “sinos” que levam à “banana”. Esses líderes aplicam em outros projetos, e assim como Nassim Taleb explicou, seguidamente têm sucesso.

Eureca! Parece que encontramos a fórmula para transformar ferro em ouro! Rapidamente essas pseudo-verdades são formatadas na forma de metodologias, enlatadas, empacotadas e vendidas.

Porém, pensem por um momento: e se todas essas metodologias forem exatamente como a dança da chuva? Como eu disse antes, é muito fácil encontrar padrões na aleatoriedade. Quando começamos a discutir minúcias, do tipo com que nível de detalhe devemos fazer uma estimativa? Que métricas devemos usar? Quais os mecanismos de comunicação da equipe? Não consigo deixar de pensar nas tribos primitivas discutindo coisas como “Quais penas devemos vestir? Que cores devemos usar na cara? Devemos dar passos longos ou curtos na dança?”

Mas a questão principal não vem à tona: é a dança da chuva que efetivamente faz chover? Ou no nosso caso: é a metodologia que de fato leva o projeto ao sucesso?

E o método científico? O problema é que um “projeto” é uma situação muito complexa. Mesmo os menores projetos são complexos. No sentido de que existem mais variáveis do que é possível medir. Um dos jeitos de testar uma teoria é fazer um experimento duplo-cego, como os laboratórios de remédios fazem: um grupo de pessoas recebe o medicamente de verdade e outro grupo recebe um placebo, sem saber. Se ambos os grupos tiverem aproximadamente o mesmo resultado, significa que o remédio não funciona.

Porém, uma metodologia é mais complicada do que um remédio. Mesmo que consigamos criar dois ambientes de trabalho físico isolados e idênticos, colocarmos dois grupos de pessoas “aproximadamente” semelhantes em cada um, começarmos exatamente ao mesmo tempo, com os mesmos requerimentos, num lado com a metodologia “A” e no outro com a metodologia “B”. Ainda assim não temos como comparar os resultados. Isso porque metodologias envolvem as micro-decisões e capacidades de cada pessoa e “aproximadamente semelhantes” é muito diferente de “iguais”. É impossível duplicar o mesmo grupo de pessoas em cada um dos ambientes. Teríamos que conseguir primeiro clonar as pessoas com sucesso. Daí, com grupos exatamente idênticos, poderíamos fazer um experimento duplo-cego. Mas isso é impossível.

A conclusão é que é impossível provar uma metodologia desse tipo como “correta” assim como é difícil desprová-la. Portanto, é inútil tentar afirmar que elas funcionam ou não. É claro que elas influenciam e, separadamente, cada uma das técnicas pode ser testada com mais cuidado. Porém, acho que não é possível afirmar cientificamente que elas funcionam.

“Mas eu testei a metodologia X no meu projeto e funcionou!”

Excelente, bom para você. Porém, para cada projeto que foi bem sucedido com certa metodologia, podemos encontrar um caso em que deu errado também. Mas os indivíduos e consultorias que vendem essas metodologias são espertas: se um projeto deu certo foi graças à metodologia. Agora, se um projeto deu errado é porque as pessoas é que não seguiram a metodologia como deveriam. Portanto, a culpa nunca é da metodologia! É uma excelente retórica para formar um argumento de vendas. E se as pessoas não estão acostumadas a avaliar as coisas racionalmente – e como expliquei acima, na maioria das vezes não raciocinam mesmo – teremos muitos consultores ganhando muito dinheiro sem precisar se comprometer com resultados.

Isso é importante porque muitos acreditam que, com a ajuda da metodologia da moda, basta aplicá-la a uma equipe que só tem pessoas inexperientes que um bom resultado vai aparecer, porque o importante não são as pessoas mas sim o processo. E é exatamente o contrário: na maioria das vezes essas metodologias não descrevem quais são as exatas qualificações que cada membro precisa ter. Porque é impossível listar todas. No máximo existem descrições vagas de “papéis” que mais geram discussões do que respondem à pergunta. Um projeto com chances de ser bem sucedida começa tendo pelo menos algumas pessoas muito experientes que saberão conduzir o resto da equipe.

Finalmente, minha recomendação é: estude as tais “metodologias”, como disse antes, de fato elas tem algumas técnicas que tem valor. Porém entenda que nenhuma delas representa a verdade. E não adianta tentar somar duas meia-metodologias que isso não vai torná-las “mais completas”. Entenda que projetos são executadas por pessoas e o comportamento humano é difícil de prever e o ambiente do mundo real é cheio de variáveis imprevisíveis, formando um sistema complexo com muita aleatoriedade envolvida.

Comece aceitando que o mundo é aleatório e fora do seu controle. Em situações complexas é melhor errar antes do que depois porque os erros trazem informações que ajudam a refinar as decisões seguintes. Aceite que é impossível prever o que vai acontecer no futuro num sistema complexo, em vez disso adapte-se: aceite que algumas coisas vão sair como previsto mas que algumas coisas vão necessariamente precisar mudar. Talvez alguma funcionalidade não prevista precisará ser feita, nesse caso talvez o prazo precise ser esticado. Talvez alguma funcionalidade prevista no fundo não era tão necessária e possa ser descartada. É assim que lidamos num ambiente complexo e imprevisível: adaptando.

A biologia explica: todos os seres vivos do planeta são resultado de uma constante sequência de tentativas e erros. A natureza não é “perfeita”, no sentido de que não existe um criador, não existe um design inteligente, não existe um grande plano, não existe destino. Todo ser vivo veio de um rascunho biológico muito ruim que, pouco a pouco, via seleção natural, foi descartando o que não funcionava e favorecendo o que funcionava. Nós humanos temos resquícios biológicos (como o apêndice, por exemplo). Somos um produto em constante evolução. Para muitos o atual estágio é “bom o suficiente”. Em termos de projetos é nesse ponto mesmo que ele pode ser lançado, quando estiver “bom o suficiente”, ou seja, ainda tem arestas a arrumar mas no geral funciona.

Tentativa e erro. Adaptação. Evolução. É assim que se gerencia qualquer coisa.

Se quiser uma visão mais detalhada sobre esse assunto recomendo começar lendo os seguintes livros:

• How We Decide do Jonah Lehrer
• Descartes’ Error do Antonio Damasio
• Predictably Irrational do Dan Ariely
• Fooled by Randomness do Nassim Taleb
• The Lucifer Effect do Philip Zimbardo

Como já devem ter visto o Rails 4.0 foi finalmente lançado hoje depois de um longo período de desenvolvimento. Para se ter uma idéia o primeiro beta do 4.0 foi lançado em fevereiro deste ano e a série 3.2.0 (que atualmente está na 3.2.13), foi lançado em Janeiro do ano passado. Portanto estamos falando de um ano e meio entre duas séries estáveis.

Antes de mais nada fica as mesmas recomendações de sempre:

• se você não sabe se deve usar o Rails 4, melhor permanecer na versão 3.2.13, mesmo para projeto novos. Isso porque muitas gems ainda não são compatíveis com a nova versão e deve levar alguns meses para que a maioria das principais gems se estabilizem.
• se estiver numa versão muito antiga de Rails, lembre-se que a série 2.3 está em fim de vida, ou seja não terá mais suporte sequer para atualizações de segurança então você deve migrar para as séries mais novas. Mas nunca pule direto pra 3.2.13, vá versão em versão como já expliquei neste outro post.
• quem está acostumado a lidar com cutting edge já pode ir e começar a colaborar para ajudar a encontrar os problemas de compatibilidade. Basicamente prepare-se para uma Gemfile cheia de apontamentos direto para o repositório git de cada gem.

Em termos de novas funcionalidades, você pode usar muitas delas já na versão 3.2.13. Por exemplo, para ter Turbolinks faça o seguinte:

# na Gemfile
gem 'turbolinks'

# no app/assets/javascripts/application.js
//= require turbolinks

Para retirar Turbolinks de um projeto com Rails 4 basta fazer exatamente o oposto e retirar as mesmas linhas que são geradas automaticamente.

Até o 3.2.13 estávamos acostumados a usar protected attributes, na versão 4.0 agora você tem strong parameters. São formas bem diferentes, em um você marca propriedades do model que são protegidas diretamente na declaração do model. Na segunda você não declara no model mas sim cria um método de ajuda no controller. Se você usar o Rails 4 pode usar a gem de strong_parameters para experimentar. Se está migrando para Rails 4 pode colocar o protected_attributes na Gemfile de volta para que seus models funcionem por enquanto.

Quem usa cache de página ou de action e quer continuar usando até retirar esse código pode usar as gems actionpack-page_caching e actionpack-action_caching. A novidade do Rails 4 é o que chamamos de Russian Doll Caching Scheme ou Cache Digest que é um controle mais refinado para nested fragment caching usando digest keys. Assista este episódio do RailsCasts para entender mais.

Falando em cache outra coisa que mudou foi o Asset Pipeline. Antes a rake task de precompilação era bem lenta, foi facilitada graças à gem turbo-sprockets-rails3 que deve ser usada em Rails 3.2 (e não mais na 4.0) e agora mudou novamente porque ela não gera mais as versões não-digest dos assets. Agora obrigatoriamente todo asset vem com os digests. Por exemplo, você vai encontrar arquivos como "public/assets/application-68fa4ee77b8ca3bdfb1ce073fc31c3c4.js" e não vai mais ter a versão "public/assets/application.js" disponível. Isso deve garantir que nenhuma parte do seu código usa assets errados. Outra vantagem é que a task assets:precompile está consideravelmente mais rápida.

No Rails 3 ganhamos o novo formato de queries de ActiveRecord chamado de Arel. Se você já nasceu no mundo Rails 3 talvez nem reconheça o antigo formado de finders usado até o Rails 2. Durante toda a vida do Rails 3 a sintaxe de finders ainda funcionava mas no Rails 4 ela foi removida e se você ainda precisar muito delas enquanto termina de migrar para a sintaxe atual pode usar a gem activerecord-deprecated_finders. Mas obviamente livre-se da sintaxe antiga o quanto antes. Todos tiveram quase 3 anos desde o lançamento da série 3.0 em Agosto de 2010. Já era hora de nos livrarmos do jeito antigo.

Finalmente, Ruby 1.8 não é mais suportado oficialmente. Você deve estar usando no mínimo Ruby 1.9.3 que é uma release muito estável ou mesmo Ruby 2.0 que também é uma release bem estável e bastante compatível com todas as gems que você vai precisar. A migração para Ruby 2.0 está bastante tranquila, e o Ruby 1.8 poderia ter sido deprecado já na época do lançamento do Rails 3.2. Mas agora na 4.0 não há outra escolha. E se você estava usando Ruby 1.8 por causa da economia de memória graças ao Ruby Enterprise Edition com Passenger, saiba que o Ruby 2.0 tem a mesma funcionalidade graças ao seu novo Bitmap GC. Existe muito material na internet sobre Ruby 2.0 e eu já havia feito uma apresentação a respeito em Abril deste ano:

Essas são somente algumas das coisas grandes que mudaram. Leiam o Ruby on Rails 4.0 Release Notes para um resumo. Eu mesmo já fiz um apresentação que apresentei ano passado num encontro em Israel e vocês podem ver os slides aqui:

O Ryan Bates, do RailsCasts fez um episódio chamado What's New in Rails 4 e outro chamado Upgrading to Rails 4. Se procurar no Google sobre Rails 4 ou separadamente sobre cada uma das mudanças que listei acima vai encontrar diversos artigos detalhando a respeito. Diversos livros e cursos online já foram atualizados para Rails 4 incluindo o do Mike e Nicole Clark da Pragmatic Programmers, o The Rails 4 Way do Obie Fernandes, na CodeSchool tem o Rails 4 Zombie Outlaws.

Enfim, não falta material. No mais, testem a nova versão e ajudem as gems a se tornarem compatíveis. Criem issues ou mesmo mandem pull requests para cada projeto.

Quem tem aplicações em produção já deve ter passado por isso. Depois de meses com seu servidor de pé de repente ver que seu espaço em disco está acabando rápido. E quando procurar o culpado, encontrá-lo no arquivo log/production.log, com algumas centenas de gigabytes ocupados. O que fazer?

No mundo UNIX existe uma solução padrão para isso, o serviço logrotate. Isso vale não só para Rails mas para qualquer tipo de log.

Porém, no Rails 3 o próprio Logger sabe como se auto-rotacionar, sem precisar depender do logrotate do sistema. Abra seu arquivo config/environments/production.rb e adicione a seguinte linha:

config.logger = Logger.new(Rails.root.join("log",Rails.env + ".log"), 5, 100*1024*1024)

O construtor aceita 3 parâmetros:

• caminho do arquivo de log - e aqui no caso está genérico para que você possa colocá-lo em ambientes de outros nomes
• quantidade de arquivos de log que quer manter
• tamanho máximo de cada arquivo de log, em bytes

No exemplo você terá no máximo 5 arquivos de 100 megabytes, quando o 6o arquivo se completar, o primeiro mais antigo é apagado e assim por diante, rotacionando sem consumir todo o espaço do seu disco. A partir daí você vai ter arquivos com nomes de production.log (o atual), depois production.log.0, production.log.1, etc.

Não tem todas as funcionalidades do serviço nativo de logrotate (como gzipar os arquivos antigos, rotacionar por período de tempo, etc), mas para a maioria dos casos deve ser mais que suficiente.

Original de 18/6/2010: Gestão 2.0

Eu retornei no último fim de semana de uma viagem à Baltimore, Maryland, onde palestrei na RailsConf. Neste evento tivemos grandes palestras e algumas delas voltadas não somente a Ruby on Rails mas à carreira de programação em geral. Uma dessas palestras foi de ninguém menos que Robert Martin, da Object Mentor. Eu traduzi um artigo seu no meu post anterior.

Recomendo assistir à palestra na íntegra.

Desde que comecei este blog, tento explicar as condições e dificuldades que um Gestor de Projetos enfrenta. Porém também estava tomando cuidado para não mencionar o termos “Agile” muitas vezes. Atualmente estamos sofrendo uma febre de “agilidade”. Todo CIO, CTO, Gerente, Consultor, para parecer “moderno” diz que sabe “Scrum”, que é “ágil”. Isso é por um lado bom, porque finalmente algumas empresas talvez consigam adotar da forma correta, mas por outro lado é muito ruim, porque estamos queimando o nome “Agile” por causa de consultorias ruins implementando isso errado no cliente. Daí a percepção que muitos desavisados ficam é que “Agile não funciona”.

Pois bem, durante a RailsConf, eu tive a oportunidade de conversar e entrevistar o Robert Martin, cuja gravação você pode assistir no Blip.TV:

Dessa entrevista, o trecho que quero apresentar é a história de como surgiu o “Agile”. Robert Martin, também conhecido como “Uncle Bob”, é um programador há décadas, certamente mais do que qualquer um de nós. Nos anos 90 ele foi um dos que notou uma insurgência de metodologias “leves” ou “lean”. Muito disso derivado dos conceitos de manufatura que revolucionaram a indústria japonesa a partir dos anos 60.

Diversos grandes nomes começaram a sugerir formas mais inteligentes de desenvolver software. Exemplos disso foram Kent Beck com seu Extreme Programming (XP); Ken Schwaber e Jeff Sutherland com seu Scrum; Alistair Cockburn com seu Crystal. Vendo que a maioria seguia uma linha similar de iterações curtas com feedback e muita comunicação, Uncle Bob ligou para Martin Fowler – outro grande conhecido no mundo de arquitetura de software – e juntos começaram a organizar uma reunião, convocando dezenas desses profissionais.

A lendária reunião se deu na estação de ski de Snowbird, em Utah, entre os dias 21 e 23 de Fevereiro de 2001. O resultado dessa reunião foi a criação do “Manifesto Ágil”. Ela delineia 4 valores e 12 princípios que todos os participantes concordaram como o mínimo denominador comum na prática de desenvolvimento de software. O manifesto diz:

Estamos descobrindo melhores maneiras de desenvolver software ao fazendo e ajudando os outros a fazer. Através desse trabalho nós chegamos a valorizar:

Indivíduos e Interações mais do que Processos e Ferramentas

Software que funciona mais do que documentação compreensiva

Colaboração do cliente mais do que negociação de contratos

Responder a mudanças mais do que seguir um plano

Ou seja, enquanto existe valor nos ítens da direita, nós valorizamos os ítens da esquerda muito mais.

Como disse antes, atualmente existe uma certa febre crescente em adoção de metodologias ágeis. Pior do que isso, existe uma tendência de expropriar o termo “Ágil” ou seus derivados como “XP” e “Scrum”, criando literalmente frankensteins mesclando o jeito antigo com o jeito novo. Frankensteins como tentar misturar RUP com Scrum, ou PMI com Scrum e assim por diante.

São tentativas oportunistas aproveitando dessa febre para ganhar dinheiro fácil. Algumas empresas, por exemplo, valorizam que um currículo para gerente tenha um “Certified Scrum Master” listado e outras coisas irrelevantes desse tipo.

E para ser mais antagônico ainda, muitos tentam implementar metodologias ágeis seguindo as diversas técnicas “by the book”, ou seja, de forma dogmática e, obviamente, todo Dogma é, por definição, burro.

Relembrando os 4 valores: a ênfase não é em implantar uma metodologia, a prioridade é software que funciona e valor ao cliente. O primeiro valor Ágil diz claramente: “nós valorizamos muito mais Pessoas e Interações do que Processos e Ferramentas”, mas o que está acontecendo atualmente é o oposto: tentativas de empurrar processos, metodologias e ferramentas.

Agora é uma boa hora para começarmos a desmistificar o mundo Agile. Esta é apenas uma introdução, mas como o Uncle Bob diz na entrevista: siga os originais. Se você realmente está comprometido a melhorar as coisas, a entregar os projetos com qualidade e valor, desligue-se dessa nova geração de consultorias: comece com os primeiros livros do Ken Schwaber, do Kent Beck, do Alistair Cockburn, do Mike Cohn.

Pergunte-se o tempo todo: estou de acordo com os 4 valores?

Se por acaso você está dando mais ênfase no processo do que nas pessoas, você já começou errado, muito errado.

Original de 11/4/2010: Gestão 2.0

O maior desserviço à área de Desenvolvimento de Software já criado na nossa história recente foi o termo “Fábrica de Software”. Pior ainda depois que a Índia implementou esse conceito em larga escala, tornando-o famoso e com credibilidade.

Digo isso porque a partir do momento que se encara “Desenvolvimento de Software” como uma tarefa de “Fábrica”, onde entra uma especificação de um lado e sai um software do outro, você acabou de destruir qualquer inovação na área. Pior ainda, considera que todo programador é necessariamente um “operário”.

Porque estamos falando de “Fábrica”, os cursos de “Engenharia de Software” se tornaram mais populares que os de “Ciências da Computação”. E mais paradoxal ainda é ver estudantes se formando como “engenheiros” mas trabalhando como “pedreiros”.

Mais ruim ainda é quando gerentes de TI, “CIO”s, “CTO”s, que sequer foram da área de software, sequer escreveram uma linha, acham que entendem como se faz software. Dado que o mercado fala de “Fábrica”, o que eles vão implementar são “linhas de produção” e junto com isso todos os procedimentos que colocam o operário em linha. Planilhas de horas, métricas de linhas de código, ou pontos de função ou pontos de história ou qualquer bobagem dessas, gantt charts e cronogramas “precisos” de entrega, etc.

A metáfora está completamente errada. Desenvolvedores não são operários, e sim os “arquitetos” propriamente ditos. O trabalho de operário em software é do compilador, este sim, que empilha um byte sobre o outro seguindo uma especificação: o código do software. Repetindo: o código do software é a especificação, a planta baixa, e o compilador é o operário que faz o trabalho braçal.

O que chamamos hoje de “arquitetos” não são arquitetos, na verdade não são nada. Não há como ser um arquiteto sem ser um programador sênior antes. Um bom programador pode se tornar um arquiteto.

Agora, o problema é que o conceito de “Fábrica” se espalhou rapidamente. O governo e as instituições de ensino abraçaram isso. Me deixa extremamente triste visitar áreas do Brasil onde as únicas opções de trabalho para programadores são essas “Fábricas”. As faculdades também se depreciaram para atender essa demanda e formar “operários” com diplomas de “engenheiros”, e assim toda uma nova geração de programadores pensa com cabeça de operário.

Uma ressalva para ser politicamente correto: não tenho nada contra operários, muito pelo contrário, é uma profissão tão respeitada como qualquer outra. Porém, ninguém vende operários de obra como arquitetos e nem os próprios operários se acham arquitetos.

Eis porque digo que foi um desserviço: toda uma geração inteira de programadores desperdiçada pensando em software enquanto empilhar tijolo. Levará pelo menos mais 2 gerações inteiras para, talvez, conseguirmos reverter isso.

Agora pensemos: e se em vez de “Fábrica” mudássemos o termos para algo mais adequado como “Atelier de Software”? Como isso mudaria a forma como você pensa e trabalha com software?