Exemplo triste – Aconteceu comigo

Ontem a tarde me aconteceu uma situação pouco comum. Após terminar o jogo do Brasil pela Copa 2010, fui com minha esposa ao supermercado fazer algumas compras. Compramos um bocado de coisas. Diria que fiquei mais de 1 hora no mercado. Na hora de pagar, eis que surge um problema. O cartão Alimentação Pass da Sodexo não funcionou. A máquina informou a seguinte mensagem: “FALHA NA COMUNICAÇÃO” (que imagino ser um problema de rede ou algo do tipo). A caixa do mercado repetiu o processo em outra máquina e o problema permaneceu. Até ai tudo bem. Afinal, indisponibilidade é algo que pode acontecer.

Passado alguns minutos, a caixa chamou o fiscal do mercado que nos atendeu de forma simpática e pegou uma outra máquina para tentar novamente fazer o pagamento (nesse momento eu já estava pensando em usar o cartão do banco de deixar pra lá o sodexo). Eis que a máquina informa que o saldo estava zerado, ou seja, teoricamente em alguma das passagens a compra foi paga. Percebi então que uma simples ida ao mercado ia me dar uma dor de cabeça sem tamanho.

O simpático fiscal, ao verificar o problema, foi a gerência da loja para tirar relatórios e verificar o que aconteceu. Voltando, a única coisa que saiu no relatório foram transações não concluídas. Nesse momento eu perguntei ao fiscal: O sistema não informa qual foi o problema? Ele me disse: Não, o sistema só informa que não foi relalizada. Acabei ficando sem saber o que estava acontecendo de fato, já que meu saldo estava zerado. A minha única certeza é que em algum lugar foi debitado a compra do meu cartão sodexo.

O próximo passo foi tentar verificar na sodexo. Abri meu iphone e entrei no site para verificar o saldo. Digitando o número do cartão e cpf, recebi a mensagem “Não foi encontrado um cartão para os dados informados”. Achei um pouco estranho e liguei para um amigo, passei meus dados e pedi para ele verificar, pois poderia ser que o site não oferecesse um comportamento correto no browser do iphone. Ele verificou e a mesma mensagem apareceu. Caiu a ficha. Estava acontecendo algum problema grave na Sodexo.

Liguei então para central de atendimento. O atendimento eletrônico me pediu o número de cartão e senha e em seguida me informou o saldo. Para minha surpresa, o saldo era o dobro do saldo que deveria ser, ou seja, nem estava zerado, nem estava correto. Comecei a falar com o atendente e pedi meu saldo novamente. Ele me disse: Seu saldo é zero. Retruquei: Como zero se o atendimento eletrônico me disse o saldo X? Ele respondeu: Houve uma queda geral nos sistemas e estamos dando o prazo de até as 00:00 de hoje para tudo voltar ao normal.

No fim das contas paguei com cartão de débito do banco.

Análise do problema.

Após esse incidente, pensei um pouco sobre esse sistema de pagamentos.

Sobre a compra, provavelmente o que aconteceu é que o Sodexo debitou o valor e como a máquina não respondeu e o sistema caiu, a transação deve ter ficado pendente, prendendo meu saldo. Nesse momento, fazia sentido não ter saldo até que o sistema fosse restabelecido por completo. Mesmo assim, alguma coisa me incomodou. Por que a mensagem de retorno não poderia informar o que estava acontecendo? Não poderia informar alguma coisa melhor que “FALHA NA COMUNICAÇÃO”? Naquela hora, eu não sabia se o problema era da Sodexo, que não informava um código/retorno de erro adequado, ou se a máquina não tratava os retornos de erros corretamente.

Enviar mensagens de erro corretamente e fazer tratamento de forma adequada são fundamentais na comunicação com o usuário, quando o sistema apresenta comportamentos inesperados. A falta de atenção nisso é mais comum do que parece e vou exemplificar. Existem diversos sistemas que ignoram mensagens, como por exemplo situações onde um dos lados (ou ambos) em uma comunicação  ignoram os status code http. Ex:

HTTP/1.1 200 OK
Content-Type: text/xml

<error>
  <code>123</code>
  <message>Ocorreu um erro</message>
</error>

Percebeu o problema?

Outro caso bem comum acontece quando quem envia uma mensagem para um objeto trata todos os retornos de erros de forma igual e não mostra claramente a mensagem. Ex:

