java_logo_2

Java é simples: você que burocratiza seus projetos

Sempre me incomodou bastante toda esta história de que Java é uma linguagem verbosa e sistemas feitos nesta são complexos. Então resolvi escrever este post pra mostrar alguns erros cometidos por desenvolvedores que, realmente, tornam não a linguagem verbosa, mas sim seus projetos verdadeiras máquinas “burrocráticas”.

Este é um primeiro post sobre alguns erros que encontro: é capaz de surgirem outros em um futuro próximo.

Pra quê interfaces?

Este é um ponto que fica muito claro quando você programa algum tempo em plataformas como Grails, Ruby on Rails ou Node.js e, em seguida, pega um projeto de revitalização de legados feitos em Java. Lemos em diversos livros ou palestras o seguinte princípio:

“Programe para uma interface, não para uma implementação”

O princípio está corretíssimo, mas a pergunta fundamental que o motiva não é feita: pra quê preciso de uma interface? Respondo: para representar uma abstração, ou seja, aquilo que é essencial no serviço e compartilhado por todas as suas diferentes implementações.

Portanto, se só existe uma implementação de uma classe no sistema por que você precisa criar uma interface? Não há o que abstrair daí.

Dica um: crie interfaces apenas se existir mais de uma implementação do serviço cuja funcionalidade você deseja abstrair.

DAOs desnecessários quando se está usando um ORM

É outro erro que encontro com frequência: imagine que seu sistema possua doze classes de domínio, todas elas persistidas contra uma mesma base de dados (relacional ou não). Um padrão comum que observo é a geração abusiva de objetos e classes no sistema:

  • Uma interface para representar o DAO para cada entidade.
  • A implementação do DAO para aquela interface
  • Todos os DAOs são executados contra a mesma base de dados
  • O DAO expõe algumas consultas, mas estas em sua esmagadora maioria (quando não todas) são usadas por uma única classe do sistema..

Levando em consideração que o papel do DAO é acessar e escrever dados em um repositório de dados, e existe uma ferramenta chamada ORM, acho interessante levantar sempre algumas perguntas:

  • Dentro de um futuro próximo você se vê trocando seu SGBD por alguma tecnologia ou fornecedor completamente diferentes?
  • Seu projeto precisa lidar com diferentes tipos de persistência de acordo com o ambiente no qual é implantado?
  • Se você usa um ORM (como Hibernate, EclipseLink ou JPA) para todas estas classes de domínio, e todas são persistidas contra o mesmo repositório de dados, realmente preciso ter implementados N DAOs apenas para persistir o estado destas?
  • Se só há uma implementação do DAO, preciso realmente de uma interface?
  • As consultas expostas por seu DAO são usadas por mais de um componente do sistema?

Minha sugestão aqui é simples: os ORMs já nos oferecem um DAO genérico por padrão (pense no Entity Manager do JPA): tire proveito disto. É exatamente o que Grails faz e, como vejo há quase uma década, funciona muito bem! Nós não escrevemos DAOs em Grails: nossos serviços usam apenas as consultas que realmente precisam e, quando há uma consulta compartilhada, a expomos ao restante do sistema através de uma função.

Se você tem um serviço responsável por gerenciar a lógica de negócio que envolve uma ou mais classes de domínio, e também possuí um ORM que já lida bem com o processo de persistência, pra quê ficar criando DAOs que expõem consultas usadas por um único ponto do sistema para todo o resto?

Solução simples: escreva seu serviço com um conjunto de métodos públicos bem definido que exponha aos clientes do mesmo apenas o que deve ser visto (isto se chama encapsulamento). Se ele precisa interagir com o banco de dados, use este DAO genérico fornecido pelo ORM internamente em seu serviço e evite com isto criar uma série de componentes que apenas irão aumentar a quantidade de código que você precisará gerenciar no futuro.

Concluindo

Neste post expus apenas duas situações que vejo repetidas vezes em projetos Java e que podem facilmente ser evitadas. Entendo perfeitamente o que motiva a ocorrência destes erros: você quer fazer bem feito mas não refletiu a respeito das boas práticas que muito provavelmente lhe foram impostas e não apresentadas.

