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!

O perfil “Geração X” é, digamos, 1.0. Este perfil provavelmente se aplica a bastante gente com raízes nos pensamentos da década de 80. Essa turma tem uma característica fortemente analítica e linear. É a galera do downsize e da maximização local desconectada dos “impactos” no ambiente à sua volta. Esta turma olha movimentos como o manifesto ágil ou similares e afirma: “No mundo real isso não funciona!”

A “Geração Y” é a mais famosa. Todo mundo está falando dessa turma 2.0. Coincidência ou não, o termo “Geração Y” em inglês é “Y Generation”. A letra “Y” em inglês pronuncia-se “Why”, que significa “Por quê?”. São, em sua essência, questionadores ou rebeldes. Dessa galera surge muita coisa nova e a internet tem dado voz às suas visões.

A “Geração Z” é Zen! Suas visões e principalmente suas ações, transcendem o atual. Ainda é muito difícil alcançar o pensamento desta turma 3.0. É gente com pensamento holístico e sistêmico. Gente que realiza feitos como o descrito no vídeo abaixo:

Pessoalmente, estou bastante curioso para ver mais ações da Geração Z. Principalmente, estou ansioso para ver o que vai surgir enquanto as Gerações Y e Z trabalham cada vez mais juntas! Quanto mais ativas as pessoas se tornarem, quanto mais elas se expressarem e transformarem o seu ambiente, mais cedo estas classificações darão lugar à unificação: a Geração H(ack). Este é apenas o começo…

Apesar do texto tendencioso, meu objetivo aqui não é comparar diretamente uma geração com a outra, mas contextualizar o comportamento de cada geração com o momento histórico que vivemos. É minha opinião sim, que o pensamento da “Geração X” não atende aos anseios da sociedade de hoje; a “Geração Y” precisa fazer mais e se posicionar mais claramente, deixando de ser objeto de estudo das gerações anteriores que precisam entendê-los e enquadrá-los; e a “Geração Z” precisa ser cada vez mais atuante para dar exemplos e criar implementações de referência para que mais e mais pessoas tenham acesso a novos paradigmas.

[]‘s, HB!

Esses dias, um grande amigo me ligou entusiasmado com a oportunidade para desenvolver um sistema. Para ele que sempre desenvolveu sua carreira tradicionalmente, esta seria uma ótima oportunidade de “matar dois coelhos com uma caixa d’água só”: Experimentar um novo modelo de trabalho e usar tudo o que aprendeu no curso Welcome to the Django à serviço de alguém.

Conversamos bastante até que ele lançou a grande pergunta: Como calcular o preço do trabalho? Esta é uma pergunta sem resposta fácil, mas vou compartilhar com você a visão que compartilhei com ele.

Determinar preço é um problema não linear. Não existe uma fórmula direta para responder à esta questão. Realmente, cada caso é um caso.

Mas não se desespere, não vamos cair no “tudo é relativo”! Existem estratégias para ajudá-lo.

A forma mais simples para se ter uma noção sobre preço, é analisar os custos. O objetivo desta análise é estimar o limite inferior do preço, ou seja, aquele valor mínimo necessário para viabilizar o negócio sem que você leve prejuízo.

Suponha que sua hora de trabalho custe R$ 50,00 e você estime que levará cerca de 100 horas de trabalho para desenvolver o sistema. Com estas duas variáveis estabelecidas, multiplicando o seu valor-hora pela quantidade de horas estimada resulta no preço de R$ 5.000,00.

Esta é uma análise pautada no custo. Mas é preciso analisar o valor também!

Vamos ao exemplo. Imagine que você desenvolva um sistema que resolve um problema qualquer no cliente. Novamente, você estimou que seriam 100 horas de trabalho para desenvolvê-lo e você cobra R$ 50,00 por hora. Outra vez, o custo de desenvolvimento do sistema é de R$ 5.000,00.

Entretanto, ao implantar este sistema, o seu cliente vai economizar cerca de 10% do tempo de todos os funcionários da empresa. Sabendo disso, qual o valor que este sistema gera? Isso mesmo! Muita gente fala de gerar valor para o cliente, mas poucos sabem o que isso significa realmente.

No nosso exemplo, se o seu cliente tem uma folha de pagamento custando R$ 500.000,00 por mês, economizar 10% disso significa deixar de gastar R$ 50.000,00 à cada mês. Como a empresa do seu cliente está em franca operação, é razoável considerar que ela funcionará por pelo menos mais um ano. Desta forma, um ano após implantar o sistema que você desenvolveu, seu cliente terá economizado R$ 600.000,00.

Diante deste cenário, você acha que cobrar R$ 50.000,00 para desenvolver o sistema seria absurdo? Você estaria cobrando menos de 10% do valor gerado pelo sistema em um ano de operação. Além disso, se considerarmos que o seu cliente lhe pagou na implantação do sistema, em apenas um mês ele terá recuperado o investimento.

Os exemplos acima são um tanto simplistas, mas servem bem para mostrar a diferença entre a visão de custo e a visão de valor. Observe que não estamos entrando no mérito de discutir escopo aberto versus escopo fechado e muitos outros fatores que podem influenciar o preço, como por exemplo a percepção de valor, concorrência no mercado, etc.

O recado final é que cabe à você correr atrás dos fatos e informações para estabelecer as relações, construir o cenário e determinar quanto vale o seu trabalho.

[]‘s, HB!