Como todos os textos do Seth Godin, este livro de 2005 também é divertido de se ler (no meu caso, ouvir). Apesar de antigo ele delineia um modelo interessante de marketing.

Em resumo, existem 2 partes que eu gosto: a primeira, quando ele fala que marketing baseado em listagem e checklist de “features” é uma bobagem. O pior tipo de marketing são aqueles onde você vê comparação de funcionalidades com outros produtos, coisas do tipo “preços menores”, “pesquisas mostram que os consumidores gostam mais de nós”, “temos mais performance”, “temos mais segurança”, “temos ítem X que o outro não tem”. Tudo isso é bobagem e normalmente constitui péssimo marketing.

Brasileiros: Cliquem aqui

Don’t miss this year’s Rails Summit Latin America. This is a huge opportunity for Railers throughout of South America to gather and meet. It will take place in Sao Paulo, Brazil once again bringing together a great roster of known Railers such as Matt Aimonetti, Rich Kilmer, Chad Fowler and many others for 2 full days, with 2 parallels tracks of Ruby and Rails goodness.

Rails Summit 2008 was a huge success with a great positive repercussion on the community. We do intend to even surpass the level of quality of last year’s event.

This year, we’ll have a larger area, with 2 rooms, both with Portuguese-English and English-Portuguese real-time translators so everybody can enjoy every single talk. We will have a great lobby for social networking complete with wi-fi network and power plugs so you can code during the event and share code and techniques with your new developer mates.

Help us out promote the event by wearing our banners in your website as well.

Register now! We will be waiting for you on October 13th and 14th.

Muita gente já me perguntou como se tornar um bom programador. Normalmente estão mais preocupados em qual linguagem aprender, qual curso fazer, quais livros técnicos ler. Porém, assim como os autores desses dois artigos que vou traduzir, eu diria que existem qualidades mais importantes a se levar em conta.

O primeiro artigo é o What makes a good programmer?

Atualização 20/04/2012: Este é um dos artigos mais lidos do meu blog, publicado pela primeira vez em 09/2009. A grande parte do artigo funciona bem até hoje, então resolvi ajustar algumas coisas e adicionar informação mais atualizada. Se você já tinha lido este artigo e quer ver somente o que eu coloquei de novo, veja este post

Você é um “switcher”, decidiu fazer o grande salto de deixar um pouco de lado o mundo Windows e decidiu comprar seu primeiro Mac. A época é boa, os preços estão acessíveis especialmente se você pode comprar com alguém de fora. Uma coisa que você precisa ter em mente: será uma mudança de paradigmas. A primeira semana ou duas são as piores e você sempre vai ter aquele pensamento “no Windows eu conseguia fazer mais fácil …” ou “no meu Linux eu conseguia fazer mais fácil …” – a tentação de retornar sempre é grande quando você sai pela primeira vez da zona de conforto. É a mesma coisa com qualquer mudança. Mas force-se e tente não usar os velhos truques, mas sim aprender novos.

Update 07/20: Por coincidência saiu na Revista Você S/A deste mês a matéria Como lidar com Chefes Tóxicos que tem tudo a ver com este artigo.

Veja esta lista de acidentes fatais da aviação civil:

  1. Jetstream into Hibbing, MN, (NTSB, 1994a);
  2. DC-8 into Jeddah, Saudi Arabia (NTSB, 1993a);
  3. C99 into Anniston, AL, (NTSB, 1993b);
  4. Beechjet into Rome, GA, (NTSB, 1992a);
  5. DC-8 loss of control at Toledo, OH, (NTSB, 1992b);
  6. 707 fuel exhaustion into JFK, Washington DC, (NTSB, 1991);
  7. L-1011 windshear accident, D/FW Airport, TX, (NTSB, 1986);
  8. MS-748 electrical failure in Pinckneyville, IL (NTSB, 1985);
  9. 737 out of Washington National, Washington DC, (NTSB, 1982);
  10. DC-8 fuel exhaustion in Portland, OR, (NTSB, 1979);
  11. 727 into Dulles New York City, NY, (NTSB, 1975);
  12. DC-8 freighter into Cold Bay, AK, (NTSB, 1974);
  13. Convair into New Haven, CT, (NTSB, 1972);
  14. L-188 into a thunderstorm at Dawson, TX, (NTSB, 1969);
  15. Lear Jet out of Palm Springs, CA, (NTSB, 1967);
  16. F-27 into Las Vegas, NV, (CAB, 1965).

Cada um desses acidentes é um exemplo de subordinados que sabiam que o Capitão estava ignorando sérios riscos e demonstrando comportamento contra-produtivo e não razoável. Esses subordinados todos sabiam que seus respectivos capitães ou estavam negando, descontando ou ignorantes aos perigos letais. Infelizmente, nenhum deles foi capaz de fazer qualquer coisa para mudar a performance, ações ou estratégias do Capitão; a maioria não conseguiu sequer fazer o Capitão se tocar do problema.

