Category Archives: livros

A estética do software

Recentemente reli A Beleza das Máquinas de David Gelernter: um livro cujo tema dentro da ciência da computação é raríssimo: estética, que sempre foi um dos meus assuntos preferidos (tente definir o que é de fato o “belo em si” e provávelmente você também se apaixonará pelo assunto).

A primeira vez que li este livro foi em 2002 (publicado no Brasil em 2000) e esta releitura foi fascinante pelo fato de que tanto o mundo como eu mudamos radicalmente de lá pra cá. É nítido um certo deslumbramento com os “computadores de mesa” presente no texto, o que chega a ser engraçado para nós, que vivemos em uma sociedade na qual os mesmos começam a sair de cena ao serem substituídos por telefones celulares com os quais sequer sonhávamos em 2000. Por outro lado, as asserções estéticas do autor continuam válidas: e como!

A tese consiste no fato de que sim: o problema estético também se aplica à ciência da computação. Porém, ao contrário da estética geral com a qual já estava acostumado, e que nunca conseguiu definir o belo com exatidão, no contexto do software esta é cirurgica. É belo no software o conciso e simples, ou seja, quanto mais bem definida for a função do mesmo, e mais simples for o seu uso, melhor será a nossa experiência estética. Parece óbvio, não é mesmo?

Como ameaça à beleza de um produto, o autor aponta um mal que aflinge a nós desenvolvedores: a nossa tendência quase irracional de incluir novos recursos em nossos produtos, aumentando assim significativamente o seu escopo de utilização e, como consequência, sua complexidade. O exemplo apontado é o Word que inicialmente era um processador de textos simples e fácil de usar mas que, com o passar do tempo, e a inclusão de novos recursos, foi se tornando cada vez mais complexo e distante do seu objetivo original: editar textos.

Trazendo esta releitura para os dias atuais, não pude deixar de fazer algumas comparações com softwares/sites/serviços que utilizamos atualmente e me perguntar: belo ou feio? O software/serviço é portanto considerado belo se for respondido “sim” a duas perguntas: o seu objetivo é simples e bem definido? é fácil de usar?. A segunda pergunta parece ser subjetiva demais: sendo assim, imagino minha mãe usando os produtos abaixo.

Dropbox (www.dropbox.com):
Objetivo: compartilhar e sincronizar arquivos entre diferentes computadores. Mais simples impossível.
Fácil de usar? Demais: tudo o que preciso fazer consiste em armazenar os arquivos a serem compartilhados em um diretório específico.
Veredito: lindo

Google:
Objetivo: encontrar conteúdo na web. Simples.
Fácil de usar? Sim, é só digitar o que se deseja encontrar.
Veredito: lindo.

Twitter:
Objetivo: possibilitar às pessoas publicarem suas idéias em apenas 140 caracteres e acompanhar outros usuários do serviço. Simples.
Fácil de usar? Nem tanto: todas as pessoas que conheço que ficaram viciadas no serviço utilizam algum cliente para acessar o serviço ao invés do próprio site.
Veredito: bonitinho (quase feio. os clientes são até belos, mas o pai deles nem tanto)

Firefox:
Objetivo: navegador web. Simples.
Fácil de usar? Sim, não há grandes complicadores no navegador. No entanto, com a inclusão de plugins o bichinho acaba se tornando um monstrinho cheio de coisas piscando pra você o tempo inteiro.
Veredito: belo com tendência a Michael Jackson.

Planilha eletrônica:
Objetivo: criar tabelas com células interligadas ou não entrei si visando calcular valores e prever resultados ou simplesmente organizar informações no formato tabular. Posteriormente, acabaram em inúmeros casos sendo usadas como aplicações ou bancos de dados. Simples? Nem um pouco!
Fácil de usar? Conheço poucas pessoas que dominem de fato o uso do Excel.
Veredito: horrívelmente deformado pelo mal uso

