Informática + Tradução = Confusão

Posted by Emerson Macedo on junho 25th, 2008

Uma discussão que sempre vem a tona no forum do GUJ e em conversas entre colegas de trabalho, é sobre o uso do pattern TO/DTO (Antigo VO, que hoje em dia significa outra coisa). Eis o trecho do livro Core J2EE Patterns:

Transfer Object

Problem
You want to transfer multiple data elements over a tier.

Forces

  • You want clients to access components in other tiers to retrieve and update data.
  • You want to reduce remote requests across the network.
  • You want to avoid network performance degradation coused by chattier applications that have high network traffic.

Solution
Use a Transfer Object to carry multiple data elements across a tier.

O Pattern Transfer Object, foi criado para solucionar os problemas dos Entity Beans (EJB 2.x), quando retornados para outro TIER, geralmente a apresentação, pois geralmente ficam em JVMs separadas. Quando você tenta retornar um Entity Bean, o que é retornado na verdade é um Stub para acesso ao mesmo. Quando são invocados os Getters deste, é aberto uma conexão de rede para cada invocação. Isso é extremamente custoso, gerando um overhead extremamente desnecessário.

Bem, mas nosso papo é tradução certo?

INI-UPDATE: Consegui o livro em português com um colega e estou adicionado a tradução em português também.

Vejamos a tradução para o português:

Transfer Object

Problema
Você deseja transferir diversos elementos de dados sobre uma camada.

Forças

  • Você deseja que os clientes acessem componentes em outras camadas para recuperar e atualizar os dados.
  • Você deseja reduzir as solicitações remotas ao longo da rede.
  • Você deseja evitar a degradação do desempenho da rede causada pelas aplicações muito ruidosas que têm alto tráfego de rede.

Solução
Use um Transfer Object para enviar vários elementos de dados por uma camada.

O leitor atento perceberia que o segundo e terceiro item da seção Forças fala de tráfego de rede e degradação do desempenho da mesma.

FIM-UPDATE

Acontece que, o termo TIER, foi traduzido erradamente no livro em português para camada. O mais correto seria camada física ou . Em Java isso pode ser considerado simplesmente “em uma outra JVM”. Essa tradução gera confusão a todo momento. Se você conversar com 10 desenvolvedores, vai perceber que a maioria acredita que TO/DTO pode/deve ser usado entre LAYERS (i.e. camadas lógicas, usadas apenas para organização do software). Eis um grave problema de tradução, pois uma grande parte não sabe a diferença entre LAYER e TIER, e o uso do Pattern dessa forma se mostrou uma solução sem sentido, conforme diversas discussões no próprio GUJ.

Outro grave problema recorrente é a tradução dos livros de Patterns. Pegue por exemplo o PEAA traduzido e veja o Pattern Active Record. O nome do Pattern foi traduzido para Registro Ativo. Parece piada, considerando que um dos maiores valores de um Pattern é a criação de um vocabulário comum.

Em fim, existem diversos outros exemplos ruins, e só quem perde com isso é o leitor.

Mas nem tudo está perdido. Existem sim traduções bem aceitáveis, porém em quantidade extremamente reduzida e demoram a sair. Você está disposto a esperar? Não acha melhor comprar o livro em inglês mesmo?

Mas se eu não domino o inglês? :(

Sinto informar, mas você vai ficar refém de boas traduções, isso quando tiver tradução. Sem contar os podcasts, como por exemplo os videos disponibilizados no InfoQ. Na verdade, muita coisa não tem tradução e nem vai ter, isso é fato.

Esse cenário serve pra reforçar a idéia de que o inglês na área de TI é fundamental para o profissional se manter atualizado, visto que existem livros que não são traduzidos, e os que são, ou a tradução é horrível, ou demora muito para ser traduzido após o lançamento da versão original.

Mesmo que o cenário mude, ainda assim tem muita coisa que você estará perdendo. Quem sabe um emprego no exterior?

Workshop Modelagem Agil e Domain Driven Design - Eu fui

Posted by Emerson Macedo on junho 17th, 2008

No último fim de semana (13 e 14 de junho/2008), participei com alguns amigos do Workshop de Modelagem ágil e DDD promovido pela Fratech em São Paulo.

O Workshop foi bem interessante, abordando temas atuais e de extrema importância no conhecimento do Desenvolvedor de Software.

No primeiro dia, o foco foi bastante em FDD, M3 e Agile Draw. Foi bem legal esse primeiro dia, pois eu experimentei algumas técnicas que nunca havia tentado. Confesso que não simpatizei muito com a modelagem com as figurinhas, nem muito com a FBS, mas eu vou pensar mais sobre o assunto e tentar me aprofundar um pouco pra tirar melhores conclusões.

Da esquerda pra direita: Colega de verde(rs), Gustavo, Eu, Colega de Branco(rs)

No segundo dia, o foco foi todo vontado para Domain Driven Design e UML em Cores. Foi bem interessante, pois o assunto tem um hype nos dias de hoje e é um assunto bastante motivador também.

A técnica de UML em Cores me ajudou um pouco a identificar algumas coisas em Model Driven Design, mas ainda assim, preciso testar mais pra definir se usarei essa técnica.

No mais gostaria de dar os parabéns ao Felipe Rodrigues e o Manoel Pimentel pelo evento que foi muito legal e tenho certeza que surgirão outros.

Da esquerda pra direita: Adndré, Eu, Felipe, Gustavo e Manoel

O unico problema é ter que se despencar do Rio de Janeiro toda vez, pois aqui estamos meio carentes de coisas do tipo, exceto pelo fato que as ultimas reuniões do RioJUG foram excelentes.

JRuby on Rails no RioJUG

Posted by Emerson Macedo on junho 4th, 2008

Na segunda-feira passada, tivemos uma palestra do Fábio Kung sobre JRuby on Rails no RioJUG. Basicamente foi um repeteco da palestra do Falando em Java 2008, a qual estive presente no dia 18/05 passado.

A palestra foi extremamente importante para abrir os olhos de muita gente que acha que Java vai ser Mainstream pra sempre. Pelo que tenho percebido, o tempo de Mainstream de uma linguagem tem diminuído bastante nos últimos tempos. Antigamente uma lingagem ficava na moda por muito mais tempo que hoje.

Em fim, voltando a palestra, foi bem interessante ver uma visão arquitetural de alto nível do GUJ 3.0, observar as escolhas das gems, o problema com as gems nativas e os contornos utilizados.

A escolha de rodar o Ruby na JVM, foi também um fator que foi muito falado durante a palestra. Os fatores principais foram a questão do compartilhamento de sessão entre os nós e o empacotamento do JForum junto na mesma aplicação, sem a necessidade de mágicas para não precisar de 2 logins.

Um fato que me surpreendeu até (já no Falando em Java 2008), foi quando o Fábio disse que a implementação JRuby está sendo considerada a implementação com melhor performance. Isso é muito legal, o que mostra o esforço grande para se obter alternativas à linguagem Java. E o melhor de tudo foi saber que já dá pra rodar o bichinho no Jetty, gerando a mesma produtividade encontrada na dupla Java/Jetty. O trabalho do Fábio foi tão fantástico no jetty_rails, que no RailsConf2008, Jeremy Kemper incluiu o jetty_rails em seu Keynote. O próprio Fábio falou sobre isso.

Pra concluir, apesar do JRuby on Rails e das novas oportunidades que irão surgir, o que mais me deixou feliz foi ver um projeto brazuca fazendo sucesso internacionalmente, no maior evento de Rails da atualidade.


Copyright © 2007 codificando.com. All rights reserved.