As reações já eram muitas e de início li as primeiras 5 mensagens da thread e me espantei com o fato de, apesar de toda a comoção, ninguém criticou o @jaseemabid. Mesmo após o Linus ter respondido o autor do pull request, ele sugeriu que “deixasse passar essa” por considerar um patch simples, afinal o cara estava colaborando. A afirmação paternalista foi desrespeitosa, apesar de provavelmente não ter sido maliciosa.

O Linus respondeu, e foi este o estopim para vários comentários que em essência são “pró-comunidade” e “contra o mau exemplo de liderança do Linus”.

Tenho a impressão que há uma tendência à inversão entre meio e fim quando o assunto é comunidade, contribuição e colaboração. Os discursos retratam a comunidade como o fim maior, enquanto comunidade é na verdade o meio mais rico para o florescimento de iniciativas livres e distribuídas. A comunidade é uma rede social e em si é ela só potencial. IMHO, a força que realmente vence a inércia é o fazer de cada um. Fazer por si mesmo. Não com um senso de individualismo ou egoísmo, mas fazer porque você deseja, gosta, acredita que deve. Não para um “bem maior” ou “bem comum”.

Essa confusão é natural e já aconteceu no #Horaextra do Rio, por exemplo. O encontro estava crescendo e sustentando o crescimento com a participação de cada vez mais gente interessante. Em certo momento surgiu uma preocupação com “não deixar aquilo morrer”, afinal estava tão bom! Por que não persistir e escalar? Com isso, iniciou-se uma discussão estranha que em essência, levava à uma institucionalização do #Horaextra. Discutimos muito e aprendemos que para o #Horaextra não morrer bastava que uma pessoa continuasse comparecendo. A continuidade só dependia do desejo individual de cada um. Felizmente concluímos que o #Horaextra é só um chopp e nada mais. Se morresse, seria porque as pessoas desejavam fazer outra coisa em vez de ir para aquele encontro e isso é ótimo.

Esse entendimento foi determinante para que outras iniciativas pudessem se inspirar naquele exemplo. No entanto, cada uma seguiria tocando seu barco independentemente, segundo os desejos individuais dos que empreendessem a nova iniciativa.

Um belo fruto disso foi o #HoraextraBH. É uma iniciativa fantástica com uma identidade toda própria, com a qual também me identifico muito. Tanto que já até cometi o equívoco de propor uma fusão entre as listas de discussões do Rio e de BH, o que não faz sentido algum. São duas iniciativas independentes e quem se identificar com ambas, basta se inscrever nas duas listas e interagir com a turma.

Mas para que eu falei tudo isso? Bom, uma coisa que admiro no Linus é que ele tem uma capacidade incrível de imaginar algo e transformar a sua realidade pautado em sua imaginação. Querer é o suficiente para ele se lançar em uma iniciativa, mesmo que não dê em nada. E o cara faz isso há mais de 20 anos.

O fato dele ter conduzido algumas iniciativas de forma pública e aberta ajudou todo um movimento a emergir entorno do Linux e tudo o mais. Mas é fundamental ter em mente que cada iniciativa emergiu por desejo de outros indivíduos que não ele. Isso é importante, pois ele não é e nem parece querer ser lider de ninguém. E isso choca as pessoas! Afinal, florestas inteiras são consumidas para propagandear estratégias coercitivas travestidas de “liderança” nas páginas da Você S.A. e similares.

Acho que isso é um ponto relevante que parece passar despercebido. A maioria das pessoas esperam dele o comportamento de um líder, rei, herói, pai, salvador. Mas o cara só segue seu desejo e pronto. Ele interage com um monte de gente? Sim, mas nos termos dele, e com aqueles cujos valores estão alinhados com os dele. Ouso dizer sinceramente, que ele parece tratar o Linux como “só um chopp”.

Qualquer um pode “tomar um chopp” com ele. As instruções são vastas. Mas se ele já disse explícitamente que não aceita pull requests pelo Github, porque as pessoas insistem? É direito dele trabalhar como deseja e se o outro discorda, é direito do outro se negar a contribuir. Normal. Não gostou? Faz um fork do projeto e sustenta seu fork! Simples, mas exige uma alta capacidade agir pelo seu desejo.

No entanto, quando acontecem esses episódios, rapidamente surgem os discursos “paz e amor”. Discursos furados, até meio socialistas, de igualdade e esforço em prol de um bem comum materializado em código. Discursos falsos sobre comunidade, pois uma comunidade que não respeita a liberdade do indivíduo não é comunidade. É outra coisa, é massa, público, platéia, audiência. É um passo para a conversa de “bem comum”, “bem maior” e a história está repleta de péssimos exemplos que aconteceram por um bem maior.

