Foram expostos alguns cases de infraestrutura de aplicações web com um alto volume de transações como, por exemplo, o boo-box, o Drimio e aplicações desenvolvidas pela globo.com.

Algumas das implementações de infraestrutura usadas por diversas empresas de médio/grande porte já são “antigas” e populares no mundo web, mas com o advento de novas tecnologias para load balance, cached, etc, fazem a tarefa de deixar uma aplicação web escalável, um pouco mais fácil de implementar e manter.

Abaixo seguem os itens mais abordados pelos desenvolvedores presentes no Fisl no tocante a escalabilidade em ambiente web.

Infraestrura em camadas:

A divisão da aplicação web em camadas permite que cada uma delas seja tratada de forma individual.
Essa divisão permite as melhores praticas para garantir que a escalabilidade seja aplicada diretamente na camada que venha a se tornar um gargalo na aplicação.

Load Balanced (Balanceadores de carga):

O uso desse artefato tanto na camada de aplicação quanto na camada de acesso a dados permite escalar a aplicação de forma horizontal.
Escalar na horizontal permite que em uma situação em que aplicação já não tenha um tempo resposta aceitável devido ao alto volume de acessos (performace x capacidade) tenha seu estado normalizado apenas por incluir um novo servidor na infraestrutura da aplicação, ou seja, na camada que foi afetada pelo problema.

Banco de dados:

Uma prática comum em sites de médio/grande porte é, além do uso de balanceadores, a divisão de requisições de modificação de dados (insert, update e delete) e leituras em diferentes bases de dados (select).
A sincronização dos dados em todas as bases envolvidas é feita por meio de replicação entre as bases.
O uso de tipo de dados corretos, índices em tabelas e boas práticas na construção de consultas ou store procedures trazem um ganho de performance considerável. Um DBA sempre é bem vindo.

Cached:

Em grande parte da cases no Fisl relacionados ao assunto desse post o termo cached sempre esteve presente nas aplicações apresentadas.
Nesse quesito o memcached, já consolidado na comunidade, foi o sistema de cached mais usado para armazenar conteúdos como resultados de queries SQL, sessões de usuários, css, javascripts, etc.

Monitoração/métricas:

Manter uma aplicação web sob controle requer monitoração constante.
O uso de ferramentas de monitoramento/métricas permite-se alertas sobre possíveis problemas de performance, falhas de hardware, bugs na aplicação e também ajuda com capacity planning.
Apache ab, nagios, cacti, mrtg, snmp, jmeter, firebug foram os mais citados.

Arquivos estáticos:

Deixar arquivos estáticos como css, imagens, javascripts, etc em um servidor a parte e se possível carregar esses dados em memória, reduzindo assim a carga no servidor de aplicação, se tornou um excelente prática.
Deixando o servidor de arquivos estáticos em um subdomínio, por exemplo, pode-se tirar vantagem do fato de navegadores modernos serem capazes de carregar arquivos de múltiplos domínios simultaneamente.
Outras melhorias de performance em arquivos estáticos podem ser verificadas aqui.

Algumas dicas deixadas pelos palestrantes:

- Procurar fazer transações curtas e comandos simples no banco de dados.

- Regras de negócio na aplicação. Banco de dados apenas para armazenar dados.

- Use cached sempre que possível.

- Sessões de usuário devem ser armazenadas em banco ou cached facilitam a escala da aplicação.

- Eliminar possíveis SPOF (Single point of failure).

- Coletar estatísticas de performance. Capacity planning deve ser feito com dados reais e não com abstratos.

- 80% a 90% do tempo de resposta para o usuário final é gasto no frontend da aplicação. Otimize ao máximo essa camada.

- Linguagem/framework de programação por si só não escala.

Apresentações originais:

Boo-box/Marco Gomes : http://www.slideshare.net/marcogomes/construindo-uma-empresa-de-servio-web-baseada-em-software-livre-e-colaborao-fisl-10

Drimio/Elton Luís Minetto : http://www.slideshare.net/eminetto/app-web-escalaveis-fisl

