Ronaldo Faria Lima

2012

ronaldo — Wed, 16 May 2012 10:51:06 +0000

Aqui está minha interpretação do que será, ou deveria ser, o ano de 2012. Trata-se de um som agitado, bem sintético e quase dançante, com uma bateria bem compassada e pesada.

Trata-se de uma composição feita em 2011, na verdade.

Espero que gostem.

Como as assertivas podem salvar a sua vida

ronaldo — Wed, 16 May 2012 10:43:08 +0000

A verificação de algoritmos não é uma coisa trivial. Testar código é muito menos trivial ainda. O System Test realizado pelo pessoal de Q.A. não é, absolutamente, uma tarefa simples. A criação de cenários de testes e a validação dos mesmos pode ser não somente uma tarefa enfadonha como também é uma tarefa complexa. O domínio que os testes devem cobrir é muito grande e garantir a qualidade do software escrito é uma tarefa não só da turma do Q.A. como também é uma obrigação do developer, no meu entender.

Porém, a verificação de algoritmos é algo muito complexo. Para a nossa sorte existe uma técnica que chama-se “argumentação de algoritmos”. Em linhas gerais significa o seguinte: os predicados no início do processamento são transformados nos predicados do fim do processamento. Esta lei permite que possamos usar assertivas para verificar os predicados. Se as assertivas falharem, há algo errado com o código.

A vantagem de usar assertivas para validação de predicados é que pode-se deixá-las no código. Elas são automaticamente desligadas no código de produção. Para os testes, pode-se compilar o software com as assertivas habilitadas dando ao system tester e ao developer um maior controle sobre a sanidade do software após mudanças.

É importante, no entanto, compreender como funciona a argumentação de algoritmos antes de sair distribuindo assertivas pelo seu código. Sugiro a leitura da excelente obra do dr. Arndt Von Staa, Programação Modular (ISBN 8535206086, ISBN-13 9788535206081). Esta obra detalha bastante o uso de assertivas para a argumentação de algoritmos. Trata-se de um livro relativamente antigo, mas cujos princípios são, na minha opinião, valiosos.

Episódio 2: Mais sobre o seu código

ronaldo — Sat, 05 May 2012 18:04:02 +0000

Neste episódio:

Desenhe antes de escrever seu código
Use os algoritmos mais simples que encontrar
Desenvolva de maneira incremental

É assim que você vê o seu usuário?

ronaldo — Fri, 04 May 2012 10:34:34 +0000

Os programadores, de uma forma geral, reclamam dos usuários dos seus programas principalmente quando estes expõem cenários não previstos ao código e o fazem quebrar de maneiras inesperadas. Outros reclamam que os usuários solicitam mudanças inverossímeis nos sistemas. Já ouvi gente reclamando que “o usuário é burro”, que “deram treinamento mas o usuário não sabe usar o sistema”, e por aí vai.

Eu entendo que o usuário é o motivo primário pelo qual todo e qualquer programa é escrito. Um programa de computador tem a função primária de fazer aquilo que o usuário não quer fazer para que este possa dedicar seu tempo à atividades mais nobres, como ir pescar com a família por exemplo. Todo e qualquer programa tem como premissa a automação. E a automação existe para que tarefas, antes manuais, sejam levadas à cabo por mecanismos automáticos, sendo o computador um exemplo.

É função do programador criar programas que sejam suficientemente robustos para aguentar toda sorte de usuários, ou seja, do usuário mais interessado em extrair performance do sistema ao usuário que deseja usar o sistema para procrastinar. O sistema precisa ficar em pé e precisa seguir as premissas operacionais que lhe foram impostas por projeto.

Os pedidos absurdos dos usuários normalmente vem de um fato: é uma tentativa de dizer ao programador como algo deve ser implementado, na visão deles. Por desconhecerem as entranhas do sistema e como tudo foi implementado, os pedidos várias vezes soam como absurdos aos ouvidos dos programadores. É importante tentar compreender o que o usuário precisa pois a solicitação, por mais estranha que possa parecer, partiu de uma necessidade.

A arte está em decifrar a necessidade real do usuário e implementar esta necessidade de tal forma que ela gere valor ao sistema, ou seja, que torne o trabalho do usuário mais fácil e mais rápido. Afinal, esta é a premissa de todo sistema computacional: tornar a vida do usuário mais fácil.

