LuizTools 2.0

Desde 2010 codificando minhas ideias!

Os Bastidores da Internet no Brasil - Resenha

Conheci esse livro por acaso. Na verdade já tinha ouvido falar dele, mas nunca tinha dado muita aten

Conheci esse livro por acaso. Na verdade já tinha ouvido falar dele, mas nunca tinha dado muita atenção. Meu antigo chefe sempre comentava que seu sonho era criar uma empresa que fosse lembrada a ponto de ir parar em um livro como esse. Criar um legado. Quando conheci esse livro de verdade estava fazendo uma capacitação no Centro de Inovação da Microsoft, em Porto Alegre, chamado Catalyst. Um dos colegas da turma que estava sendo capacitada para conduzir melhor suas startups comentou sobre o livro e como gostaria de ter presenciado os acontecimentos daquela época. "Àquela época" ao qual ele se referia era a bolha da Internet, que talvez você já tenha ouvido falar.

As histórias de sucesso e de fracasso que marcaram a web brasileira

Esse é o subtítulo do livro e com ele você já tem uma ideia do que o espera em suas páginas. Escrito pelo jornalista Eduardo Vieira no início dos anos 2000, é um livro que retrata a história da internet comercial como a conhecemos, principalmente em terras brasileiras. O livro começa retratando o surgimento da mesma nos EUA e sua posterior chegada nas universidades brasileiras e mais tarde em nossas empresas e lares.

O brasileiro é um povo empreendedor por natureza e a chegada da Internet fez com que muitos negócios surgissem e um dos primeiros capítulos retrata o surgimento dessas startups da década de 90. A Microsoft brasileira de Marcelo Lacerda, chamada Nutec que mais tarde entraria na Internet como NutecNet, um dos primeiros provedores de acesso brasileiros. Conta a história de Mandic, que pra mim era apenas o nome de uma empresa, mais tarde descobrindo sobre o pioneirismo de Aleksandar Mandic, outro aventureiro da Internet brasileira. Outro famosos empreendedor citado no livro é Jack London, que apesar do nome é o brasileiro por trás do primeiro e-commerce nacional, a BookNet (algo como um Amazon tupiniquim) que mais tarde seria vendida se tornando o Submarino.

As Grandes Marcas e o Big Bang

Mais tarde, com o crescimento de iniciativas bem sucedidas como a NutecNet, a Mandic e a Booknet, grandes marcas foram se formando na Internet brasileira, como o ZAZ (através da compra da NutecNet pelo Grupo RBS, que mais tarde seria vendido novamente para a Telefônica fundar o Terra), ZipMail, Cadê? (vendido para a StarMedia e depois para o Yahoo!) e UOL, que juntos aos pioneiros London, Mandic e Lacerda se tornaram os maiores players nacionais.

Com a explosão da Internet nos EUA que ocorreu em 1994, estampada em diversas revistas famosas como a Time, o céu era o limite para os negócios de Internet, principalmente de um dos que viriam a se tornar um player mundial: a AOL e seus copy-cats brasileiros UOL e BOL, sendo este último da editora Abril, que mais tarde viriam a ser fundidos. Houve uma tentativa de fusão com a AOL, que era o maior player mundial, mas que não deu certo.

A invasão estrangeira

Conforme a Internet evoluia o seu número de usuários aumentava exponencialmente, mesmo por aqui com a infraestrutura precária e o custo altíssimo de se ter um computador, ainda mais conectado à uma linha telefônica. Com isso, os grandes grupos de Internet que se formaram no exterior agora extendiam suas presenças para países da América Latina e principalmente para o Brasil, maior mercado da região. Uma dessas primeiras empresas foi a StarMedia do uruguaio Fernando Espuelas que no auge da bolha em 1999 levantou mais de uma centena de milhões de dólares em investimento para sua expansão para Brasil e México, chegando a comprar o buscador nacional Cadê? antes de fracassar em sua empreitada, mais tarde vendendo o Cadê? para o Yahoo!.

Outro fracasso memorável de empresas de Internet estrangeiras em terras brasileiras foi a AOL que investiu pesado por aqui sem conseguir acabar com a hegemonia que existia das empresas nacionais. Entretanto, a bolha tinha crescido a tal ponto em 2000 e as startups levantavam tanto dinheiro de investimento que a AOL chegou a comprar a Time-Warner, um dos maiores grupos de mídia do mundo por U$180 bilhões, em uma das maiores fusões da história. Entretanto, em 2 anos o estouro da bolha mostraria que nada era tão fácil assim e passamos pela famosa recessão de investimentos em startups dos anos 2000.

O Almoço Grátis