Globo.com/Camila Dias : http://www.slideshare.net/camilapdias/fisl10-mysql-na-globocom-por-camila-dias-1663778

Pouco ou quase nada se falou sobre uso de alguma ferramenta específicas Microsoft, até porque o foco do grupo que já existe há algum tempo é exatamente a utilização do .Net com práticas de engenharia de software e arquitertura.

O evento, segundo a organização, não teve fins lucrativos e o valor foi revertido em brindes e coffe break além de algumas outras despezas (achei muito bacana a prestação de contas apresentada pelo Giovanni, idealizador do grupo).

Estes foram os temas apresentados, com um pequeno resumo de cada palestra. De acordo com a organização, as apresentações e as filmagens estarão disponíveis no site do grupo em breve.

Programando com prazer com Domain Driven Design (DDD) – Giovanni Basi

A principal preocupação do arquiteto ou desenvolvedor de software deve ser com o futuro, ou seja, a “manutenibilidade” do sistema. Com o design baseado na lógica do domínio do cliente (DDD), tudo fica mais fácil, desde a forma de se comunicar (linguagem ubíqua) até a modelagem, desenvolvimento e manutenção do software.

Utilizando Injeção de dependência com Unity (Enterprise Library) - Leandro Daniel

O acoplamento é um problema enorme em POO. Fazer testes em uma classe de negócio que dependa de uma outra que envia e-mail, por exemplo, ou adicionar uma nova funcionalidade a um pedaço que já esteja amarrado a uma implementação é triste demais. O Unity, um dos blocos da Enterprise Library (incorporado a partir da versão 4.0), foi criado para ajudar nessa tarefa injetando a dependência quando necessário. No entanto, é preciso avaliar o uso para não tornar seu software ainda mais acoplado

ASP.Net MVC: tome seu HTML de volta - Victor Cavalcante

Nesta palestra foi feita uma comparação entre o ASP.NET MVC e Web Forms, mostrando como ficamos como, com este último, muito presos à interface e fica difícil fazer testes enquanto que, com MVC separa a lógica da apresentação ficando mais flexível e testável. Por outro lado, MVC tem um preço, é necessário colocar a mão na massa, controlar o HTML, é necessário saber programar para web.

ORM - Sendo preguiçoso com NHibernate - Juliano Oliveira

No início da palestra o Juliano trocou o título para “Sendo produtivo com NHibernate”. Este que é um dos frameworks mais conhecidos para mapeamento de objeto relacional é de grande valor na hora de desenvolver seu sistema e diminui bastante a dor de cabeça com criação de tabelas, colunas, constraints, etc. na base de dados. Foi mostrado também o NHProf uma ferramenta comercial para que funciona como o Profiler do SQL Server.

Testes: garantindo que seu código faz o que você quer - Mauricio Aniche

Uma frase que eu tenho ouvido muito ultimamente, mas, graças a Deus, a grande maioria das vezes, só como ilustração “Tá pronto, só falta testar”, foi mencionada mais uma vez. E não é difícil ouvir isso nas empresas que ainda não adotam boas práticas de desenvolvimento. Foi feita uma bela apresentação de como os testes podem ajudar tanto a evitar bugs como na qualidade e na própria codificação, pois fica fácil entender a lógica e as regras de negócio fazendo testes. O uso de ferramentas de automatização de testes como o NUnit ou o Próprio MSTest do Visual Studio, o uso de frameworks de mock potencializam a produtividade.

Valeu muito a pena participar e já estou esperando o próximo.

A palestra foi dividida em quatro partes: Fundamentos, Abordagens, Como eu desenvolvo com testes no Rails e Dicas. Mas separei aqui em mais duas: Boas Práticas e Maus Sinais.

Fundamentos

• TDD, BDD e suas suas diferenças.

Abordagens

• Outside-in: perspectiva dos usuários, testes de fora para dentro. São os testes de aceitação, mostram onde chegar.
• Inside-out: perspectiva do desenvolvedor, testes de dentro para fora. São os testes unitários, mostram como chegar.
• Atenção para não duplicar testes. Por exemplo, quando testar validações no model, não testar novamente essa validação no teste do controller que usa esse model.

