Introdução:

Ano passado participei pela primeira vez do evento, que teve sua primeira edição em 2008, e concluí que deveria vir nos próximos, pois vale a pena.

Esse ano não foi diferente, e foi mais legal ainda. Mais legal pelo fato que consegui convencer outros brasileiros a participar da viagem, e também porque a qualidade do evento estava ainda melhor. Ah, a Google ainda pagou o hotel, que dividi com o Renato Mangini de BH – uma forma gentil que eles acharam para reconhecer o trabalho que fazemos nas comunidades SP-GTUG e BH-GTUG.

Saí de São Paulo no sábado 9/05, rumo a San Francisco, fazendo escala em Miami. Cheguei em San Francisco no domingo e  já saí correndo para o escritório da Google, onde tivemos um encontro das gtugs do mundo inteiro. Ano passado foi apenas um jantar, mas durante o ano de 2010 tivemos uma explosão de grupos iniciando e vários coordenadores decidiram participar do evento.

O Barcamp:

Depois de uma breve apresentação de todos os membros (havia mais de cem), recebemos stickers para escrever sobre um determinado tópico e que devíamos grudar em uma lousa branca. Depois de um processo de moderação, as conversas foram divididas em seis mesas, com tempo aproximado de uma hora para cada sessão.

barcamp - evento das gtugs

tópicos para discussão no barcamp

Eu falei do processo de criação de um novo site para as GTUGs, onde o Renato também colaborou. Participamos também de forma bem ativa das outras discussões e que foram bem interessantes. O resumo de cada conversa pode ser visto aqui.

No final do evento, por volta das sete horas da noite, tivemos um jantar com comida e bebida a vontade. Também ganhamos uma jaqueta e camiseta personalizada das GTUGs.

Foi sem dúvida um evento histórico. É raro ter a oportunidade de falar com pessoas de mais de trinta países e trocar idéias e experiências sobre qualquer assunto que viesse na cabeça.

A mustang e visita a sede da Google:

Na segunda-feira, decidi alugar um carro e convidei outros brasileiros que estavam por lá. Quando chegamos na loja, o Sam da StudioSol deu a brilhante idéia de alugarmos uma Mustang, ao invés de um carro compacto comum. Como estávamos em quatro pessoas, a brincadeira saiu por volta de 50usd – razoável.

Demos uma volta pela Fisherman´s Wharf, onde é possível ver a ilha de Alcatraz. Almoçamos por ali mesmo e depois pegamos a auto estrada rumo a Mountain View, sede da Google. Não vou escrever sobre a sensação de dirigir uma Mustang, pois daria outro post, mas é algo bem legal.

mustang alugada em san francisco

Golden Gate bridge

Passamos pelo escritório da Google, tiramos foto em frente ao prédio do Android, usamos o wifi de visitante que é gratuito e passamos por dentro da antiga sede (nome que eles dão para o prédio que era da Silicon Graphics).

Eu, Sam e Bruno no prédio do Android

Na volta passamos na Target e Babies R US, e depois jantamos no Lori´s, que tem um milkshake de Oreo simplesmente fantástico.

Primeiro dia de Google I/O:

Já estava em San Francisco há dois dias, e a ansiedade para o evento só aumentava. Acordei às seis da manhã, e por volta das sete já estava lá para fazer o credenciamento e tomar o café da manhã. Tudo estava impecável, e verde! O que deixava claro o foco em Android na conferência.

Entrada do moscone west

Por volta das 8:30 a fila para o keynote já dava voltas dentro do Moscone West. Às  9:00, a entrada principal abriu, e o que eu via era apenas um monte de geeks correndo para pegar lugar na fileira mais próxima possível do palco. Consegui ficar na oitava fileira, o que foi bastante razoável.

Vic Gundotra abriu o evento, agradecendo a presença de todos, falando do histórico e das evoluções tomando como base a apresentação do ano passado. Mais uma vez, tempo para alfinetar a Apple, mostrando o boneco do Android comendo uma maça e com os números de milhares de ativações de Android por dia.

Vários membros do time do Android subiram ao palco para falar das novidades, incluindo integrações com hardware através do ADK (Android Development Kit). No final, a belíssima surpresa de que todos no evento estariam recebendo um Galaxy Tab da Samsung de 10’1.

Brasileiros felizes com o galaxy tab

Ao longo do dia, diversas palestras sobre Android, AppEngine e outras tecnologias aconteceram. As mesmas já estão disponíveis no site do Google I/O.