Existem os maus usuários, como eu disse. São aqueles que vão jogar a culpa de tudo em cima do seu sistema justamente para procrastinarem. É responsabilidade do programador fazer com que o sistema seja suficientemente robusto para evitar que tais usuários quebrem-no. Normalmente é este perfil de usuário que descobre os erros escondidos no código e sou de opinião que estes usuários são os melhores system testers que existem. Afinal, eles irão exercitar seu código de maneiras imprevisíveis e descobrirão problemas que nenhum profissional de testes seria capaz de encontrar.

Ao contrário de enxergar estes “maus” usuários como realmente “maus” é importante ter o feedback deles. Eles terão uma visão crítica do seu sistema que permitirá que você não só melhore a qualidade do código como também melhore sua usabilidade.

A arte está em saber separar o trigo do joio. Há “maus” usuários que lhe darão pistas falsas e criarão defeitos que, na verdade, não existem. E por isso é importantíssimo ter evidências de tudo o que foi feito justamente para que você tenha argumentos suficientes para rebater os “falsos defeitos”.

Em suma, mesmo os maus usuários são importantes para a evolução do seu código. E sem usuário, não há programador pois os programas foram feitos para atender as demandas, e expectativas, dos usuários e não para satisfazer o ego do programador.

Velhos hábitos para novas fronteiras

ronaldo — Sun, 29 Apr 2012 15:39:59 +0000

A tecnologia avança a tal ritmo que está começando a ficar difícil acompanhar tudo o que acontece no ramo. O fato é que a tecnologia está abrindo novas fronteiras em nossas vidas e nós continuamos presos à paradigmas antigos que começam a tornar-se obsoletos. Vejo por mim mesmo e aqui está um belo exemplo do que quero dizer: ainda ando com um belo caderno de anotações embaixo do braço quando preciso trabalhar com meus clientes para anotar suas observações e pontos-de-vista.

Por que este comportamento já que há gadgets que fazem a mesma coisa com a metade do peso e com a possibilidade de melhorar minha produtividade? Velhos hábitos, esta é a palavra. Me habituei a tomar notas com caneta e não me acostumei ainda com a ideia de anotar minhas coisas em um tablet ou coisa que o valha. Certamente estou perdendo com isso: anotar à mão é mais lento do que usar o teclado de um tablet, mesmo que virtual, para tomar notas. As ferramentas de sketch existentes para as plataformas móveis já permitem que eu desenhe livremente com os dedos, sem a real necessidade de desenhar em uma folha de papel.

A principal vantagem de usar um equipamento eletrônico para este tipo de atividade é a velocidade que se consegue obter para tomar notas sem contar com a possibilidade de compartilhamento instantâneo da informação.

Assim acontece com todo mundo. As pessoas ainda fazem inspeção visual de longas planilhas de dados ao invés de ter o computador fazendo isso por elas. Ainda buscamos informação de maneira alfabética em telas de computador ao invés de dizer ao computador o que queremos.

Parte dessa deficiência em acompanhar a tecnologia está em nossa educação. Não fomos preparados para isso. Pelo menos minha geração não foi. Quando estudei no primário e secundário o computador era obra de ficção científica. Na faculdade, computador era só para quem fazia o recém-criado curso de Ciências da Computação. No trabalho fui efetivamente ter minha primeira estação de trabalho que funcionava como um terminal telnet para um shell unix remoto – sem nenhuma facilidade gráfica nem tampouco algum tipo de aplicação de produtividade como uma agenda por exemplo.

A velocidade na melhoria da tecnologia me fez acreditar que a educação, conforme a conhecemos hoje, está defasada. Estamos ensinando matérias rudimentares nas escolas sendo que precisa-se de muito mais. Ficou claro para mim que a educação precisa continuar além das escolas, de maneira contínua, sem se limitar ao término de um curso. Se não fizermos assim, continuaremos fazendo o trabalho que as máquinas deveriam fazer para nós e, o que é pior, desperdiçando o aparato tecnológico que hoje está à nossa completa e inteira disposição.

Pense nisso.

Ambiente de trabalho: você está fazendo isso errado

ronaldo — Sat, 28 Apr 2012 17:20:18 +0000

Desenvolver software exige concentração. E para que você consiga concentrar-se, é necessário um ambiente de trabalho agradável e, principalmente, silencioso. O excesso de ruído leva à ruptura do pensamento, interrompendo muitas vezes uma linha de raciocínio muito complicada. O resultado é que o programador passa a gastar mais tempo com o que deveria fazer e como todo mundo trabalha com o prazo nas costas o resultado é código escrito às pressas.

