Tecnologia de Internet (Locaweb)

O palestrante Marco André Lopes Mendes iniciou a apresentação dizendo que iria tentar convencer quem estava assistindo a usar Python.

Ele mostrou dez razões (que viraram doze) para aprender Python.

1 – É legal
Simples, legível, clara, elegante e próxima da linguagem natural. Mesmo quem não tem conhecimento da linguagem, entende bem quando olha o código.
Abaixo um exemplo de manipulação de arquivos texto:

arquivo = open("emails.txt")
dominios = {}

for contato in arquivo:
    resto, dominio = contato.split("@")
    dominio = dominio.replace("\r\n", "")

    if dominio in dominios:
        dominios[dominio] += 1
    else
        dominios[dominio] = 1
arquivo.close()

arquivo = open("dominios.txt", "w")
print "%-30s - %-5s" %("Dominios", "Ocorrencias")
for dominio in dominios.keys()
    print "%-30s - %-5s" %(dominio, dominios[dominio])
    registro = "%s;%s\n" %(dominio, dominios[dominio])
    arquivo.write(registro)
arquivo.close()

.
2 – Já vem com acessórios
Uma analogia com um carro que já vem com opcionais de série. Os recursos que vêm com Python são poderosos: persistência de objetos, banco de dados, geração de arquivos PDFs, geração de gráficos, protocolos de rede, Web, criptografia, etc.
.
3 – É muito utilizado fora do Brasil
Casos de sucesso como Google, Industrial Light and Magic, DreamWorks e Nokia.
.
4 – É utilizado no Brasil com sucesso
Exemplos são Async – Stoq, LZT, Instituto Nokia de Tecnologia e InVesalius.
.
5 – É utilizado na Web fora do Brasil
Por exemplo, Novel e Cia, utilizando Django, um framework de desenvolvimento rápido para Web.
.
6 – É utilizado na Web no Brasil
IDG Brasil, Vencia, República Federativa do Brasil, Politec, SEBRAE, Varig.
.
7 – Há empregos para programadores Python no Brasil
Bons programadores Python não ficam sem emprego.
Meu comentário: bons programadores em qualquer linguagem, mas bons mesmos, não ficam desempregados.
.
8 – Conversa com outras linguagens
Se você possui bibliotecas em C e C++, pode utilizá-las integrando com Python. Há também implementações para Java (Jython) e .NET (IronPython).
.
9 – É multi-plataforma
Linux, Unix, Mac OS, Windows e plataformas diferentes das tradicionais, como celulares, dispositivos móveis e XO/OLPC.
.
10 – É multi-paradigma
Você pode utilizar com Programação Estruturada, Programação Orientada a Objetos e Programação Funcional. Veja os exemplos:

Programação Estruturada

import random

def jogaDados()
    dado1 = random.randrange(1, 7)
    dado2 = random.randrange(1, 7)
    somaTemp = dado1 + dado2
    print "Jogador tirou %d + %d = %d" %(dado1, dado2, somaTemp)
    return somaTemp

soma = jogaDados()
if soma == 7 or soma == 11:
    situacaoJogo = "GANHOU"
elif soma == 2 or soma == 3 or soma == 12:
    situacaoJogo = "PERDEU"
else:
    situacaoJogo = "CONTINUA"
    meuPonto = soma
    print "Ponto: ", meuPonto

while situacaoJogo == "CONTINUA":
    soma = jogaDados()
    if soma == meuPonto: situacaoJogo = "GANHOU"
    elif soma == 7: situacaoJogo = "PERDEU"

if situacaoJogo = "GANHOU": print "Jogador ganha"
else: print "Jogador perde"

.
Programação Orientada a Objetos

class Contador(object):
    def __init__(self):
        self.dic = {}

    def incluir(self, item):
        quantidade = self.dic.get(item, 0) + 1
        self.dic[item] = quantidade

    def contar(self, item):
        return self.dic[item]

>>> cont = Contador()
>>> palavra = 'inconstitucional'
>>> for letra in palavra:
...   cont.incluir(letra)
...
>>> for letra in sorted(set(palavra)):
...   print letra, cont.contar(letra)

