Python Brasil

Estive esta semana, com meus colegas Felipe Mobus e Marcio Silva, na 5a edição do Python Brasil, na cidade de Caxias do Sul, serra gaúcha. O evento foi organizado pela Associação Python Brasil e é o maior evento sobre a linguagem de programação no Brasil. É um evento itinerante e o Rio Grande do Sul o sediou pela primeira vez.

Foram três dias de palestras bastante técnicas e deu para aprender  coisas bem interessantes, clarear algumas dúvidas e conversar com bastante gente legal.

Um dos temas mais fortes no evento foi Django, como já era de se esperar. Django está em alta na comunidade Python, e certamente com muitos méritos. É um excelente framework e estamos estudando ele para adotar em alguns projetos na Propus. Seu ORM (Object-relational mapping) é sensacional, entre outras funcionalidades muito interessantes. Um dos criadores do Django, o americano Jacob Kaplan-Moss, esteva presente no evento e fez uma palestra muito interessante sobre desenvolvimento web. Para quem não conhece Django, vale a pena perder um pouquinho de tempo a ler a respeito.

Quem não pôde ficar de fora foi o super polêmico GIL (Global Interpreter Lock) do interpretador CPython. Parece que esse é o ponto mais negativo do Python (na verdade do CPython), uma vez que ele não permite que duas threads acessem a memória ao mesmo tempo, jogando assim no lixo todo o ganho de performance que um programa multi-thread poderia ter com máquinas multi processadas, o que é muito comum hoje em dia e já se mostrou ser o futuro mesmo. Enfim, isso é uma discussão tremenda e existe vários argumentos positivos e negativos em relação ao tão odiado GIL. Basta procurar por “Python GIL” no google e se divertir com o assunto. Tem muito pano pra manga.

Outro americano, Collin Winter, funcionário do Google, palestrou no evento também. Collin falou sobre o Unladen Swallow, um projeto do Google focado em otimizar o interpretador CPython. Eles criaram um fork do projeto CPython, mas a ideia é retornar todas as melhorias que eles puderem fazer ao projeto principal. Ele apresentou vários exemplos onde o interpretador é muito ineficiente e poderia ser melhorado. O Google possui muita coisa escrita em Python, uma vez que Python é uma de suas linguagens oficiais. Devido à grande escala do Google, eles têm todo o interesse em tornar o interpretador mais eficiente.

O keynote speaker do último dia foi o Gustavo Niemeyer, da Canonical. Ele fez uma palestra bastante interessante comparando friamente Python e Java. Existe uma certa rivalidade entre as duas linguagens, então é difícil encontrar boas comparações imparciais. Gostei do tom da palestra do Gustavo, que procurou ser muito imparcial. Ele fez várias provocações ao Python e defendeu que, para um projeto grande, com muitos desenvolvedores, Java parece ser a melhor opção, por ser mais organizado. A permissividade e alta flexibilidade do Python são indiscutivelmente fantásticas, porém isso pode atrapalhar quando a coisa cresce.

Enfim, foi um bom evento e certamente agregou muito. Sendo Python uma das linguagens oficiais na Propus, é de fundamental importância estarmos o mais sintonizados possível no que está acontecendo na comunidade em volta da linguagem. Mesmo ouvindo alguns pontos fortes de Java, vamos continuar programando muito em Python, porque colocando as duas linguagens na balança, Java fica pra trás, considerando as demandas que temos. Python é extremamente produtivo e sua flexibilidade é algo chave para a Propus, pois trabalhamos com projetos bastante específicos, e muitas vezes precisamos de uma interação muito íntima com outros sistemas e com o sistema operacional.

Uma das coisas que prezamos na Propus é que temos que ser profundos conhecedores das tecnologias envolvidas no nosso trabalho. Infelizmente vemos muita gente prestando serviço em áreas onde os técnicos têm um conhecimento muito superficial das coisas, e muitas vezes nenhum conhecimento teórico. Não é esse serviço que queremos vender. Somos incansáveis estudantes, primeiro porque gostamos muito do que fazemos, segundo porque queremos que nossos clientes se sintam à vontade de nos confiar alguma missão importante.

Encontro VoIPCenter

Acontece nos próximos dias 16, 17 e 18 de setembro o IV Encontro VoIPCenter, na cidade de São Paulo. O Encontro VoIPCenter é um evento focado em soluções VoIP com software livre, realizado pela empresa Innovus.

