Gandralf's Blog

Já perdi a conta de quantas vezes tenho que procurar no google coisas como “install etckeeper amazon ami“. Este é um exemplo de atividade que eu faço muito de vez em quando e, exatamente por isso, nunca me lembro bem como se faz. E aí dá-lhe pai dos burros!

Enfim, os comandos são:

Etckeeper

É uma ferramenta que controla o seu /etc, com git ou bazar. Dia destes brinco um pouco com puppet & cia mas, por enquanto, estou usando ela.

Pulo do gato: habilitar o repositório epel.
No AMI: Editar /etc/yum.repos.d/epel.repo e habilitá-lo com enabled=1. Depois, mande um yum install etckeeper

Depois de instalado, faça o primeiro commit com etckeeper init e etckeeper commit.

MySQL User

Comando tudo-em-um que cria um usuário, associa uma senha e dá direitos ao zé:
grant all privileges on schulambsdb.* to 'clodiswaldo'@'localhost' identified by '1stupidpass';

Push-to-deploy

Para o pull funcionar, adicionar unset GIT_DIR logo no início do hook post-receive. O script em (meio tabajara) seria mais ou menos assim…

Ruby stuff

• Desenv packages: yum install gcc-c++ curl-devel httpd-devel openssl-devel zlib-devel libxml2 libxml2-devel libxslt libxslt-devel make
• Bundler for deployment: bundle install --deployment --without "test development"

No meu último post, Quem sabe, faz. Quem não sabe, ensina. Ou não., minha birra era com o pessoal que aumentava a resistência à inovação graças à uma combinação ingrata de arrogância, ineficiência e objetivos questionáveis. E se algumas idéias boas foram má aplicadas, pior: elas ficam “queimadas”.

Mas o post foi superficial, sobre diversos pontos. Um deles é que é sobre arquétipos, não pessoas. De fato, a mesma pessoa pode se pegar assumindo um ou outro papel. E as motivações que levam as pessoas a agirem de uma forma ou de outra mal foram tocadas.

Por último, existem outros arquétipos envolvidos nesta história que não foram citados e podem ser mal interpretados, com o do crítico.

O termo “crítico” tem um apelo extremamente negativo para a maioria das pessoas. Ele é um chato e inútil. Ou incorpora a ácida piadinha do “Crítico é que nem eunuco, sabe como faz, vê fazerem todo dia, mas nunca fez nada”. E volta e meia é um insuportável Capitão Óbvio:

Read the rest of this entry »

Faz muito tempo que tenho uma preocupação muito grande com testes automatizados.

Meu primeiro contato foi, obviamente, com o JUnit, ainda em 2001. O que mais me encantou foi a possibilidade de aniquilar um fantasma que assusta muita gente: o “eu juro que já tinha testado!”.

Quantas vezes não fiquei com carão ao ver um bug que, sim, eu já tinha corrigido, mas ele teimava em voltar. Ou ainda mais simples: um bug desconhecido (e óbvio) sobre uma funcionalidade que já tinha sido bem testada, mas que quebrou por um efeito colateral qualquer.

Assim, a primeira coisa que me pegou foi a possibilidade de ter testes de regressão. Mas, obviamente, não foi a única. Junto com isso veio outras coisas, como o TDD, suporte a refactoring de gente grande, segurança, explorações, etc.
Read the rest of this entry »

Duas alternativas interessantes em projetos (ou momentos) nos quais as mudanças são tão frequentes que o clássico planejamento de uma iteração timebox mais atrapalha do que ajuda são:

1. Entender o porque e evitar esta instabilidade. Daria para perguntar coisas como:
   • Putz, não dá para esperar um sprintzinho, não?
   • Tem que fazer isso agora mesmo e arriscar o planejamento/meta do sprint (iteração) atual?
   • A principal causa destas mudanças é X, portanto temos que fazer Y de forma a trazer um mínimo de estabilidade para o sprint corrente. Por exemplo: acúmulo de dívidas técnicas => reverter o quadro, ou priorização equivocada => trabalhar melhor o backlog antes do sprint
