Um Manifesto!

Primeiro: análise anual é uma merda! Um ano é MUITO TEMPO, tanto para recordar quanto para planejar... seis meses seria um intervalo melhor, com certeza. Especialmente em tecnologia, seis meses é o tempo de mudanças. Mas como agora vai virar o ano, vai resolução anual mesmo.

Analisando o texto do ano passado para ver como foram as coisas, quanto ao que eu esperava. Tudo que cumpri de lá, cumpri em seis meses, o resto nem pretendo mais. Foi um puta ano afinal:

Primeiro, entrei na faculdade! Estou fazendo Análise e Desenvolvimento de Sistemas, curso de 2 anos e meio. Nem tenho paciência para um curso chato de 4 anos, um curso chato de 2,5 é o bastante. As notas estão boas, apesar do conteúdo não acrescentar muito na prática. A decepção maior é falta de nerds no curso.

Não me certifiquei em java, nem em linux. Nem tenho planos para isso por enquanto. Mas aprendi bastante em ambos.

Os projetos da primeira metade do ano foram todos mais ou menos, medianos mesmo. Mas nesses primeiros seis meses do ano aprendi muita coisa sobre desenvolvimento, Orientação a Objetos, Domínios e etc tendo como por em prática tudo isso. Foi realmente um salto de qualidade e produtividade na programação. Quem mais se beneficia é o PHP mesmo.

Eis que chega o meio do ano, e a coisa esquenta!

Uma vaga para estagiar numa grande empresa aparece... grande não, na maior. Um estágio na IBM! Vejam só minha surpresa quando, ainda no primeiro semetre da faculdade consegui o estágio.

A vaga em si não era o que eu queria, mas poderia abrir muitas portas(e abriu). Trabalharia com suporte a servidores... windows. Mas foi muito bom, aprendi bastante, e apesar do foco ser windows estive o tempo todo em contato com as áreas de middleware, UNIX e DB. Além disso o cliente para qual prestava serviço era a Tv Globo, em um ambiente gigantesco!

Conheci grandes pessoas e aprendi bastante, com certeza. Principalmente processos, os que funcionam, como funcionam e quando não funcionam também.

Mas também não tinha mais tempo para muita coisa. Quase não programava, projetos estagnados e faculdade decaindo. Além do cansaço eu já quase não tinha tempo para namorada, tão paciente.

Infelizmente eu não queria suportar servidores, faço minha carreira de desenvolvimento, quero programar, tocar bons projetos e tudo mais. É para isso que eu estudo e é isso que eu gosto. Numa decisão muito difícil, larguei o estágio.

Quer dizer, estou largando. Eu já sai, mas ainda falta alguma papelada. E a faculdade, consegui recuperar no final, e foi OK. Mas é tempo de arriscar e correr atrás do que quero.

Assim chego ao fim do ano, com certeza esqueci de muita coisa que aconteceu, mas o mais relevante esta ai para ser recordado quando chegar o ano que vem. Agora de volta a 100%(voltando ainda ao rumo) freela, 100% livre, e podendo me dedicar aos projetos legais.

Para o ano que vem? Ao menos para o começo refazer este site horrível, dominar a arte do desenvolvimento Mobile, gastar menos e ganhar mais rsrs. E conforme for indo, vou vendo.

Abraços,
Boas festas!

Finalmente a camada de dados...

A camada, ou layer, de persistência ou de acesso aos dados é a parte da aplicação responsável por se comunicar com o banco de dados, ou com o framework de persistência, sendo os dois padrões mais conhecidos o DAO e o Active Record.

 

 

 

Numa aplicação orientada a objetos, e bem modelada e modular, temos a boa separação entre as responsabilidades de cada parte da aplicação. A parte de acesso ao banco de dados é uma das mais interessantes (a minha camada favorita!), ela é responsável por se conectar ao banco de dados e extrair, inserir e atualizar as informações. É responsável também por transformar modelos de Objetos em modelos Relacionais, o tal do ORM(Mapeamento Objeto Relacional), já que em muitos casos lidamos com banco de dados relacionais.

Podemos acessar de duas formas o banco de dados, usando um framework ou escrevendo SQL próprio. Hoje em dia existe uma variedade de frameworks, que programam os vários recursos necessários, de modo que costuma ser perda de tempo fazer o acesso direto ao Banco de Dados. Geralmente o ORM é feito através desses frameworks.