O estouro da bolha nos EUA aconteceu um pouco antes do que no Brasil, mostrando até que nas crises eles são mais adiantados que a gente. Por aqui, surgiam os provedores gratuitos, como o IG (antes sigla de Internet Grátis, hoje Internet Group) que vieram para esculhambar com o mercado de provedores como o UOL e Terra. Focados na venda de publicidade para anunciantes, que aliás era o modelo que imperava na Internet dos anos 2000, permitiam às pessoas se conectar na Internet por meio de seus famosos discadores sem pagar nada por isso, atraindo a fúria dos fundadores de provedores de acesso, que era um negócio muito comum nesta época.

O livro acaba narrando também a trajetória da GP Investimentos de Beto Sucupira como um dos primeiros fundos brasileiros a acreditar no mercado de startups e investir pesado. Entretanto, como investidores bem treinados fazem, souberam fazer boas apostas e saída ainda melhores, antes da bolha estourar e ferrar com muito investidor. Também narra a criação do iBest, primeiro prêmio brasileiro de Internet e mais tarde provedor de acesso também.

A Explosão e O Rescaldo

Muito dinheiro, muita especulação e um otimismo sem precedentes marcaram época no início dos anos 2000 logo antes da bolha estourar. Com capital nacional e estrangeiro relativamente fácil de ser obtido não era raro festas e eventos para promover o encontro de startupeiros e onde ideias sem implementação alguma podiam ser vendidas por R$10 mil. Este capítulo conta também sobre outros empreendimentos, como Miner, meta-buscador brasileiro comprado pelo UOL, também conta a história da NetTrade, primeira corretora de valores online no Brasil. Mostra como grupo Pão de Açúcar foi o primeiro (e mais bem sucedido até hoje entre as redes de supermercados) varejista a entrar no mundo online. O site de leilões Freelance que depois mudou para Lokau e muitos outros como o surgimento da Globo.com.

Mas mais do que essas iniciativas, retrata o surgimento (em um flashback,  que torna o livro um tanto confuso em certos momentos pela falta de linearidade) do NetScape e como ele revolucionou o uso da Internet e ajudou a torná-la comercial de fato, até a ascensão do IE que canibalizou o mercado de navegadores ao chegar instalado no Windows tornando-o pronto para a Internet, sem softwares adicionais.

Mas voltando à bolha, o ano de 2000 foi terrível para a Nasdaq que vinha em sua maior crescente nos últimos 28 anos com centenas de aberturas de capital ao ano em parte graças à popularização da Internet e a supervalorização das startups que haviam surgido e cujo IPO era meta natural. Embora sites americanos como o Yahoo! e brasileiros como Americanas.com e Submarino registrasse lucro, isso era a exceção e não a regra no início dos anos 2000. As startups mantinham-se graças à investimentos pesados de fundos e registravam prejuízos milhonários sem qualquer previsão de break-even e mesmo assim com avaliações altíssimas. A intangibilidade e o ineditismo dos negócios online cegou muita gente que não percebeu a fragilidade dos mesmos. Houve uma inversão de valores onde o mais importante era crescer, e não se manter, criando a célebre frase de Dilbert: "profits are for loosers", ou "lucro é para os perdedores".

Com a recessão, os empreendedores não tiveram mais margem para errar e o mercado de investimento de risco contraiu-se, não somente no Brasil como no mundo inteiro.

O Futuro

O livro encerra com algumas projeções e pensamentos sobre a Internet e os eu futuro no país e no mundo. Para um livro lançado em 2003, ele até acertou bastante. Hoje vivemos uma nova economia de startups e os investimentos voltaram a aparecer, mesmo que timidamente, tem alguns anos. Algumas startups como EasyTaxi, Dafiti, NetShoes, Twitter entre outras parecem operar no modo crescer sem lucrar, indicando a possível tendência de acontecer outra bolha em breve. Incentivos dos governos também surgem por todos os cantos como o Startup Chile, o Startup Brasil, Startup Peru, o SEED em Minas (também brasileiro) entre muitos outros. Nunca incentivou-se tanto o empreendedorismo no Brasil e na América Latina e o otimismo voltou a brilhar entre os empreendedores.

Se a bolha foi ruim? Eu acho que não. Claro, eu não perdi nenhum centavo, nem mesmo tinha um computador na época que a Internet pintou por aqui, mas entendo hoje que graças à ela houve um profissionalismo muito maior das startups. Salvo exceções, hoje práticas e técnicas comuns de startups bem sucedidas são aprendidas e praticadas por muitos fundadores em seus negócios como Lean Startup e Business Model Generation. Obviamente isto por si só não garante o sucesso da empreitada, mas ao menos coloca os seus pés no chão e evita erros mais crassos como os da bolha de 2000.

