tucaz.blog.now() Rotating Header Image

Qual é a dos apertadores de botões?

Não importa onde eu vá, seja a empresa grande ou pequena, sempre existem pessoas dos dois grupos: apertadores de botões e as pessoas que vão pra frente.

As pessoas que vão pra frente são fáceis de identificar e não me interessa falar muito sobre elas neste post. Elas estão sempre empolgadas, comentam a respeito de novidades e procuram fazer ela e as pessoas em sua volta prosperarem, mesmo quando essa não é a intenção.

Já os apertadores de botão estão sempre na mesma. O incrível é que esse perfil (ou falta de perfil?) existe em todos os papéis e profissões. DBAs -que só rodam scripts e não analisam o log (nem quando solicitado!) pra ver o que aconteceu e ajudar o pobre desenvolvedor que não tem acesso ao DB-, Desenvolvedores -que programam o que está especificado não importando o quão errado esteja do ponto de vista técnico ou funcional-, entre muitos outros.

No entanto, podemos ainda criar outra categoria de apertadores de botões: os que fazem apenas tarefas repetitivas. Quem nunca viu o “operador de computador” (acho que essa expressão é do mesmo tempo CPD) que todo dia, o dia inteiro, fica copiando/alterando arquivos de lá pra cá, sempre igual?

Por mais que eu não goste do meu trabalho (ainda bem que eu gosto!), acredito que devemos tirar o melhor proveito dele. Ou melhor, devemos tirar o melhor proveito de tudo que fazemos na vida. Portanto, o que motiva uma pessoa a executar o mesmo processo igual todo dia sem nem mesmo pensar em uma maneira de automatizá-lo ou de faze-lo de maneira diferente?

Mesmo que você não consiga remover todos os processos repetitivos ou não crie uma obra de arte quando conseguir é importante tentar. Não importa se você vai ser reconhecido por isso, não importa se você irá ganhar $algo$ em troca e não importa se você não é pago pra automatizar nada. Faça por você! Mesmo quando o esforço não valer a pena você vai no mínimo ter aprendido alguma coisa nova.

Portanto, se você se encaixa em algum desses perfis, já passou da hora de se mexer e mudar, não acha?

Reunião .NET Architects em 16/01/2010 – Referências

Ontem durante a reunião do nosso grupo de discussão de .NET o Fabio Galuppo falou sobre um pouco sobre F#. A apresentação foi muito boa e logo após, durante a “mesa redonda”, eu mencionei uma série de aulas gravadas na Universidade de Berkeley sobre o assunto Linguagens Funcionais. É o curso completo gravado. Como o pessoal se interessou e pediu os links ai vai:

Depois da reunião oficialmente terminada fomos almoçar e como acabamos entrando no assunto de gestão de projetos comentei um pouquinho a respeito de gestão democrática e prometi deixar alguns links disponíveis:

Eu não uso Scrum porque Scrum não funciona!

É Isso ai! Scrum não funciona!

Sabe porque Scrum não funciona? Porque se chama Scrum. Esse hoje é o maior problema do Scrum. Há dois anos atrás pouquíssimo se falava nisto que hoje virou hype. Nessa época as pessoas só falavam que usam Scrum depois de estudar bastante, trocar experiências e exercitar bastante. Ai sim alguém tinha coragem de dizer “Eu uso Scrum” e ainda assim com um pouco de receio, pois sabiam que tinha mais coisas além de apagar toda documentação do projeto e e quebrar as cadeiras pra fazer as reuniões em pé. As pessoas (a maioria) que diziam isso sabiam o que estavam dizendo. Scrum tinha credibilidade.

Nessa época, essas pessoas que conheciam agiram como evangelizadores do Scrum e finalmente ele atingiu as massas. No entanto, hoje o que mais se ouve são times/pessoas que não tem a menor idéia das noções e fundamentos por trás do Scrum ou qualquer outro processo/metodologia/framework ágil dizendo que são praticantes de Scrum. Até gente que nunca participou de um projeto usando Scrum hoje vende Scrum.

Isso é propaganda ruim. E propaganda ruim se multiplica muito mais rápido do que a boa. O pior da propaganda ruim é que cria-se ainda mais preconceito em cima de algo que já encontra resistência naturalmente. Isso tira todas as chances de sucesso de uma implementação de Scrum. Estou cansado de ver em todos os lugares pessoas frustradas dizendo que tentaram implantar Scrum em suas empresas e não conseguiram. Mas é claro que não! O filme do Scrum já está queimado. Você vai falhar antes mesmo de tentar.

Já faz um tempo que eu parei de vender a idéia de usar Scrum. Desde então eu digo que eu procuro executar práticas ágeis. Soa mais leve, mais simples. O pré-conceito diminui dessa forma e a resistência também. Do que importa se meu facilitador chama Gerente de Projetos ou Scrum Master? As pessoas se preocupam mais com nomes do que com resultados e esse é o problema. Agilidade é o que há, mas funciona melhor sem rótulos.

Verbos HTTP: GET e POST. Você sabe mesmo a diferença?

Até pouco tempo atrás quando eu fazia entrevistas a fim de contratar desenvolvedores, não importando o nível, eu fazia a mesma pergunta: “Você sabe a diferença entre GET e POST em uma request HTTP?”. Por incrível que pareça poucas pessoas sabiam responder. Na maioria das vezes alguém que se considerava um desenvolvedor web não tinha a menor idéia  sobre o que eu estava falando. Acho que era culpa do RH que fazia uma pré-seleção muito ruim, mas anyway…