Estarei palestrando pela terceira vez nesse evento este ano. Nesta edição, apresentarei a palestra “VoIP e mitos: por que a voz picota, atrasa… QoS e seus desafios”, apresentada também no último Fórum Internacional Software Livre.

O evento será no Hotel Century Paulista, no bairro Paraíso, em São Paulo – SP. Para quem está interessado em ver boas palestras sobre o tema, recomendo. A programação está bastante interessante.

Fórum Internacional de Software Livre – fisl10

A 10a edição do Fórum Internacional de Software Livre aconteceu em Porto Alegre entre os dias 24 e 27 de junho. O evento mais uma vez foi um grande sucesso, contando a participação de mais de 8000 pessoas e a presença do Presidente Lula, que fez um discurso muito favorável ao tema. Não vou falar sobre isso porque a imprensa já está falando bastante.

A Propus, em parceria com a DigiVoice, esteve presente no evento como patrocinador prata. O estande esteve bastante movimentado durante os quatro dias do evento.

No sábado 27 às 17h00 apresentei a palestra “VoIP e mitos: por que a voz picota, atrasa… QoS e seus desafios“, que abordou forte os conceitos de QoS (qualidade de serviço), quando ele deve (ou não) ser utilizado nas redes e quais as suas implicações.

Abaixo estão os slides para serem vistos direto pelo site, através do SlideShare. Deixo disponível também a versão dos slides em PDF.

Procurei ser bastante teórico na palestra, pois ao longo dos anos trabalhando com tecnologia, tenho percebido que a maioria dos problemas que as pessoas enfrentam nas implementações, especialmente de telefonia digital, são por falta de teoria, erros básicos de conceito, etc.

Infelizmente, os 50 minutos que o evento disponibiliza voaram em instantes e nem houve tempo para abrir para perguntas, o que me entristece, pois percebi que muitas pessoas tinham perguntas para fazer. O assunto é de fato bastante extenso e é normal que as pessoas tenham dúvidas e mais dúvidas. Eu mesmo, que já venho trabalhando com QoS há muitos anos, volta-e-meia fico bastante perdido em alguma implementação.

Conversando com meu amigo Armando, da DigiVoice, vamos tentar fazer uma sequência de palestras, especialmente teóricas, sobre VoIP (transcorrendo também por redes). A nossa ideia é difundir mais os conceitos por trás dessa grande tecnologia, que muitas vezes acaba frustrando muita gente pois tem sido demasiadamente mal implementada.

Como de praxe, fiz muitas fotos durantes todos os dias do evento. Durante os próximos dias estarei imerso no trabalho de “pós-processamento” delas, selecionando o que presta e editando cada uma. As melhores vão para o meu Flickr e os álbuns completos para o Gallery. Fique de olho. 😉

Horário de verão tupiniquim, versão técnica

Seguindo o meu último post, quero falar um pouco sobre a importância do relógio, especialmente nos dias de hoje, de um mundo interconectado.

Antes de tudo, que horas são?

O meu relógio está marcando aqui 21h25. É essa a hora certa? Se eu ligar para um amigo agora em Seattle, ele vai me dizer 17h25, em Londres 1h25 da madrugada. Que confusão, eu só quero saber que horas são. Se a resposta foi qualquer hora + 25 minutos, está correta. Tudo depende de onde a resposta está partindo!

Como o mundo inteiro pode se coordenar com essa bagunça de fusos horários, horário de verão cuja regra varia de região pra região, e outras peripécias, como fusos horários de 15 e 30 minutos de separação, etc? Para isso existe o Tempo Universal Coordenado, o UTC, ou GMT (Greenwich Mean Time), ou ainda “Zulu Time”. É importante salientar que a hora UTC nunca varia. Sempre anda para frente na mesma frequência, perfeitamente alinhada com o sol no meridiano zero.

É em função dessa previsibilidade e uniformidade que é a hora utilizada por muitos sistemas no mundo. Toda a aviação no mundo, inclusive aqui no Brasil, por exemplo, só fala UTC. Grande parte dos sistemas na Internet são baseados em UTC. Grandes empresas com sedes em vários países só operam com referências UTC, e assim por diante…

Vários países no mundo possuem horário de verão, por várias razões, principalmente para economizar energia. Não vou entrar no mérito da questão. Os países com governos com algum nível de inteligência possuem regras repetitivas definindo o dia que o horário de verão começa e termina. Não é o caso do Brasil, infelizmente, que nunca teve uma regra, e agora que tem uma, é quase enigmática, baseando-se no calendário lunar. Acredite, não estou brincando!

