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.

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.

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:

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.

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.

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.

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.

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 é?

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!

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

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.

Por exemplo, tem um bom roadmap para aprender Node.js com confiança ou então, um outro para aprender JavaScript avançado.

Bom, fica ai a dica rápida.

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.

Primeiro um exemplo. Se eu quiser iterar por todas as propriedades é métodos de um objeto o código é exatamente o que imaginamos.

1
2
3
4
5
6
7
8
9
10
11
12

var propriedade;
var pessoa = {
    nome: 'Thiago',
    sobrenome: 'Temple',
    dizOla: function() {
        alert('Ola');
    }
};
for(propriedade in pessoa){
    document.writeln(propriedade);
}
//exibe: nome sobrenome dizOla

Esse código produz um retorno com: nome sobrenome dizOla

Se eu quiser exibir somente os atributos e não os métodos, eu preciso adicionar um filtro no loop, dessa forma:

1
2
3
4
5
6

for(propriedade in pessoa){
    if (typeof pessoa[propriedade] !== 'function') {
        document.writeln(propriedade);
    };
}
//exibe: nome sobrenome

Até aqui bem simples.

O primeiro ponto a considerar é que nunca podemos garantir a ordem do retorno de um loop for in. Geralmente isso não importaria muito, como no exemplo anterior, mas no caso de um array, que é também um objeto, isso pode ser importante. Nesse momento é melhor usar mesmo um loop for do que um loop for in.

A segundo ponto a considerar é que o JavaScript tem herança através da propriedade prototype, e que todo objeto herda de Object. Isso é importante porque o JavaScript é uma linguagem dinâmica e, portanto, se alterarmos Object isso vai refletir nos nossos objetos, não importa o momento que alteramos Object. Por exemplo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

var propriedade;
var pessoa = {
    nome: 'Thiago',
    sobrenome: 'Temple',
    dizOla: function() {
        alert('Ola');
    }
};

Object.prototype.naoRelacionado = 'eu nao devia estar aqui';

for(propriedade in pessoa){
    document.writeln(propriedade);
}

//exibe: nome sobrenome dizOla naoRelacionado

No código acima eu defini um objeto chamado pessoa e depois disso eu adicionei um atributo chamado naoRelacionado à Object. Mesmo assim esse atributo foi exibido dentro loop for in. Isso pode vir a ser um problema quando alteramos o prototype de Object em outra parte do código que não esta relacionado ao código que estamos fazendo.

No caso do loop for in, podemos resolver isso com o método hasOwnProperty.

1
2
3
4
5
6
7

for(propriedade in pessoa){
    if(pessoa.hasOwnProperty(propriedade)) {
        document.writeln(propriedade);
    }
}

//exibe: nome sobrenome dizOla

O método hasOwnProperty verifica se a propriedade foi definida no objeto em questão.

É isso ai.

Inversão de Controle com Castle Windsor e ASP.NET MVC

Demonstração usando ASP.NET MVC e Castle Windsor como container de inversão de controle.

O código está disponível no GitHub.

Bora falar um pouco mais de JavaScript e o que existe de estranho com os construtores de Arrays do JavaScript.

Construtores de Arrays do JavaScript

No JavaScript podemos construir um Array da seguinte forma:

1
2
3

var a = new Array("texto");
console.log(a.length); // 1
console.log(a[0]); // texto

Quando passamos uma string ou outro tipo de objeto para o construtor de uma Array, o JavaScript cria uma array com um item e atribui o valor passado para esse item.

Agora vamos dar uma olhada em outro exemplo:

1
2
3

var a = new Array(3);
console.log(a.length) // 3
console.log(a[0]); // undefined

Quando passamos um número inteiro para o construtor ele cria um array com o número de elementos informados e, todos os elementos criados não tem um valor atribuído a eles, por isso o undefined.

Um terceiro exemplo:

1

var a = new Array(3.2); // RangeError: invalid array length

Quando passamos um número decimal para o construtor, ele obviamente não cria um array decimal, mas também não cria um array com um só elemento e com o valor passado, o JavaScript retorna um erro para esse comando.

Uma prática um pouco melhor

A melhor forma de criar arrays no JavaScript é usando o construtor implícito dele, por exemplo:

1
2
3

var a = ["texto"]; // Cria um elemento e atribui o valor a ele

var b = [1, 2, 3]; // Cria um array com 3 elementos e com os valores 1, 2 e 3

Um problema simples de resolver esse, não é?

Validação com jQuery Validation

O jQuery validation é um plugin para fazer validações de formulários. Nesse video mostro como fazer algumas validações como:

• campos obrigatórios
• customizações de mensagens
• validações de tipos de dados específicos como data, email e números
• validações remotas usando ajax
• globalização usando o plugin Globalize