No final, uma festa com comida e bebida a vontade, além do show do Jane´s Addiction. Vários expositores estavam lá mostrando robôs, carros que voam e outras coisas mais …

Segundo dia de Google I/O:

No segundo dia, Sundar Pichai (Chrome) abriu o evento. Falou-se muito da evolução do Chrome, de segurança, do mercado, e como todas as empresas evoluíram seus browsers desde o momento que a Google começou a trabalhar fortemente em aspectos como segurança e HTML5.

Membros do time apareceram para mostrar experimentos com HTML5 e CSS3d e logo na sequência foi falado de Chrome OS e do cenário atual. Mais uma surpresa foi que todos os presentes no evento ganhariam um ChromeBook (não mais chamado de netbook) da Samsung.

Durante o dia, várias palestras aconteceram – desde Android, HTML5, até Python no Google e Venture Capital. Perdi algumas, pois fui convidado para uma chamada Advocate Summit – fechada e entrada permitida mediante convite. Tive a honra e a chance de participar de uma sessão fechada com o top management do Google: Vic Gundotra, Michael Winton, Sundar Pichai e dois outros nomes que não me recordo.

Advocate summit

No final do dia, todos os GTUG managers foram convidados para um jantar próximo ao Moscone West, e os brasileiros que estavam comigo também participaram. Tive a chance de conhecer mais dois brasileiros empreendedores que moram lá em San Francisco: Rafael Sanches – criador do Recipe Search, app para Android bem famosa nos EUA, e sua esposa, Silvia.

Para fechar com chave de ouro, cada mesa de jantar teria direito a receber um ADK, e a pessoa que receberia, teria que ser escolhida por mérito. Como na mesa só havia brasileiros e o Renato já tinha o dele garantido, ficou pra mim. Como já tenho experiência com Arduino, vai ser tranquilo brincar com o aparelho.

Concluindo:

Terminado o jantar, era hora de juntar as malas e voltar para o Brasil. No final desses eventos sempre reflito sobre as oportunidades que a vida me proporciona. O que tenho a dizer ? Sou uma pessoa privilegiada, e devo agradecer todos os dias por isso.

Quer participar do #io2012 ? Então veja aqui o que você precisa, e participe também do SP-GTUG – grupo o qual sou um dos coordenadores, onde discutimos sobre as tecnologias que a Google desenvolve.

Um abraço!

Robson Dantas

Bookmarks

Vamos falar que sua foto tem um fundo totalmente verde, e que você quer removê-lo. Fazer isso no GIMP, Photoshop, ou outros, leva um tempinho, dependendo dos detalhes da imagem.

Daí que entra um conjunto de utilitários para linha de comando – chamado ImageMagick - que permite realizar uma série de operações, entre eles remover fundo, compor imagens, converter formatos, etc.

Lembro que esse utilitário era usado para tratar imagens em uma empresa que faz sistemas para trânsito na qual trabalhei, já que também tem APIs para várias linguagens: C++, perl, php, C#, python, etc.

Então, vamos ao trabalho:  Supondo que você tenha a imagem abaixo, chamada imagem1.gif, e que queira converter para um png transparente:

imagem com fundo vermelho

Rodando o comando abaixo, teremos uma imagem transparente (png):

/diretorio_image_magick/convert.exe vermelho.gif -transparent red vermelho.png

Em outras palavras: Rode convert.exe no arquivo vermelho.gif e tire todo o vermelho, salvando como vermelho.png. Resultado abaixo:

imagem sem o fundo vermelho

Obviamente que há outros parâmetros que você pode brincar, como o fuzz (lógica fuzzy). Basta olhar a vasta documentação no site, que eu recomendo, dado o poder da biblioteca.

Um abraço,

Robson Dantas

Bookmarks

Postei essa informação no meu twitter, e estou mandando o link por aqui também, veja:

Opções gratuitas para vídeo conferência

Espero que ajude.

.

-Robson Dantas

Bookmarks

Google em San Francisco e a Ferrari

Andando um pouco pelo escritório, pude ver o refeitório e as mesas dos Googlers que ficam por lá.

Refeitório do Google

Refeitório e a ponte no fundo

Local onde foi servido o jantar

Durante o jantar tivemos um grande espaço para networking, e após várias cervejas e vinhos as coisas ficaram mais fáceis. Pude conversar com membros de GTUG de vários países, dos quais me recordo: Chile, Argentina, Colômbia, Suécia, Japão, China, Canadá, Estados Unidos, França, Alemanha e Austrália.