2. Chutar o balde e, ao invés de lutar contra estas mudanças, abraça-las de modo a trabalhar com elas da melhor maneira possível. Neste caso, aceita-se a impossibilidade (ou pouca praticidade) de se planejar um sprint com as tarefas x, y e z, sem surpresas significativas. E daí não dá para planejar o timebox bonitinho. Dá para, talvez, estabelecer um plano de entrega, baseado em metas.

Read the rest of this entry »

“Toda unanimidade é burra”. Talvez por isso prefiro diversidade de opiniões e perspectivas. Afinal, o que você espera aprender de pessoas que pensam igual a ti?

A Ffffuuuu Conf foi mais ou menos assim. Fui lá não porque queria ver uma opinião divergente, mas porque algumas das pessoas mais bacanas com quem já trabalhei fariam apresentações. E eu sabia que eles tinham algo a dizer.

Além disso, o espírito subversivo da conferência era instigante. Seria o oposto do que se vê na maioria das conferências, infestadas por drug-dealer-wannabes, com um “use isso que é legal”. Não! O espírito é o oposto: “use isso e se f*oda”!

E que venham as trollagens!

A keynote “Patterns of fail” foi épica. Ela apresentou aguns padrões que (infelizmente) presenciei. Também tinha o maior índice de trollagens por slide quadrado da conferência.
Gostei, em especial de:

• “The most interesting and character defining trait of these people is how they recovered” (de um #fail)
• Bikeshedding: quando todo mundo vai discutir picuinha. Já tinha visto isso, mas nunca imaginei que teria uma página na wikipedia. Pensei que, no máximo, numa tirinha do Dilbert.
• Behavioral Patterns, que foi o coração da apresentação. De chorar de rir… e de tristeza.

Só não posso concordar com alguns comentários sobre a 37signals & cia. Agora não me lembro de nenhum argumento em específico, mas só uma sensação de desdém sobre o trabalho deles. E sobre os fanboys que se acham depois de lerem o livro. Mas o problema não é do livro, pois eles também se achariam depois de verem meia dúzia de posts no highscalability.com.

Sinto muito, mas os caras são muito bons. Quanto ao livro, é meio um monte de causos, bem parecidos com o que já tinham escrito no blog. E alguns causos merecem ser contados, não por definirem uma verdade absoluta ou uma receita de sucesso, mas por trazerem uma perspectiva interessante. O errado é interpretar a experiência alheia, mesmo que contundente, como uma verdade científica. Vai ter gente achando que o livro é óbvio (eu, por exemplo, que já conhecia a maior parte dos pontos de vista apresentados), e vai ter gente que vai achar o livro revelador. Mas vamos voltar à ffffuuuu conf, que aqui não é sobre a 37…

Não sei como não rolou um banho de sangue depois desta apresentação.

Read the rest of this entry »

Aqui deixei algumas partes de uma entrevista do Kent Beck para a InfoQ, em janeiro de 2008.

XP is a rather practice oriented methodology. Can you describe the relationship between implementation patterns and XP and how they work together?

I think the easy part of XP is practice related, but there is 3 legs on the stool: practices, values and principles and I think people who are successful applying XP are paying attention to all 3. This gets back a little bit to some of my disenchantment with the direction of agile development in general, people are now asking the question: “How am I going to do agile development?” and agile development isn’t a thing you do, it’s an attitude, it’s a set of personal values about responding to the real world, being open to the information that is there and being willing to do something about it.

That is agility. Yes, there is a lot of practices that come out of that but to me that is where it starts, it’s this attitude. If somebody understood a bunch of practices and tried to do them, you could do agile development without being agile and it’s a disaster because you’re acting out of harmony with what you really believe when you do that.

So you’re more or less saying that you have to be agile to do agile, but you can’t do agile if you are not agile?

That is my opinion, yes. The times when I have been closed off, when I haven’t really listen to what is going on in the real world, when I built a fantasy picture in my head of how things are, I haven’t been agile. And I have all the same skills, I program the same, I know the patterns and I have the tools, but without connection to what other people are saying about what’s going on in the world, then you can’t really be agile.

Read the rest of this entry »

Netflix is the largest online DVD rental service, offering flat rate rental-by-mail and online streaming to customers in the United States(Wikipedia). The goal of the NetFlix Prize competition is to improve the accuracy of the prediction algorithm to more accurately project how individual subscribers will rate a movie based on intelligent predictions derived from finding similar users and movies in the database. This problem has been challenged to the public by Netflix themselves, available at: http://www.netflixprize.com/. Netflix already employs a movie recommendation system called Cinematch (SM) to recommend movies to current customers based on their movie renting and rating histories. The Netflix challenge is to build a recommendation system that can make recommendations with an improved accuracy of 10% over the Cinematch (SM) system as it was used by Netflix in 2006.

Mais em www.hackedexistence.com (dica do Ivan Ribeiro)

Já faz um tempo que o Google anunciou sua solução para fontes na web: Google Font API.

É uma solução bem elegante, mas tem um problema: tem poucas fontes. Bom, pelo menos para os designers mais exigentes. Enfim…

Every now and then we look around, select fresh high-quality free fonts and present them to you in a brief overview. The choice is enormous, so the time you need to find them is usually time you should be investing in your current projects. We search for them and find them so that you don’t have to.

In this selection, we’re pleased to present Piron, Nobile, St Marie, Code, Arcus, Crimson Text, Quadranta, Juice, Prociono, Mr Jones, Ibarra Real and various useful symbol fonts. Please note that some fonts are for personal use only and are clearly marked as such. Please read the license agreements carefully before using the fonts; they can change from time to time.

Resumindo: para usar a fonte, inclua o css com a definição desta, passando o nome da dita-cuja como parâmetro:
<link href='http://fonts.googleapis.com/css?family=Cantarell' rel='stylesheet' type='text/css'>
E depois… divirta-se!
h1 { font-family: 'Cantarell', arial, serif; }

O código retornado pelo CSS do exemplo:

@font-face {
font-family: 'Cantarell';
font-style: normal;
font-weight: normal;
src: local('Cantarell'), url('http://themes.googleusercontent.com/font?kit=tGao7ZPoloMxQHxq-2oxNA') format('truetype');
}

Observe que a url do css aponta para um simples arquivo de fonte true type. Em tese, poderíamos fazer algo similar em nossas aplicações se usássemos uma fonte true type livre.

Saiu na Smashing Magazine: 30 New Free High-Quality Fonts. No final deste artigo tem uma série de outros links para mais fontes free.

Agora dá para brincar legal, e não precisa mais ficar restrito às fotes do Google

Nas minhas andanças acabei encontrando este texto do Scott Ambler, sobre arquitetura: Agile Architecture. A descrição dele tem algo a ver com a apresentação da arquitetura na Gonow que fiz.

So how can you be smart about all of this? Although you don’t want to overbuild your system based on future/mythical requirements there isn’t anything wrong with thinking about the future. It is a two phase strategy:

• Initial modeling. Do some initial architecture envisioning to think things through, to explore critical concepts and thereby get you going in the right direction. This doesn’t mean that you need to create mounds of architectural documentation, although it is likely that you will do some modeling and yes, egads!, even create sufficient architectural documentation to meet your needs.
• Defer design decisions. One of the principles of lean software development is to defer commitment to the last possible moment that you need to make the decision, thereby increasing your flexibility and raising your chances of success.

Também me fez lembrar de outro post, The Scatology of Agile Architecture, desta vez do Uncle Bob

One of the more insidious and persistent myths of agile development is that up-front architecture and design are bad; that you should never spend time up front making architectural decisions. That instead you should evolve your architecture and design from nothing, one test-case at a time.

Pardon me, but that’s Horse Shit.

Quem ficou de fora do evento pode ter um gostinho do que rolou por lá. A O’Reilly disponibilizou algumas sessões em vídeo.

Read the rest of this entry »