Como eu desenvolvo com testes no Rails

• Testes unitários somente para models, testes funcionais mínimos e testes de aceitação guiando seu design de alto nível.
• Não fazer testes para helpers: se há uma complexidade em um helper que precise de um teste, essa lógica não deveria estar na View. Os helpers devem contém formatação e não lógica de negócio.
• Processo ideal: criar uma feature no Cucumber e vai descendo do alto nível (browser, session/routes, view) para os níveis mais baixos (controllers, models).

Dicas

• Use factories para fazer testes.
• Especifique os casos de falha, não crie testes somente para a execução perfeita da funcionalidade.
• Os testes precisam revelar o comportamento e a intenção. Testes com nomes de métodos ficam esquisitos, coloque no nome do teste o comportamento que você está testando.
• Testes não precisam ser totalmente DRY (Don’t Repeat Yourself), pois devem ser muito fáceis de entender, somente “batendo o olho”.
• Use com moderação objetos de substituição (mocks, stubs, proxies, etc).
• Não utilize mocks como stubs.
• Não confie cegamente em métricas: é muito fácil criar testes que não testam nada e que aumenta a cobertura de testes.

Boas práticas

• Não substitua (com mocks, por exemplo) o objeto que você está testando.
• Crie wrappers para objetos que você não é dono, ao invés de tentar modificar os objetos de terceiros nos seus testes, já que no Ruby você tem o poder para alterar tudo.
• Teste também o que não deve acontecer, sendo explícito a respeito disso.

Maus sinais

• Métodos de setup longos: você está testando muita coisa ao mesmo tempo e seu design provalmente está acoplado.
• Falta de testes de integração:  você irá perder a sincronia com as alterações que são feitas nos testes unitários.

.
Grande parte do que foi passado na apresentação  se aplica em qualquer plataforma onde você esteja desenvolvendo orientado a testes.

O arquivo PDF com slides da apresentação você pode baixar aqui. O que achei muito legal desses slides é que eles vêm comentados com o texto de base para a apresentação, ou seja, praticamente você pode “ler” a apresentação que foi feita.
.

Em resumo, com palestras de diversos níveis técnicos e didáticos, das quais tive a oportunidade de acompanhar, destaco as seguintes:

• Fábio Akita - Características e recursos do Ruby on Rails para incrementar o Blog em 15 minutos de DHH; (slide, código)
• Lucas Húngaro - TDD e Rails: Mais rápido, mais forte e melhor; (pdf)
• Bernardo Heynemann e Gabriel Falcão - Testes de aceitação como Pyccuracy;
• Leonardo Rochael - IPython para principiantes;
• Fábio Berbert de Paula - Como ingressar no mercado usando software livre;
• Camila Dias - MySQL (resumo da palestra, slide)
• Marco Gomes - Construindo uma empresa de serviços WEB baseada em software livre e colaboração;
• Guilherme Chapiewski - Uso do software livre e introdução à metodologias ágeis (slide)
• Nelson Lago - Empreender com software livre.

A grande lição que transmito com esta jornada, vai além dos conceitos técnicos, a vivência e adquirição de conhecimento trazidos das palavras comunidade, comunicação e colaboração, mostram que o ponto principal a ser focado é a cultura, então seja no desenvolvimento de software, seja na aplicação de metodologias ágeis ou na vida em geral, compartilhe o conhecimento, exponha suas idéias, seus códigos, pois a humanidade não só ganha com isso, mas ela evolui. Então, eis algumas dicas:

Não importa o seu nível de conhecimento - sempre existirá o experiente, o intermediário, o iniciante e o curioso, então compartilhe o que você sabe, crie um blog, participe de fóruns, contribua com algum projeto de código aberto (open source), nem que seja para informar que uma tradução não está correta, que faltou um ponto ou uma acentuação, pois desta maneira você contribuirá para que um curioso se torne um iniciante, um iniciante se torne um intermediário e assim por diante;
Documente suas dificuldades - quando sentir alguma dificuldade na resolução de um problema, na melhorar maneira de aplicar um padrão de projeto, documente como você resolveu e publique seus passos, pois esses passos poderão contribuir para que outros alcancem o mesmo resultado de forma mais rápida;
A melhor forma de aprender é ensinar - seja voluntário, ao explorar uma nova ferramenta, tecnologia, conceito, compartilhe com seus colegas, passe a informação adiante, faça uma apresentação, monte um grupo de estudos. Com certeza o maior beneficiado com isto é aquele que compartilha, pois enraíza o conhecimento;
E por fim, comunique-se - e-mail, twitter e afins, são excelentes ferramentas, mas eu falo de comunicação olhos nos olhos, pergunte o nome do colega ao seu lado, do vizinho à sua frente, sim, aquele que talvez trabalha a anos no mesmo ambiente que o seu, mas você sequer conhece o timbre de voz dele. Descubra com qual tecnologia ele trabalha e se existem formas de ambos se ajudarem, de contribuírem para algo melhor. A comunicação é o elo entre comunidade e colaboração, e ela pode resolver problemas numa velocidade muito maior que qualquer e e-mail,  sms,  mensagem,  etc.

Post original:
http://mauriciodeamorim.com.br/2009/06/29/uma-grande-semana-no-fisl-10

Tela de aviso sobre problema de segurança em um site

Assim você pode escolher se quer seguir ou não. Isso não significa com 100% de certeza que o site está realmente invadido, apenas que, pelo critérios do próprio Google, ele acha que sim.

Agora, o que leva um site a ser invadido? Existem várias maneiras e você como dono de um website, deve ficar muito atento a isso:

• sua senha na sua hospedagem é fraca. E senha fraca é mais comum do que se pensa. Você usa uma daquelas senhas do tipo “123456″, ou “teste123″ ou mesmo combinações de palavras e datas “joao1970″? Tudo isso é muito fraco e lhes digo que trivialmente quebrável. A senha precisa ser o mais aleatório possível. Quer um exemplo de senha forte? Use este gerador e gere combinações como estas:

  D2F16079AD2267C09BBD3ECD7C546892C4FB3F4AF52BD556ED857

  (Claro, tome todo cuidado para não esquecer depois qual era a senha, é como trancar a porta de casa e esquecer onde deixou a chave

• a programação do seu site é falha. E isso é extremamente comum. Na verdade é mais fácil achar um site com defeito do que bem protegido.

  Especialmente se o programador não tem interesse em se aprofundar realmente na área (não, faculdade, cursos, certificações, nada disso é garantia). Lembrem-se, exemplos de revista, livros, foram feitos para serem didáticos. Por exemplo, se um livro mostra um exemplo de como se faz um formulário que recebe um upload de imagens, ou um formulário para cadastrar e-mails, eles estão preocupados em explicar apenas um assunto. Coisas como performance, escalabilidade, usabilidade, segurança, não estão sendo discutidos. Especificamente sobre segurança, esses exemplos quase sempre tem buracos, por exemplo, coisas como “Injeção de SQL”. Ou imagine que em vez de fazer upload de uma imagem como JPG, o malfeitor faça download de um arquivo do tipo “virus.exe.jpg” e seu site aceita e os usuários baixam?

Esses são apenas 2 pequenos exemplos. O mundo da internet tem dezenas de maneiras de se invadir e contaminar um website. Às vezes nem precisa de muito, basta alguém que baixou uma versão de um software como Drupal ou Joomla (e não importa se é open source ou comercial, o risco é o mesmo) e nunca fez atualizações, mesmo depois de já terem sido descobertas falhas de segurança que já foram corrigidas. Sistemas obsoletos vão se tornando mais e mais vulneráveis à medida que novas formas de invasão ou bugs são descobertos.

Além de “Injeção de SQL” (SQL Injection), ainda existem Cross-Site Request Forgery, Cross Site Scripting, Replay Attack, Session Fixation e muito mais. Hoje em dia não basta apenas que o site esteja “rodando”, isso quase sempre não garante muita coisa. Por isso sempre procure pessoas/empresas experientes e de boa reputação para fazer seu site, porque caso contrário é o nome da sua empresa que pode ficar prejudicada quando seus usuários começarem a ser infectados e quando o Google Safe Browsing passar a categorizá-lo como site perigoso.

http://code.google.com/speed/

que tem por objetivo ajudar todas as pessoas que trabalham com desenvolvimento de aplicativos web a torná-los mais rápidos. Abaixo um vídeo em inglês (sem legendas) sobre porque cada milisegundo conta:

Esse site tem 3 áreas:

• Uma área de tutoriais;
• Uma área com ferramentas para download e;
• A própria comunidade de desenvolvedores web.

Vale dar uma olhada para rever ou aprender novas técnicas para melhorar a performance do seu site.

Afinal, com um site mais rápido todos ganham.

Crianças praticando Calistenia em 1943

Jeff Bay, desenvolvedor de sistemas da ThoughtWorks, escreveu um artigo muito interessante no livro “The ThoughtWorks Antology” entitulado “Object Calisthenics” onde ele propõe um exercício “calistênico” para melhorar o design de software e ajudar a internalizar princípios de bom design de programação orientada a objetos.

O exercício consiste em escrever um programa pequeno, de umas 1.000 linhas, seguindo 9 regras bem rígidas:

1. Use apenas um nível de identação por método. O objetivo aqui é garantir que cada método faça apenas uma coisa. Assim facilitamos a leitura e facilidade de manutenção do código. Exemplo:

   
   class Board {
     ...
     String board() {
       StringBuffer buf = new StringBuffer();
       for(int i = 0; i < 10; i++) {
         for(int j = 0; j < 10; j++)
           buf.append(data[i][j]);
         buf.append("\n" );
       }
       return buf.toString();
     }
   }
   
   Class Board {
     ...
     String board() {
       StringBuffer buf = new StringBuffer();
       collectRows(buf);
       Return buf.toString();
     }
   
     Void collectRows(StringBuffer buf) {
       For(int I = 0; I < 10; i++)
         collectRow(buf, i);
     }
   
     Void collectRow(StringBuffer buf, int row) {
       For(int I = 0; I < 10; i++)
         Buf.append(data[row][i]);
       buf.append("\n" );
     }
   }
   

2. Não use else. Aqui iremos evitar aquelas construções de vários ifs e elses um dentro do outro, que também dificultam bastante a leitura do código. Exemplo:

   
   public static void endMe() {
     if (status == DONE) {
       doSomething();
     } else {
       
     }
   }
   
   public static void endMe() {
     if (status == DONE) {
       doSomething();
       return;
     }
     
   }
   

   Outro exemplo:

   
   public static Node head() {
     if (isAdvancing()) { return first; }
     else { return last; }
   }
   
   public static Node head() {
     return isAdvancing() ? first : last;
   }
   

3. Crie objetos para tipos primitivos e strings. Se um determinado método espara um ano como parâmetro, crie um objeto chamado ano. Um int por si só é apenas um escalar sem significado. Um objeto, mesmo que seja bem pequeno, irá dar ao compilador e ao programador mais informação sobre o valor e por quê ele está sendo usado.
4. Use apenas um ponto por linha. Com muitos pontos na mesma linha às vezes fica difícil saber que objeto é responsável por qual atividade. Pense da seguinte forma: você pode brincar com seus brincados, com os brinquedos que você faz, com os brinquedos que deram para você. Contudo, você nunca deve brincar com os brinquedos do seu brinquedo. Exemplo:

   
   class Board {
     ...
   
     class Piece {
       ...
       String representation;
     }
     class Location {
       ...
       Piece current;
     }
   
     String boardRepresentation() {
       StringBuffer buf = new StringBuffer();
       for(Location l : squares())
         buf.append(l.current.representation.substring(0, 1));
       return buf.toString();
     }
   }
   
   class Board {
     ...
   
     class Piece {
       ...
       private String representation;
       String character() {
         return representation.substring(0, 1);
       }
   
       void addTo(StringBuffer buf) {
         buf.append(character());
       }
     }
     class Location {
       ...
       private Piece current;
   
       void addTo(StringBuffer buf) {
         current.addTo(buf);
       }
     }
   
     String boardRepresentation() {
       StringBuffer buf = new StringBuffer();
       for(Location l : squares())
         l.addTo(buf);
       return buf.toString();
     }
   }
   

   Note que, apesar de os detalhes da implementação ficarem mais difusos e dar a impressão de que é mais difícil ler esse código, você acaba de criar um método com um nome claro para transformar uma peça em um caracter. Os nomes dos métodos devem servir como comentários, o que facilita a leitura e a manutenção do código.

5. Não abrevie. É muito tentador abreviar nomes de classes, objetos e variáveis. Resista à tentação. Abreviações dificultam o entendimento do código. Procure manter os nomes com apenas uma ou duas palavras, e evite nomes que duplicam contexto. Por exemplo, na classe Order o método de envio não precisa se chamar shipOrder(). Chamando o método apenas de ship(), você terá chamadas como order.ship(), mais fáceis de ler do que order.orderShip().
6. Mantenha todas as entidades pequenas. Isso significa que nenhuma classe pode ter mais do que 50 linhas. Classes como mais de 50 linhas muito provavelmente fazem mais do que uma coisa, o que as deixa mais difíceis de ler e reutilizar.
7. Não use classes com mais de duas variáveis instanciadas. A maioria das classes deveria ser responsável por manipular uma instância de uma variável, no máximo duas. Adicionar mais instâncias de uma variável a uma classe diminui a coesão da classe. Programando com essa regra em mente você irá perceber que existem dois tipos de classes, as que mantém o estado de uma instância de uma variável e as que coordenam duas variáveis separadas. Procure não misturar as duas responsabilidades na mesma classe. Exemplo:

   
     String first;
     String middle;
     String last;
   }
   

   Esse código pode ser decomposto nas classes abaixo:

   
   class Name {
     Surname family;
     GivenNames given;
   }
   
   class Surname {
     String family;
   }
   
   class GivenNames {
     List names;
   }
   

   Decompor um conjunto de atributos numa hierarquia de objetos que colaboram entre si nos conduz a um modelo de objetos mais efetivo. No código acima separamos o Surname, frequentemente usado para busca de nomes, dos GivenNames, que foi transformado em uma lista de strings para acomodar pessoas com nomes compostos ou com mais nomes que só primeiro nome, nome do meio e último nome.

