Temple Coding

código, tecnologia e outras nerdices

Publicando um site Octopress usando GitHub pages a partir de um novo computador

| Comentários

OK, eu admito, esse post é bem específico e ele serve mais para que eu nunca mais esqueça como fazer isso.

Esse blog é hospedado no GitHub Pages e é feito só com HTML, não tem nenhum CMS por trás. Mas eu uso o Octopress para gerar os arquivos HTML pra mim.

Tudo funciona muito bem, e esse post não é sobre como usar nem o Octopress, nem o GitHub pages, suas documentações são bem claras e não são necessários muitos passos para ter um site no GitHub pages de forma gratuita.

De qualquer forma, quando se publica um site no GitHub pages, o código fica hospedado e visível no GitHub no branch master e as páginas processadas e geradas ficam em um branch chamado gh-pages.

O problema

Tudo funcionava perfeitamente até eu ter que fazer um clone do repositório em uma outra máquina (já que troquei de computador) e publicar uma atualização do site.

Os passos que executei foram:

1
2
3
git clone git@github.com:usuario/repositorio.git

bundle install #para instalar as dependências do ruby
1
rake setup_github_pages

O comando acima cria o diretório _deploy e também um branch local gh-pages.

Após as minhas modificações quando fui fazer o deploy:

1
rake gen_deploy

Eu recebia o seguinte erro:

1
! [rejected]     gh-pages -> gh-pages (non-fast-forward)

E ainda dizia que o repositório não estava atualizado.

A solução

Enfim, depois de muito procurar, porque um git pull não resolveu, eu resolvi fazer um force push no momento do deploy.

Para isso eu abri o arquivo Rakefile e editei a tarefa push. Onde estava:

1
system "git push origin #{deploy_branch}"

Eu troquei para:

1
system "git push origin +#{deploy_branch}"

Perceba o sinal de + ali, isso fará um force push e resolve o problema. Depois de um deploy usando o force push, eu voltei a tarefa para como ela estava antes e tudo passou a funcionar normalmente mais uma vez.

Instalando uma máquina de desenvolvimento com dois comandos

| Comentários

Recentemente eu tive que preparar duas máquinas de desenvolvimento, um novo notebook Windows 8 e uma VM Windows 7 e, honestamente, por mais que eu goste de uma máquina nova, perder tempo instalando uma porção de aplicações e configurar tantas outras não é algo que eu ache divertido. Além do mais, sempre tem algumas coisas que eu não faço todo dia e, na hora que eu preciso eu não lembro. Por exemplo, como é que eu gero uma chave RSA para usar com ssh mesmo?

Enfim, dessa vez, ao invés de instalar tudo manualmente, eu decidi fazer um script que faz todas essas coisas automaticamente para mim. Usando PowerShell e Chocolatey.

Chocolatey Acho que o PowerShell é bem conhecido, então não vou perder muito tempo com ele. Sobre o Chocolatey, ele é um gerenciador de pacotes para linha de comando do Windows. Ele funciona mais ou menos como funciona o apt-get no linux ou o brew no Mac. É um projeto open source e gratuito bem interessante, é relativamente recente se comparado com as outras plataformas, mas ele funciona muito bem no Windows e é muito prático para evitar ficar procurando instaladores. Já existe uma grande variedade de aplicações disponíveis para serem instaladas através dele. Mas também, se precisar, é muito fácil criar um pacote e publicar lá, eu mesmo criei um pacote para instalar o DevKit do Ruby na versão 1.9.3 do Ruby.

Ok, chega de história. O script completo que eu criei está disponível em um gist. Ele é até que bem simples e suas principais partes estão comentadas (em inglês). Fique a vontade para baixar e modificar a gosto.

Mas o que ele faz?

Instala as seguintes aplicações usando o Chocolatey

  • Git
  • Poshgit
  • Ruby (1.9.3)
  • Node.js
  • WebPI
  • Notepad++
  • Sublime Text
  • ConEmu
  • Python
  • .NET Framework (4.0 e 4.5)
  • Putty
  • Firefox
  • Chrome
  • Fiddler
  • Filezilla
  • Winrar
  • MongoDB
  • Nuget Package Explorer
  • Skydrive
  • Evernote
  • Windows Installer (3.1 e 4.5)