_ Ah… mas e se no futuro meu sistema precisar de…
_ Bom: se você sabe o que vai ocorrer, você não tem um “e se”, mas sim um “vai”, então aplique.
_ Mas o futuro é imprevisível, preciso me preparar para ele.
_ Bacana: que então você tenha uma base de código menos complexa pra poder se adaptar mais rápido a ele.

awkmug

Armas secretas: AWK

AWK é uma “arma secreta“: faz parte daquele conjunto de ferramentas que sempre estiveram ao seu lado (surge em 1977 e quase toda distribuição Linux a inclui), você a ignora durante toda a sua vida e em um belo dia resolve experimentá-la. É o momento em que aquele sentimento de “ENTÃO QUER DIZER QUE SOFRI TODOS ESTES ANOS A TOA???” aparece. :)

O que é AWK?

Trata-se de uma linguagem de programação cujo nome vêm das iniciais dos seus criadores (Alfred Aho, Peter Weinberger e Brian Kernighan – galerinha bruta) e nos permite escrever programas que tenham como fonte de dados arquivos texto. O mais impressionante é que você consegue resultados incríveis com pouquíssimas linhas de código.

É uma excelente ferramenta quando desejamos extrair inteligência de arquivos texto, especialmente logs. Sei que esta descrição é muito ruim, sendo assim, que tal irmos direto ao código?

Exemplo real: log de acesso do /dev/All

Sempre que alguém acessa o /dev/All é incluída uma linha em um arquivo de log nos informando a data, hora, IP do visitante e página visitada tal como no exemplo a seguir:

03/06/2015 10:20:00 186.213.73.169 http://www.devall.com.br
03/06/2015 10:20:01 34.13.3.69 http://www.devall.com.br
03/06/2015 10:20:20 186.213.73.169 http://www.devall.com.br
04/06/2015 10:20 186.213.73.169 http://www.devall.com.br/blog/info/3

Se quisermos saber quantos acessos tivemos por dia fica fácil pensar em um programa: dado que o caractere de espaço separa estes quatro campos basta escrever um parser simples na minha linguagem favorita e voilá: crio um acumulador para cada dia lendo o arquivo do início ao fim.

Mas e se eu te disser que consigo o mesmo efeito com apenas uma linha de AWK?

{contador[$1]++} END {for (j in contador) print j, contador[j]}

E como eu uso isto?

cat acessos.log | awk '{contador[$1]++} END {for (j in contador) print j, contador[j]}'

Gerando a saída:

03/06/2015 3
04/06/2015 1

Parece até mágica: agora vamos dissecar este código.

Entendendo o AWK

A sintaxe da linguagem é composta por dois elementos fundamentais: uma condição referente à linha corrente do arquivo sendo lido e o que deve ser executado caso esta condição seja satisfeita. Podemos resumir a sintaxe ao código abaixo:

condição {ações a serem executadas}

No nosso código temos claramente duas condições. Vamos à primeira:

{contador[$1]++}

Não há uma condição estabelecida, sendo assim o bloco entre chaves sempre será executado a cada linha lida. O código é tão simples que assusta: criamos uma tabela de hash cuja chave corresponda ao primeiro campo do arquivo.

Campo? Sim: por padrão AWK interpreta o caractere de espaço como um separador de campos. “$1″ representa o primeiro campo (data), “$2″ o segundo (hora) e por aí vai. Ao aplicar o operador “++” em meu hash, AWK automaticamente o interpreta como um valor numérico e o incrementa.

Ao final da leitura do arquivo temos uma tabela de hash tal como a exposta a seguir:

 ["03/06/2015" => 3, "04/06/2015" => 1] 

Note que não precisamos declarar nossas variáveis antes de usá-las, o que nos gera um código muito mais simples. Agora vamos à segunda condição:

 END { for (j in contador) print j, contador[j]} 

AWK possuí algumas variáveis e condições embutidas. Dentre estas encontra-se “END”: uma condição que é satisfeita apenas quando chegamos ao final do arquivo. E o que fazemos quando isto ocorre? Geramos um relatório de saída ao nosso usuário final.

Apenas iteramos sobre as chaves presentes em nossa tabela de hash usando a estrutura de controle “for” e, para cada uma destas, iremos imprimir seu valor, seguido do número de acessos que fomos incrementando a cada linha do arquivo.