Temos dois padrões comuns para a comunicação com o BD/Framework: o Data Access Objet(DAO) e o Active Record (AR). Poderíamos acrescentar também o padrão Repositório, mas este terá um artigo próprio, na evolução deste tema. Os dois, DAO e AR, são padrões bem distintos e refletem abordagens extremamente diferentes na modelagem da aplicação.

 O Active Record se tornou extremamente popular com o framework Rails, para a linguagem Ruby, como a produtividade e simplicidade do framework revoluciona o desenvolvimento muitos abraçaram o padrão também em outros frameworks. O padrão é muito comum em frameworks para linguagens dinâmica, sendo até difícil achar um que não o use(nem tanto...).

 

 

A modelagem em Active Record "invade" a camada do Modelo/Domínio da aplicação, definindo que um Objeto do modelo é o reflexo de uma "linha" do banco de dados. Assim sendo, os objetos que são persistentes devem estender/especializar uma classe ou interface que seja equivalente a uma linha do banco de dados. O Modelo é uma Extensão do Banco de Dados.

Essa interface, que o modelo ou classe genérica programa, define os métodos de interação com o banco de dados que um modelo possui. Então o próprio modelo é responsável pela sua persistência. O próprio objeto implementa métodos como Salvar, Restaura, Filtrar e etc. Além das funções de "Join". Desta forma o Active Record tem uma abordagem simples, visto de outras camadas é uma forma lógica e fácil de se trabalhar..

Nos frameworks, temos uma classe abstrata que é capaz de decidir como montar as queries SQL de acordo com as propriedades do objeto que a estender. Desse modo costuma bastar estender e não há necessidade de alterar o modelo, no máximo acrescentando informações ou meta-dados sobre a tabela equivalente, de acordo com a abordagem do framework.

O problema com o Active Record é que seu modelo fica com muita responsabilidade, Activer Redord não Escala!, e cria "BFC"s (Big Fucking Classes), já que o modelo além de conter as regras de negócio também cuida do banco de dados. Essa abordagem do Active Record é muitas vezes considerada uma falha no design da aplicação, pelo fato de que o Domínio passa a ser subordinado do Banco de dados. Este argumento pode ser rebatido já que na maioria dos sistemas, as classes do Modelo são apenas representações do Domínio, e não programam regras em si, e que essas regras passam estar representadas na persistência, não afetando o design de muitas aplicações.

Na prática, se temos uma classe Usuário esta deve estender uma outra classe, digamos Record. Record é uma classe provida pelo framework de persistência, ela implementa os métodos Select, Save e Delete. Ela também exige que seja implementado um método Configure pela classe filha, para definir os parâmetros do banco de dados. Assim sempre que precisamos buscar um usuário do banco de dados, usamos o método Select da própria classe Usuário, e por ai vai.

Se por um lado o Active Record atua de forma simples e explorando a flexibilidade dos frameworks de persistência de hoje e dinamismo das linguagens, o DAO por sua vez surge num ambiente de framework mais rígidos e que demandavam maior numero de chamadas e configurações. O DAO é praticamente o oposto do Active Record, em design. 

As classes DAO representam uma camada própria, e formam um pacote de acesso de dados, algumas vezes sob o pacote do modelo, algumas vezes um pacote independente e outras vezes parte do pacote de controladores. O mais comum é mesmo que o pacote de DAO fique subordinado ao Modelo, mas sem estendê-lo. Assim temos uma separação e relativa independência da camada de acesso dados e do Domínio.

 

 

 

O principio é que para cada Modelo, temos um DAO correspondente. Toda interação e configuração com o Banco de dados, ou com o framework de persistência, ficam na camada dos DAO. Então o DAO passa a programar métodos como Select, Delete, Insert, Update e outros que venham a ser necessário. Podem programar métodos mais específicos, como selecionarOndeNomeComecaComLetra ou cadastrarLista.

O DAO pode ser usado também como camada entre a aplicação e o modelo, ou entre diferentes aplicações. Passa-se a não acessar o modelo diretamente (com new) e usar os métodos do DAO para tal, mas essa abordagem nem sempre é usada. Assim, sempre que quiser uma instância de um Modelo, usa-se o DAO.