Foi muito legal compartilhar e receber conhecimento dos outros, principalmente no que diz respeito a organização dos eventos.

Além dos membros de GTUG, estavam presentes diversos Googlers, entre eles:

• Stephanie Liu – developer relations;
• Jason Cooper – developer programs engineer;
• Tim Bray – Android ( e também um dos responsáveis pela especificação do XML );
• Pamela Fox – Google Maps e Wave;
• Naoki – praticamente todas as APIs;
• Ikai Lan – AppEngine;
• Arne Kurrik – HTML5 e Chrome;

No final do jantar, o pessoal do Google solicitou que cada um fizesse uma auto apresentação. Muitas risadas e um grande momento de descontração. Além disso, falaram da importância das GTUGs e do enorme mapa que ficará disponível no I/O com as fotos das pessoas.

Antes de ir embora, bati um papo com o Ikai sobre o futuro do AppEngine e ouvi diversas coisas promissoras, na qual falarei no nosso próximo encontro em São Paulo .

Ikai - AppEngine

Pamela Fox e Stephanie Liu

Escorregador que vai de um andar para outro

Acho que foi isso. Um dia inesquecível na minha vida.

Amanhã tem mais, fiquem ligados!

Mais fotos no Picasa

Robson Dantas

Bookmarks

Saí de São Paulo no sábado 15/05 e 15horas depois estava descendo em San Francisco, debaixo de um tempo nublado e frio. Nem mal cheguei já saí andando pela cidade para conhecer os pontos turísticos – fisherman wharf, golden gate bridge, union square, etc. Ah, e é claro que dei uma passada na loja da Apple

Na segunda-feira, aluguei um carro e fui visitar a sede da Google em Mountain View. O que tenho a falar do lugar ? É, realmente é espetacular e gigante! Uma rua de vários quilômetros só de prédios do Google.

Almocei com Arne Kurrik, do developer relations team, e fiquei espantado com a variedade de comidas: eram 7 restaurantes, com as mais variadas comidas e bebidas a vontade. Encontrei o Patrick Chanezon, que é uma figura bem conhecida nos eventos e ficamos conversando sobre o SP-GTUG e AppEngine.

Quando estava no caminho de volta para San Francisco,  passei em frente ao prédio onde fica o time do Android. Preste atenção no tamanho do mesmo, impressiona!

E assim acabou a minha segunda-feira, um sonho realizado.

Hoje pela manhã – dia que começou o Bootcamp, fui ao Moscone West para realizar o checkin e retirar meu kit – uma camiseta, a credencial e o tão esperado Nexus One ( sim, ele é tudo o que você imagina ).

Logo de cara, encontrei várias pessoas conhecidas, principalmente no meio do Opensocial. Entre eles estava Yoichiro – um dos cabeças do Mixi no Japão (maior rede social que há por lá) e Eiji Kitamura, que contribui com o Shindig-PHP.

Também encontrei o Van Riper, do Silicon Valley GTUG e a Francesca do Firenze GTUG. Trocamos algumas idéias e logo após subimos para o evento.

Já tinha definido minha agenda que era: Android, Google Maps API V3, Google AppEngine e Chrome Extensions.  Todos os eventos de Android estavam lotados e muita gente interessada no desenvolvimento de aplicativos.

Android:

Roman Nurik começou a apresentação, e pelo fato de ser um bootcamp, o conteúdo do mesmo foi bem superficial. Mesmo assim, deu para perceber o tanto de gente interessada e o volume de funcionalidades interessantes disponíveis, nas quais destaco multi-tasking e background service.

Google Maps API V3:

Essa palestra foi um hands on, onde tivemos a chance de codificar junto com um engenheiro do Google. Achei muito legal as melhorias que foram feitas na API V3, principalmente a parte de integração com o Google Maps (site). Caso queira acessar o conteúdo disponibilizado pelo palestrante como Sample, basta ir para a url onebox.appspot.com .

As palestras de AppEngine e Chrome Extensions cobriram assuntos de como começar uma aplicação e um plugin do zero, e também cobriram uns aspectos básicos. Acabei brincando com background service no AppEngine e com integração via OAuth nos plugins do Chrome.

Amanhã começa o I/O de verdade, com as palestras mais longas e mais atrativas. Hoje foi só um aquecimento, cobrindo aspectos um pouco mais básicos. A medida que as mesmas forem acontecendo, vou postando por aqui. Fique ligado!