Outro exemplo: validando arquivos

Alguns anos atrás precisei interagir com um sistema que salvava notas fiscais em arquivos textuais similares ao exposto a seguir:

0100|Bolacha Mabel|3.40
0100|Leite Itambé|2.00
0200|5,40

O caractere “|” era usado para separar os campos e havia diferentes tipos de registros dentro do mesmo arquivo. Aqueles que começavam com “0100” representavam um item da nota fiscal (nome do item e valor pago respectivamente), e “0200” o valor total da nota. Uma validação simples deste arquivo é verificar se o valor total bate com o somatório do valor pago em cada item.

O validador em AWK abaixo ilustra melhor a linguagem. Iremos salvá-lo em um arquivo chamado “prog.awk”.


BEGIN {FS = "|"}
$1 == "0100" { total += $3}
$1 == "0200" && $2 != total { print "Valor inválido. Total = ", $2, "Somatório = ", total}
$1 == "0200" && $2 == total {print "Arquivo OK"}

A primeira condição é executada quando o programa é iniciado, o que é representado pela condição “BEGIN”. Nesta linha definimos que o caractere separador de campos será “|” mudando o valor de uma variável embutida da linguagem que é o FS (Field Separator).

A segunda linha verifica se o campo 1 contém o texto “0100”. Se for o caso, iremos criar uma variável chamada “total” na qual iremos incrementar o valor presente no terceiro campo. (nota importante: evite o caractere vírgula ao lidar com números de pontos flutuante com AWK).

A terceira linha verifica se o arquivo é inválido. Primeiro checamos se o valor do primeiro campo é “0200” e se o valor do segundo campo desta linha é diferente ao que calculamos na variável “total”. Se for, iremos imprimir o erro para o usuário.

A quarta linha valida o arquivo fazendo o oposto do que foi feito na terceira.

E como executamos este programa no Linux?

 cat notafiscal.txt | awk -f prog.awk 

Mais recursos sobre AWK

O objetivo por trás deste post foi apenas mostrar com o que se parece a linguagem de programação para despertar sua curiosidade sobre o assunto. Claro que não cabiam aqui todos os detalhes a seu respeito, mas você os encontrará nos links abaixo:

AWK Community Portal – http://awk.info – o nome já diz tudo: é o portal da comunidade mundial com muitos links e textos interessantes a respeito.

AWK User Guide – http://www.math.utah.edu/docs/info/gawk_toc.html – é o texto que estou usando para me aprofundar na linguagem. Excelente leitura!

JAWK – http://jawk.sourceforge.net/ – Se você usa a JVM vai gostar de conhecer este projeto: é uma implementação completa do AWK para Java. Muito bom como linguagem embarcada!

AWK.net – https://awkdotnet.codeplex.com/ – Curte .net? Encontrei esta implementação, mas não cheguei a experimentá-la.

Notas finais

Minhas experiências recentes com AWK têm sido extremamente satisfatórias: em um de nossos projetos em que precisamos lidar com arquivos de log conseguimos um excelente ganho de produtividade conhecendo muito pouco a linguagem.

Espero que com este post mais pessoas incluam AWK em sua caixa de ferramentas, pois é algo que vale muito à pena aprender.

 

devall

/dev/All completa uma semana (versão 1.0)

Se você me segue pelo Twitter ou Facebook já deve ter percebido que semana passada só tive um assunto: /dev/All. E não é pra menos: faz muito tempo que não me envolvo (e me divirto) tanto assim com um projeto profissional.

Apenas para lembrar: /dev/All é um agregador de blogs sobre TI/desenvolvimento de software/arquitetura/coisas tech e também um podcast cujas gravações começam a partir de amanhã (mais sobre o aspecto “podcast” semana que vêm).

A ideia original

Eu queria muito algo que pudesse ler no caminho para o trabalho. Como a esmagadora maioria do que leio envolve TI, e não há bons agregadores de blogs nacionais, por que não criar um? Primeira surpresa: descobri que pouquíssimas pessoas usam /dev/All em seus celulares, ou seja, poucos o vêem assim:

devall_mobile