Resumindo: leitura obrigatória para todo profissional e empreendedor de Internet.

ASP.NET Button não dispara postback

Outros nomes possíveis para este post seriam "ASP.NET Button não funciona" ou "Que m**** que está ac

Outros nomes possíveis para este post seriam "ASP.NET Button não funciona" ou "Que m**** que está acontecendo com meu formulário?". De qualquer forma, este post será bem rápido. O objetivo é listar algumas causas comuns que fazem com que botões parem de funcionar com ASP.NET Webforms. Não há nenhuma mágica ou bug conhecido, apenas falta de atenção ou prática com a construção de formulário com este padrão de desenvolvimento web da plataforma .NET. Acredito que este post será vivo, ou seja, irei colocando mais conteúdo conforme for descobrindo mais causas para este problema.

O Problema

O problema é simples e objetivo: você tem um formulário ASP.NET com um botão. Você clica no botão e o que deveria acontecer não acontece. Claro, tem algumas variações, que podemos chamar de sintomas. Para cada sintoma, há um remédio diferente.

A tela apresenta um erro

Se a tela apresenta um erro em ASP.NET, considere-se com sorte pois geralmente os erros são muito bons em dizer onde está o problema. Alguns erros comuns incluem você estar com sua tag ASP.NET mal formada, como falta de runat="server" ou similar. Dê uma revisada nas linhas do seu .aspx ou .aspx.cs conforme mencionado no erro e acredito que não terá problemas.

Um erro comum de funcionamento de botão é quando utilizamos eles dentro de algum controle de repetição, como Repeater. Em geral os programadores esquecem que colocando o comportamento de carregar o repeater dentro do Page_Load, o mesmo será chamado toda vez acontecer algum postback, inclusive quando um botão é clicado. Por isso, é uma boa prática colocar uma verificação no Page_Load para somente carregar se não for um postback. Mas o que isso tem a ver com problemas de botão? Quando a página carrega a primeira vez e o botão é renderizado, ele possui um identificador único no ViewState, que, caso seja recarregada a tela, será alterado. Com isso, o botão que originalmente chamou o postback não existe mais e a chamada fica como se fosse anônima ou "injetada", o que é uma violação de segurança do ASP.NET que causará um erro.

A tela não apresenta erro

Aqui que mora o problema, quando estamos às cegas com um botão não funcionando. Uma dica é, usando o Google Chrome, abrir as ferramentas (F12) e ver no Console se não tem algum erro de Javascript. Isso é bem comum quando usamos UpdatePanel, que por padrão suprime os erros da página. Em geral os erros de Ajax não são muito esclarecedores, mas basta executar tudo novamente com F5, para depurar, que se acontecer o erro novamente o depurador do Visual Studio vai te levar até a linha do erro.

Às vezes o ASP.NET não apresenta erro pois de fato não existe erro. Ou seja, é algum problema de lógica ou algo Javascript seu que está bloqueando a execução do botão. Veja se seu botão não possui um OnClientClick definido, pois se caso possuir, tenha certeza de que o método Javascript associado retorna true para garantir a continuidade da execução do botão. Ainda no assunto Javascript, revise se na sua página não existe alguma tag script mal formada, lembrando que a tag script sempre deve ser fechada com o padrão "></script>" e jamais com a versão enxuta "/>", caso contrário lhe trará problemas. Sim isso é muito idiota, mas acontece, então se liga!

Um último adendo cabe aos ASP.NET Validators. Por padrão os Validators, como o RequiredFieldValidator, fazem a validação via Javascript antes de qualquer postback, e caso tenha qualquer problema em sua página impedirá que o postback aconteça. Se você usa validadores em qualquer ponto de seu formulário, pode ser uma boa verificar se não são eles que estão impedindo seu botão de funcionar. Esse ponto se torna ainda mais importante caso você esteja usando WebUserControls na sua página, pois às vezes eles estão escondidos, como em modais, mas mesmo assim com seus Validators ativos, impedindo o postback da página. Uma ideia pode ser dizer que seu botão não causa validação, definindo a propriedade CausesValidation para false. Isso claro, se o click do seu botão não for interferir com os demais dados do seu formulário.

Espero ter ajudado.

Tem mais algum caso em que seu botão não funciona e que deseja compartilhar? Outro detalhe que deixei passar? Escreva nos comentários!

Aumentando o desempenho de seus sites - Parte 2

Neste post continuo com mais dicas para melhorar a performance de sites que possuam muitas visitas.