O uso de DAOs é(ou era ao menos) bem mais comum nos projetos Java. Como muitos frameworks ainda eram muito rígidos, e precisavam de mais código para fazer o ORM, ou para escrever queries mais personalizadas, esse código passou a residir na camada do DAO, algumas vezes tanto a descrição da transformação ORM quanto a montagem das queries através dos métodos do framework. Ou então, em casos onde as queries deviam ser muito precisas, a interação direta com o Banco de dados.

A abordagem de DAO costuma(va) ser associada a um design mais elegante, devido à separação das camadas. Assim tínhamos mais flexibilidade ao manipular o framework. Porém com a evolução dos frameworks, estes passam a perder um pouco a utilidade, já que são necessárias poucas chamadas aos framework e estes conseguem criar queries cada vez mais complexas automaticamente.

O DAO entra em "crise" com a evolução dos Framework, e sua utilidade passou a ser questionada, pois muitas vezes passaram simplesmente a programar os mesmos métodos que o framework provia, apenas repassando os chamados. Ficando entre um caso de programá-los por puro design e passando a ser overengineering. Com o conhecimento do padrão de Repositórios esses caso passou a ser entendido de outra forma..

Na prática, se temos um modelo Usuário, teremos um DAO UsuárioDAO. A classe Usuário não se altera, mas implementamos na UsuárioDAO os métodos necessários, como select, save e delete. Os métodos de UsuárioDAO fazem as validações necessárias e montam as chamadas para o framework de acordo com as especificações do Usuário, repassando então o objeto ao framework. Pode ainda implementar métodos especificos como validaLogin. Então ao precisar criar, recuperar ou salvar um objeto usa-se o DAO deste.

Apesar de ter escrito bastante, esta abordagem ainda é superficial. Apresentei os principais conceitos destes padrões, para exemplos práticos basta procurar frameworks para sua linguagem. Para o Active Record existem várias opções, mas na verdade não existem framework para DAO, já que DAO pode ser usado em conjunto com outras abordagem de persistência.

Um outro importante ponto na camada de persistência e acesso aos dados, é o padrão Repositório (repository), que solucionou alguns problemas dos DAO e se adapta melhor a estes frameworks mais flexíveis e menos complexos, mas este fica para um próximo texto.

Desenvolvedores, programadores e adeptos, ao desenvolver aplicações e sistemas, há algumas guias que nos ajudam a criar um bom código, fácil de manter, de entender e que outros programadores vão poder mexer caso necessário. O primeiro passo para isso é o uso de Orientação a Objetos. Mas mesmo dentro deste, há alguns conceitos importantes de serem colocados. Eis alguns pontos, ainda rascunhados, que é bom ter em mente:  

 

• Tempo
• Fácil manutenção
• Fácil de entender: O código é semântico, sem confusões e se auto-explica. Comentário apenas onde é necessário. O Código se auto-documenta.
• Fácil de testar: Unidades simples, reuso, testes automatizados. É mais fácil testar pequenas unidades.
• Modularidade
• Acoplamento: Baixo acoplamento, permite melhores testes mais independência do código e maior reuso.
• Dependência: Use apenas onde necessário.
• Isolar mudanças: Segurança com testes. Mudanças de framework, de infraestrutura.
• Não se exponha muito
• Independência de implementação: Mudanças na implementação, no código de um método, não afeta o comportamento de onde usa este método.
• Privado / Público: Propriedades privadas, assessores públicos. Protege as informações.
• getters e setters: Muda a implementação, a fonte de dados, a regra de negócio. Ficam os assessores, a interface.
• Responsabilidade
• Sempre retorne algo significante: Evitar retornar null. Interface encadeada. No mínimo, retorne boleano.
• Trate entradas inválidas: Não confie no resto do código. Valide sempre. Trate Nulos. (Especial foco em linguagem de tipo dinâmico/fraco)
• Cuide de seus erros internamente: Use exceções com significado.
• Interfaces
• Exponha suas interfaces: Maior reuso, maior independência. Evitar acoplamento especifico.
• Use interfaces com significado: Código é documentação.
• Padrões
• Pense em padrões: Resolver problemas de forma padronizadas. Nem sempre são os "Padrões de Projetos"(design patterns).
• Use herança corretamente: Cuidado com armadilhas por facilidade de uso. Herança tem que fazer sentido. Evite BigFuckingClasses.
• Use composição corretamente: Composição sobre herança. Corrente de responsabilidade, interfaces e acoplamento. 