A primeira versão (0.1) era focada apenas em dispositivos móveis, por isto era tão ruim no desktop (naquele momento eu realmente acreditava que as pessoas só o usariam como eu o faço (indo para o trabalho).

Mas aí percebi que podia ir além:  semana passada ficamos (eu, Pedro Campos ( estagiário da itexto) e Nanna) em cima do projeto: nisto saíram 15 releases, muitas vezes dois, três, quatro, cinco por dia. Neste post vou contar o que fizemos e o que mudou agora com o release 1.0. :)

As maiores dificuldades

Leitura de feeds

Se você é um usuário mais antigo do Grails Brasil talvez se lembre de uma antiga seção do site chamada “Blogs”. Foi o primeiro agregador de blogs que escrevi: mas como não haviam tantos blogs sobre o assunto na época, acabou perdendo o estimulo e matei o site.

Engraçado como me esqueci do quão complicado pode ser a escrita de um bot que leia feeds. Parece fácil em um primeiro momento: você irá apenas escrever um crawler que lerá documentos nos formatos XML (RSS e Atom), certo? Errado: a coisa é muito mais complicada do que aparenta.

Eu diria que uns 80% do nosso tempo foi melhorando o crawler. Por mais incrível que pareça há feeds que misturam RSS com Atom, alguns não implementam 100% do padrão, outros estabelecem seu próprio (Medium mesmo é um dos mais chatos).

Então implementamos uma biblioteca Java apenas para ler feeds – que devemos inclusive liberar o código no GitHub da itexto em breve pois acredito que muita gente deve sofrer com os problemas que enfrentamos (ROME não nos atendeu por ser muito mais complexo do que precisávamos).

Outro ponto importante: ter o extrator de posts como um processo independente do site principal. Isto nos permite corrigir e aprimorar o crawler sem precisarmos prejudicar a experiência final do usuário. Por esta razão criamos um projeto independente chamado “Feed Hunter”, que é quem alimenta o /dev/All hoje (falaremos mais sobre a arquitetura dele no futuro).

Ouvir os usuários

Não bastava apenas ter um agregador de blogs na rede: tem de ter conteúdo. Por esta razão Pedro entrou em contato com inúmeros autores durante a semana e o resultado foi positivo: todo dia você encontra bons posts no /dev/All, e o número de autores não para de crescer (temos 57 até a escrita deste post, e até o final da semana que vêm com certeza teremos mais de 100).

Então durante a semana acabamos aprendendo um pouco mais a respeito do que realmente estávamos fazendo. Foi uma experiência extremamente enriquecedora.

Ser mobile first é fácil: mobile e desktop, não

Apesar de termos alguns designers para os quais terceirizamos nossas demandas, decidimos usar esta experiência para treinarmos o que sabemos (ou achamos que sabemos) sobre design responsivo.

Confesso que ainda não estou 100% satisfeito com o nosso comportamento no desktop: ainda há um vácuo a ser preenchido pelo conteúdo do podcast que me incomoda. Mas isto deve ser resolvido nesta semana.

O que há de novo na versão 1.0

Novo crawler

Nesta semana você deve ter notado que diversos posts exibiam em seus sumários tags HTML e, em outros casos, simplesmente não mostravam nada. Isto se deu por causa dos motivos que citei acima. Sendo assim trabalhamos bastante em um novo crawler para resolver estes problemas.

Para minimizar o tempo de downtime do site quando precisamos atualizar este componente, hoje ele é executado como um processo completamente independente. Além disto, também vamos liberar o código fonte para que outras pessoas possam tirar proveito das coisas que aprendemos (e estamos aprendendo) neste trabalho.

Um dashboard para os blogueiros

Havia uma ausência (adorei esta frase) notória no /dev/All: você podia se cadastrar mas não podia alterar seus dados ou do seu blog. Notou isto? Este não é mais o problema: neste release estamos liberando um dashboard para todos os blogueiros que lhes permitem acompanhar a popularidade do que escrevem, tal como pode ser visto na imagem abaixo:

devall_dashboard

Hoje você pode ver quantos cliques por dia seu blog recebe, mas até o final da semana uma série de outras estatísticas estarão disponíveis como, por exemplo, que horas as pessoas acessam seu blog.