8. Não use coleções de primeira-classe. A aplicação dessa regra é simples: qualquer classe que contenha uma coleção não deve conter outras variáveis. Cada coleção pertencerá à sua própria classe, assim os comportamentos relacionados a essa coleção terão um lugar. Uma coleção é uma variável primitiva muito útil. Tem vários comportamentos mas poucas dicas semânticas para facilitar a manutenção do código.
9. Não use Getters/Setters/Properties. A última frase da regra anterior leva quase que diretamente à essa última regra. Se os seus objetos estão encapsulando o conjunto apropriado de instâncias de variáveis mas seu design ainda parece estranho, é hora de examinar mais algumas violações diretas ao encapsulamento. O comportamento não irá seguir a instância de variável se puder simplesmente perguntar pelo valor no lugar atual. Essa regra é às vezes enunciada como “Diga, não pergunte”.

Oito dessas nove regras são formas de visualizar e implementar o Santo Graal da programação orientada a objetos, o encapsulamento de dados. Além disso, uma das regras direciona para uso apropriado do polimorfismo (não usar else e minimizar lógica condicional) e outra é uma estratégia de nomenclatura que força uma nomeação de forma concisa e clara.

Lembre-se que isso é apenas um exercício. É provável que você se depare com situações em que uma regra contradiz a outra, ou mesmo que você se depare com pedaços de códigos que parecerão estranhos. Contudo, experimente escrever umas 1.000 linhas de código usando todas essas regras. Você se verá quebrando velhos hábitos. E ao reler esse código ou passar para outro programador o ler, verá quão mais fácil é sua leitura e manutenção.

