Categorias
Reviews

Programming Embedded Systems, Second Edition

Programming Embedded Systems, Second EditionRecentemente recebi gratuitamente uma encomenda com 4 livros da editora O’Reilly para que eu fizesse as resenhas desses livros.

Antes de tudo eu devo avisar que essa resenha não pertence à série de resenhas que eu vinha fazendo, e que devo continuar em breve, à qual eu dei o nome de “Leitura Obrigatória”.

O livro de hoje é o Programming Embedded Systems, Second Edition. Eu já estou quase terminando a leitura deste livro e já me sinto à vontade para recomendá-lo por aqui porque eu realmente me empolguei com o material.

Como muitos já sabem eu voltei a praticar o antigo hobby de montar dispositivos eletrônicos, e desde que eu havia parado de brincar com essas coisas muita coisa mudou. Hoje em dia é muito comum encontrar microprocessadores e microcontroladores em vários projetos, e trabalhar com esses componentes exige um conhecimento que mora entre a eletrônica “pura” e a informática.

Como eu já tenho bons conhecimentos de informática e meus conhecimentos de eletrônica “pura” estavam evoluindo com a prática do meu antigo hobby, estava faltando construir a ponte que iria unir essas duas áreas do conhecimento.

Na mesma época recebi uma proposta da O’Reilly para fazer resenhas dos livros de Python deles e aproveitei para pedir alguns títulos que tratavam de dispositivos embarcados. Recebi este livro juntamente com outros 3 de Python (aguardem resenhas) e comecei a lê-lo.

O livro tem foco prático como em quase todos os títulos da editora O’Reilly. Os autores realmente irão desenvolver o assunto em cima de uma plataforma real de desenvolvimento que usa um processador ARM XScale e irão conduzir o leitor desde o ponto onde a gente faz um LED piscar até o momento onde desenvolvemos aplicações reais com RTOS e Linux.

O livro fala sobre device drivers, interrupções, registradores, memória e sobre como gerenciar e desenvolver software em C (gcc) para usar todas essas funcionalidades.

Vale destacar que esse livro fica exatamente na fronteira entre um livro de nível básico e um livro avançado, ou seja, se você não entende nada de eletrônica e muito pouco de informática esse livro não irá lhe servir. Se você também já é um especialista no assunto pode achar o livro massante demais na primeira parte que trata de assuntos mais básicos.

O próximo passo agora é adquirir um kit de desenvolvimento parecido com esse que foi proposto no livro e começar a brincar. Eu tenho certeza que eu vou me divertir muito com esse tipo de coisa depois de ler este livro.

Para comprar: Programming Embedded Systems, Second Edition

Categorias
Reviews

Fundamentos do desenho orientado a objetos com UML (Fundamentals of Object-Oriented design in UML)

Fundamentals of Object-Oriented design in UMLComo eu já havia comentado na minha resenha anterior (Padrões de Projeto) este livro foi fundamental para o meu entendimento sobre programação orientada à objetos. De todos os livros que considero leitura obrigatória este entrou na lista este entrou na lista mais por “gratidão aos serviços prestados” do que por ser um livro “matador”.

É bem provável que existam livros que tratam sobre o desenho orientado à objetos que são mais completos do que este mas esse me cativou pela forma como foi escrito. Ele é um livro que trata de assuntos realmente chatos e complicados de se explicar usando uma dose muito sutil de bom-humor.

Em um dos capítulos o autor, Meillir Page-Jones, lista uma série de erros comuns que são cometidos por programadores de primeira viagem e explica porque esses erros ocorrem. O exemplos citados por eles são bastante capciosos e em alguns casos a gente consegue perceber que estão errados mas não conseguimos imaginar como consertaríamos esses erros. Neste caso então ele nos acompanha passo a passo até a solução do problema listado.

Outros assuntos tratados de forma mais séria e profunda no livro são relacionados à idéia básica da POO que é desenvolver sistemas com:

  • Alta coesão
  • Baixo Acoplamento

Desenvolver componentes de software com alta coesão, baixo acoplamento e pensando em interfaces no lugar de tipos (como sugerido no livro Padrões de Projeto) certamente farão com que seus sistemas fiquem extremamente robustos. Se eles forem acompanhados de Testes automatizados (XP), refatorados constantemente (Refatoração) não consigo pensar em um adjetivo melhor do que “perfeito” para atribuir ao seu trabalho.

Eu li a versão traduzida para o português deste livro. A tradução foi feita pela editora Makron e achei a tradução razoável. Não é uma boa tradução mas a leitura e o entendimento do assunto não fica comprometida por causa dela. Me parece também que a versão traduzida saiu de circulação e por essa razão pode ser mais complicado achar a versão traduzida para comprar.

Para comprar: Fundamentos do desenho orientado a objetos com UML ou Fundamentals of Object-Oriented design in UML

Categorias
Reviews