Neste post continuo com mais dicas para melhorar a performance de sites que possuam muitas visitas. A primeira versão deste post pode ser encontrada neste link.

Carregue componentes após o load

Você deve olhar para sua página e se questionar: "O que é absolutamente necessário para que a página renderize?". O resto do conteúdo e dos componentes podem esperar.

JavaScript é um candidato ideal para ser carregado depois do evento load. Por exemplo se você tem um código JavaScript para fazer animações em botões, eles podem esperar, porque as animações só vão fazer sentido depois que toda página tiver sido renderizada. Outros locais a se dar uma olhada incluem conteúdo oculto (conteúdos que aparecem somente após alguma interação do usuário) e algumas imagens que não são visualizadas em um primeiro momento.

É bacana quando os objetivos de performance estão alinhados com as melhoras práticas web. Neste caso, a idéia de aperfeiçoamentos progressivos nos diz que Javascript, quando suportado, pode melhorar a experiência do usuário, mas você tem que ter certeza de que a página funciona mesmo sem JavaScript. Então depois que tiver certeza disso, você pode aperfeiçoar ela com alguns scripts pós-carregados que dêem mais recursos à página, como botões animados.

Carregue componentes antes do load

Pré-carregar pode ser entendido como o oposto de Pós-carregar, mas na verdade ele possui um objetivo diferente. Pré-carregar componentes lhe dá uma vantagem sobre o tempo ocioso do browser, quando ele poderia, por exemplo, estar carregando imagens que serão usadas futuramente. A idéia é quando o usuário troque de página, ele tenha uma experiência ainda mais rápida do que na primeira página.

Existem vários tipos de pré-carregamento:

  • Não-condicional: assim que o load inicia, vá em frente e carregue uns componentes extras. O site do Google utiliza esta técnica, carregando todas imagens através de CSS Sprite que serão usadas nas páginas seguintes (página de resultados, por exemplo)
  • Condicional: baseado na ação do usuário você faz um palpite do que o usuáro está pensando e já carrega os próximos componentes. O Yahoo usa esta técnica na caixa de busca deles, carregando alguns componentes conforme o que o usuário digita na caixa de busca.
  • Antecipado: esta técnica é utilizada quando você está pensando em trocar o layout do seu site em breve. Geralmente você ouve coisas do tipo "Muito legal o novo site do fulano, mas o antigo era mais rápido.". Isso acontece porque o site antigo já estava com os elementos em cache, como imagens, JS e CSS, enquanto que no novo site tudo teve de ser baixado. O pré-carregamento antecipado consiste em fazer com que seus visitantes do site antigo já baixem alguns componentes e deixem-os em cache no navegador, para quando o novo site for pro ar, a transição seja mais suave. Faça isso linkando CSS e JS antecipados, alguns dias antes do lançamento. Colocar algumas imagens sobrepostas também pode ajudar.

Divida componentes entre domínios

Dividir os componentes entre domínios pode maximizar o download paralelo de componentes. Garanta que não está usando mais do que 2-4 domínios por causa do tempo de resolução de DNS ou a técnica sairá pela culatra. Por exemplo, você pode hospedar seu HTML e conteúdo dinâmico em www.teste.com.br e dividir componentes estáticos ente img.teste.com.br e css-js.teste.com.br.

Fora 404!

Requisições HTTP são recursos "caros" à performance de um site o que torna uma imensa burrice permitir erros 404 em seu site por preguiça ou ignorância.

Alguns sites possuem páginas 404 bacanas que ajudam o usuário a encontrar o que não acharam na URL acessada, entretanto, mesmo estas páginas consomem recursos do servidor. Pior ainda é quando os erros 404 são causados por links de JS e CSS quebrados. No primeiro caso, além de gerar uma custosa requisição, o carregamento do restante da página irá travar até que o referido erro aconteça porque o download de javascript não permite outros downloads em paralelo. Como se não fosse o bastante, muitos browsers tentarão ler a página 404 procurando algum script útil pois buscavam um arquivo de scripts...

Use link ao invés de @import

Uma das melhores práticas que citei na parte 1 deste post dizia que CSS deve estar no topo da página para permitir a renderização progressiva. No IE a diretiva @import tem o mesmo comportamento que usar um <link> no rodapé da página, então é melhor não usá-la.

Otimize as imagens