[]‘s, HB!

Além do conteúdo em si, o que sempre me interessou nos podcasts são as motivações que levam cada autor a se dedicar à empreitada. Este sempre foi o critério importante nas minhas preferências.

Há tempos atrás, o Rafael Lima decidiu converter seu tempo perdido no trânsito no podcast Voltando pra Casa. Sua motivação era extremamente simples e por isso o projeto era sensacional. A cada dia, ele simplesmente refletia em voz alta sobre o assunto que mais se destacou em sua mente agitada. Acompanhei cada episódio e ainda espero o Rafa abandonar a desculpa de que está trabalhando de mais para retomar o projeto.

Com um viés mais técnico, o Rafael Rosa Fu e o Carlos Brando criaram o Grokpodcast. Novamente, uma motivação simples regeu o desenvolvimento de um show fantástico: alimentar suas insaciáveis curiosidades. Cada episódio é uma verdadeira investigação por um tópico de interesse da dupla. Simples assim. Isso rendeu e ainda rende grandes horas de diversão e aprendizado para os ouvintes.

Recentemente, conheci o Og Maciel e seu Castalio Podcast. Ele me contactou querendo falar sobre Python e Django entre outros assuntos. Aceitei prontamente e fui explorar os episódios anteriores para conhecer melhor o seu projeto. Comecei ouvindo o bate-papo com o saudoso Gabriel Falcão, nosso Lenny Kravitz brasileiro, e simplesmente não consegui mais parar.

Quando iniciamos nossa conversa, fui logo perguntar qual era seu objetivo com o podcast. A resposta não podia ter sido mais clara: “Faço o podcast para conhecer melhor as pessoas que acompanho pela comunidade”. Uma motivação extremamente simples e intrínsica ao autor. Totalmente excelente!

A moral da história vale a reflexão. Todos os 3 podcasts são iniciativas despretenciosas, motivadas pelo desejo de quem se propõe o desafio. Tenho para mim, que este tipo de relação despretenciosa entre o empreendedor e o empreendimento contribui enormemente para sua evolução orgânica. Isso elimina a “mania de grandeza” e o “paradoxo do ovo ou a galinha”, onde a decisão de fazer um podcast pode alimentar hipóteses não validadas que inviabilizam o projeto. Coisas como “preciso me tornar um engenheiro de som”, ou “tenho que comprar um microfone próprio antes de começar”.

Neste artigo, podcast é apenas um exemplo. Mude o nome ou o tipo do projeto, mas recado continua simples e direto: “Faça! – o mais simples possível, apenas o essencial para ir adiante.”

[]‘s, HB!

A web é pautada em um protocolo (HTTP) simples para ser global. Esse protocolo, por sua vez, é um em uma multiplicidade de camadas (de rede). Sobre este protocolo, múltiplos clientes (browsers) interagem e co-existem. Paralelamente, múltiplas linguagens, com múltiplos paradigmas, em multi-plataformas, suportando múltiplos idiomas, são combinadas em sistemas que possuem múltiplas camadas e múltiplos elementos (imagens, css, js, html, etc). Ou seja, a web é um ecossistema! É plural por definição.

Essa angústia ou pretensão de encontrar o Santo Graal das ferramentas para resolver tudo, gera todo tipo de distorção sem noção no mercado. Gera desde sistemas com “vícios” e “cacoetes”, até “cargos” como “programador frontend” que não precisa saber nada além de html e javascript, ou “web designer” que é incapaz de interagir via html e css com o browser que é sua mídia alvo, ou “programador backend” que se limita à criar classes e fazer consultas em banco, mas não interage nem com a camada cliente, nem com a infraestrutura de distribuição da aplicação.

Tudo isso gera desperdícios incalculáveis, que inviabilizam qualquer desenvolvimento sustentável e ancoram os profissionais de tecnologia, que são profissionais criativos em essência, ao status de commodities.

Já ouvi algumas pessoas argumentarem: “Blasfêmia! Isso é loucura! Não se faz uma equipe só com generalistas. É preciso se especializar!”

Como diria o Rei Leônidas, loucura é contratar um “especialista” que não tenha um conhecimento geral sólido o suficiente para também ser considerado um “generalista”. Esse tipo de profissional é incapaz de tomar decisões pautadas no contexto do projeto. Esse cara vai sempre ficar com foco na tecnologia e vai martelar o problema para que ele encaixe de qualquer jeito na solução que ele tem para oferecer.