O que muita gente se confunde é que na verdade não existe horário de verão. O que existe é fuso horário de verão. Um país, ou uma região, quando entra no horário de verão, na verdade está “se mudando” para o fuso horário seguinte. No caso do Brasil, os estados que atendem o horário de verão estão normalmente em UTC-3. No horário de verão, estão em UTC-2. A hora de referência, UTC, é sempre a mesma. Varia apenas o fator de correção em relação ao UTC.

A confusão técnica está em não sabermos quando essa mudança vai acontecer, pois dependia de um canetasso do Presidente.

Considerando que, de acordo com a regra publicada em 2007, parte do Brasil foi para o horário de verão no segundo domingo de outubro e; este ano a regra mudou para o terceiro domingo de outubro, sendo publicada no início de setembro apenas, vamos a alguns exemplos de problemas que isso ocasiona:

Exemplo 1, uma reunião:

No dia 31 de agosto, eu em Porto Alegre marco uma reunião para o dia 14 de outubro às 11h00 da manhã (hora de Porto Alegre) com minha amiga Fernanda que mora em Zurich, portanto 15h00 para ela. Os sistemas de agendamento obviamente vão gravar isso em UTC, para não haver confusão. O sistema consulta o regramento de hora de verão e verifica que no dia 14 de outubro às 11h00 vai ser 13h00 UTC, pois nesse dia Porto Alegre estaria no horário de verão. Reunião marcada. O governo publica a regra dizendo que o horário verão começa dia 19 de outubro. Chega o dia 14 de outubro 11h00 local, 14h00 UTC, 16h00 em Zurich. Ooops, acho que estou uma hora atrasado! Entenderam o drama?

Exemplo 2, aviação:

Este é um exemplo real que aconteceu comigo:

Em agosto em 2006, eu comprei uma passagem da American Airlines para Dallas num voo partindo de São Paulo dia 22 de outubro. Por razões óbvias a aviação opera toda em UTC, e assim são os planos de voo. O plano do voo que eu comprei previa decolagem às 0h30 UTC. Em agosto, os sistemas da American Airlines previam que 22 de outubro seria horário de verão no Brasil, logo aplicaram uma diferença de 2 horas em relação ao UTC, me vendendo um voo que partiria portanto às 22h30 hora local, pois por lei as passagens têm que ser emitidas em hora local, o que faz sentido até. Após eu ter a passagem em mão, o governo no auge de sua estupidez posterga o início do horário de verão para 5 de novembro, pois as ultra-modernas urnas eletrônicas não suportavam isso (claro, com essa bagunça!). Se o plano de voo da American Airlines era para às 0h30 UTC e agora a diferença horária era de 3 horas e não 2, meu voo consequentemente seria às 21h30, correto? A Tam, onde voei de Porto Alegre pra Guarulhos, também registra todos os seus planos de voo em UTC, mas eles usam como referência a hora local, então mantiveram seus voos travados na hora local, ajustando a UTC, o que é razoável para voos domésticos. Resultado, a Tam atrasou todos os seus voos em uma hora em relação ao UTC para manter a hora local e todo mundo perdeu as suas conexões no aeroporto de Guarulhos, causando um prejuízo absurdo para todo o sistema de aviação, que teve que fazer um replanejamento monstruoso de slots e escalas de tripulação e aeronaves para cumprir um canetasso do Presidente.

Como de costume, publiquei o arquivo com a mais nova regra, desta vez mais confusa do que nunca, do nosso horário de verão. Pra simplificar a jogada no Linux, fiz um script que faz a operação toda. Faça o seguinte logado como root:

wget http://hackers.propus.com.br/~marlon/dst/update_dst.sh
bash update_dst.sh

O script vai baixar automaticamente outro arquivo, o southamerica, onde estão as regras que são válidas até 2100, isso se não mudar tudo de novo, é claro.

Para os curiosos, eu fiz um script em Python que calcula o término do horário de verão de acordo com a nova lei para qualquer ano.

Os usuários Windows podem baixar este arquivo de registro e executá-lo em seu computador. Ele vale apenas para 2008. Você deve verificar na sua configuração de relógio se o fuso horário está certo para -03:00 Hora de Brasília e se a opção para ajustar automaticamente para o horário de verão está marcada.

ATENÇÃO: se você quiser mudar para o horário de verão manualmente, jamais mexa no relógio. Altere o fuso horário para -02:00 Fernando de Noronha então. Lembre-se que a sua hora UTC nunca pode mudar.

Boa sorte.