Veja mais fotos no Picasa

abs

Robson Dantas

Bookmarks

Muitas empresas utilizam soluções de cache que são muito mais rápidas e eficientes, e entre as opções disponíveis, eu gostaria de destacar o memcached. Empresas como Facebook, Google, Wikipedia fazem uso bem intenso dessa ferramenta e ela é bem otimizada para uso em larga escala.

Apesar de ser projetado para Linux, há um port para windows no qual eu uso para testes ( nunca testado em ambiente de produção). Basicamente sua função é armazenar coleções em memória, servindo os dados via socket para os clientes que conectarem ao servidor.  Usa UDP como protocolo de comunicação e um mecanismo muito eficiente para gerenciamento de dados.

Um exemplo prático de como seria usado o mecanismo de cache:

• Usuário A chama uma página e requisita cidades do estado de SP e a mesma não está em cache;
• Aplicação chama consulta no banco de dados, adiciona a chave ao cache: cache.set(“cidades”,coleção);
• Usuário B chama a aplicação e verifica que os dados estão no cache. Aplicação consulta cache e retorna os dados para serem tratados: cache.get(“cidades”);

Se não tenha ficado claro, um pseudo-código pode ajudar:

• se existir cache.get(“cidade”) então:
  -> popular controles com essa coleção
• caso contrário:
  -> buscar dados de cidade do banco;
  -> setar cache cache.set(“cidade”, dados_do_banco);
  -> popular controles com essa coleção;

Problemas de um cenário real:

Na teoria parece muito simples, certo ? Se você estiver pensando em um ambiente que não haja restrição por condições de corrida ( usuários simultâneos realizando a mesma operação ), então é realmente simples.

Mas imagine um momento em que você precisa incrementar um registro no cache, e esse registro só pode ser incrementado se ninguém mais estiver fazendo o processo. Como você resolveria essa questão ?

Pesquisando um pouco, acabei lembrando dos mecanismos de semáforo e de entrada em região crítica, o que me levou a criar um modelo que tenta fazer algo parecido. Só para lembrar o processo de região crítica (retirado do link acima da wikipedia):

Para entrar numa região crítica, uma linha de execução deve obter um semáforo, que será descartado na saída da região crítica. Cada recurso compartilhado, ou um conjunto de recursos compartilhados em comum, possui um semáforo próprio. Qualquer outra linha de execução deverá esperar para entrar numa região crítica em uso, mas poderá usar a CPU para executar qualquer outro código, incluindo regiões críticas protegidas por outro semáforo.

Logo abaixo, postei o exemplo criado em Python, porém estou escrevendo um pseudo-código que pode ser facilmente migrado para qualquer linguagem:

1. Conectar no memcache;
2. Tentar adicionar a chave(“lock”);
3. Se adicionar, então não tem ninguém esperando – incremente o registro que você precisa, remova a chave lock;
4. Caso tenha a chave, tente esperar alguns micro-segundos, e executar a operação “N” vezes. Se “N” for atingido, retornar erro, caso contrário, basta executar o procedimento anterior;
5. Desconectar do memcache;

import memcache
import time

def lock_update(key):

    # parametrizacoes, todo passar para um cfg
    m = memcache.Client(['127.0.0.1:11211'], debug=0)
    lock = "lock_" + key
    max_tries = 5 #tenta 5 vezes
    tries = 0
    expiration = 60 #segundos
    got_lock = False
    number = -1
    wait_time_between_tries = 101 #microsegundos

    # teste inicial, apenas para colocar algo na chave, caso não tenha no cache
    if m.get(key) is None:
        m.set(key,0)

    if(m):
        # roda o numero de tentativas para adquirir o lock
        for tries in range(0, max_tries):
            # se conseguir adicionar, adquire o lock
            if(m.add(lock, 1, expiration)):
                got_lock = True
                break

            # se nao conseguiu, espera um pouco
            time.sleep(wait_time_between_tries / 1000000.0)

        # consegui adquirir o lock
        if(got_lock):
            number = m.incr(key)
            m.delete(lock, 0)

        # retorna o valor
        return number

# só para teste pela linha de comando
if __name__=="__main__":
    print lock_update("teste")

Simples, não ?

Espero que ajude

abs

Robson Dantas

Bookmarks