Opcionalmente, no meio da execução do script ele pergunta se quer instalar o SQL Express 2012 (também utilizando o Chocolatey).

Customização do PowerShell e Git Bash

Eu tenho alguns atalhos criados tanto para o shell do PowerShell como o do Git, então eu baixo automaticamente essas customizações e adiciono nos respectivos arquivos de customização.

Configuração do Git

Na maior parte do tempo eu uso o Git como repositório de código ou o git svn e eu tenho algumas configurações globais que eu gosto de usar, como alguns arquivos que geralmente eu ignoro, ou alguns atalhos específicos para o git. Então eu também baixo essas configurações de dois outros gists que que tenho.

Gems e pacotes Node

Algumas gems para o Ruby que eu sempre uso são instaladas automaticamente, depois disso alguns pacotes do Node.js também são instalados.

Geração da chave RSA

Por fim, a última coisa que eu faço é gerar uma chave RSA que eu vou usar para me conectar via SSH em outros terminais, ou no GitHub.

Executando o script

Para executar o script são necessários dois comandos, mas primeiro, baixe o script do gist. Depois disso, abra o PowerShell como Administrador e, para executar um script baixado da internet é preciso modificar a política de execução do PowerShell, então digite:

1
Set-ExecutionPolicy Unrestricted

Depois disso, é só executar o script. Supondo que ele esteja no desktop, execute:

1
~/Desktop/dev_setup.ps1

E é isso, você tem todas as aplicações instaladas. Em algum momento da execução do script ele vai perguntar se você quer instalar o SQL Express e também uma senha para a chave RSA, mas no mais você tem uma máquina instalada com apenas dois comandos.

PS: Eu tentei fazer com que o Visual Studio 2012 fosse instalado automaticamente também, mas honestamente, não existe muita documentação sobre o assunto e achei que não valia o trabalho. Afinal, nesse caso é só montar um ISO e seguir os passos da instalação. Para uma aplicação só tá valendo.

Se você ficou com preguiça de ir lá olhar o script, veja ele aqui completo:

Só é uma bagunça se você deixar. Responsabilidade única com JavaScript

| Comentários

Muita gente que reclama de JavaScript mas não se dá ao mínimo trabalho de entender a linguagem e, boa parte das vezes, não trata o código desenvolvido como um código de verdade, afinal de contas “é só JavaScript mesmo”.

Mas esse é só uma das razões de boa parte dos problemas enfrentados quando a gente tem que dar manutenção em um código já existente. O bom e velho spaguetti de código.

Código spaghetti

Tenho que admitir que eu já contribui para bastante código spaguetti (como do exemplo que vou mostrar aqui). Exatamente porque não tratei esse código como um programa sério e não apliquei princípios básicos como o da responsabilidade única.

Vamos imaginar uma cesta de compras como a da imagem abaixo, que tem um link para atualizar a quantidade de itens do carrinho. O código que vou mostrar, captura o click no link usando o jQuery e faz uma validação de que o valor informado no campo é numérico. A regra de negócio diz ainda que tem que ser uma quantidade entre 0 e 10. Não posso vender mais do que 10 unidades de um mesmo item.

Carrinho de compras

Um código que faria isso é esse:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
$(document).ready(function() {
    $(".update_cart").click(function(e) {
      e.preventDefault();
      var itemsCount = $(this).closest("td").prev()
        .children(".quantity").val();
      if(isNaN(itemsCount) || parseInt(itemsCount, 10) < 0 ||
          parseInt(itemsCount, 10) > 10) {
          showError("Nao é numero valido");
          return;
      }
      $.ajax({
        url: '/updatecart',
        data: {
          // lógica para formatar os dados a serem enviados para o servidor
        },
        success: function(data) {
          // update table with cart data
        },
        error: function(xhr, status, error) {
          // handle error
        }
      });
    });
  });