Quem trabalha com web, não precisa saber tudo (isso é impossível). Mas deve ter disposição (e curiosidade) para aprender tudo!

[]‘s, HB!

No entanto, ontem nós não nos reunimos para programar, mas sim para apreciar a defesa de tese de graduação do nosso amigo Bernardo Fontes, cujo título eu repeti no título deste post.

A tese ficou bastante rica, relacionando a dinâmica do Coding Dojo com as teorias construtivistas e de aprendizagem baseada em problemas, além de expor os elementos do Dojo como ferramentas para o ensino de programação.

Para poder analisar o Dojo, foi preciso falar muito sobre sua origem e história. Esta parte pareceu um grande flashback. Muitos dos personagens da história estavam ali, sentados na platéia. Platéia que permaneceu atenta o tempo inteiro, refletindo e lembrando as inúmeras pequenas ações despretensiosas que realizaram.

Como, diz a terceira lei de Clarke, qualquer tecnologia suficientemente avançada é indistinguível de magia. Seguindo esta linha, afirmo que existem tecnologias sociais e humanas extremamente avançadas no Coding Dojo. Ainda pode ser difícil de explicar como funcionam, mas seus efeitos positivos são fáceis de serem percebidos.

São estas tecnologias que vêm nos ajudando a evoluir a cada sessão, tanto pessoalmente quanto tecnicamente. Enquanto no passado nós nos limitávamos à problemas lúdicos, agora também implementamos algoritmos clássicos. Tudo dentro da regra, com TDD, baby-steps, código coletivo e todo o resto.

Parabéns, Bernardo, pela realização. Tenho certeza de que este trabalho vai inspirar muitas outras pessoas, espalhando os benefícios do Coding Dojo para muitos outros.

Se você ficou curioso ou interessado, não pense duas vezes. Inscreva-se agora na lista de discussão do Dojorio e curta a página no Facebook. Não importa se você é de outro estado ou até de outro país. Simplesmente participe!

[]‘s, HB!

A turma da Dekode teve o prazer de participar do beta a convite do nosso amigo Pedro Belo. A experiência nos permitiu comprovar o que já sabíamos: publicar aplicações no Heroku é realmente fácil. Sem contar que a plataforma é grátis para quem não precisa de uma infraestrutura muito forte, com opções pagas de escalabilidade para todos os gostos. O resultado disso tudo é que agora usaremos o Heroku nas próximas turmas do Welcome to the Django.

Desde a primeira turma do curso, usávamos uma ferramenta própria para deploy, carinhosamente apelidada de Herike: o Heroku do Henrique. Inspirada pela facilidade do Heroku, ela permitia aos alunos publicarem suas aplicações com um simples git push. A grande limitação desta ferramenta era de só estar disponível para os alunos durante o período do curso. Agora, usando o Heroku, os alunos vão ganhar experiência com um serviço de hospedagem que vão poder continuar usando mesmo depois que o curso acabar.

Esta novidade já acontecerá nas aulas da próxima turma, que começam em novembro. Se você quer aprender Django e a publicar suas aplicações no Heroku, aproveite a oportunidade e garanta a sua vaga no curso Welcome to the Django.

[]’s, HB!

As palestras foram ótimas, os convidados, melhores ainda, mas o clímax do evento, foram as inúmeras conversas e trocas de idéias com velhos e novos amigos dos quatro cantos do Brasil. Foi assim, em um ambiente inclusivo e descontraído, que a PythonBrasil[7] ficou marcada como um evento totalmente excelente.

Para a tripulação da Dekode, o evento foi ainda mais especial. Além de ser uma PythonBrasil, foi o primeiro evento onde todos nós pudemos contribuir com a comunidade, fazendo o que a Dekode se propõe: compartilhar conhecimento.

O Thiago Garcia compartilhou a sua experiência e explicou para o pessoal tudo que uma faculdade precisa: Python, Dojo e Choppada. O Flávio Amieiro abordou benchmarking de servidores, sem fotos de alpinistas, perguntando Seu servidor aguenta a pressão? O Bernardo Fontes fez um braindump sobre seu tema favorito: Testando Aplicações Django: Quando, Como e Onde?. E o Henrique Bastos compartilhou um pouco das nossas estratégias e experiências em Missões Resgate com Django, além de apresentar sua visão sobre comunidade e o processo de Community Overflow.