.
Programação Funcional

# Fibonacci: 10 primeiros números
print map(lambda x,f=lambda x,f:(x<=1) or (f(x-1,f)+f(x-2,f)): f(x,f),range(10))

.
11 – É boa como primeira linguagem
Se você está aprendendo a programar, pode escolher Python sem receios.
.
12 – Existe uma comunidade forte no Brasil
O Python Brasil reune grupos de usuários em todo o Brasil interessados em difundir e divulgar Python. A sua lista de discussões é bastante movimentada.
.
Marco André também disse que Python é muito utilizado na automatização de processos. Na Locaweb, Python é extensamente utilizado em ambientes Unix-like, sendo a linguagem padrão para a equipe de Linux, onde são desenvolvidas aplicações para linha de comando e para Web também.

No final da palestra, várias pessoas com conhecimento em Python comentaram que poderia ser mostrado mais recursos da linguagem que a diferencia das outras. Eu particularmente nunca desenvolvi nada em Python, mas considero ser uma ótima escolha no intuito de você se tornar um programador poliglota.

Os slides da palestra você encontra nesse link.
.

Há dois dias atrás o Levy falou sobre como melhorar a permformance de um site no browser aqui mesmo no TecBlog. Hoje o Google lançou uma nova iniciativa em:

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.

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.

Li ontem um artigo chamado Polyglote Programming do Neal Ford, autor do “The Productive Programmer” comentado pelo Erich aqui no TecBlog.

Esse artigo, publicado numa antologia de artigos de funcionários da ThoughtWorks, fala sobre a necessidade de saber programar em várias linguagens não só para saber usar a linguagem mais apropriada para cada sistema mas também, dentro de um único sistema, saber usar a linguagem mais apropriada para a tarefa a ser resolvida.