Embora esse seja um código simples – e que está pouco mais curto do que realmente seria já que eu omiti alguns detalhes da implementação – ele viola um dos princípios de desenvolvimento mais importantes na minha opinião, que é o princípio da responsabilidade única. Mas, é um código que nós vemos com bastante facilidade em muitos aplicações na web.

Mesmo que a gente não tenha classes em JavaScript, as funções são usadas para fazer separações de responsabilidades. Veja, no exemplo acima, a função responsável por responder ao evento de click de atualização faz a validação, faz a chamada ajax e também atualiza a página após o resultado, seja com sucesso ou não.

Fazendo uma breve analogia, a chamada ajax como essa acima, pode ser comparada a uma chamada de um web service feito por um código C# ou Java. Ou seja, é um serviço externo ao código que está sendo executado, ou melhor ainda, é uma dependência externa que está gerando acoplamento no código. Taí a primeira separação que a gente pode fazer.

Outra ponto, o script acima lê informações da página (DOM) e depois atualiza informações nessa mesma página de acordo com o retorno do processamento. Então, em uma outra analogia, pode-se dizer que o DOM nesse caso, é uma forma de banco de dados do programa, portanto, é outra dependência externa que a gente pode separar no código.

Então vamos ver o que seria um código melhor estruturado para esse caso.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
$(document).ready(function() {

  function BasketUpdater (basketView, basketService) {
    this.init = function() {
      basketView.handleUpdate(this.update);
    }

    this.isValid = function(item) {
      var quantity = item.quantity;
      return !isNaN(itemsCount) &&
        parseInt(itemsCount, 10) >= 0 && parseInt(itemsCount, 10) <= 10;
    }

    this.update = function(item) {
      if(this.isValid(item)) {
        basketService.update(item,
          basketView.refreshViewSuccess, basketView.refreshViewError)
      }
    }
  }

  function BasketView() {
    this.handleUpdate = function(callback) {
      $(".update_cart").click(function(e) {
        e.preventDefault();
        // logica para formatar um objeto com os dados do item no formulario
        callback(item);
      }
    }

    this.refreshViewSuccess = function() {
      // 
    }

    this.refreshViewError = function() {
      // 
    }
  }

  function BasketService(url) {
    this.update = function(item, callbackSuccess, callbackError) {
      $.ajax({
        url: url,
        data: item,
        success: function(data) {
          algum codigo para formatar os dados de retorno
          callbackSuccess(data);
        },
        error: function(xhr, status, error) {
        // algum codigo para tratar a mensagem de erro
          callbackError(error);
        }
      });
    }
  }

  var basketService = new BasketService('http://localhost/updateCart');
  var basketView = new BasketView();
  var basketUpdater = new BasketUpdater(basketView, basketService);

  basketUpdater.init();

});

Mesmo que esse código seja um tanto quanto mais extenso que o anterior, fica bem clara a divisão de responsabilidades. Temos uma função para atualizar a view BasketView, uma para fazer a chamada ajax BasketService e uma com a lógica de negócio necessária para a página BasketUpdater.

Os benefícios de um código como esse (comparado com o anterior) são muitos, e bem semelhantes aos que a gente vê em códigos “servidor” bem estruturados.

  1. As dependências necessárias para que um objeto funcione (sim, uma função em JavaScript é um objeto) estão claras e definidas já no construtor.
  2. Uma função não depende explicitamente de outra, ela apenas espera um objeto que implemente determinados métodos
  3. É possível testar as funções isoladamente com um framework de testes
  4. É possível utilizar injeção de dependência e no caso dos testes, usar mocks
  5. É possível alterar uma função sem interferir na outra (desde que os nomes dos métodos se mantenham os mesmos)

Para concluir, temos um código muito mais organizado, de fácil manutenção e com responsabilidades claras. Para chegar nesse resultado, fiz uso apenas de técnicas já conhecidas de outras linguagens e sem inventar muita coisa. Então da próxima vez que você for dizer que é muito difícil dar manutenção em código JavaScript, pense se você está contribuindo para um código sustentável ou só preparando o almoço do próximo domingo.

Spaghetti

Meu TED Talk favorito

| Comentários

Ainda hoje, depois de muitos TEDs ouvidos e assistidos, o meu favorito ainda é um de 2007.

Ben Dunlap fala sobre uma vida apaixonada.

Assista primeiro, depois a gente conversa:

Diversas lições podem ser tiradas desse vídeo. Eu poderia focar na superação de um sobrevivente do holocausto, na forma como uma pessoa decidiu lidar com alguém que estava roubando suas coisas e como decidiu ver o melhor das pessoas, ou até sobre como lidar com diferenças culturais no mundo corporativo.

Mas eu fico mesmo com a lição mais clara que é a lição final. Se duas pessoas com tanto conhecimento e, no estágio da vida em que se encontravam na historia contada, podem ter tanta paixão pelo conhecimento, não importando o tipo do conhecimento, porque eu, que não sei quase nada da vida vou agir de forma diferente?

Viva cada dia como se fosse o último, aprenda como se fosse viver para sempre. Mahatma Ghandi

Então é isso, de tempos em tempos, eu gosto de assistir à esse vídeo para me lembrar disso.

Programação orientada à coincidência

| Comentários

Eu gosto muito de programar, gosto dos desafios técnicos que programar que traz. Mas o que eu mais gosto é do constante aprendizado que faz parte da profissão de programador.

Por causa de tudo isso eu nunca entendi ou gostei de frases como “se esta funcionando não mexe” ou “não encosta nesse código porque senão para de funcionar”. Como alguém que gosta de aprender, minha primeira pergunta é: porque para de funcionar? Ou, porque não pode mexer? Ou, o que vai estragar?

Informações sobre os mais diversos assuntos estão disponíveis de forma muito fácil (para uns até um pouco mais que para outros, não é NSA?) então não vejo sentido de não buscar se aprofundar nos assuntos. Scott Hanselman, em um ótimo post, já disse que a internet não é uma caixa preta. Citando uma frase desse post que resume o que eu quero dizer:

When coding on the web, remember that effectively NOTHING is hidden from you.

NADA esta escondido de você, enfase no NADA.

No livro The Pragmatic Programmer, Andrew Hunt e David Thomas dedicam um capitulo à programação por coincidência e eles abrem o capitulo com uma metáfora muito interessante. Eles comparam um programador que codifica por tentativa e erro, resolvendo problemas de forma aleatórias e sem conhecimento sobre o assunto à um soldado andando em um campo minado. O soldado pode dar um, dois, vários passos sem pisar em uma mina, achar que esta fazendo algo correto, mas é somente uma caminhada aleatória, uma hora ele pode pisar em uma mina e explodir.

Outra coisa bem comum quando não se entende do problema, é a tendencia de resolver as coisas sempre do mesmo jeito, ou seja é o velho caso daquela frase “se você só tem um martelo todo o problema é um prego”. Parece que é uma formula magica, funcionou para um problema não se sabe como, deve funcionar para os outros.

Ainda nesse sentido, pode ser que um problema seja resolvido passando dados inválidos para um método e que isso resulte numa resposta inesperada do programa. Mas se a sua unica fonte de analise for a resposta daquela chamada com dados inválidos, quando aquele programa for corrigido, sua chamada não vai mais funcionar porque aquela coincidência foi modificada.

E o pior na minha opinião, é a ignorância que isso gera. Até hoje ainda vejo gente que acha que POST é mais seguro do que GET só porque os dados não são enviados na URL!

Escolhendo a pilula vermelha

E sim, entender e aprender as coisas dá trabalho, toma tempo, tomar a pilula vermelha às vezes quer dizer por em prática para aprender, ou, como já disse um Yogi Berra:

Mastering knowledge alone, without experience isn’t effective

Ou, numa tradução livre e direta: Dominar um assunto sem a pratica não é efetivo.

Mas até onde ir?

Essa é uma linha difícil de traçar. De uma forma geral eu tento entender o suficiente para resolver o problema que eu estou enfrentando, e qualquer outra coisa, eu deixo para ler mais tarde.

Por exemplo, eu estava estudando Backbone.js usando esse tutorial, e nele é usado o padrão AMD implementado pelo Require.JS. Eu podia simplesmente seguir o tutorial que isso resolveria o problema, mas o que eu decidi fazer foi ler um pouco sobre o Require.JS no seu site para entender o seu funcionamento e depois ler sobre o padrão AMD quando eu tivesse um pouco mais de tempo. Esse tutorial, também usa o Node.js, ou seja, depois eu ainda fui explorar um pouco sobre o Node.js :)