Alguns dos pontos listados aqui são resultados de longos anos de experiência, de pesquisa e de práticas que diversas equipes com que venho trabalhando aplicam. Além disso, vale a pena olhar iniciativas como YSlow (Yahoo) e PageSpeed (Google), ambas lideradas por um cara chamado Steve Souders, referência no assunto.

Para começar, imagine-se num cenário onde seu negócio depende exclusivamente de resultados de aplicações web, e que todos os esforços devem ser aplicados para que seu site esteja altamente disponível, com o menor custo possível. Quais seriam os pontos que você atacaria para que tenha sucesso na sua empreitada ?

Que tal começar por esses abaixo ?

• Verificar toda a configuração de hardware do seu parque de máquinas;
• Realizar testes de estresse e chegar em um modelo que determine o volume máximo de transações que sua aplicação aguenta;
• Realizar um benchmark com outros aplicativos que tenham as mesmas características e determinar planos de ação;
• Aplicar um guia de boas práticas – que estão descritas mais pra frente
• Traçar um plano de melhoria para suas aplicações;

Guia de boas práticas para sua aplicação:

Carregue somente o necessário na página:

Lembre-se que mesmo que não estejam em uso, os recursos são carregados se tiverem referências no HTML. Javascripts são os vilões para liberar a renderização da página, por parte do browser.

Otimize os recursos:

Otimize imagens, javascripts, css. Técnicas como css sprites, “minificação” de javascripts e redução de paleta de cores são as mais utilizadas e diminuirão o uso de recursos de rede de forma drástica.

Lembre-se do item número um – os javascripts seguram a renderização da página até que sejam totalmente baixados. Existem técnicas que amenizam isso, e uma das mais utilizadas é manter os arquivos de javascript no final da página, antes da tag body.

Para os arquivos css, coloque-os na tag head da página, diferentemente do que foi feito com os Javascript. O time do YSlow descobriu, através de experimentos, que tal ação faz a página renderizar de forma mais rápida.

Diminua o acesso ao banco de dados, faça cache:

Cache é uma das técnicas mais aplicadas nas aplicações web. O número de opções é bem grande: Pode ser cache em disco, cache distribuído, cache em memória etc…

Acessos ao banco de dados podem ser considerados um dos recursos mais caros pela aplicação web. Apesar de existirem técnicas de pooling de conexões para redução do tempo de latência entre a conexão do servidor web com o banco de dados, mecanismos de SELECT, INSERT, UPDATE e DELETE podem ser muito complexos e causarem altíssimos atrasos nas respostas.

Imagine uma página que faz 10 requisições ao banco a cada atualização de página, sendo que seu conteúdo que muda somente cinco ou seis vezes por dia. O custo de requisições frequentes ao banco de dados é alto, portanto, vale a pena realizar um cache dessa página (guardando somente o html resultante em disco).

Vale a pena tentar reduzir o número de chamadas, ou tentar guardar em algum mecanismo de cache dados que sejam frequentemente chamados pela aplicação e que não são alterados com tanta frequência. Como exemplo, podemos imaginar uma lista de estados ou cidade.

Realize flush da página assim que possível:

Pode parecer excesso de zelo, mas não é! Praticamente todas as linguagens de programação implementam um mecanismo de buferização do html, antes de começar a liberar os dados. Algumas até esperam que todo o conteúdo da página seja processado, para liberar o HTML ao browser.

No asp.net , você pode user o Response.Flush , no PHP você pode usar a função flush(); e assim por diante …

Mova conteúdo estático para outros domínios:

Essa técnica serve para reduzir o envio desnecessário de cookies, além de possibilitar uma migração futura para um CDN (content delivery network). Misturar aplicações dinâmicas com conteúdo dinâmico pode gerar um overhead desnecessário para o servidor web, principalmente no que se diz respeito a cookies. Os cookies são salvos no browser e a cada request realizado, são retransmitidos ao servidor web, até que os mesmos expirem.

Para uma página dinâmica, como um aspx, php, faz todo sentido receber os cookies de volta, caso tenham sido gravados, ou até mesmo usados para implementação de session. Mas não faz sentido retransmití-lo ao chamar arquivos como imagens, css, etc.

Além disso, tal prática vai possibilitar que você sirva conteúdo através de CDN´s em um segundo momento, sem muita dor de cabeça. CDN´s são utilizados em larga escala por empresas grandes – como exemplo cito o Google e o Facebook. Esses mecanismos implementam um sistema distribuído de cacheamento e roteamento, servindo os dados de um servidor mais próximo ao usuário, com menor latência de rede.

