Compressão até dar erro

Estava desenvolvendo um código javascript esses dias e tudo estava correto, até ir para produção 😀

Quando fui olhar a compilação, descobri o seguinte erro:

failed to read/parse data in file *.js

missing name after . operator

O problema estava durante a geração do arquivo minificado com o YUI Compressor. A linha de código com problema era a seguinte:

this.delete = function() {
     ...
};

Legal, aprendi que não posso escrever uma função com o nome delete.

Anúncios

Crash, no limite!!!

Caiu para eu resolver um problema bem interessante. No navegador Safari (versão 6.0.1) para o IOS ao abrir uma página o navegador simplesmente fechava, apresentado a janela de erro com o stacktrace. Uau… que página foda, fez o browser do IOS se fechar (nota importante em todos os outros browser funcionava, até no IE 9)

Outras pessoas já tinham conseguindo identificar que desabilitando os CSS da página ela abria sem problemas. Ao ler o stacktrace, confirmo que o problema estava realmente na configuração de estilos, em especial em animações.

Começo aquele trabalho de ir comentando os trechos de código CSS e recarregando a página até que não desse mais o erro. Como tinha poucos estilos envolvendo transitions e/ou transform foi bem rápido.
O problema era causado no seguinte HTML:


<section id="content">
<canvas />
</section>

com a seguinte formatação
#content {
-moz-transition: all .1s linear 0s;
-o-transition: all .1s linear 0s;
-webkit-transition: all .1s linear 0s;
transition: all .1s linear 0s;
}

eu tinha duas escolhas para resolver o problema:

  1. retirar o canvas
  2. retitrar o -webkit-transition

Qual será que escolhi?? Ficar com o desenho na tela, mesmo que sem transição durante as alterações, óbvio.

O comando certo no lugar certo

Essa semana aconteceu uma daquelas coisas muito irritantes. Ao liberar, em produção, uma nova versão do sistema a autenticação com o Facebook não estava funcionando. E não posso dizer que foi falta de teste, havia sido bem verificado.

Durante umas 3 horas eu mexi em todas as configurações possíveis e impossíveis, tanto no app do Facebook, quanto no IIS e nada. Com as configurações do ambiente de desenvolvimento funcionava perfeitamente.

Depois de algumas trocas de ideias eu fui olhar no código fonte em C#, revira daqui e dali e acho uma classe que não sabia que existia (feita por um outro colega) e começo a depura-lá.

O código da classe não parecia ter sido feito pelo meu colega, procurei na internet e achei um código bem parecido (http://social.msdn.microsoft.com/Forums/en-US/7ef9a2b0-c150-458e-9980-d1254837d0dd/aspnet-mvc-facebook-login-returns-wrong-url), porem com uma leve diferença no método GetHtml.

Para encurtar a história, quando a URL para o Facebook era montada (http://endeco.com.br:80/LoginFacebook) a porta 80 gerava um bug em algum lugar na API do próprio Facebook. Logo o comando

.Replace("%3a80", "")

retirava a anomalia e o código funcionou perfeito.

No ambiente de testes funcionava correto pois o endereço era http://localhost:52576, uma porta qualquer.

MALDIÇÃO!!!!!!!

Tempo perdido no navegador

Todo o desenvolvedor de software web tem um grande problema e ele se chama browser, ou navegador, ou programa_que_eu_navego. Atualmente o mais utilizado (e melhor) é o Google Chrome, mas temos que nos preocupar com Internet Explorer 9, Internet Explorer 10, Firefox, Opera, Safari e algum novo que é utilizado por menos de 1% das pessoas.

Existem alguns padrões que regulam o desenvolvimento web, principalmente o W3C. Mas a coisas é meio zoada. Ter o mesmo layout funcionamento perfeitamente em todos os navegadores é um dom e eu não tenho esse dom, mesmo porque o DOM muda bastante. 😀

Recentemente eu tive um problema, uma requisição HTTP Post realizada através do jQuery não estava funcionando no IE 9, mas no IE 10 sim. A mensagem de erro do browser era muito bem detalhada, era o seguinte “No Transport”. Depois de algum tempo procurado encontro que o problema ocorre por causa das requisições entre 2 servidores (chamada de CORS, http://pt.wikipedia.org/wiki/Cross-origin_resource_sharing) e que o IE 9 não implementa totalmente isso. Depois de muita troca de código e procura, consigo evoluir o problema, a mensagem passou a ser “Acesso Negado”.

Horas (no plural mesmo) procurando uma solução e finalmente encontro um post http://stackoverflow.com/questions/10232017/ie9-jquery-ajax-with-cors-returns-access-is-denied com o que viria a ser a minha solução. A explicação é bem simples, o jquery ajax utiliza o XMLHttpRequest para realizar a requisição, porem o IE 9 não permite utiliza-lo neste cenário. Existe um outra solução, que somente o IE suporta, utilizar o XDomainRequest.

Um cara, e eu confio em alguém vestido de Batman, criou um código que modifica o comportamento do jquery ajax para usar o XDomainRequest quando necessário. Obrigado Julian Aubourg (https://github.com/jaubourg).

Depois disso tudo funcionou?? Não, claro que não, nada é tão fácil, tivemos que alterar o serviço pois o XDomainRequest transfere os dados de maneira diferente do XMLHttpRequest. Finalmente achamos um meio termo que funcionou para ambos.

Moral da história: poderia só existir o Netscape Navigator.