Links

•  jQuery validation
• Globalize

1
2
3
4
5
6
7
8
9
10
11
12
13

var comErro = function() {
    throw {
        name: 'CustomError',
        message: 'Um erro muito grave para ser tratado'
    };
};

try {
    comErro();
}
catch(e) {
    console.log(e.name + ' - ' + e.message); //CustomError - Um erro muito grave para ser tratado
}

Apesar do JavaScript não ser tipado, existe uma convenção que diz que todo objeto de erro deve conter ao menos duas propriedades: name e message. Acho que os nomes das propriedades são auto-explicatórios.

Obviamente, nada nos impede de adicionar outras propriedades com mais detalhes sobre o erro.

Tipos de erro do JavaScript

Por padrão o JavaScript tem internamente seis tipos diferentes de erro que ele pode gerar.

Isso serve apenas como referência, como mostrei no exemplo anterior, podemos criar os nossos próprios tipos de erro sem problemas.

Construtores de objetos de erro

Por fim, o JavaScript também tem alguns construtores para os objetos que podemos usar para retornar um erro, por exemplo, eu poderia reescrever a exemplo acima da seguinte forma:

1
2
3
4
5
6
7
8
9
10
11
12

var comErro = function() {
    var error = new Error('Um erro muito grave para ser tratado');
    error.name = 'CustomError';
    throw error;
};

try {
    comErro();
}
catch(e) {
    console.log(e.name + ' - ' + e.message); //CustomError - Um erro muito grave para ser tratado
}

Esse código gera exatamente o mesmo resultado que antes, o único detalhe que quero ressaltar é que se eu não tivesse feito:

1

error.name = 'CustomError';

o nome do erro seria Error.

Como o objeto Error, temos também um construtor para cada tipo de erro do JavaScript: EvalError, TypeError, ReferenceError, etc.

Ajax com jQuery

Existem diversas formas de fazer ajax com jQuery. O jQuery é muito versátil e poderoso, mas também é capaz de tornar algumas atividades que antes eram tediosas em códigos simples e curtos, ainda mais com a ajuda de alguns plugins.

Links

Documentação ajax do jQuery jQuery Form Plugin Toastr Plugin jQuery loadmask plugin

Código fonte

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

Uma função no JavaScript é um objeto, isso quer dizer que a gente pode passar uma função como parâmetro para outra função. Quando passamos uma função como parâmetro para outra, a função passada como parâmetro é uma função de callback.

Por exemplo:

1
2
3
4
5
6
7

var pessoa = function(nome, dizerOla) {
    dizerOla(nome);
};
var olaNoConsole = function(nome) {
    console.log(nome); // 
}
pessoa('Thiago', olaNoConsole);

No código acima, eu defini uma função chamada pessoa e outra olaNoConsole. A função pessoa recebe uma string com um nome e uma função de callback que ela vai usar para fazer uma saudação. Repare que, quando passo a função olaNoConsole como parâmetro, eu não utilizo parêntesis. Os parêntesis executam a função, então nesse momento que eu não quero executar a função, eu não os utilizo. A função de callback pode ser também uma função anônima como no exemplo abaixo:

1
2
3
4
5
6

var pessoa = function(nome, dizerOla) {
    dizerOla(nome);
};
pessoa('Thiago', function(nome) {
    alert('Ola ' + nome);
});

A mesma função pessoa agora recebendo uma função anônima que faz um alert como saudação.

Por quê?

Por que fazer uso de funções de callback? Acho que o exemplo acima deixa claro que a principal vantagem é o reuso sem causar acoplamento. No caso a função pessoa nunca sabe como é feita a saudação, tudo o que ela sabe é que tem que chamar a função de callback passando um parâmetro. Foi possível trocar a saudação de console para alert sem alterar a função pessoa.

Um exemplo um pouco mais útil é quando fazemos loops de elementos, por exemplo, vamos supor que eu queira consultar todos os meus campos texto na página, fazer alguma coisa com cada um deles e no fim retornar a lista de campos.

1
2
3
4
5
6
7
8

var listaCampos = function() {
    var campos = document.getElementsByTagName("input");
    var totalItens = campos.length, i;
    for (i = 0; i < totalItens; i++) {
        // algo bem complexo com cada campo
    }
    return campos;
};

Depois disso eu decido que eu quero que cada campo tenha uma borda vermelha, porque eu quero destacar esses campos. Eu poderia pegar o retorno dessa função, fazer um for em cada item de novo e adicionar a borda.

1
2
3
4
5

var campos = listaCampos();
var totalItens = campos.length, i;
for (i = 0; i < totalItens; i++) {
    campos[i].setAttribute("style", "border: 1px solid red");
}