Ficou bem confuso...e ainda existe muito mais. Eu uso a seguinte métrica para saber se a modelagem esta legal: Se eu consigo explicar de forma clara o por que de ser assim, é por que esta no caminho. Se complicar para explicar/desenhar o modelo, é por que esta ruim.

ATENÇÃO: TEXTO QUASE EMOTIVO SOBRE DESENVOLVIMENTO DE SISTEMAS. BASTANTE BLABLABLA FRENTE. CUIDADO.

Trabalhando em um projeto pessoal me ocorreu: Será que preciso mesmo dividir a responsabilidade do sistema, dividir as camadas e ainda me preocupar em baixo acoplamento e com semântica?
Vou explicar-me melhor: Meus projetos pessoais são a oportunidade de colocar em prática as várias idéias e teorias sobre desenvolvimento e arquitetura, que se bem aplicados passarão para os proximos clientes. É a chance de fazer o sistema perfeito, de modo que uma engenharia reversa para UML resultaria numa obra de Picasso. São projetos reais, onde tenho a chance de testar frameworks, metodologias e etc.

Quer dizer, são projetos que geralmente nunca termino. Por que quase sempre aparece uma idéia legal para testar. Mas estou perdendo o foco do texto... 

 

Nesse projeto aplico Desenvolvimento guiado a testes(O TDD), divido as funcionalidades em pequenos métodos, baixo acoplado, re-uso tudo que posso... sempre refatorando, me preocupando se as classes não ficam complexas demais, se não fogem a sua responsabilidade. “Será que um Repositório pode usar outro Repositório?”, “Essa uma pesquisa em massa no banco esta no escopo dessa classe?”, “Esse nome transmite o sentido do método? E esse retorno é apropriado?” e etc... assim nos mínimos detalhes. Ai parei para me perguntar, será que preciso disso tudo?

Quer dizer, especialmente para começar no TDD (desenvolvimento guiado a testes...) é bem chato, é um começo difícil. Por que as classes as vezes não são fáceis de testar, são muitos testes, muitos casos a cobrir, tem que ter um banco de dados para isso... são várias “pedras no caminho”.

As vezes parece que seria muito mais rápido escrever uma pagina para lidar com cada requisição, acessar o BD direto ali e simplesmente fazer acontecer a mágica do sistema... não é mais fácil? Tudo esta no escopo, me guiar pela requisição e pelo retorno apenas. Não é mais fácil?

Recebi de braços abertos e sem defesa a resposta, como uma flecha varando meu peito, fria: “NEM FODENDO NÃO É MAIS FÁCIL!”. Senta que lá vem mais história.

Essa semana mesmo estava fazendo manutenção numa aplicação mais antiga que desenvolvi. É um ERP, uso crítico da empresa, na época ainda estava aprendo OO, então mal tinha esboço de classes naquilo ( Só tinha um classe para o BD, e os modelos que a estendiam... modelo estendendo BD! Triste mesmo...). E o pior que era organizada até, exista um quase MVC por trás da aplicação, mas conforme adcionava funcionalidades as pressas, tudo ia para debaixo dos panos.

As responsabilidades não eram bem dividas, não tinha um rotina de testes básica, camadas são para os fracos. Ou seja, o sistema se tornou imprevisível! A cada clique eu temia que o banco de dados fosse para o espaço e meu processador fritasse. Para garantir que uma nova regra de negócio acontece por todo o sistema, eram várias alterações, em vários lugares as vezes desconexos. “Adicionar porcentagem de aproveitamento: arquivo salvar_conta, classe conta (nos 5 loops dos 3 métodos), arquivo benchmark ( no loop 2, 5 e na exibição).”

 

 

 

Numa mesma aplicação desenvolvida pouco tempo depois, ainda não tinha os testes automáticos e o mesmo cuidado de hoje, mas já tinham camadas, modelagem, interfaces... é moleza. “Quer mudar uma posição da foto, vai na View”, “As imagens não estão armazenando corretamente, será no uploader ou no tratamento de imagens?”,”Uhm, não esta recuperando esse campo do BD, abre o DAO.”, é padrão, tem poucas dúvidas e a implementação é rápida, acha-se os problemas facilmente.