Utilize ferramentas para análise de desempenho – conhecidas por profilers:

Em java é muito comum usar ferramentas para análise de código fonte, que identificam possíveis problemas de performance ou overhead.

• Veja uma lista de profilers disponíveis para Java;
• Veja um artigo sobre uso de Perfmon para Asp.Net;
• Veja um artigo sobre profilers para Python;

Guia de boas práticas para infra-estrutura:

Apesar de muitas das práticas estarem baseadas no servidor Apache, com certeza você você poderá aproveitá-las para outros servidores web como IIS, por exemplo.

Faça uso de balanceadores de carga:

Balanceadores de carga representam uma forma fácil de aumentar os recursos de infra-estrutura. São feitos via hardware específico ou via software e os que mais utilizei são: Alteon, LVS ( linux ) e F5 BigIP.

O uso correto de tais aplicações melhoram e muito o desempenho, porém, vale lembrar que alguns pontos devem ser levados em consideração:

• O uso de sticky session ( para aplicações autenticadas), diminui a capacidade de saída, uma vez que os mecanismos de balanceamento levam em consideração endereço ip do usuário;
• Divida as configurações de domínio entre dinâmico e estático para garantir maior eficiência no balanceamento;
• Evite balancear somente via DNS;

Ative a compressão de páginas:

Quando você vai transferir um arquivo grande você costuma zipá-lo, certo ? Para as páginas web você deveria fazer o mesmo. Browsers modernos como Firefox, Chrome e IE a partir da versão 8 suportam compressão, enviando um parâmetro no cabeçalho da requisição, para o servidor web.

Para os browsers que não suportam, o servidor web não vão comprimir os dados, portanto, não há efeitos colaterais para seu aplicativo. Essa técnica, apesar de aumentar um pouco o processamento, reduz drasticamente o tamanho dos arquivos, principalmente javascript, css e html´s.

Marque a data de expiração dos arquivos:

Arquivos como imagens dificilmente são modificados, portanto, marcar a data de expiração para uma data futura pelo servidor web, vai fazer com que o browser do usuário faça cache dos arquivos, não precisando enviar uma requisição novamente desse arquivo.

Compilação do servidor Apache:

Compile seu servidor para carregar somente os módulos que você precisa. Instalações padrão costumam vir carregadas de módulos opcionais que provavelmente você não vá usar e que estão lá ocupando memória de bobeira.

Além da compilação, escolha o melhor formato do Apache MPM (multi processing module). Existem dois formatos:

• Worker MPM – que usa múltiplos processos filhos e threads para servir cada requisição. Tem um uso relativamente baixo de memória, porém seu nível de isolamento é menor. Se um processo filho é corrompido,  todas as threads pertencentes ao filho são afetadas. É melhor usado para máquinas com vários processadores;
• Prefork MPM – usa multiplos processos filhos, porém, cada um deles é responsável por uma requisição http. É mais tolerante a falhas, pois cada processo filho é isolado. Porém esse nível de isolamento custa um maior uso de memória e quanto mais acesso, mais memória usada.

Utilize endereços IP ao invés de nomes nos arquivos de configuração:

Faça uso de endereços de IP, para prevenir chamadas desnecessárias de DNS. Normalmente essas entradas são usadas em diretivas Allow e Deny no Apache.

Não use AllowOverride None:

Essa diretiva no Apache gera chamadas desnecessárias no filesystem. Basicamente, para cada diretório/subdiretório de um determinado arquivo, o Apache fará chamadas para localizar arquivos .htaccess .

Configure o KeepAlive e o KeepAliveTimeout:

Para páginas com muitas imagens, uma única conexão TCP pode ser usada para trazer os dados, reduzindo latência de rede.

Divida o conteúdo dinâmico do estático em dois servidores:

Usando o mod_proxy você pode fazer com que um servidor tipo lighthttp ou apache sem nenhum módulo ativo, possa servir conteúdo estático e repassar para um Apache o conteúdo dinâmico.

Pelo fato dos segmentos de memória usados pelo servidor web não serem divididos e realocados até que os processos acabem (ou deixei de existir), o uso de conteúdo dinâmico mesclado com conteúdo estático pode gerar overheads desnecessários. Exemplo: uma página PHP pode carregar 20MB de memória ram, e após liberado, esse espaço de memória não será desalocado e pode dar espaço para servir um arquivo jpeg que não usará todo esse espaço de memória.

Evite o uso de CGI – use módulos para melhorar performance:

Módulos como FastCgi, mod_php, mod_perl, mod_python, melhoram e muito a performance dos aplicativos dinâmicos. Ao invés de configurá-los como CGI diferetamente, dê preferência ao uso desses módulos citados.

Adquira um CDN, caso possível:

Se grande parte de seu conteúdo é composto por arquivos de mídia – imagens, vídeos, áudio, etc, considere a hipótese de usar um CDN – content delivery network. Além de reduzirem a carga de rede da sua infra-estrutura, aumentam e muito a velocidade em que o conteúdo é servido, pois seus mecanismos de cache procuram um servidor que terá a menor latência para servir ao usuário final.

Ex: Se um usuário que está nos EUA solicitar o download de um vídeo, o CDN vai rotear o usuário para um servidor dos EUA, que terá uma latência muito menor do que vir até um servidor localizado no Brasil. Há um custo de roteamento alto nessa transação.

Utilizei duas soluções com muito sucesso em diversos aplicativos:

• Akamai Edge Server – solução oferecida pela Exceda, no Brasil;
• MaxCDN – Possui um custo barato, porém, ainda não existe cobertura de servidores no Brasil;

Acho que é isso. Tentei cobrir, na medida do possível, alguns pontos de forma genérica. Tentarei manter esse guia sempre atualizado, e é claro, sua opinião é fundamental. Se tiver algo para contribuir, deixe um comentário.

Não deixe de instalar as ferramentas YSlow e PageSpeed no seu Firefox. Dão dicas valiosas para aumentar o desempenho do seu aplicativo.

Um abraço,

Robson Dantas

Bookmarks

Pois bem. Estava lendo agora pouco sobre o método que foi usado, e ficou claro que havia uma falha de segurança enorme no Internet Explorer, e diga-se de passagem que afeta praticamente todas as versões, que possibilitou o ataque.

Em poucas palavras, o ataque explorava uma falha no IE, instalando um malware no computador do usuário, permitindo controle total sobre a máquina infectada. Veja abaixo um pedaço do post do Mashable, que explica o que aconteceu:

As with most targeted attacks, the intruders gained access to an organization by sending a tailored attack to one or a few targeted individuals. We suspect these individuals were targeted because they likely had access to valuable intellectual property. These attacks will look like they come from a trusted source, leading the target to fall for the trap and clicking a link or file. That’s when the exploitation takes place, using the vulnerability in Microsoft’s Internet Explorer.

Once the malware is downloaded and installed, it opens a back door that allows the attacker to perform reconnaissance and gain complete control over the compromised system. The attacker can now identify high value targets and start to siphon off valuable data from the company.

Enfim, se você usa Internet Explorer, sugiro que atualize seu browser agora mesmo, já que a Microsoft publicou um fix para a falha explorada, ou faça algo realmente melhor: troque seu browser para algo decente, como o Firefox ou Chrome.

Não deixe de comentar.

Bookmarks

Os passos são bem simples, porém, demoram um pouco por causa do tamanho dos downloads.

• Conecte seu iPhone com cabo USB e pelo iTunes mande fazer um sincronismo para backup;
• Ainda pelo iTunes, mande baixar a versão do OS 3. Quando fiz isso, meu iTunes pediu para atualizar e baixou 70MB. Depois da atualização, mais 230 MB de atualização do OS 3. Como de costume, só ficar olhando e esperando atualizar;
• O processo de jailbreak para OS 3 é feito pelo redsnow. Só rode esse cara se você NÃO ESTIVER usando yellowsnow para desbloquear as ligações (casos de iPhones vindos de fora do Brasil). Você pode acessar o site do redsnow por aqui ;
• O download do redsnow pode ser feito via torrent ou por mirrors independentes. Eu baixei pelo mirror independente. Nota: as versões que coloquei aqui pra download são pra windows, se quiser pra MAC, entre no site direto;
• Depois de baixado o redsnow, descompacte e não deixe de ler o readme;
• Execute o redsnow e tenha certeza de já estar com seu iPhone rodando OS 3. A primeira tela manda você deixar o aparelho DESLIGADO, porém, com o cabo USB ligado. Faça isso!
• Depois, ele manda você localizar o arquivo de firmware. Estou rodando o windows XP e o meu estava em:  “C:\Documents and Settings\usuario\Dados de aplicativos\Apple Computer\iTunes\iPhone Software Updates\iPhone1,2_3.0_7A341_Restore.ipsw”;
• Feito isso, ele vai mandar você executar uma série de comandos: Segurar o power por 3 segundos, manter o power segurado e pressionar e tecla home por 15 segundos, soltar o power e manter o home segurado. Se der certo, você verá que o windows vai localizar um dispositivo USB;
• Após o passo acima é só esperar que o processo será feito e estará com Cydia rolando;