É claro, não existe uma regra, e ninguém pode dizer até onde cada um deve ir, você é quem tem que traçar a linha entre o que é informação necessária e o que é procrastinação, sempre tentando ser pragmático.

O mais importante de tudo é deixar a preguiça de lado e entender o que você faz. Não basta pegar a primeira resposta no StackOverflow. Afinal de contas, você também não ia gostar que um médico te receitasse um medicamento só porque esse remédio funciona para a dor de barriga de outra pessoa, você quer que ele te examine e te diga porque esse remédio vai funcionar, não é?

Quatro bons livros para mudar a forma como você vê/escreve JavaScript

| Comentários

A maioria dos programadores que eu conheço dizem que não gostam de JavaScript. Eu entendo que a linguagem tem muitas coisas que são “meio bizarras”, mas eu também tenho certeza que não gostar de JavaScript, vem do fato de que as pessoas não conhecem a linguagem além da sintaxe básica e, de copy/paste de scripts prontos encontrados na internet.

JavaScript tem chaves {}, ponto e virgula, tem Java no nome mas seu funcionamento não tem nada a ver nem com Java ou com qualquer outra linguagem derivada de C, como o C#. Por isso, para usar o JavaScript de uma maneira correta e até para começar a gostar da linguagem a gente tem que entender seu funcionamento.