O conhecimento ganhado é gradativo: OO, camadas, Repositórios, frameworks, Testes... quanto mais é aplicado, mais fácil é dar manutenção. MANUTENÇÃO é a palavra. Só parece que é mais fácil fazer sem preocupação, mas isso só vai ficar legal por uma ou duas páginas. Quando o sistema começa a se conectar, quando começam a surgir alterações(e sempre, SEMPRE surgem!) ai que faz falta a boa modelagem.

Obviamente também tem que tomar cuidado com o “overengeneering”, modelar demais pode ser perigoso e criar correntes de responsabilidades sem sentido entre outros. Tem que estar sempre em busca do ponto de equilibrio.

Especialmente de um tempo para cá, quando comecei a aplicar o TDD, depois de muito lutar contra(tenho que admitir), comecei a ver os benefícios. É muito mais que garantir que os métodos estão retornando certo... é a chance de garantir a boa implementação do sistema. Os testes são as métricas do bom código.

Se esta difícil escrever uma rotina de testes consistente, é um sintoma que a modelagem não esta muito boa: Os métodos estão com muita responsabilidade, ou tudo esta muito acoplado. Se a responsabilidade esta bem divida, há bastante re-uso e os métodos fazem sentido, é fácil bolar os testes.

Os testes são também uma boa documentação. Quer saber como um classe deve se comportar, como ela será usada? Veja como foi testada, quais os pontos críticos do teste.

Quer saber qual implementação é mais rápida, ou tem melhor performance? Coloque marcadores nos testes, contadores. Adicione uma ferramenta de profiling. Você vai ter a garantia que mudou a implementação, o sistema esta funcionando igual, e saber se ficou mais rápido ou não.

 

Uma análise boa por exemplo é: E se eu mudar de framework(ou adotar um) para área XPTO, o quanto isso vai afetar o sistema? Bom, a mudança deve ser transparente, a dependência do framework e infraestrutura em geral deve ser bem separada. E os testes devem garantir que tudo continua funcionando da mesma forma após a mudança.

É, foi um desabafo sim, mas foi sincero. Seguimos aprendendo ;D 

Como disse, adquiri um celular novo. Demorei um pouco para descobrir, mas é muito simples configurar o Nokia 5310 no Linux.Aqui faço apenas a conexão pelo cabo USB, para conexão por bluetooth procure por ai, ou espere eu tentar ;)

 

O primeiro passo é desativar dois módulos que "quebravam" ao conectar o celular de modo diferente do armazenamento de dados. Remova os seguintes módulos:

# modprobe -r cdc_ehter
# modprobe -r rndis_host

Agora adcione-os ao arquivo /etc/modprobe.d/blacklist , assim: 

blacklist cdc_ether
blacklist rndis_host

Dessa forma eles não serão mais recarregados. E agora plugue o cabo usb do celular no computador e use o comando lsusb para saber o id dele, no meu caso retornou o seguinte:

Bus 001 Device 028: ID 0421:006b Nokia Mobile Phones

O "0421" é o "vendor", no caso nokia, e o "006b" é o produto. Levante então o módulo usbserial assim, substituindo onde necessário os numeros:

# modprobe usbserial vendor=0x0421 product=0x006b 

Agora configure o celular para perguntar qual tipo de conexão fazer pelo cabo usb toda a vez. As opções são:

• Nokia PC Suite : Que vai dar acesso a agenda, calendario e ao modem
• Impressão e Mídia : Vai atuar como pendrive para as mídias
• Cartão de Memória : Vai dar acesso direto ao cartão de memória

Ou seja, bem óbvio o que escolher.Uma boa forma de acompanhar se tudo esta certo, e aonde o modem foi reconhecido é usando o comando "tail -f /var/log/messages".

Para acessar os contatos e usar o modem, escolha o Nokia PC Suite. Existem alguns programas compativeis para acessar os dados do celular, como o wammu e kmobiletools (que eu uso). Basta configura-los para acessar o celular, geralmente em /dev/ttyUSB0 (ou outro se este estiver em uso) ou /dev/ttyACM0 (caso o módulo cdc_acm).

Para usar o modem, acesse como Nokia PC Suite e configure o discador para usar o celular como modem, configure provedor e senha conforme indicado pelo prestador, no caso da vivo o usuario é o numero do telefone com ddd, como em This e-mail address is being protected from spambots. You need JavaScript enabled to view it e a senha vivo, e o número é *99# , diferente do #777 que uso no modem da vivo. Basta discar e ser feliz(se tiver 3G...) ;)