これは僕のはじめの日本語で核ブログポスト。減った糞な日本語で書くのもすみません、でも今日は"@satokoさん":http://twitter.com/satoko ていうプログラマーと話して何となく日本語で書ムードになりました。僕はブラジル生まれなので、子供のころからアニメや漫画読みながら少しだけ日本語学んだ、でも経験不足です。 残園ながらまだ日本まで旅行した事がまだない。僕はブラジル生まれで Ruby on Railsの初めてのエバンジェリストです。2006年に初めてのRails本がポルトガル語で書きました。ルビーも日本生まれって事は面白い、マッツさんが本当に英雄と思います。 で、ほかの日本人が、もし、このブログを読んだら、日本にRailsがどうやっているか書いてください、すごく興味あります。 どうもよろしくお願いします。

Para quem se interessou pelos assuntos relacionados a gerenciamento, administração, processos, que tenho explorado nos meus posts e palestras, eis as minhas referências. São os livros que li recentemente (de uns 9 meses para cá) e os que estão na minha fila para começar ou terminar.

Lendo


Este artigo é um apanhado geral de diversos temas relacionados que compõe alguns dos conhecimentos necessários para entender o tema de Auto-Organização. Nesse caso é importante entender esse conceito também do ponto de vista da fundação física e matemática.

A motivação toda é por causa do 11o princípio do Manifesto Ágil:

“As melhores arquiteturas, requerimentos e designs emergem a partir de equipes auto-organizadas.” – Principles behind the Agile Manifesto

Agilidade requer auto-organização. Mas esse conceito é alienígena para a maioria das pessoas e organizações. O 12o princípio ainda completa:

“A intervalos regulares, a equipe reflete em como se tornar mais efetivo, então refina e ajusta seu comportamento de acordo.” – Principles behind the Agile Manifesto

Nesse caso precisa entender o conceito de Organização de Aprendizado ou melhor ainda, entender o momento dinâmico de aprendizado e melhoria contínua que se chama Limite do Caos e como implementar Agilidade essencialmente significa, em termos de física:

Retirar a organização – que é um sistema complexo – de seu estado de equilíbrio dinâmico, aumentando a entropia geral do sistema, forçando em direção ao caos. No ponto ideal, no limite do caos, a auto-organização acontece e a organização se torna uma organização de aprendizado.

Lembrem-se: “aprendizado” também incluia a exploração do desconhecido, incorporar novas informação. Fazendo o que sempre se faz não se está aprendendo nada, por definição. É preciso fazer diferente, errar e melhorar para aprender.

Vamos aos conceitos agora.

Nas palestras do Encontro Locaweb eu discuti sobre o tema de “Agilidade em projetos de desenvolvimento de software”. Pelo menos essa foi a idéia original. A cada cidade que eu palestrava eu também fazia ajustes à palestra original e isso modificou bastante o tema e no final, na quinta versão eu expandi o conceito de gerenciamento também para o conceito de Organizações. Ontem à noite finalmente arranjei um tempo para ajustar novamente a palestra e gravei uma versão de 1:30h, a sexta versão. Ai...

Nas minhas últimas palestras sobre agilidade eu explico sobre Contrato de Escopo Fixo e Contrato de Escopo Flexível ou Negociável.

Em gerenciamento clássico de projetos, existe a imagem do triângulo de Custo x Tempo x Escopo. O objetivo dos mecanismos tradicionais é em tentar manter esses pontos todos fixos e previsíveis. O PMBOK é justamente um conjunto de conhecimentos com esse objetivo.

Hoje, sabemos que esses mecanismos não funcionam como gostaríamos. A premissa do “controle” é que é impossível efetivamente ter controle. E o pior, quanto maior o projeto, mais esses mecanismos são ilusórios. Para começo de conversa: nós não somos bidus, não temos o poder de adivinhar o futuro. Damos risada de cartomantes, mas somos os primeiros a achar que conseguimos prever um projeto de 2 anos com precisão.

Seja quando se quer aplicar uma nova metodologia, implementar novos processos, a razão número 1 do fracasso da maioria das tentativas é a seguinte: dar a autoridade dessa implementação para uma pessoa ou uma equipe isolada. Repetindo: não crie cargos do tipo “Analista de Processos” ou departamentos como “Departamento de Processos”. Ou seja, não dê a ninguém a autoridade de desenhar os processos que serão implementados por outras equipes. Isso não funciona. Ponto final. Normalmente as empresas...

Se você ainda não aprendeu Git, um bom lugar para começar é meu Micro Tutorial de Git. Para complementar, existem algumas dicas úteis para usar no dia-a-dia que vou explicar agora. Mesmo assim, Git é um mundo rico e complexo, existem infinitas possibilidades e você nunca vai se cansar de aprender coisas novas com ele. Recomendo também acompanhar o site GitReady para continuar aprendendo truques novos.

Para começar, vamos criar um novo repositório para exemplo:

1
2
3
4
5
rails teste
cd teste
git init
git add .
git commit -m "initial commit"

Agora vamos falar sobre como desfazer modificações, manipular commits, e muito mais.