De onde veio esta ideia? Por que queremos te incentivar a escrever e também por que acompanhando os acessos do /dev/All vimos que as pessoas estavam clicando (e muito!) nos links que expomos! Então, por que não fornecer estas informações aos blogueiros.

Visando garantir sua privacidade, o usuário só possuí acesso aos blogs que possuí.

Ferramenta de busca

busca_devall

Esta foi outra coisa que muitos usuários pediram (e que era uma falta absurda), sendo assim, a incluímos no site. Agora você pode executar consultas no site.

O próximo passo é a categorização dos posts através do próprio crawler: algo no qual já estamos trabalhando. Ele será capaz de descobrir qual o assunto do post através da análise do texto (isto também vai pro GitHub).

E o futuro?

O próximo passo será a publicação do podcast e as melhorias subsequentes em nosso crawler. Claro: novas seções poderão surgir no site, mas neste momento o objetivo é fornecer ferramentas gratuitas para blogueiros e bons posts para que possamos ler.

Haverá também um RSS do /dev/All em breve, provavelmente esta semana. E agora volto a escrever a Semana Groovy :)

Qualquer dúvida ou sugestão, basta entrar em contato conosco! Espero que vocês curtam tanto o /dev/All quanto nós estamos amando construí-lo.

devall

/dev/All – agregador de blogs de desenvolvedores (e também um podcast)!

Hoje estou lançando um projeto no qual venho trabalhando já faz algum tempo. Se chama /dev/All, está em um estágio “pré-beta” mas acredito que já esteja 50% usável. Bom, ele supre dois objetivos meus:

Agregador de blogs voltados a desenvolvimento de software

Sempre senti muita falta de um agregador de blogs voltados para a minha área em português. Já vi algumas iniciativas mas todas não satisfaziam algumas necessidades básicas minhas:

  • Serem fáceis de se usar em trânsito (especialmente no ônibus)
  • Permitirem que os autores cadastrem facilmente seus blogs
  • Terem como foco exclusivamente TI e desenvolvimento de software
  • Que ofereça ferramentas para que os autores acompanhem a popularidade de seus posts e também lhes ajude a divulgar seu trabalho.

O funcionamento do /dev/All é bastante simples. Se você tiver um blog, basta se cadastrar neste link fornecendo o seu endereço. Se você não tiver um blog, bem: basta acessar a página principal para ver os últimos links que nosso crawler encontrou.

Ainda estamos trabalhando na parte envolvendo as ferramentas, mas com certeza deve sair algo nesta semana ou na próxima.

O sonho do podcast próprio!

Este é um projeto de anos: inicialmente se chamaria “/dev/Kico Podcast”, mas dado que as pessoas ligam muito este blog a Groovy e Grails, e eu lido com um range muito maior de tecnologias, primeiro pensei em uma generalização do site. Por que não “/dev/Tudo”? Por que me lembra “X-Tudo”. Então acabei chegando em “/dev/All” que soa bem melhor.

Neste podcast pretendo falar sobre alguns dos links mais interessantes que aparecerem no nosso feed e principalmente sobre as tecnologias que não aparecem nas convenções. Já estou montando nossa primeira ementa inclusive. Espero que gostem.

E o endereço do site?

http://www.devall.com.br

Quer nos ajudar?

Como disse no início deste post, ainda estamos em um estado bastante embrionário, sendo assim bugs surgirão. Caso apareçam, basta entrar em contato comigo por e-mail: kico@itexto.com.br

Ainda mais importante: se você tem um blog, por favor, se cadastre! Vai ser muito legal ver seus posts na nossa página inicial! Basta preencher este formulário!

Todo feedback é super bem vindo!

 

Ah, e o link né? http://www.devall.com.br

groovy_grails_na_itexto

Início das turmas de Groovy e Grails para desenvolvedores independentes na itexto!

Estou preparando na itexto um novo tipo de treinamento de Groovy e Grails voltado para desenvolvedores independentes. Até então nosso foco tem sido empresas, mas acredito que agora seja o momento ideal para o início destas novas turmas.

A idéia é criar uma experiência que vá além das aulas: estou falando de trocar experiências entre alunos e instrutor (eu) gerando como resultado algo como uma mini consultoria na qual apresentamos nossos problemas e compartilhamos as soluções durante o curso.