O problema com essa solução é que eu fiz dois loops, um quando peguei os campos e um quando quis deixá-los com a borda vermelha. É possível ser mais simples (e mais rápido) do que isso, eu poderia alterar dentro do for original da função listaCampos e adicionar a linha para deixar os campos com a borda vermelha.

1
2
3
4
5
6
7
8
9

var listaCampos = function() {
    var campos = document.getElementsByTagName("input");
    var totalItens = campos.length, i;
    for (i = 0; i < totalItens; i++) {
        // algo bem complexo com cada campo
        campos[i].setAttribute("style", "border: 1px solid red");
    }
    return campos;
};

O problema dessa segunda opção é que se eu quiser usar essa função listaCampos em outra parte no meu código, eu sempre vou ter os campos com a borda vermelha. E nem sempre eu quero vermelho, pode ser que em outro ponto eu queria azul! Aí entra o callback.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

var campoVermelho = function(campo) {
    campo.setAttribute("style", "border: 1px solid red");
};

var listaCampos = function(callback) {
    var campos = document.getElementsByTagName("input");
    var totalItens = campos.length, i;

    if (typeof callback !== 'function') {
        callback = false;
    }

    for (i = 0; i < totalItens; i++) {
        // algo bem complexo com cada campo
        if(callback) {
            callback(campos[i]);
        }
    }
    return campos;
};

listaCampos(campoVermelho);

No código acima, a primeira coisa que eu fiz foi criar a função de callback que espera um campo como parâmetro e faz com que a borda desse campo fique vermelha. Depois, na função listaCampos eu alterei a função para que ela receba um parâmetro, que vai ser uma função de callback.

Em seguida eu testo para ver se uma função foi realmente passada (já que no JavaScript os parâmetros não são obrigatórios). Dentro do loop, se a função de callback foi passada como parâmetro, eu a executo.

Nesse caso agora se eu quisesse que os campos tivessem a borda azul era só criar uma outra função que fizesse isso e passar como parâmetro para a função listaCampos. A função listaCampos continua sendo genérica e pode ser utilizada por outras. Melhor que isso, é uma função que faz uma coisa só e não está com a funcionalidade acoplada a ela.

Funções de callback e escopo

Dito isso, agora vem a parte um pouco mais complicada que é a parte do escopo com as funções de callback. Imagine que ao invés de passar uma função, eu tenho um objeto e eu passo um método desse objeto como callback para a função listaCampos.

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

var listaCampos = function(callback) {
    var campos = documente.getElementsByTagName("input");
    var totalItens = campos.length, i;

    if (typeof callback !== 'function') {
        callback = false;
    }

    for (i = 0; i < totalItens; i++) {
        // algo bem complexo com cada campo
        if(callback) {
            callback(campos[i]);
        }
    }

    return campos;
};

var customCampo = {
    'cor': 'red',
    'defineCor': function(campo){
        campo.setAttribute('style', 'border: 1px solid ' + this.cor);
    }
};

listaCampos(customCampo.defineCor);

No exemplo acima, o objeto customCampo tem um método defineCor que eu passo como callback para a função listaCampos. O problema é que o método defineCor usa this para fazer acesso ao valor da propriedade cor. Mas, a função listaCampos faz parte do objeto global e portanto nesse momento this vai fazer acesso ao objeto global também.

A solução para esse caso é sempre que passar uma função de callback, passar também o objeto que será o contexto da função de callback.

1

listaCampos(customCampo.defineCor, customCampo);

E aí eu preciso modificar também a função listaCampos

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

var listaCampos = function(callback, ctx) {
    var campos = documente.getElementsByTagName("input");
    var totalItens = campos.length, i;

    if (typeof callback !== 'function') {
        callback = false;
    }

    for (i = 0; i < totalItens; i++) {
        // algo bem complexo com cada campo
        if(typeof callback === 'function') {
            callback.call(ctx, campos[i]);
        }
    }

    return campos;
};

Isso resolve o problema, mas quando chamamos a função listaCampos temos que informar duas vezes o objeto customCampo:

1

listaCampos(customCampo.defineCor, customCampo);

Existe uma forma um pouco mais elegante para isso, a gente pode chamar a função listaCampos dessa forma:

1

listaCampos('defineCor', customCampo);

E aí alteramos a função listaCampos para:

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

var listaCampos = function(callback, ctx) {
    var campos = documente.getElementsByTagName("input");
    var totalItens = campos.length, i;

    if (typeof callback === 'string') {
        callback = ctx[callback];
    }

    if (typeof callback !== 'function') {
        callback = false;
    }

    for (i = 0; i < totalItens; i++) {
        // algo bem complexo com cada campo

        if(typeof callback === 'function') {
            callback.call(ctx, campos[i]);
        }
    }

    return campos;
};