try {
  objeto.fazAlgumaCoisa();
catch (Exception e) {
  log.error("Deu algum erro");
}

Já vi muito código assim e isso dificulta bastante pra quem está tentando entender o que está acontecendo.

Pior que isso foi o sistema web me dizer que não achou meu cartão, quando na verdade algum outro sistema que esse se comunica estava fora do ar. Não podia simplesmente informar algo como “Nosso sistema está em manutenção, previsão de retorno para X horas”? Cartão inexistente é inadmissível, pois certamente o cliente ficará confuso sobre o que está acontecendo.

E o saldo no atendimento eletrônico que estava dobrado? Eu aprendi certa vez que esse tipo de informação deveria vir de somente um lugar. No caso eu obtive 3 valores diferentes para meu saldo, o que me indica que esse principio não foi respeitado.

E sobre a indisponibilidade do sistema? Que tal enviar automaticamente um SMS/twitter/email ou qualquer outra coisa para que os clientes possam se preparar para esse tipo de situação? Ser pego de surpresa é sempre ruim.

Conclusão

Comunicação não é só importante entre pessoas. Nossos Softwares precisam comunicar-se adequadamente com seus usuários. Muitos ignoram isso completamente. Tenho certeza que podemos melhorar isso.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Vou fazer um resumo das palestras que assisti.

Chad Fowler – http://chadfowler.com

A palestra do Chad foi como sempre focada em carrreia. Ele advertiu os desenvolvedores que produzem porcaria todo dia sem peso algum na consciência. Ele pensa (e eu também) que nós não devemos investir tempo desnvolvendo coisas que já sabemos que são porcaria. E isso não é pessimismo, simplesmente é não perder tempo.

Chad falou também sobre os FUDs que sempre usam contra Ruby/Rails. Isso não foi nenhuma novidade mas ele abordou de forma bem divertida e valeu muto a pena.

Uma das partes mais legais foi a estatística mostrando que Ruby só faz parte de 6% da requisição do usuário. Na verdade não só ruby, mas outra tecnologia também. Isso bom para refletirmos sobre as discussões sobre performance e escalabilidade das aplicações web.

Gregg Pollack – http://envlabs.com

O foco da palestra do gregg foi sobre como atacar alguns pontos para o otimizar sua aplicação Rails. Dentre as formas, ele apresentou algumas gems/plugins que ajudam a identificar alguns pontos para melhoria de performance em uma aplicação. Vou destacar algumas:

• Bullet – Ajuda a identificar queries com alguns problemas. Ex: N + 1
• Rails Indexes – Identifica colunas onde deveriam ter índices. Se baseia nas buscas do sistema.
• Scrooge – Faz com que o ActiveRecord passe a buscar somente os campos que estão sendo usados, ao invés de buscar todos os campos. Ex: em um find(:all), após a primeira execução, o scrooge identifica quais campos foram usados e ná próxima vez modifica a query para não buscar os campos desnecessários.
• Rack Bug – É uma Monitor para aplicações Rack. Fornece basicamente todas as informações. Sessões, CPU, Memória, etc. Bem útil
• oink – Mostra detalhes dos requests de cada controller. Ex: consumo de memória.
• Cloud Crowd – Servidor para rodar tarefas em background. Feito em sinatra.

Ilya Grigorik – http://www.igvita.com/about/

Ilya falou sobre integração/comunicação de aplicações baseadas em web, utilizando-se de tecnologias como XMPP, AMQP, Webhooks, PubsubHubbub. Foi bem interessante, pois a maioria do auditório conhecia pouco sobre o assunto.

Fabio Akita – http://akitaonrails.com

A palestra do akita foi sobre agile. Ele falou bastante sobre a teoria do caos, sistemas complexos e a evolução das coisas. No fim, o recado maior foi alertar que agile não é o último estágio no desenvolvimento de software, deixando claro que temos (e vamos) que evoluir ainda mais.

Glenn Vanderburg – http://blog.thinkrelevance.com

Palestra sobre o framework Tarantula, que tem por objetivo fazer testes de ataques XSS, SQL Injection, entre outros. Achei bem interessante, pois é possível automatizar esse passo, que geralmente fazemos manualmente. Glenn inclusive sugeriu que faça parte do build antes de lançar um release.

Fabio Kung – http://fabiokung.com/

Fabio fez uma ótima palestra sobre DSLs (Domain Specific Languages) internas usando Ruby. Ao invés de apresentar exemplos simples ele apresentou um exemplo real de uma necessidade de uma aplicação que trata de instâncias de máquinas na cloud da Locaweb.

Carlos Vilella http://lixo.org

Carlos fez uma palestra bem curta, falando sobre o uso de Ruby na Thoughtworks. Falou sobre os poucos projetos que falharam e deixou o restante do tempo para perguntas.

Tapajós – http://tapajos.me/

A palestra do Tapajós foi sobre bancos de dados não relacionais. Focado bastante em CouchDB e Rails, ele explorou algumas features chaves na utilização dessa abordagem de banco de dados, também fazendo uma curta palestra e deixando boa parte do tempo para perguntas.

Bruno Miranda – Rails não escala

Eu gostei muto da palestra do Bruno, apesar de achar que o que ele falou é básico para qualquer Arquiteto de Software experiente.  Bruno falou bastante sobre filas, sharding, Cache, Proxy reverso, otimização de queries e sobre rodar processos em background. Acho que a palestra dele foi válida pois qualquer um hoje em dia que aprende tecnologias como Rails sai fazendo aplicações sem um conhecimento mínimo de arquitetura de software. Quando as coisas não dão certo culpam a tecnologia, gerando FUDs.

Vinicius Teles (http://improveit.com.br/) – Empreendorismo

A palestra do Vinícius foi ótima para quem pretende desenvolver um produto e/ou abrir seu próprio negócio. Ele abordou pontos como Fluxo de Caixa, oportunidades vastas que existem no Brasil e o impacto de pequenas decisões certas ou erradas que tomamos na nossa vida profissional.

Obie Fernandes – http://obiefernandez.com/

A palestra do Obie encerrou o evento em grande estilo, falando sobre talento, esforço e reforçando bem o que eu disse há um tempo atrás nesse blog. Não adianta você saber um monte de coisas se não souber bem, se não tiver experiência com isso, treino, treino e mais treino. Você só ganha nível com tempo e treino, isso é fato.

Pra finalizar, gostaria de parabenizar ao Fabio Akita e a Locaweb pelo excelente evento mais uma vez.

E ano que vem tem mais.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Aplicativos Open Social parecem algo como uma brincadeirinha de criança, coisa que qualquer pessoa faz. Mas na verdade, desenvolver esse tipo de aplicação para um programa como o Big Brother Brasil não é tão simples. Aplicações de grande volume geralmente usam arquiteturas recheadas de cache, processamento assíncrono usando fila, criptografia, alguns servidores e um bocado de outras coisas que o torna tão complexo quanto qualquer outro sistema.

Quero aproveitar também e destacar, que conseguimos desenvolver o produto completo “do zero”, em pouco mais de 1 mês. Isso inclui configuração de todos os servidores (inclusive produção que são várias máquinas), ambiente interno de desenvolvimento, servidor de integração contínua, desenho dos bonecos dos brothers de forma personalizada, vários testes de carga em ambientes que simulam produção e muita comunicação. Estou falando disso, pois usamos metodologias ágeis e acredito fortemente que se não fosse assim, não teria sido possível entregar o aplicativo nesse tempo (e não trabalhamos nenhum fim de semana). No caso específico aqui da globo.com, SCRUM é a metodologia usada, mas poderia ser Extreme Programming ou alguma outra qualquer. Um detalhe também importante é que nosso time tem apenas 10 pessoas, o que contraria um pouco o modelo tradicional que diz que com mais gente o trabalho anda mais rápido.

Se você gosta de Big Brother Brasil e deseja expressar sua opinião sobre algum brother, entre na seção de aplicativos do orkut e procure por: BBB – Voodoo Brother.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Essas situações são muito frequentes, principalmente a primeira, com códigos fedorentos. Por isso, eu adoto uma postura: Sempre assino meus códigos.

O que seria assinar o código? Bem, assinar o código é aquela simples documentação que vem logo acima do arquivo, como por exemplo em Java, usando o famoso javadoc:

package xpto;
import x;
/**
* @author Emerson Macedo
*/
public class Abc {
// ...
}

Assinar o código pode parecer meio arrogante mas o objetivo não é esse. O propósito de assinar o código e se expor. Quando você assina alguma coisa, explicitamente está colocando a sua autoria naquilo, ficando sujeito tanto a críticas, quanto a elogios.

Quando algum pintor faz um quadro, ele sempre vem assinado em alguma parte. Dificilmente o autor dessa obra de arte vai terminar esse quadro antes que ele tenha certeza que está com ótima qualidade (pelo menos na visão dele).

E no que isso implica? Isso implica que você (1) vai pensar 2 vezes antes de colocar aquela habitual gambiarra no seu código, (2) vai pensar bem antes de concluir alguma coisa sem devidos testes automatizados e (3) vai ser muito mais responsável com o código que você está desenvolvendo.

Conclusão

Como qualquer desenvolvedor, já desenvolvi códigos ruins em diversos projetos pelos quais passei. Aquele que nunca desenvolveu código fedorento que atire a primeira pedra. Hoje em dia, não desprezo a qualidade daquilo que desenvolvo. Acredito muito que quando assinamos nossos códigos e nos damos conta que outro desenvolvedor/programador irá utiliza-lo futuramente, isso gera um maior cuidado com a qualidade.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.