Design Patterns (Padrões de Projeto) – Review

design-patterns-bookProgramo computadores há muito tempo. Quando iniciei minha ‘carreira’ usava a linguagem BASIC e LOGO em meu MSX Expert (BASIC) e um TK3000 (LOGO). A linguagem BASIC causou alguns estragos gigantescos em meu cérebro tornando superdifícil aprender a programar em uma linguagem estruturada futuramente. Foi difícil eu perder o meu apego ao “GOTO”.

Mas depois de ter lido um livro sobre Turbo Pascal, cujo nome do autor infelizmente não me recordo, todo o que eu já tinha visto sobre o paradigma procedural se encaixou magicamente e aquilo começou a fazer sentido pra mim. Eu gosto de chamar isso que aconteceu comigo de ‘iluminação’.

Então esse livro sobre Turbo Pascal me iluminou para que eu compreendesse o paradigma procedural.

Mas então os programadores gritaram: “Faça-se a OO” e a OO “se fez”. Lá fui eu novamente correr atrás de entender como essa tal de “Programação Orientada a Objetos” funcionava.

Li muita coisa. Vi muito hype em cima do assunto. Vi muita mágica sendo feita e muita mágica sendo desfeita usando-se POO. Mas aquilo ainda não fazia muito sentido pra mim.

Depois de ler um livro chamado “Fundamentos do Desenho Orientado a Objetos” (que falarei no futuro) o meu cérebro começou a criar as conexões entre todo o conhecimento que eu já tinha adquirido. Mas faltava a faísca para produzir o fogo que me iluminaria.

Com a popularização da linguagem Java vários hypes surgiram (e continuam a surgir) e entre eles estavam os “Design Patterns“. Nem dei muita atenção porque as ‘modinhas’ produzidas no universo javanista são tão duradouras quanto a fama que o grupo musical “Polegar” teve no passado.

Certo dia um livro chamado “Design Patterns” caiu em minhas mãos e resolvi folheá-lo. Notei que não tinha uma única linha de código em Java e então percebi que aquilo ali já existia antes mesmo de Java ter começado a lançar suas modinhas.

Comecei a ler o livro e em uma passagem encontrei uma frase que dizia algo parecido com: “No desenvolvimento Orientado à Objetos não desenvolva para tipos, desenvolva para interfaces.” e aí então a faísca foi lançada.

Devorei o livro rapidamente e adquiri uma cópia (uma tradução para o português que estava muito mais barata do que o original em inglês) e devorei o conteúdo em uma semana.

O livro tem alguns capítulos que introduzem o conceito de padrões, fala sobre o modelo MVC (Model-View-Controller) para separação dos componentes de uma aplicação e fala sobre alguns conceitos de OO que são bem interessantes. A partir daí temos os padrões que são catalogados de maneira a possibilitar uma rápida consulta.

Cada padrão acompanha uma descrição, um diagrama explicativo, os casos de uso, os casos onde não devemos usar tal padrão, o relacionamento desse padrão com outros e exemplos em Smalltalk e C++.

Esse livro não é adequado para pessoas que ainda não conhecem os conceitos básicos da Programação Orientada a Objetos pois ele assume que o leitor já conheça ao menos o básico sobre este assunto.

padroes-de-projeto-livroA cópia traduzida que eu tenho é editada pela Bookman e tem uma tradução excelente onde os nomes dos padrões são preservados na forma original em inglês.

Esse livro é um clássico da literatura técnica e algumas pessoas o chamam de “GoF” que é a abreviação para “Gang of Four“, uma alusão aos quatro renomados autores do livro: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides.

Para comprar: Padrões de Projeto ou Design Patterns

Gostou desse review?

Assine a minha newsletter quinzenal e receba artigos sobre Programação, Python, Django, carreira e empreendedorismo.

[mc4wp_form]
Categorias
Reviews

Programação Extrema Explicada (Extreme Programming Explained)

Programação Extrema Explicada (Extreme Programming Explained)Nunca gostei de estudar metodologias de desenvolvimento. Também não gostava das chatíssimas aulas de “Análise de Sistemas” que costumava assistir no curso de Processamento de Dados que fiz. E eu nunca gostei de estudar isso porque tudo que as metodologias diziam nunca se aplicava ao universo onde eu trabalhava.

Eu não trabalhava com coisas muito especiais. O tipo de software que eu costumava desenvolver era tão comum quanto os atuais sistemas de gestão para os quais essas metodologias de desenvolvimento dizem servir.

Um exemplo da minha experiência com essas metodologias ‘tradicionais’ tem relação com a análise de requisitos. Eu estudava tudo o que era dito sobre análise de requisitos e tentava aplicar no meu dia-a-dia mas nada funcionava. Eu me sentia o mais burro dos programadores por não conseguir fazer isso dar certo. Achava que o problema era comigo até perceber que o problema era do cliente.