var customCampo = {
    'cor': 'red',
    'defineCor': function(campo){
        campo.setAttribute('style', 'border: 1px solid ' + this.cor);
    }
};

Um pouco mais elegante.

Por hoje é só, espero que tenha sido útil!

É um dos livros com a maior quantidade de dicas praticas que já li. Diversas dicas e ideias de uso imediato. Para quem usa, ou planeja usar, o WordPress como plataforma é ainda mais útil. O livro apresenta vários plug-ins que vão facilitar a vida na hora de escrever, ajudar a trazer mais performance para o site, trazer mais facilidade e valor para os usuários que vão ler o blog.

Produzindo conteúdo

Os capitulos 5 e 6 “Creating Remarkable Content” e “Producing Content Regularly” são ótimos para dar ideias e abrir a mente para a produção de conteúdo diversificado e com regularidade.

Promovendo seu blog

As dicas para promover o blog do capitulo 7 foram extremamente valiosas. Eu sempre tive pra mim que SEO era uma daquelas coisas irrelevantes, que simplesmente funciona e pronto, bom, não é exatamente assim. Além disso, eu passei a olhar as estatísticas de visita do site de uma outra forma.

Para empresas e blogs em grupo

Se você faz um blog para sua empresa ou grupo, essa parte também não foi esquecida, embora, para blogs como esse isso não faça tanta diferença.

Para concluir essa breve análise do livro Technical Blogging; esse foi um livro que eu comprei sem esperar muita coisa dele, achando que não ia tirar muito proveito. Me enganei. Eu comecei a ler e não parei enquanto não terminei. Ótimo, eu recomendo.

Seletores jQuery

Para selecionar elementos do DOM o jQuery faz uso dos seletores do CSS e também possui alguns seletores próprios. Nesse video eu mostro alguns exemplos desses seletores, de forma individual e combinando tanto seletores CSS como seletores jQuery.

Links

Documentação dos seletores jQuery

A primeira parte é fácil, eu já falei um pouco disso quando falei de declaração de variáveis. Toda variável declarada com a palavra chave var tem o escopo da função em que foi declarada. Portanto, na função abaixo:

1
2
3
4
5
6
7

var func1 = function() {
    var i = 100;
    for(var i = 0; i < 10; i++) {
        // qualquer coisa aqui 
    }
    console.log(i); // 10 
}

A variável i vai ser 10 no fim do método, porque dentro de um método, não importa onde a variável é declarada, ela sempre faz parte do escopo da função. E claro, não pode ser acessada fora da função.

Agora o this é um pouco mais complicado. O this sempre faz referência ao objeto que a função faz parte. Por exemplo:

1
2
3
4
5
6
7

var pessoa = {
    'nome': 'Thiago',
    'getNome': function(){
        console.log('Olá, ' + this.nome);
    }
};
pessoa.getNome(); // Olá, Thiago

No exemplo acima, eu declaro um objeto e atribuo à variável pessoa. E getNome é definido com uma função, portanto essa função é um método desse objeto. Dessa forma o contexto de this dentro desse método é o objeto em que ele foi definido e chamada de getNome funciona como o esperado.

Já no exemplo abaixo:

1
2
3
4
5
6
7
8
9
10

var pessoa = {
    'nome': 'Thiago',
    'getNome': function(){
        var fx = function() {
            console.log('Olá, ' + this.nome);
        };
        fx();
    }
};
pessoa.getNome(); // Olá, undefined

Dentro do método, fx é apenas uma variável que recebe uma função, não é um método que faz parte de um objeto, por isso, this nesse caso faz referência ao escopo global, que no caso do browser, quer dizer o objeto window.

Trocando o escopo de uma função

A última coisa que eu quero dizer sobre o escopo e this é que no JavaScript nós podemos alterar a referência this. Veja o exemplo abaixo:

1
2
3
4
5
6
7
8
9

var dizOla = function() {
    console.log('Ola, ' + this.nome);
};

var pessoa = {
    'nome': 'Thiago Temple'
}

dizOla.call(pessoa);

A função dizOla nao faz parte de nenhum objeto, portanto this dentro daquela função faz referencia ao objeto window. Mas, quando executo a função usando o método call, eu passo o objeto pessoa como parâmetro. Nesse momento estou dizendo para a função dizOla usar o objeto pessoa como contexto.

Alterar o escopo no JavaScript é uma característica muito importante e muito utilizada, porque é uma forma bem simples e eficaz de fazer reuso de funções.

É isso aí por hoje. Até a próxima!