A organização do evento foi impecável e foi muito bom poder presenciar mais um show da comunidade.py. Ano que vem, esperamos que os cariocas consigam trazer todo mundo mais pra perto das nossas praias, pra repetir mais essa vez a nossa história, com muita diversão, cerveja e ideias marcantes.

[]’s, LR!

——————–

Já que ainda estamos no espírito de compartilhamento de ideias, quem tiver alguma apresentação e quiser compartilhar, dê o upload, de preferência pra um SlideShare da vida, e coloque o link nos comentários. Valeu!

No final do ano passado eu lancei o curso Welcome to the Django com o objetivo de compartilhar minha experiência e fascínio pelo ecossistema Django e Python.

O curso foi super bem recebido pela comunidade. Cerca de 200 desenvolvedores foram treinados em quatro turmas, e as inscrições para a 5ª turma já estão com a corda toda.

Partindo desta experiência, logo no início do ano, decidi me dedicar profissionalmente ao desenvolvimento de iniciativas que democratizassem o acesso aos benefícios do desenvolvimento sustentável de software. Foi assim que surgiu a Dekode, uma empresa com a filosofia de não apenas desenvolver melhores softwares, mas também compartilhar o conhecimento sobre todo o processo.

Para apoiar esta iniciativa, reuni uma super tripulação que compartilha a crença de que é preciso desenvolver pessoas para que elas desenvolvam grandes softwares. Estas feras são Bernardo Fontes, Flávio Amieiro e Thiago Garcia.

Trabalhamos bastante aprimorando o curso online Welcome to the Django e estamos preparando novos cursos a partir dos inúmeros feedbacks dos nossos alunos. Além disso, estamos auxiliando outros profissionais talentosos a condensarem seus conhecimentos em treinamentos relevantes para a comunidade e o mercado.

Criamos o Imersão Django que é um treinamento in-company com objetivo de capacitar desenvolvedores em seu próprio ambiente de trabalho. O processo de imersão trabalha a assimilação do conhecimento teórico através da experiência prática. Deste modo, durante todo o treinamento, são trabalhados problemas reais onde serão aplicados os conhecimentos adquiridos, aprimorando as competências da equipe no próprio contexto da empresa.

Temos feito consultorias, mentoring e coaching, tanto in-house quanto remoto, para ajudar nossos clientes a conquistar seus objetivos. Nesse processo a gente acaba trabalhando todos os aspectos do desenvolvimento de software, passando pelo código, por ferramentas, arquitetura, processos, commit pattern, integração continua, testes automatizados, etc.

Como podem ver, temos trabalhado em iniciativas bem interessantes. Mas não queremos nos limitar a um ou outro modelo. Queremos sempre nos manter abertos ao diálogo para melhor servirmos nossos clientes e cada vez mais desenvolvermos nossa vocação. Nosso maior talento é resolver problemas ligados à tecnologia e nosso maior desejo é compartilhar o conhecimento criado a cada dia.

Então, o que você achou? Você tem um problema que precisa de atenção? Compartilhe nos comentários abaixo ou entre em contato conosco. Será um prazer descobrir como ajudar você!

[]‘s, HB!

Este post é um pouco grande, mas vale a leitura para você entender as razões que nos levaram a cancelar o evento deste ano.

Em 2009, eu e o Guilherme Chapiewski, com o apoio de toda a comunidade, desbravamos a iniciativa de fazer um grande evento. Foi uma experiência extremamente enriquecedora e gratificante.

Já em 2010, o bastão foi passado e a condução do evento ficou com nossos amigos André Fonseca, Ramon Bispo, Rodrigo Pinto e Sylvestre Mergulhão. O evento foi um sucesso ainda maior que o do ano anterior.

Com uma seqüência tão bem sucedida, seria natural que as expectativas para 2011 fossem ainda maiores. Recebemos muitos emails de pessoas dos quatro cantos do Brasil afirmando o desejo de participar do evento.

Em 2011, trabalhamos para organizá-lo, mas a época do ano colidia com o Rock in Rio. Muita gente pode pensar: Legal! Dá pra ir no Dev in Rio e partir para o Rock in Rio. No início, pensamos assim, mas na prática a teoria é outra.

A colisão de datas se juntou com alguns outros problemas que nos levaram à decisão de darmos um passo para trás e cancelar o evento de 2011. Vou compartilhar alguns dos pontos chaves que nos levaram a esta decisão.

O primeiro ponto é que existe um grande número de pessoas que saem de suas casas em outros estados, encaram mais de 24 horas de viagem de ônibus só para participar do Dev in Rio. Muitos são estudantes, ou recém chegados ao mercado de trabalho. A participação destas pessoas é fundamental. São elas que pegam as idéias e conceitos discutidos no evento e inovam realizando inúmeras iniciativas em suas cidades.