O autor termina o texto dizendo que apesar de algumas pessoas acharem que essas regras seriam impossíveis de se aplicar num projeto real, antes de escrever esse artigo ele tinha acabado de trabalhar num sistema com mais de 100.000 linhas de código nesse estilo. Todos os programadores envolvidos nesse projeto perceberam quão mais fácil é trabalhar em desenvolvimento quando se abraça a simplicidade extrema.

]]> http://tecblog.locaweb.com.br/2009/06/24/exercicios-calistenicos-para-objetos/feed/ http://tecblog.locaweb.com.br/2009/06/24/locaweb-no-fisl-forum-internacional-de-software-livre/ http://tecblog.locaweb.com.br/2009/06/24/locaweb-no-fisl-forum-internacional-de-software-livre/#comments Wed, 24 Jun 2009 12:48:59 +0000 danicuki http://tecblog.locaweb.com.br/?p=488 Começa hoje o maior encontro da comunidade de software livre do Brasil. Serão cerca de 7.000 pessoas, reunidas em Porto Alegre, para discutir tecnologia, ciência, política, educação, mercado de trabalho e até, porque não dizer, religião. Alguns adeptos do software livre encaram isso como uma grande causa, defendendo com unhas e dentes a utilização do Linux, OpenOffice, Firefox, citando apenas alguns dentre outras centenas de softwares livre amplamente utilizados no mercado. Da mesma forma que defendem o uso de SL, rejeitam veementemente produtos proprietários.

Naturalmente, não há como negar a importância para a indústria de tecnologia de ambas as filosofias (livre e proprietária), sendo que o melhor caminho deveria ser o do debate, da interoperabilidade, da mútua colaboração. Além disso, a questão é mais complexa do que simplesmente uma rixa entre dois grupos: existem dezenas de tipos de licenças de uso de software (GPL, BSD, Apache, etc), cada uma com características bem particulares. Com certeza teremos discussões calorosas sobre o assunto (como por exemplo, qual será o futuro do MySQL agora que a Sun foi comprada pela Oracle).

Temos também a presença confirmada do presidente Lula na conferência, além do prefeito de Porto Alegre e do governador do Rio Grande do Sul, além dos ícones mundialmente conhecidos, como Richard Stallman e Peter Sunde (fundador do Pirate Bay)

A Locaweb, que há quase 10 anos possui hospedagem em ambientes Linux, está presente no evento. Além do stand, quase 30 pessoas dos times de desenvolvimento estarão passeando pelo evento, interagindo com a comunidade e discutindo soluções de tecnologia que possam melhorar a qualidade de seus serviços. Hoje a Locaweb possui uma ampla infra-estrutura na plataforma Linux, com suporte a Python, Ruby, Java, PHP, Perl, MySQL.

Fiquem ligados no nosso blog para a cobertura completa de palestras e os principais acontecimentos deste grande encontro.

]]> http://tecblog.locaweb.com.br/2009/06/24/locaweb-no-fisl-forum-internacional-de-software-livre/feed/ http://tecblog.locaweb.com.br/2009/06/23/melhorando-a-performance-de-um-site-no-browser/ http://tecblog.locaweb.com.br/2009/06/23/melhorando-a-performance-de-um-site-no-browser/#comments Tue, 23 Jun 2009 11:38:53 +0000 Levy Carneiro http://tecblog.locaweb.com.br/?p=462 Escalar um site para atender milhões de usuários é sempre bom. Mas isto raramente é o problema. O mais importante é melhorar o tempo de carregamento ou renderização de uma página no browser. Aqui os segundos fazem diferença entre um site que abre “num estalo” e outro que demora a carregar acabando por frustrar o visitante.

Para melhorar a performance client-side de seu site existem diversos itens que você precisa aperfeiçoar em seu site:

- Reduzir o número de componentes na página. Uma página com 30 imagens, 10 arquivos CSS e 15 arquivos Javascript realmente vai demorar um certo tempo para ser carregada no browser. É possível reduzir isto tudo para, digamos, 2 imagens, 1 arquivo CSS e 1 arquivo Javascript, usando CSS Sprites e técnicas de consolidação de arquivos. Agora sim seu site carregará muito mais rápido;