De uma certa forma, o desenvolvimento de sistemas web já é poliglota, pois precisamos saber SQL, javascript, XML, HTML e alguma linguagem (Ruby, PHP, Java, etc.) para unir tudo. Mas a idéia do Neal Ford é ir além e usar as plataformas poliglotas (JVM, C#) para desenvolver cada pedaço de código com a linguagem mais apropriada para o que aquele pedaço de código precisa resolver.

Um exemplo que ele cita é a leitura de arquivos, que pode ser bastante trabalhosa em Java:

package com.nealford.polyglot.linenumbers;

import java.io.*;
import static java.lang.System.*;

public class LineNumbers {
  public LineNumbers(String path) {
    File file = new File(path);
    LineNumberReader reader = null;
    try {
      reader = new LineNumberReader(new FileReader(file));
      while (reader.ready()) {
        out.println(reader.getLineNumber() + ":"
          + reader.readLine());
      }
    } catch (FileNotFoundException e) {
      e.printStackTrace();
    } catch (IOException e) {
      e.printStackTrace();
    } finally {
      try {
        reader.close();
      } catch (IOException ignored) {
      }
    }
  }

  public static void main(String[] args) {
    new LineNumbers(args[0]);
  }
}

Mas que em Groovy, que roda em JVM, ficaria:

def number=0
new File (args[0]).eachLine { line ->
  number++
  println "$number: $line"
}

Outro exemplo é um pedaço de código tirado do projeto Apache Commons para determinar em Java quando um string é vazio:

public static boolean isBlank(String str) {
  int strLen;
  if (str == null || (strLen = str.length()) == 0) {
    return true;
  }
  for (int i = 0; i < strLen; i++) {
    if ((Character.isWhitespace(str.charAt(i)) == false)) {
      return false;
    }
  }
  return true;
}

Usando Jruby teríamos:

class String
  def blank?
    empty? || strip.empty?
  end
end

E os testes para comprovar que está tudo certo:

require "test/unit"
require "blankness"

class BlankTest < Test::Unit::TestCase
  def test_blank
    assert "".blank?
    assert " ".blank?
    assert nil.to_s.blank?
    assert ! "x".blank?
  end
end

Outra dica que ele dá é usar uma linguagem funcional (Haskell, Scala, F#) para resolver a dificuldade que linguagens imperativas como Java e C# tem em lidar com threading:

class SafeArray{
  private final Object[] _arr;
  private final int _begin;
  private final int _len;
  public SafeArray(Object[] arr, int len){
    _arr = arr;
    _begin = begin;
    _len = len;
  }

  public Object at(int i){
    if(i < 0 || i >= _len){
      throw new ArrayIndexOutOfBoundsException(i);
    }
    return _arr[_begin + i];
  }
  public int getLength(){
    return _len;
  }
}

A mesma funcionalidade em Jaskell, a implementação de Haskell para JVM:

newSafeArray arr begin len = {
  length = len;
  at i = if i < begin || i >= len then
    throw $ ArrayIndexOutOfBoundsException.new[i]
  else
    arr[begin + i];
}

E o último exemplo do artigo compara construção de testes com JMock, para testar a interação entre uma classe Order com uma classe Warehouse:

package com.nealford.conf.jmock.warehouse;

import org.jmock.Mock;
import org.jmock.MockObjectTestCase;

public class OrderInteractionTester extends MockObjectTestCase {
  private static String TALISKER = "Talisker" ;

  public void testFillingRemovesInventoryIfInStock() {
    //setup - data
    Order order = new OrderImpl(TALISKER, 50);
    Mock warehouseMock = new Mock(Warehouse.class);

    //setup - expectations
    warehouseMock.expects(once()).method("hasInventory" )
      .with(eq(TALISKER),eq(50))
      .will(returnValue(true));
    warehouseMock.expects(once()).method("remove" )
      .with(eq(TALISKER), eq(50))
      .after("hasInventory" );

    //exercise
    order.fill((Warehouse) warehouseMock.proxy());

    //verify
    warehouseMock.verify();
    assertTrue(order.isFilled());
  }
}

E com JRuby:

require 'test/unit'
require 'rubygems'
require 'mocha'

require "java"
require "Warehouse.jar"
%w(OrderImpl Order Warehouse WarehouseImpl).each { |f|
  include_class "com.nealford.conf.jmock.warehouse.#{f}"
}

class OrderInteractionTest < Test::Unit::TestCase
  TALISKER = "Talisker"

  def test_filling_removes_inventory_if_in_stock
    order = OrderImpl.new(TALISKER, 50)
    warehouse = Warehouse.new
    warehouse.stubs(:hasInventory).with(TALISKER, 50).returns(true)
    warehouse.stubs(:remove).with(TALISKER, 50)
    order.fill(warehouse)
    assert order.is_filled
  end
end

Para terminar esse post, aqui vai um link para um vídeo do Neal Ford explicando o conceito de programação poliglota:

http://www.nofluffjuststuff.com/media.jsp?id=28

O 3o. dia da RailsConf (2o. dia de palestras) foi um dia muito agitado. Tivemos palestras de grandes nomes do desenvolvimento de software, como Neal Ford e Robert Martin.

A palestra do Neal Ford e seu colega, Paul Gross, foi muito interessante. É impressionante ver como eles conseguiram administrar bem o (curto) tempo que tiveram e passar a mensagem de forma eficiente. Em um evento como esses uma boa parte dos palestrantes acaba perdendo um pouco do foco e tenta passar mais informação do que o que cabe na agenda.

Eles falaram de um grande projeto realizado pela consultoria em que trabalham, ThoughtWorks, e sobre as coisas que aprenderam com ele.

Aqui vão alguns conselhos:

• Lute para manter sua suíte de testes rápida.
• Invente coisas novas sempre que precisar.
• Escreva testes inteligentes (eles quiseram dizer que o teste tem que ter um propósito maior do que simplesmente adicionar cobertura ao código).
• Escale sua infra-estrutura de desenvolvimento da mesma forma com que você escala a sua infra-estrutura de produção.
• Evite fazer design adiantado. Faça apenas do que precisa ser implementado no momento.
• Adicione complexidade gradualmente.
• Não use banco de dados como fila de mensagens (principalmente porque isso pode deixar o DBA muito bravo).
• Defina bem quais são as regras e os limites do seu projeto, por exemplo, em que situações será permitido utilizar mocks e stubs para realizar testes.
• Divirtam-se

Para manter a velocidade dos testes funcionais eles utilizaram e recomendam o DeepTest. Para os testes de aceitação em grande escala, utilizaram o Selenium Grid.

Além das recomendações, a dupla também compartilhou as suas impressões com relação ao trabalho em equipe e sobre tecnologia. Sobre trabalhar em equipe:

• Software tem mais a ver com comunicação do que com tecnologia.
• Ter a equipe trabalhando junto, no mesmo local, é muito bom.
• Programação pareada é excelente.

Neal Ford disparou uma piadinha dizendo que “programação pareada dissemina conhecimento mais rápido do que a gripe suína” (a palestra foi bastante descontraída).

Além disso, com relação a lidar com tecnologia:

• Escalar é difícil, não importa qual tecnologia se esteja utilizando.
• Rails pode escalar! (isso não é mais novidade para a comunidade, mas é importante reforçar)
• Atualizar o sistema é difícil. Para eles, isso significou arcar com o custo de 6 semanas de um desenvolvedor para migrar do Rails 1.2.3 para o 2.2.

A palestra teve muito mais conselhos e exemplos, alguns usando a analogia do jogo de “papel, pedra e tesoura”. Os slides estão disponíveis aqui para quem quiser conferir.

Acabamos de ter uma excelente palestra do guru Robert Martin, o Tio Bob. É impressionante ver a sua desenvoltura e capacidade de comunicação. Até agora esse foi o ponto alto da RailsConf’09.

Em resumo, a mensagem que ele passou foi:

• Nada deixa o código mais flexível do que escrever testes. Um código com uma boa suíte de testes ganha flexibilidade em ordens de magnitude. Se você tem uma arquitetura horrível mas uma boa suíte de testes, seu código é ainda assim mais flexível do que um que possua uma excelente arquitetura e nenhum teste.
• A presença de testes eliminam o medo de mexer no código.
• Nenhum código pode ser considerado limpo, código sempre é limpável. E isso se atinge com testes.

Ao argumentar sobre a necessidade de se escrever testes de software, em especial utilizando TDD, ele disse:

Escrever testes antes de escrever código é como lavar as mãos antes de fazer uma cirurgia. Se o seu médico não lavasse as mãos, você acharia isso profissional da parte dele?

Nesse momento, a platéia ficou em silêncio e as pessoas começaram a olhar umas para as outras.

Profissão: desenvolvedor

Com muita desenvoltura,  Bob Martin argumentou que programadores não tinham disciplina antigamente. Foram as práticas de testes, XP, programação pareada, integração contínua, entre outras, que fizeram com que tivéssemos disciplina. Antes disso, os programadores não eram profissionais. E ponto final.

Ao final da palestra, um dos participantes questionou se não estava acontecendo uma onda de “super-profissionalismo”, causada pela euforia que as pessoas têm demonstrado por todas as práticas mencionadas. Após divagar por um momento, o carismático Tio Bob reafirmou sua posição:

Deixe-me pensar… temos como ser profissionais demais? Não! Ser profissional é ter honra, é ter disciplina e acima de tudo, não ter medo de seguir a disciplina.

Se você, por causa de um prazo apertado ou por pressão, abandona sua disciplina, então você deixou de ser profissional. Você fez isso porque sentiu medo e isso também não é profissional. Profissionais não devem sentir medo e sim tratar esse tipo de situação com calma.

E então a analogia com a medicina veio à tona novamente:

Se um médico abandonasse sua disciplina por causa de pressão ou prazo, o que ele faria? Operaria o seu paciente sem ter o menor cuidado?

A propósito, o tema da palestra era “O que acabou com o SmallTalk poderia acabar com o Ruby também“. Entre outras coisas, o que Bob Martin apontou como motivos para o fim do SmallTalk foram: a arrogância da comunidade de desenvolvedores e o fato de terem ignorado as necessidades empresariais.

A platéia aplaudiu Bob Martin de pé e no final tivemos uma pequena interação com ele exclusiva que está disponível no AkitaOnRails.

Os organizadores da conferência disponibilizaram a gravação da palestra no blip.tv. Assistam!

Andei procurando informação sobre otimização de páginas da web e encontrei uma apresentação bastante interessante:

http://billwscott.com/share/presentations/2008/stanford/HPWP-RealWorld.pdf

a apresentação é do pessoal de Stanford, descreve basicamente como medir o tempo de renderização das páginas web pelos browsers e mostra algumas estratégias para diminuir esse tempo.

Uma outra página, essa do yui,

http://yuiblog.com/blog/2009/04/13/yui-270-on-taskspeed/

faz um benchmark dos frameworks javascript (prototype, jquery, yui, etc.), realizando tarefas comuns em elementos DHTML.

Um blog muito interessante para se acompanhar é The Daily WTF – curious perversions in information technology. Para quem não sabe, WTF é uma gíria americana que serve para denotar espanto. Conforme explicação no Wiktionary:

(vulgar military and Internet slang) what the fuck, where the fuck, why the fuck, when the fuck or who the fuck.
…
WTF may be used to introduce a question, as in “WTF are you talking about?” or as an interjection “WTF! That’s a load of bull!”

No post de 16/3 do The Daily WTF havia um pedaço de código javascript para detecção de javascript. Reproduzo abaixo o texto completo do post:

“I work at a major financial services company,” writes Seth. “We have a public site that requires JavaScript be enabled. When it’s not, the visitor is redirected to an error page that explains the website’s requirements.”

Definitively determining whether someone has JavaScript turned on or not can be a pretty challenging task, but fortunately, Seth’s colleagues developed a bulletproof method to figure this out. They used JavaScript.


function javascriptEnabled(){
return true;
}


Clearly, if that function is successfully called, then JavaScript must be enabled. Like the isComputerOn() method that was (allegedly) part of the BeOS API, if it doesn’t return true, then clearly, it’s off. So, by applying this logic later on in the code, Seth’s colleagues came up with this:


function validateSettings(){
if(!javascriptEnabled()){
location.href="no_js.htm";
}
...
}


Seth added, “To their credit… err, I think… they said that they didn’t realize JavaScript could be disabled in their browser. They tested it by having javascriptEnabled return false.”

Como disse antes, os melhores navegadores do mercado (Safari/Webkit, Firefox, Chrome, Opera) estão todos investindo no novo padrão HTML 5, bem como em engines muito mais velozes de Javascript. Isso abre a possibilidade de criar coisas muito interessantes.

Jacob Seidelin escreveu uma série de artigos muito interessantes explorando a técnica de Ray Casting (não confundir com Ray Tracing) com Javascript e o recurso canvas do HTML 5, suportado pelo Opera (no caso os artigos são do blog Dev.Opera) e eu testei no Safari 4 Beta e funciona também (no Firefox Beta ainda não).

No caso, ele reconstruiu a fundação para o jogo Wolfenstein 3D usando essa técnica. Siga os seguintes artigos:

• Parte 1
• Parte 2
• Jogo funcionando
  
• Download dos Códigos (licença MIT)
  

Excelente exemplo do que se pode fazer com coisas simples hoje como um navegador e conhecimento de Ciência da Computação aplicada à computação gráfica.

O Google acaba de disponibilizar um manual com dicas de Search Engine Optimization (”otimização do mecanismo de buscas”, mais conhecida pela sigla SEO). O arquivo, em formato PDF está e escrito em inglês, tem 22 páginas e pode ser baixado gratuitamente.

Lá você não vai encontrar apenas dicas básicas que muitos já conhecem, um dos responsáveis pela criação do manual, Brandon Falls, avisa no Google Webmaster Central Blog “Listamos as melhores práticas que nós usamos dentro do Google.”

O manual informa como fazer um título adequado para a página, usar meta tags, melhorar a estrutura das URLs, otimizar as imagens, usar o robots.txt, etc.

Faça o download do manual Google SEO (Search Engine Optimization)