A análise de requisitos ensinada pelos métodos convencionais não funciona porque nenhum cliente tem noção do que realmente precisa em um sistema. Eu percebi que o cliente sabe o que é o problema mas não sabe como resolvê-lo e em alguns casos ele sequer tem uma noção exata do problema a ser resolvido.

Se nem o cliente sabe do que precisa, para que serviria a melhor das análise de requisitos? De nada. E esse é o caso que se aplica apenas à análise de requisitos. Acredite em mim: eu tenho um caso desses para cada uma das etapas do desenvolvimento de uma aplicação.

Uma coisa que as metodologias de desenvolvimento atuais também assumem, de maneira errada, é que um software é algo estático. Isso é uma visão extremamente equivocada do que é software. Software é flexível, software muda (o tempo todo), software evolui, software cresce…

E é nessa diferença fundamental que a metodologia XP (eXtreme Programming) se difere das outras. Ela assume que software muda.

A algum tempo atrás, comecei a trabalhar em uma empresa que utilizava a metodologia XP para desenvolver alguns projetos. Por curiosidade fui dar uma olhada nessa metodologia e descobri que finalmente alguém, que trabalhou com desenvolvimento de software, tinha criado uma metodologia que reflete a realidade de um ambiente de desenvolvimento de software.

O livro “Programação Extrema Explicada” foi escrito por Kent Beck que é o idealizador dessa metodologia e que é o ponto de partida para muitos outros livros que detalham essa metodologia. É um livro curto, de leitura leve, e que fala direto com o desenvolvedor utilizando histórias reais no lugar de usar documentos formais e densos e chatos.

Ao mesmo tempo é um livro que ‘cutuca’ o desenvolvedor e levanta polêmicas sobre assuntos que deveriam ser debatidos por todos os desenvolvedores que já trabalharam em projetos que fracassaram.

Atualmente estou lendo a versão em português, traduzido pela editora Bookman, mesmo já tendo lido a versão original em inglês. Usando XP e relendo o livro estou confirmando que aquela sensação agradável que tive ao ler essa obra pela primeira vez é verdadeira.

Por essa razão considero a leitura desse trabalho obrigatória para todos os desenvolvedores, mesmo para aqueles que já conhecem XP e não gostam de algumas de suas propostas.

Para comprar: Programação Extrema Explicada – Acolha as mudanças ou Extreme Programming – Embrace Change

Categorias
Reviews

Leitura Obrigatória (Refatoração / Refactoring)

Quem me conhece sabe que adoro livros. Compro eles aos montes e quase sempre tenho uma fila interminável de leitura que nunca diminui.

Gosto de livros porque encontrei neles a melhor forma de aprender as coisas. Nunca gostei de salas de aulas e treinamentos mas sempre fui muito curioso e graças ao meu pai, que sempre lia muito, descobri que, no meu caso, a melhor forma de aprender algo novo é através dos livros.

Tendo lido vários livros eu consegui montar uma lista de livros que todos os desenvolvedores de software deveriam ler ou ao menos ter em suas prateleiras para uma rápida consulta. Sei que o Google é uma excelente ferramenta de ajuda, mas em certas situações o bom e velho livrinho repousado ao lado do teclado nos inspira para o trabalho como se fosse alguém lhe dizendo o que deve ser feito.

Como a lista é razoavelmente grande e pode crescer ainda mais vou adotar a tática de postar um de cada vez (talvez dois, quando tiver mais inspirado) aqui no blog. Assim que um novo post surgir eu irei fazer uma cópia do conteúdo dele para na página de resenhas que ficará permanentemente nos links da barra lateral.

A lista que será apresentada não é definitiva e é formada por livros que eu li e por alguns que eu ainda não li mas sei que são indispensáveis. Também tenho livros que não servem para serem lidos de ponta-a-ponta, mas simplesmente para uma rápida referência.

Refatoração (Refactoring) – Martin Fowler

Refatoração (Refactoring)Esse livro é fundamental para aqueles programadores que começaram há pouco tempo a trabalhar mas que já possuem alguns sistemas desenvolvidos. Refatorar um sistema é o nome que o autor dá à prática de aprimorar e/ou mudar o código da aplicação sem que o comportamento visível dela se altere. O funcionamento da refatoração é assegurado pela construção de testes para o sistema que será refatorado. Esses testes servem justamente para garantir que o funcionamento do sistema não será modificado pela refatoração.

O capítulo que fala sobre ‘bad smells‘ já vale a compra do livro. É um dos melhores apanhados de problemas encontrados em código fontes existentes. Depois de falar sobre os ‘bad smells‘ do código um amplo catálogo de táticas e técnicas para refatorar o sistema é fornecido.

Este livro pode ser usado para a leitura de ponta-a-ponta e deve ser guardado para referências futuras. A tradução para o português foi feita pela editora Bookman e é muito caprichosa (como quase todas as traduções da editora).

Para comprar: Refactoring e Refatoração