Estas pessoas, naturalmente, precisam de algum suporte de infra-estrutura. Com o Rock in Rio colidindo com a data do Dev in Rio, as passagens começaram a subir de preço e a sumir e os hotéis foram ficando lotados. Ou seja, setembro tornou-se um mês caro para visitar o Rio de Janeiro.

O segundo ponto é que o Dev in Rio 2011 contava com o apoio dos nossos amigos da Associação Python Brasil e da Python Software Foundation, que aproveitando a proximidade com as datas dos eventos PythonBrasil[7] e PyAr, apoiariam também o Dev in Rio. Este apoio era bastante significativo e por isso tentamos ao máximo manter a data do evento.

O terceiro ponto: mesmo com todo o problema que teríamos com logística, ainda assim, tentamos mudar a data do evento. Neste aspecto, vale ressaltar a dedicação do Ramon Bispo para tentar ajustar a logística e do André Fonseca que fez um trabalho incrível contatando os patrocinadores.

No entanto, o esforço para este tipo de reorganização seria muito grande. O Dev in Rio é um evento tocado por voluntários. Coincidentemente, neste ano, muitos de nós estamos experimentando grandes mudanças em nossas vidas. São novas empresas, novos rumos em carreiras, novos membros nas famílias, enfim, coisas normais da vida que nos levam à escolhas difíceis, porém necessárias.

Mas então, o que tudo isso quer dizer? Acabou o Dev in Rio? Claro que não! O Dev in Rio, bem como muitas outras iniciativas, nasceu despretensiosamente no melhor estilo Small Acts e tem servido a comunidade da melhor maneira possível. Certamente aprendemos muita coisa nestes 3 anos de estrada e isso nos levará aos passos naturais: revisar, refatorar e fazer o deploy de algo melhor.

Sabemos que muita gente estava super animada para a edição de 2011. Ficamos realmente felizes em contar com o apoio de vocês e tristes por não podermos atender às suas expectativas neste ano.

Nas próximas iniciativas do evento, queremos envolvê-los mais. Afinal, o Dev in Rio é para os Desenvolvedores! Se você quiser ficar por dentro das próximas iniciativas para poder apoiá-las ou participar, nos envie os seus dados para contato.

Mais uma vez, muitíssimo obrigado à todos pelo apoio.

Um grande abraço!

Aproveitando o tema interessante, consultei a comunidade pelo Twitter para poder apimentar mais a discussão. As respostas foram bem legais e servem como boas referências para quem quer estudar sobre o assunto.

Deixo registrado aqui o meu muito obrigado à todos que contribuíram.

Qual a melhor referência sobre a Linguagem Javascript que você conhece?

• Mozilla Developer Network
• JavaScript: The Definitive Guide – David Flanagan
• JavaScript: The Good Parts – Douglas Crockford
• Javascript Guia do Programador – Maujor
• Pro JavaScript Techniques – John Resig
• Professional Javascript for Web Developers – Nicholas Zakas
• W3Schools

Qual Framework Javascript você mais usa em seus projetos?

• JQuery
• Head.js
• Modernizr
• ExtJS
• mootools
• Require.js

[]‘s, HB!

Como se tudo isso não bastasse, ainda contaremos com a presença de grandes nomes da comunidade internacional, como:

• Alan Runyan – Co-fundador do Plone e Presidente da Enfold Systems;
• Gustavo Niemeyer – Líder Técnico da Canonical;
• Jim Fulton – Diretor de Tecnologia da Zope Corp;
• Maciej Fijalkowski – Core Developer do revolucionário Pypy;
• Steve Holden – Presidente da Python Software Foundation;
• Wesley Chun – Evangelista de Software do Google ligado ao Google App Engine;

Independente da sua idade ou experiência com tecnologia, a PythonBrasil[7] é definitivamente o lugar onde você deve estar entre 29 de setembro e 1º de outubro. Esta é uma excelente oportunidade para você expandir seus conhecimentos e principalmente, participar da comunidade que é uma das mais diversas e abrangentes do mundo da tecnologia.

Além disso, não deixe de compartilhar o que você sabe! Vá ao evento disposto à conhecer muita gente boa e trocar muitas idéias sobre tecnologia. A PythonBrasil[7] será o espaço perfeito para colaborar e criar novos conhecimentos.

Vejo você lá!

[]‘s, HB!