Depois que o designer tenha terminado de criar as imagens para sua página, existem ainda algumas coisas que você pode fazer antes de enviar as imagens para seu servidor.

  • você pode verificar os GIFs e ver se eles estão usando um tamanho de palheta correspondente ao número de cores na imagem. Usando o software ImageMagick é fácil de verificar com o comando: identify -verbose imagem.gif. Quando você ver que uma imagem está usando 4 cores e uma palheta de 256 cores, há espaço para melhoria.
  • Tente converter GIFs para PNGs e ver se há alguma economia. Geralmente tem. Desenvolvedores muitas vezes hesitam em usar PNGs devido ao suporte limitado nos browsers, mas isto é coisa do passado. O único problema real é a transparência-alfa em PNGs true color, mas novamente, GIFs não são true color e não suportam transparência variável. Então qualquer coisa que um GIF possa fazer um PNG também faz (exceto animações). Este simples comando do ImageMagick gera PNGs seguros para usar: convert image.gif image.png
  • Execute o aplicativo pngcrush (ou qualquer outro otmizador de PNG) em todos seus PNGs, por exemplo, com este comando: pngcrush imagem.png -rem alla -reduce -brute resultado.png
  • Execute o aplicativo jpegtran em todos seus JPEGs. Esta ferramenta faz operações sem perdas em JPEGs como rotação e também pode ser usada para otimizar e remover comentários e outras informações inúteis (como informações EXIF) em suas imagens. Ex: jpegtran -copy none -optimize -perfect imagem.jpg destino.jpg

Otimize seus CSS Sprites

Aqui vão algumas dicas que deixarão seus sprites ainda mais otimizados:

  • organizar as imagens no sprite horizontalmente ao invés de verticalmente resultará em arquivos menores
  • combinar cores similares em uma sprite lhe ajuda a manter a contagem de cores baixa, idealmente abaixo de 256 cores para que se encaixe em um arquivo PNG8.
  • não deixe grandes espaços entre as imagens do sprite. Isto não afeta muito o tamanho do arquivo mas requer menos memória do usuário para descomprimir a imagem em um mapa de pixels. Uma imagem 100x100 tem 10 mil pixels, enquanto uma 1000x1000 tem um milhão

Não escale as imagens no HTML

Não use uma imagem grande que você precise definir a largura e altura dela em HTML. Se você precisar fazer isso:
<img width="100" height="100" src="meucachorro.jpg" alt="Meu Cachorro" />
então sua imagem (meucachorro.jpg) deve ter o tamanho de 100x100px ao invés redimensionar uma imagem de 500x500px, por exemplo.

Mantenha seus componentes abaixo de 25K

Esta restrição está relacionada ao fato que o iPhone não faz cache de componentes maiores que 25K. Note que este é o tamanho não comprimido. Isto é um exemplo de onde a minificação é importante porque o gzip sozinho pode não ser suficiente. Para mais informações, busque por iPhone Cacheability no Google.

Evite imagens com Src vazio

Imagens com o atributo src vazio provocam requisições ao seu servidor, em busca das imagens. Independente da forma que você fez isso:

<img src="">

ou

var img = new Image();
img.src = "";

Por quê este comportamento é ruim? Simplesmente porque lota seus servidores enviando um monte de tráfego inesperado, especialmente em páginas que recebem milhões de pages views por dia. Como se isso não fosse o bastante, você gasta tempo de processamento gerando páginas que não serão visualizadas. E por último, mas não menos importante, você pode acabar corrompendo dados. Se você está rastreando estado na requisição, seja por cookies ou de outra forma, você tem a possibilidade de destruir esses dados. Isso porque a requisição de imagem não retorna uma imagem, todos os cabeçalhos são lidos e aceitos pelo browser, incluindo todos cookies. Enquanto que o resto da resposta é jogada fora, o dano já pode ter sido feito.

A causa raiz deste comportamento é que a resolução de URLs dos browsers é definida na RFC 3986 - Uniform Resource Identifiers. Quando uma string vazia é encontrada como uma URI, ela é considerada uma URI relativa e é resolvida de acordo. Então tecnicamente, os browsers estão fazendo o que é esperado que façam para resolver URLs relativas. O problema é que neste contexto, a string vazia é claramente intencional.

HTML5 adiciona à RFC instruções aos browsers não fazerem requisições adicionais. Espera-se que em um futuro próximo não tenhamos mais esse problema, embora a RFC não cubra <script src=""> and <link href="">.

Conclusões

Neste post continuei um post muito antigo sobre dicas de otimização de sites. Muitas delas aplico em projetos que participo e que atinjam milhares de visitantes por dia, como o Busca Acelerada que possui mais de 240mil page-views por mês. Estas dicas foram retiradas de diversas fontes da Internet, em especial das guidelines de performance do Yahoo e de palestras que assisti sobre o assunto em diversos eventos pelo país. Em um post futuro, quero dar dicas específicas para desenvolvedores ASP.NET, sobre como turbinar suas web applications. Então aguardem!