Dica importante: Se estiver usando Installous, suas aplicações irão desaparecer, e só depois de instalar ele novamente que vão voltar pro aparelho.

Espero ter ajudado e qualquer dúvida só comentar

Bookmarks

CMSBrasil2009 - Matt Mulenweg - WordPress

Representando a AgênciaClick, estavam presentes eu (Robson Dantas) @robsondantas –  gerente de tecnologia, Edson Suey @esuey – gerente de tecnologia e Leonardo Santos @leonardosouza – líder célula de interface . Não nos dividimos para poder cobrir todo o conteúdo, cada um foi pro seu canto, postando updates no Twitter.

Assuntos abordados:

• CMS – focaram em soluções Opensource (todas baseadas em PHP) – WordPress, Drupal e Joomla;
• Metodologias ágeis (case da Globo.com);
• Hospedagem com servidores linux;
• SEO;

Organização das palestras:

• No auditório principal, apresentações genéricas e mesas redondas para discussão;
• No auditório secundário, oficinas com foco mais técnico;

Sequência do que foi visto:

1) Começamos o evento, assistindo uma apresentação do Guilherme Chapiewski, falando de metodologias ágeis, especificamente aplicadas na Globo.com. Eu gosto muito do tema, mas acredito que para o mundo de agências, fica muito difícil vender um projeto para o cliente e adotar o processo da forma que foi colocado (contrato de escopo negociável). Imagine você falando para o cliente: “Olha, vou te vender 10 sprints, e você vai receber o conteúdo desses sprints” – complicado, não ? ; para utilizar internamente, entre as áreas, acho que é válido.

2) Logo após, entrou o Matt Mulenweg, o cara que criou o WordPress. A palestra foi muito fraca na minha concepção, sinceramente esperava mais. Foi contada a história de como nasceu a WordPress, mas não foi falado nada do futuro da ferramenta e qual linha vão atacar. Rolaram alguns defeitos técnicos na palestra, principalmente com falha dos microfones, que pararam de funcionar algumas vezes.

3) Assistimos uma palestra sobre hospedagem na web com Linux e essa foi hilária. Alguns participantes deram uma aula de linux para o palestrante, que deveria falar sobre Linux . No fim, o cara conseguiu apresentar algo interessante sobre performance e proxy reverso. Saí no meio da palestra e fui conferir o fim da mesa redonda com o Matt Mulenweg respondendo questões dos participantes.

Pausamos para o almoço, comemos uma feijoada, mas sem o joelho de porco, né Leozão

4) Voltando para o evento, fui conferir a palestra da Addison Berry, líder do time de documentação do Drupal. Ela falou um pouco sobre o projeto e deu foco na versão 7.0, onde ela disse que o produto será um “cutting edge”, ou seja, inovando drasticamente.

Achei um pouco melhor que a palestra do Matt, e deu pra entender um pouco da linha de atuação do Drupal, até o funcionamento do processo de entrada de desenvolvedores no projeto.

5) Nas oficinas ficaram o Leo e o Edson, se divertindo com os palestrantes e as gafes de pronúncia da língua inglesa. Rolaram eventos técnicos sobre desenvolvimento de plugins com wordpress, plugin de e-commerce, além de hands-on com Drupal e depois Joomla.

Para finalizar, vão aqui minhas considerações finais:

• Minha nota para o evento: 6,5;
• Faltou organização e espaço; muitas pessoas sentadas no chão e várias vezes os equipamentos de áudio e vídeo falharam;
• Não havia controle de entrada e saída de participantes. Pagamos pela inscrição gold, que dava acesso as oficinas e palestras, mas dava pra ver claramente que não havia diferença, dava pra ir nos 2 sem controle algum;
• O tempo de perguntas foi muito curto, acho que esse era o ponto principal;
• O tema de CMS é bem difundido e tem muita gente antenada;

Acho que valeu o dia, deu pra ver que muita gente tem interesse no assunto. Caso tenha alguma consideração, não deixe de comentar.

Deixo aqui, também, o post da PagSeguro oferecendo uma mochila para os trackbacks.

um abraço,

-Robson

Bookmarks