Um ponto interessante no texto é a dificuldade que a beleza do software possui de ser aceita. Segundo o autor, esta dificuldade seria resultante do fato de softwares estéticamente agradáveis serem considerados “brinquedos” pela maioria (“afeminados” é a palavra usada pelo autor) e, portanto, não serem levados a sério. E é ai que as coisas melhoraram.

Observando todo este buzz sobre Web 2.0, o que podemos observar é que sim: as aplicações estão mais simples e também mais fáceis de serem usadas. Logo, o software atualmente é mais belo E, a resistência citada pelo autor foi vencida, o que beneficia muito a nós, usuários, e também a mim, que não vou precisar gastar horas explicando minha mãe a como usar estes serviços. :)

PS: vale a pena comprar o livro hoje? Só se for pra ver como era o mundo antes do ano 2000. Ele se resume em apenas dois fatos: software belo é conciso e simples E há dificuldade em se aceitar esta beleza (esta segunda tese nem sequer vale mais tanto assim)

Livro “A arte do Desenvolvimento Ágil”:bacana, porém com tradução de merda

Recentemente terminei de ler o livro “A Arte do Desenvolvimento Ágil”, de James Shore e Shane Warden, publicado aqui no Brasil pela Alta Books. Venho me dedicando ultimamente a me aprofundar no assunto, sendo assim, como já havia lido algumas resenhas do original em inglês, ao encontrar em uma livraria o memso já traduzido para o português a compra foi imediata.

O foco consiste na XP. Ok com relação a isto. Afinal de contas, como nunca havia lido algo de mais profundo a respeito (apenas diversos artigos em revistas e na Internet), seria uma experiência interessante.

De fato valeu a pena: a abordagem do livro é muito bacana. Boa parte do foco diz respeito ao modo como se deve implantar metodologias ágeis em ambientes mais tradicionais de desenvolvimento, o que cai como uma luva para o meu caso. Encontrei diversas sugestões que, quando coloquei em prática, REALMENTE me ajudaram MUITO a solucionar uma série de problemas com os quais me deparava já havia algum tempo.

Outro ponto que gostei DEMAIS são as seções de perguntas e respostas. Na maior parte das vezes, parecia que o autor sabia exatamente quais eram as dúvidas que haviam surgido na minha cabeça ao finalizar o capítulo.

Também é muito legal o fato de ficar nítido desde o início não se tratar do trabalho de autores deslumbrados com XP. Na realidade, muito pelo contrário, em todos os capítulos sempre há uma seção chamada “Contra indicações” aonde são expostos os casos aonde algumas das práticas da XP (e a própria XP) não devem em hipótese alguma serem adotadas.

Quando alguma prática não é viável para determinadas situações, o livro também vêm com seções chamadas “Alternativas”, aonde, como o próprio nome já diz, são expostas outras abordagens às práticas da XP. No meu caso, estas se mostraram valiosíssimas, pois como sofro com a falta de alguns dos recursos básicos (como por exemplo uma equipe maior), as alternativas se mostraram as únicas soluções viáveis para alguns dos meus problemas.

Resumindo, é um livrão.

Um livro excelente com um trabalho de revisão e tradução que é um LIXO

Pra começar, há diversos erros de português. Ora, não é trabalho da editora AO MENOS passar um corretor ortográfico? Quando você encontra um capítulo entitulado “Evitando o Disperdício” (capítulo 13), e, no transcorrer de TODO O TEXTO, o revisor não ter notado que se escreve “o cenário”, e não “a cenário”, é sinal de que simplesmente não há revisão. Plural por exemplo é algo que, tenho certeza, trata-se de um conceito desconhecido para o tradutor/revisor deste livro.