As empresas de tecnologia que são geridas por quem não entende de tecnologia normalmente oferecem aos empregados um ambiente de trabalho open space. Este ambiente é um dos mais barulhentos que existem: telefone tocando, gente falando alto, ruído de teclado, falta de privacidade. Este ambiente é excelente para a interação entre as pessoas mas péssimo para a concentração.

As divisórias precisam ser altas. Os programadores precisam ter um espaço silencioso para concentrarem-se. Uma simples conversa ao telefone pode colocar a perder toda uma linha de raciocínio. É necessário, porém, haver um espaço comum onde as pessoas possam interagir com recursos como um quadro branco ou um flip chart, papel, canetas, café e biscoitos. A pausa para o café com biscoitos é essencial para arrefecer o pensamento.

A ideia de open space simplesmente não é adequada para desenvolver software. É preciso pensar em outra solução para distribuir as pessoas fisicamente de modo que estas tenham privacidade e silêncio necessários para concentrarem-se naquilo que estão fazendo. Simplesmente amontoar as pessoas em um espaço aberto não é uma boa ideia. Ou você já conseguiu resolver algum problema lógico intrincado com um telefone tocando até cair?

Soul Travel

ronaldo — Sat, 28 Apr 2012 10:29:49 +0000

Um som interessante. Uma brincadeira com patterns levou a esse som com uma linha de baixo bem marcante. Espero que gostem.

Ouça aos meus podcasts no iTunes

ronaldo — Sat, 28 Apr 2012 00:18:37 +0000

Uma novidade para quem acompanha o meu blog: agora você pode ouvir aos meus podcasts diretamente pelo iTunes. Há, por enquanto, apenas um único episódio no qual falo sobre o que você precisa saber para programar para iOS. Em breve vou publicar outros com assuntos já tratados no blog e alguns assuntos novos.

Espero que essa novidade seja do agrado de todos.

Faça bug tracking!

ronaldo — Fri, 27 Apr 2012 10:10:41 +0000

Se você desenvolve por conta própria, ou mesmo em um time de desenvolvimento, já teve de encarar os defeitos do seu código. Eu costumo dizer que se há código, há defeito. É virtualmente impossível escrever código sem algum tipo de problema. Somos humanos, afinal de contas.

Fazer bug tracking é muito mais do que simplesmente anotar quais defeitos seu sistema tem. Alguns programadores detestam gerar evidências do que estão fazendo e normalmente não usam as ferramentas de bug tracking de maneira adequada. Mas, qual a importância de fazer bug tracking além de satisfazer o ego do meu gerente?

O bug tracking é uma maneira de você controlar a qualidade do seu código. Normalmente os pontos mais exercitados do seu software são aqueles que apresentarão mais defeitos. E isso é esperado. O que não é esperado é o excesso de defeitos. Quando um código começa a apresentar defeitos excessivos é por que não foi desenvolvido com o devido cuidado.

Além do controle de qualidade, o bug tracking também é uma forma de criar conhecimento em cima da base de código, permitindo um acompanhamento da evolução do código. Por este motivo é importante escrever e documentar os “passes de mágica” na ferramenta de bug tracking para que seja possível verificar-se, no futuro, por que determinada decisão foi tomada e por que determinada manutenção foi efetuada de determinada maneira.

Algumas ferramentas de bug tracking também permitem que você saiba quanto tempo anda gastando com cada item de desenvolvimento. E tempo, em termos de desenvolvimento de software, é literalmente dinheiro. Quanto mais tempo você gastar consertando defeitos, mais dinheiro está jogando fora. Em verdade, quanto mais defeito tiver seu código, menor será o valor monetário do seu sistema.

Do ponto-de-vista único e exclusivo do técnico, eu vejo o bug tracking como uma forma poderosa de organizar o seu trabalho, permitindo que você crie limites para os desenvolvimentos. Isso organiza o desenvolvimento de tal forma que o trabalho torna-se mais centrado e focado em determinados aspectos.

Se você não faz bug tracking, procure fazer. Seja disciplinado e gere sempre evidências na ferramenta de bug tracking. O esforço vale a pena. Existem boas ferramentas de bug tracking no mercado, algumas pagas e outras gratuitas. Eu utilizo para os meus propósitos o Bugzilla que é muito poderoso, apesar de ter uma interface algo feia. Há ainda o Atlassian Jira, uma ferramenta paga e até mais poderosa.

Primeiro Podcast: O que você precisa para começar a desenvolver para o iOS

ronaldo — Fri, 27 Apr 2012 02:09:27 +0000

Aqui está minha primeira experiência com os podcasts. Espero que gostem!