Hoje essa informação já chegou a maioria dos desenvolvedores web (já era hora, não?) então a pergunta no contexto original perdeu um pouco a validade. Todo mundo sabe que enviar formulários via GET manda as informações pela querystring e que POST manda encapsulado dentro da request e bla bla bla. No entanto, com a nova “moda”, que acho bem bacana aliás, de REST(ful) a pergunta ganhou um contexto novo e tornou a ser válida: você sabe qual a diferença dos verbos em uma request HTTP? Não só de GET e POST, mas de todo o resto?

Decidi fazer esse post rápido enquanto retomava meus estudos a respeito de WCF e assistia a um vídeo do MIX do ano passado que está no final deste post.

POST não escala, GET sim. Porquê? Por causa da semântica! POST, PUT, DELETE e outros verbos são por definição non-safe e com efeitos colaterais, ou seja, é esperado que uma request usando esses verbos modifique algum recurso. Dessa forma é impossível fazer cache desse tipo de chamada. E como todos nós sabemos, sem cache = sem escalabilidade, isn’t that right?

Vamos tomar como exemplo uma chamada a URI imaginária: http://meusite.com.br/usuario/novo passando via POST todas as informações necessárias para se criar um usuário. Se tudo correr bem, vamos receber como resposta um HTTP Status Code 201 indicando que o recurso foi criado e a URL para acessa-lo. Provavelmente algo como http://meusite.com.br/usuário/765.

Agora a pergunta: é seguro para os intermediários dessa request tais como proxies, clientes, etc efetuarem o cache disso? Não! Imagine um usuário do sistema que utiliza esse recurso tentando cadastrar um novo usuário com os mesmos dados. Ao invés de receber uma resposta de conflito ele receberia um status 201 dizendo que o recurso foi criado. De fato o recurso foi criado, mas será que deveriamos mostrar isso pra ele quando na verdade a criação desse recurso já havia acontecido e a ação que ele executou neste momento não trouxe sucesso? Acho que não.

Já o GET, por definição é cacheavel, pois não possui efeitos colaterais. Ele apenas devolve o recurso desejado sem modificar nada. Claro que isso só acontece quando bem usado, pois tem muita gente que utiliza esse verbo de maneira errada e baseado em parâmetros executa ações que deveriam ser associadas a outros verbos HTTP. Como não modifica nenhuma informação é possível efetuar o cache desse recurso com segurança.

Pra quem quiser ver mais a respeito de REST, GET, POST e cache, basta acessar o vídeo no site do MIX 09.

De volta a terrinha

Acho que todo mundo já sabe, mas para aqueles que não sabem ainda voltei ao Brasil no mês passado. A idéia era ir para os EUA e ficar por lá, mas como nem tudo na vida são rosas tive uns problemas familiares por aqui que fizeram com que voltasse. A idéia de me mudar daqui ainda é muito forte e vai acontecer. Só teve de ser postergada um pouquinho :)

Apesar de voltar pro Brasil continuo trabalhando pra HNI, mas de maneira remota, o que não deixa de ser uma experiência bem interessante dada a diferença de timezone e dificuldade de comunicação.

Isso quer dizer que vou voltar a postar bastante no blog como eu fazia antes? Espero que sim, mas agora vou fazer um pouco diferente e gostaria de um feedback de quem lê pra ver se estou agradando ou não. A idéia do blog foi sempre postar coisas que eu acho interessante e conheço, mas com alguma experiência prática e opinião pessoal no assunto. Isso faz com que os posts saiam relativamente grandes e demorem muito para serem escritos (da trabalho, mesmo que o resultado final não seja o melhor do mundo! eheheh).

Por conta dos problemas do dia a dia e da natureza do meu atual trabalho posts assim vão ficar um pouco mais raros, mas quero aumentar sua frequência em breve. Enquanto isso, vou compartilhar informações mais curtas, comentários menores e links que acho que valham a pena divulgar.

Além disso, também estou fazendo uns tweaks no blog e um deles que já pode ser visto é o de idiomas. Quando acessarem o blog pela próxima vez via HTTP o plugin vai identificar sua origem e direcionar para os posts na lingua correspondente: inglês ou português. As duas línguas vão ficar disponíveis, mas será necessário clicar no post de outro idioma para le-lo.

O endereço direto para os posts em inglês é: http://blog.tucaz.net/en e para os posts em português é: http://blog.tucaz.net/br.

Dessa maneira contínuo escrevendo em inglês e praticando o idioma e posso escrever também em portugûes conteúdo que acho que valha a pena apenas para nós brasileiros (como é o caso do próximo post que está na fila).

Ainda não sei exatamente como os feeds vão se comportar, mas vamos descobrir em breve. :)

Por último, caso encontrem problemas com o feed ou com o blog ou tenham comentários ou perguntas de qualquer natureza, POR FAVOR me avisem pra eu melhorar/resolver o que for necessário. Okidoki?

Soçarba

(Inglês) [Book Review] Startup

Desculpe, mas este post só está disponível em Inglês.

(Inglês) Basic stuff: handling exceptions in .NET

Desculpe, mas este post só está disponível em Inglês.

(Inglês) Leading by omission

Desculpe, mas este post só está disponível em Inglês.

(Inglês) Communicating and understanding are the keys to succeed

Desculpe, mas este post só está disponível em Inglês.

(Inglês) Almost good!

Desculpe, mas este post só está disponível em Inglês.