Na realidade, o trabalho de tradução e revisão do livro é tão porco que em alguns momentos preferi consultar algumas das palavras que encontrei no site da O’Reilly (http://oreilly.com/catalog/9780596527679/) para ver se REALMENTE eram o que eu estava pensando. Quando este tipo de situação ocorre, tenha certeza: não é o reslutado de um trabalho de excelente qualidade.

Em alguns pontos, são feitas traduções literais que chegam ao ridículo. Por exemplo: o que você acha que é um “desenvolvimento em 10 minutos”? Respondo: “Ten Minute Build”. E esta é apenas uma das pérolas que encontrei.

Compro ou não compro?

Apesar de todos estes problemas com a revisão/tradução do livro, repare no que escrevi acima:

“o trabalho de tradução e revisão do livro é tão porco que em alguns momentos preferi consultar algumas das palavras que encontrei no site da O’Reilly”

Se o CONTEÚDO do livro tivesse a mesma qualidade que a sua tradução/revisão, com certeza eu não teria me dado a este trabalho. Sim, no final das contas, a leitura valeu MUITO à pena. A pergunta que deveria ser feita neste ponto portanto é: compro a tradução nacional? Só se for a sua única opção. Caso seja este o seu caso, siga o meu conselho: tenha o site da O’Reilly aberto ao seu lado durante a leitura, pois com esta tradução…

Behind Closed Doors – como o gerente dos sonhos trabalharia

Behind Closed Doors

Behind Closed Doors

De uns tempos pra cá tenho tido a necessidade de aprimorar o meu lado “gerencial” (algo incrívelmente rock orgasmico está para acontecer nos próximos meses (mistério por enquanto)). Sendo assim, abandonei por algumas semanas a minha leitura convencional (nada de Wittgenstein e Hegel, muito menos algoritmos de qualquer espécie…) para tentar entender como de fato funciona o trabalho de um gerente.

Na minha busca por leitura apropriada, topei com inúmeros livros intragáveis. Eu não quero ser um expert em administração/gerenciamento/burocracia. Quero apenas saber se estou fazendo as coisas da maneira correta e, melhor ainda: aonde estou vacilando feio na minha percepção de gerenciamento. E o “Behind Closed Doors” caiu como uma luvra pra mim.

Isto porque não é um livro de administração convencional: não há teorias expostas, muito menos regras rígidas sobre como o trabalho de gerenciamento deve ser feito. Ao invés, as autoras optaram por narrar o cotídiano de um gerente fictício (Sam) que é basicamente o gerente que qualquer um sonha ter. Num primeiro momento, o que veio à minha mente foi: “putz! isto deve ser brega pra cacete!”: ainda bem que estava errado, pois a abordagem funciona muito bem. São expostos pequenos detalhes do dia a dia que separam um gerente idiota de outro funcional. A todo momento me vinha aquela sensação de “ahn… então é por isto que fulano fez aquilo…”.

(aliás, a escolha feita pelas autoras faz sentido, visto que o livro faz parte da excelente coleção “The Pragmatic Programmers”)

Acredito que para pessoas como eu, que possuem paixão pela parte técnica do trabalho e uma certa preguiça relacionada à area gerencial o livro expõe um lado prático da gerência que destrói diversos preconceitos relacionados a esta área. O leitor tem uma noção de como um gerente deve lidar com situações como por exemplo funcionários insatisfeitos ou falta de foco dentro das empresas, sem utilizar aquele vocabulário pedante com o qual topei em outras leituras intragáveis sobre o assunto.

Realmente recomendo a leitura do livro. Porém se você estiver sob o domínio de um gerente idiota, um aviso: você sentirá IMENSA inveja dos subordinados de Sam!

Leituras obrigatórias (ao menos pra mim) a todo desenvolvedor

Uma das grandes frustações que tenho diz respeito aos livros que leio, pois conheço pouquíssimas pessoas que também os leram para que possamos trocar algumas idéias a respeito. Sendo assim, dado que este blog está ficando cada dia mais popular (muito obrigado a todos vocês por isto), segue aqui alguns dos livros que, pelo menos na minha opinião, são essenciais para a formação de um bom desenvolvedor.

E, claro: poeremos posteriormente debater a respeito. O que acham?

Sendo assim, aqui vem a lista:

Code Complete: de Steve McConell

Quase uma bíblia para mim. Aliás, é um dos poucos livros que li basicamente todas as edições (li a primeira em inglês e a segunda em português). Se você procura por um guia de boas práticas de desenvolvimento, EIS a fonte.

O livro trata basicamente da etapa de implementação dos sistemas e, o mais interessante é que, apesar de ser publicado pela editora Microsoft, trata de problemas comuns em diversas outras linguagens não-Microsoft, como por exemplo Java, Pascal, Cobol e outras.

E sabem o que é mais engraçado? Após ler o livro, e em seguida confrontar a Win32, fica nítido que a própria Microsoft deveria ter lido com mais atenção ao mesmo. :)