No site da itexto você pode saber mais a respeito da estrutura que estamos montando para estas turmas (incluindo os benefícios) clicando neste link.

Nesta semana e na próxima o foco é a coleta de feedback. O que você gostaria de ver em nossos treinamentos para desenvolvedores independentes? Quais as suas dificuldades? Caso esteja interessado em nos ajudar, basta preencher este formulário (link).

No mesmo formulário perguntamos se você teria interesse em participar destes treinamentos. Em caso afirmativo (torço para que sim!), entraremos em contato com você assim que tivermos tudo 100% organizado e fechado.

Vai ser massa!

Semana Groovy 29!

Notícias e eventos

Treinamento com José Yoshiriro de Groovy e Grails dias 9 e 10 de maio

Nos dias 9 e 10 de maio ocorrerá no Centro de Treinamentos da Novatec um workshop com José Yoshiriro. Mias detalhes neste link: http://ctnovatec.com.br/cursos/trilha-java/curso-groovygrails/ 

itexto pede seu feedback sobre suas turmas abertas online de Groovy e Grails

Queremos construir uma experiência única de aprendizado para desenvolvedores interessados em aprender (ou se aprofundar) em Groovy e Grails.  Sendo assim, estamos finalizando o planejamento para nossa primeira turma e precisamos da sua opinião. Mais detalhes neste link: http://www.itexto.com.br/site/?p=693

Grails Brasil 4.0.2

Acho que poucos repararam, mas nesta semana colocamos no ar a versão 4.0.2 do Grails Brasil. Pouco a pouco estamos caminhando para torná-lo cada vez melhor! :)

Nova newsletter: Groovy Dev

Esta semana por acaso descobri uma nova newsletter sobre Groovy (está em sua terceira edição). Se chama Groovy Dev. Segue o link: http://groovydevweekly.com/ .

Posts

Contribuição da comunidade

A partir desta edição da Semana Groovy vamos publicar os links que nos foram fornecidos por membros da comunidade Groovy e Grails. Você também pode nos fornecer seus links, para tal, basta preencher este formulário: http://goo.gl/forms/ZsH5UqklbL 

IntelliJ terá suporte ao Grails 3.0 a partir de julho - Fernando nos mandou um link pertencente ao fórum da JetBrains no qual um usuário pergunta quando será incluído suporte a Grails 3 na IDE. A resposta da equipe foi rápida: a partir de julho! Interessados podem acompanhar a discussão neste link: https://youtrack.jetbrains.com/issue/IDEA-136970

Especial Gradle

Dado que o Grails 3 é baseado neste motor de construção, nada melhor do que alguns links para que vocês possam já ir se acostumando com a ferramenta. :)

Using Gradle and Bower to manage JS/CSS dependencies – Tenho visto cada vez mais projetos nos quais todo o frontend é implementado de forma independente do Grails usando Bower e Grunt. Este post vai direto ao ponto. – https://objectpartners.com/2015/04/29/using-gradle-and-bower-to-manage-jscss-dependencies/

Gradle Goodness: Handling Copying Duplicate Files – O nome já diz tudo: como lidar com arquivos duplicados usando o Gradle – http://mrhaki.blogspot.com.br/2015/04/gradle-goodness-handle-copying.html

E-book gratuito da O’Reilly: Building and Testing with Gradle – nada melhor que um livro pra te guiar nos seus primeiros passos com a ferramenta! – http://www2.gradle.org/l/68052/2015-01-13/6dm

Grails

Saving application PID in file – A partir do Grails 3 você pode empacotar sua aplicação como um JAR. Um dos problemas é justamente identificar o processo que você iniciou, o que é feito através do identificador do processo (PID). Mr Haki nos mostra de uma maneira bem fácil como fazer isto neste link: http://mrhaki.blogspot.com.br/2015/04/grails-goodness-save-application-pid-in.html

Incluindo informações de inicialização no seu log – Mais uma vez Mr Haki nos dá uma dica valiosa – especialmente para administradores de sistema – nos ensinando como incluir informações de inicialização em nosso projeto Grails. Link: http://mrhaki.blogspot.com.br/2015/04/grails-goodness-log-startup-info.html