Aqui vai uma pequena lista de quatro livros que li sobre JavaScript que vão ajudar a aprofundar seu conhecimento sobre: a linguagem, sobre as interações com o browser e até como escrever um código mais rápido, organizado e elegante usando o que o JavaScript tem de melhor.

Os livros que vou indicar podem ter assuntos que são cobertos mais de uma vez em cada livro. Mas de uma forma geral, são livros que se complementam tratando a linguagem e o ambiente em que ela existe de formas diferentes.

JavaScript: The Good Parts por Douglas Crockford

Pra mim esse livro é uma boa introdução para quem quer começar a entender um pouco além da sintaxe básica da linguagem. Não, ele não é um livro que vai aprofundar muito na linguagem, vai apenas começar a cobrir alguns tópicos de uma forma mais avançada. Mas principalmente, vai ajudar a entender um pouco melhor o que JavaScript tem de bom. Se você já entende bem a sintaxe do JavaScript, já sabe como funcionam objetos e funções no JavaScript você pode pular esse livro.

JavaScript Patterns por Stoyan Stefanov

Como o nome diz, vai falar de padrões. Os padrões aqui estão relacionados às características especificas do JavaScript, como por exemplo, como fazer reuso de código usando Prototype. Fala ainda de convenções adotadas na linguagem, como resolver o problema do escopo global, como usar construtores, entre outros. O livro aborda também alguns dos padrões do GoF, mas com uma visão focada nas características do JavaScript. Esse com certeza é um livro que deve ser lido por qualquer programador que queira levar o JavaScript mais a sério.

Secrets of the JavaScript Ninja por John Resig

Pra mim, o melhor livro sobre JavaScript do ponto de vista didático. Ótimos exemplos, explicações bem claras e muitos detalhes sobre a linguagem. Foi nesse livro que vi a melhor explicação do funcionamento de closures em JavaScript. Dos livros que estou indicando, é o que lida mais com as interações entre o JavaScript e o browser, inclusive demostrando estratégias para lidar com as diferenças entre os principais fabricantes de browser.