Introduction to Algorithms: Thomas H. Cormen

Um fato que me choca: poucos desenvolvedores possuem um livro básico de algoritmos em sua biblioteca. Curiosamente, quando estou trabalhando em algo realmente cabeludo, um dos primeiros livros que procuro é justamente este.

São os algoritmos básicos que vemos na faculdade: ordenação, grafos, processamento de caracteres, etc. Sendo assim, o que este livro tem de diferente dos demais? Simples: é a referência básica usado por estes.

The Art of Computer Programming: Donald E. Knuth

Publicado em quatro volumes (o quarto só saiu 20 anos após a escrita dos três primeiros), é A BÍBLIA para quem leva desenvolvimento REALMENTE a sério ( ficaria muito feliz se me dessem o box contendo os quatro volumes de presente).

Me lembro que costumava andar com estes volumes debaixo do braço como se fossem a coisa mais valiosa do mundo enquanto estudava na UFMG. O que realmente fascina neste livro consiste no fato de seu primeiro volume ter sido publicado em 1968 e, até hoje, ser extremamente atual.

Se o “Introduction to Algorithms” do Cormen é a fonte de referência de todos os outros, este é a referência básica de Cormen. O que é bacana neste livro consiste na abordagem científica que Knuth dá aos algoritmos. E a maneira como é escrito também é maravilhosa. Um clássico (e só pra lembrar, aceito doações!).

Me lembro que era extremamente caro até bem pouco tempo atrás, mas atualmente já é possível comprar o box completo na Amazon por um preço bem razoável.

A Linguagem de Programação C: Kernighan e Ritchie

O livro que torna muita coisa clara. Li a primeira edição do mesmo em inglês na faculdade e foi realmente um momento de iluminação para mim.

Como vêm diretamente da fonte (são os criadores do C descrevendo-o), acaba por explicar muito mais do que o simples funcionamento da linguagem. O interessante é que este pequeno livro acidentalmente vai além da própria linguagem C. No final das contas, o leitor irá ler a descrição de como funcionam de fato elementos presentes em praticamente todas as linguagens de programação, como por exemplo strings, ponteiros, variáveis, etc.

Mesmo que você jamais venha a escrever uma única linha em C, a leitura deste livro é obrigatória para aqueles que desejem saber como as coisas REALMENTE funcionam por trás dos panos.

Escrevendo Código Seguro: David Leblanc

Outro bom livro da editora Microsoft (aliás, eles tem títulos ótimos): basicamente, se o “Code Complete” é um guia de boas práticas de desenvolvimento, “Escrevendo Código Seguro” pode ser visto como um quase excelente guia de como se, como o próprio nome já diz, se deve escrever “código seguro”.

Entra na lista por ter sido uma experiência incrívelmente reveladora para mim. Isto porquê me expôs a diversos dos erros que até então eu estava cometendo e simplesmente não me dava conta. É incrível como sua auto estima vai para o chão após sua leitura (isto é ótimo!).

Há muito conteúdo relacionado à geração de código em si, porém muito mais interessante é a  parte “administrativa” do mesmo, ou seja, quando o autor expõe como desenvolvedores devem se relacionar com seus colegas de trabalho ou clientes quando o assunto é segurança.

E aí você me pergunta: “porque um guia quase excelente”? Simples: o foco é basicamente tecnologias Microsoft e, apenas tecnologias Microsoft, o que é compreensível levando-se em consideração qual a sua editora.

Bem, estes são os livros que, ao menos na minha opinião, deveriam estar na estante de todo desenvolvedor que leve a sério seu trabalho. E as suas sugestões? Quais seriam? E com relação a estas, o que achou?