- Usar técnicas de cache client-side. Arquivos que não mudam tão frequentemente como o logotipo de seu site, alguns ícones, e até arquivos CSS e Javascript podem usar o cabeçalho HTTP “Expires” fazendo com que browsers mantenham estes arquivos em cache local, afinal pra que baixar os mesmos arquivos toda vez que um visitante abre seu site? Para isto funcionar direito, você precisará expirar os arquivos atualizados com um número sequencial, por exemplo: logotipo.jpg?20090622001 (ano/mês/dia/alteração_do_dia).

Estes não são os itens mais importantes e nem os únicos. Para ver uma lista completa de coisas que influenciam na velocidade de seu site, baixe o plugin YSlow no Firefox, e rode o teste de velocidade em seu site. Quanto maior a nota, mais rápido é seu site. No relatório existem explicações sobre o motivo daquele item impactar na velocidade de seu site, e o mais importante: como fazer para melhorar.

Um plugin semelhante e bem recente é o Page Speed da Google. Um ponto forte dele é conter diversas ferramentas que ajudam na otimização de seu site, dentre elas, uma excelente que gera online uma versão otimizada das imagens, permitindo que você possa usá-las no site imediatamente. Por exemplo: se uma imagem banner.jpg contém 100KB, você pode gerar uma versão otimizada com apenas 30KB (depende de imagem para imagem), economizando em transferência de dados e velocidade de carregamento.

Um blog interessante que fala sobre este tópico, é o blog de Steve Souders, autor do livro High Performance Web Sites. Tanto o blog como o livro são extremamente recomendados.

]]> http://tecblog.locaweb.com.br/2009/06/23/melhorando-a-performance-de-um-site-no-browser/feed/ http://tecblog.locaweb.com.br/2009/06/22/programacao-serena/ http://tecblog.locaweb.com.br/2009/06/22/programacao-serena/#comments Mon, 22 Jun 2009 10:47:25 +0000 Fernando Amorim http://tecblog.locaweb.com.br/?p=457 Meu pai, que considero um exemplo de pessoa honesta, humilde e de bom caráter, me ensinou que na vida precisamos agir com serenidade. Ele me apresentou a oração da serenidade:

Concedei-me, Senhor, a serenidade necessária para aceitar as coisas que não posso modificar, coragem para modificar aquelas que posso e sabedoria para distinguir umas das outras.

Agora, o que isso tem a ver com desenvolvimento de software?

Imagine um cenário que você precise incluir uma nova funcionalidade em uma aplicação existente. Suponha que o código dessa aplicação não está muito bom, há acoplamentos entre os objetos, pouca cobertura de testes e a arquitetura deixa a desejar. Você precisa incluir a nova funcionalidade, mas não pode aumentar o débito técnico.

Por outro lado, você não irá refazer toda a aplicação de uma forma melhor, pois além de você não ter tempo (e dinheiro) disponível para isso, o sistema hoje atende os requisitos atuais e executa sem problemas.

Nessa situação, você precisa de sabedoria para distinguir o que pode ser modificado neste momento no código existente para melhorá-lo e o que você não irá modificar agora, já que não afeta diretamente a nova funcionalidade.

Você necessita de coragem para modificar o código legado, pagar o débito técnico, criar testes automatizados, refatorar, tornar o código mais claro, reformular o design, diminuir acoplamentos.

Você terá serenidade para aceitar que nem tudo pode ser melhorado agora, pois você tem prazo e orçamento a serem cumpridos. O objetivo neste momento é implementar a nova funcionalidade.

Com serenidade você pode alcançar uma melhoria contínua no seu software.
.
Obs.: Após rascunhar o conteúdo deste post dei uma olhada no meu leitor de feeds e me deparei com o post Parar e Refatorar? da InfoQ Brasil. A discussão sobre o tema é longa, mas a serenidade também se aplica.

Post original:
http://prodis.pro.br/2009/06/20/programacao-serena

.

]]> http://tecblog.locaweb.com.br/2009/06/22/programacao-serena/feed/