Effective JavaScript: 68 Specific Ways to Harness the Power of JavaScript por David Herman

Esse é sem duvidas o livro que vai mais a fundo na linguagem. É um livro curto, mas com muitas informações. Se você deixar para ler esse livro por ultimo (eu recomendo assim), vai ver que algumas das dicas vão ser repetidas, mas a maioria das dicas vai trazer bastante informação. Alguns dos itens precisam ser lidos mais de uma vez porque são bem complexos (pelo menos para o meu cérebro limitado), mas o livro é pura informação do começo ao fim.

Tudo isso sobre JavaScript?

Pode parecer muito para uma linguagem que muitas vezes parece tão simples e, de fato, a sintaxe do JavaScript é simples. Mas alguns conceitos não são muito conhecidos especialmente para programadores acostumados com linguagens estáticas e não habituados à programação funcional. Se você não quiser/puder ler todos mas ainda assim quiser ler sobre JavaScript eu diria para ler pelo menos dois: JavaScript Patterns e Secrets of the JavaScript Ninja. Esses dois cobrem a maior parte dos assuntos que vemos no dia a dia, e com certeza já vão ajudar a sair do nível “copy/paste” para chegar no nível de entender o que realmente esta acontecendo quando você faz suas aplicações com JavaScript.

Boa leitura!

Análise do livro Pragmatic Thinking and Learning

| Comentários

Alguns livros são tão bons que você tem vontade de falar deles para todo mundo antesmesmo de terminar. Esse é um deles.

Numa tradução livre e amadora do resumo do livro no site, diz o seguinte:

Nesse livro escrito por Andy Hunt, você vai aprender nosso cérebro é conectado e, como tirar proveito d arquitetura do seu cérebro. Você vai aprender novas dicas e truques para aprender mais, mais rápido e guardar mais do que você aprende.

Eu posso resumir a minha avaliação desse livro em uma frase bem curta. Eu queira ter lido antes.

Realmente o livro traz diversas informações sobre o funcionamento do nosso cérebro, informações que, pelo menos para mim, eram novas. Ou então eram informações que eu tinha obtido e não tinha guardado. É muito interessante (e útil) as analogias que autor usa para explicar o nosso cérebro fazendo referências à arquitetura de computadores e a programação assíncrona.

O livro não fica só na parte teórica do funcionamento de cérebro. É interessante entender o que é o modelo Dreyfus e os estágios que passamos na obtenção de conhecimento. São eles: iniciante, iniciante avançado, competente, proficiente e expert. Embora eu não ache que as pessoas possam ser categorizadas em níveis, ou melhor, só em cinco níveis, eu acho também que é uma forma de feedback e uma forma de termos parâmetros para nos guiar em como alcançar um nível mais alto de conhecimento.

Que as pessoas aprendem de forma diferente já é bem divulgado, mas o que eu achei interessante sobre as formas que aprendemos (relacionado com o funcionamento do nosso cérebro), foi que o livro expõe de forma bem clara e, sempre usando ótimas métaforas, como podemos explorar essas diferenças com técnicas práticas.

Uma das técnicas passadas no livro é a técnica de definição de objetivos de aprendizado

chamada S.M.A.R.T. Que é o acrônimo para Specific, Measurable, Attainable, Relevant e Time-Bound. Outras incluem, carregar sempre um livro de notas, criar um wiki pessoal,desenhar mapas mentais, entre outros. Tudo sempre com um ótimo embasamento teórico.

Eu, como leio muito, gostei muito do livro e tenho tentado por em práticas coisas que já aprendi. Espero que você aproveite a dica e leia o livro, eu gostei muito.

ASP.NET MVC Model Binding

| Comentários

ASP.NET MVC Model Binding

Nesse video explico o funcionamento do ASP.NET MVC Model Binding, começo com alguns exemplos básicos e depois mostro como criar um Model Binder Customizado.

Por fim, mostro como criar um Model Binder Provider que retorna um Model Binder customizado e genérico para usar junto com o Entity Framework, mas que obviamente poderia ser qualquer outro como NHibernate.

