Gandralf's Blog

Just another WordPress site

Archive for the ‘Development’ Category

O Contexto é o Rei

leave a comment

Desenvolver um software para uma startup e sacrificar algo como testes automatizados? Nem pensar!

Lá no Quora, o Kent Beck deu uma boa resposta a uma questão: fazer os testes automatizados ou não, no início de uma startup? (~6 meses)

The needs of a startup before product/market fit are very different than those after. Before, you need the absolute lowest possible latency from idea through implementation to validation. If you can do that without any code at all, so much the better. Reducing latency gives you the chance to experiment as many times as possible for a given amount of money to increase your chances of survival. After you find a product that meets a real market need, you need to shift to a throughput-oriented engineering strategy so you can last until revenue ramps up.

The practical implications of this for testing is that before product/market fit you should only write tests that reduce latency. Sometimes this means no automated tests. As a feature proves promising and you begin to elaborate it, this means just enough tests to keep the validation cycle short. If a feature is complicated AND YOU CAN’T THINK OF A CHEAP WAY TO TEST IT, you may have to write extensive tests to get the feature to a verifiable state.

Then comes the transition. You’ve started growing. You’re feeling the pain of scaling. Now you need testing. More than that, though, the whole organization needs to begin valuing throughput instead of latency. If that shift takes place, then extensive testing comes along as a natural consequence.

Menos dogma, mais atenção ao contexto. O contexto pode tornar o que é comumente visto como tosco na coisa certa, e vice-versa. Aí, descambando para o lado zen, eu diria: Be water, my friend.

Written by gandralf

June 13th, 2014 at 3:10 pm

Posted in Development

Comandos de infra que de vez em quando uso (mas sempre esqueço…)

leave a comment

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"

Written by gandralf

December 28th, 2012 at 1:27 am

Posted in Development,Infra

O Crítico

leave a comment

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:
o crítico, versão capitão óbvio
Read the rest of this entry »

Written by gandralf

September 12th, 2011 at 7:09 pm

Posted in Development

Japybara – testes funcionais e de integração para java

leave a comment

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 »

Written by gandralf

August 7th, 2011 at 8:13 pm

Quando iterações atrapalham (aka scrum x Kanban)

leave a comment

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 »

Written by gandralf

April 5th, 2011 at 6:15 pm

Posted in Development

Tagged with , , ,

#ffffuuuuconf

5 comments

“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 »

Written by gandralf

November 23rd, 2010 at 6:30 am

Posted in Development

Tagged with , , , , ,

Entrevista com o Kent Beck

leave a comment

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 »

Written by gandralf

November 20th, 2010 at 7:35 pm

Posted in Development

Tagged with , , , ,

Machine Learning Algorithm for the Netflix Prize (Hadoop, Java, Python)

leave a comment

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)

Written by gandralf

August 16th, 2010 at 1:34 am

30 + 20 + 25 + 15 + 40 New Free High-Quality Fonts

leave a comment

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

Written by gandralf

August 16th, 2010 at 1:31 am

Agile Architecture

leave a comment

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.

Written by gandralf

August 16th, 2010 at 1:22 am