O código está disponível no meu github.

Integrar é traduzir, não é reproduzir

| Comentários

Eu trabalho fazendo integrações de aplicações web com o SAP há alguns anos já. E existem “alguns padrões” (vou chamar de padrões), que existem no SAP que são bem particulares à esse ERP.

Só para ambientar aqueles que não conhecem nada de SAP, o SAP é um grande ERP e ele possui todo um ecossistema próprio para customização e criação de soluções de negócio. Por exemplo, ele tem uma linguagem própria o ABAP, tem um protocolo de comunicações proprietário, o RFC, entre outras coisas. Fora isso, existe também toda uma cultura particular de desenvolvimento, que honestamente, eu não conheço muito, já que nunca fui um programador ABAP.

A minha questão aqui é, independente do porque, e se esta certo ou não, geralmente quando faço integrações com o SAP encontro coisas que não estou acostumado a ver quando desenvolvo minhas soluções usando outras tecnologias, como por exemplo, .NET e C#.

Por exemplo, em muitas integrações que fiz com o SAP quando chamo uma função remota e essa gera um erro, ao invés de receber um exceção, a chamada é executada com sucesso e uma estrutura de dados (como na imagem abaixo) é retornada preenchida contendo um tipo de erro, um código e possivelmente algumas mensagens. Esse é um padrão usado e que já vi várias vezes.

Obs.: Steven McConnell deve ficar tão orgulhoso disso.

OK, mas qual é o problema disso e o que tem a ver com o que eu faço?

Bom, o problema na minha opinião, é quando esse tipo de padrão começa a vazar para outras aplicações. Tenho que admitir que eu já fiz a minha parte de permitir que isso vazasse. Shame on me!

Mas voltando, se estamos fazendo uma integração com uma aplicação terceira, não importa qual, e ela tem uma particularidade, não precisamos expor essa particularidade, podemos encapsulá-la e mudar o padrão para algo mais genérico, ou que faça sentido para a nossa plataforma de desenvolvimento. Por exemplo, no caso de um Web Service, lançar um SoapException.

Outro padrão comum ao SAP é a nomenclatura de estruturas. Não sei porque, mas encontramos muitas estruturas com esse tipo de nomenclatura.

Talvez isso faça sentido na cabeça de algum alemão louco, mas, voltando ao C#, um nome de variável pode ter até 1023 bytes, isso quer dizer que podemos ser bem mais descritivos que isso. E no caso de um Web Service também, não ha uma limitação especifica para o nome de uma tag XML.

Mais uma vez o ponto é, no momento em que estamos fazendo uma integração, seja qual for a tecnologia utilizada (no meu caso é o BizTalk), esse é o momento de abstrair particularidades, de aplicar boas práticas para quem vai consumir essa integração.

Eu vejo uma integração como uma tradutora. Ela ouve em alemão e traduz para português, ela não traduz algumas partes para português e mantém outras no formato original. Para mim, que não falo nada de alemão, isso só me atrapalharia.

E nem sempre é uma questão de certo ou errado, mas sim de pontos que são mais idiomáticos em uma tecnologia do que em outra. Nesse caso o problema são as traduções literais que muitas vezes não fazem sentido, temos que contextualizar para a tecnologia que estamos usando.

Mais uma vez usando o SAP como bode expiatório exemplo, existem alguns casos em que as strings não podem ter mais do 132 caracteres, por isso vemos estruturas como a anterior que tem campos message1, message2, message3, etc., e, embora isso funcione, é uma limitação daquela plataforma/tecnologia. Esse não é o caso de um XML ou do próprio C#, portanto, passar uma estrutura dessas adiante é simplesmente fazer uma tradução literal e não olhar para o contexto.

Concluindo, quando for integrar duas ou mais aplicações, tenha em mente os limites tecnológicos, funcionais e semânticos de cada ponta. Leve em consideração o que é um padrão proprietário e deve ser transformado do que realmente é um padrão de integração e deve ser mantido. Existem inclusive livros que podem nos ajudar com isso.