Recentemente eu fiz um post falando sobre os processos que estou vivendo na InfoMarka. Tudo ainda está muito embrionário e estamos finalizando o nosso primeiro Sprint. Já avançamos bastante na forma com que nos comunicamos e o quadro com as tarefas está sendo bastante expressivo já que não podemos estar juntos todo dia. Tanto é que já temos desenhos, nomes e rabiscos, tudo com o intuito de tornar a informação dele digerível de maneira mais rápida e simples. Enfim, esse é todo um assunto para um post que está aqui de rascunho.
Esse post tem o intuito de fazer propaganda e só. Mas não propaganda da empresa ou do DojoRio. Mas sim, das palestras que acontecerão na semana que vem na UFF. Em um primeiro momento, o Magno Mathias e eu iríamos fazer as nossas apresentações somente para a turma de Informática I. Conversando com os professores, conseguimos reservar o auditório da Engenharia e agora as palestras vão rolar para todo o curso de Ciência da Computação! Eu irei falar sobre o DojoRio – sim é aquela minha apresentação de sempre, mas ela sofreu uma grande refatoração depois de passar nos testes que fiz com ela =) – e o Magno irá falar sobre o processo que está acontecendo na InfoMarka e as experiências que ele e toda a equipe estão adquirindo. Se bobear, eu também dou um pitaco na apresentação dele. Então, vamos lá para os dados:
Quando? As palestras vão rolar na próxima segunda-feira, dia 30 de Agosto, às 11:00.
Onde? Auditório da Engenharia – Bloco D – Campus da Praia Vermelha, UFF
Aqui segue uma descrição das palestras que nós encaminhamos para o Instituto de Computação.
- InfoMarka – Pensando Além do Que Você Imagina
- A InfoMarka é uma empresa onde existem pessoas, projetos e clientes como qualquer outra no mercado. O intuito desta palestra é mostrar a empresa para o maior número possível de estudantes, e até mesmo de professores, mostrando sua estrutura e funcionamento e estimular o instinto empreendedor nos estudantes.
- Magno Mathias – Graduando em Ciência da Computação pela UFF. Tem um grande interesse pelas áreas de empreendedorismo e administração dentro de uma empresa. Foi um dos semi-finalistas do Desafio Sebrae e atualmente atua como Presidente da Infomarka com o intuito de aprender e ensinar em conjunto com todos os membros da empresa.
- Aprenda a Programar Direito. Pergunte-me: “Como?”
- Aprender a programar é algo que vai muito além das quatro paredes e do quadro de giz branco das salas de aula. A apresentação tem o intuito de mostrar o que é Coding Dojo, uma maneira alternativa e extremamente eficaz de tratar o ensino de programação, e explicar o porquê de ele funcionar tão bem através de seus processos, ferramentas e o foco nas pessoas.
- Bernardo Fontes – Graduando em Ciência da Computação pela UFF. Membro atuante das diversas comunidades de desenvolvimento do Rio de Janeiro como o #horaextra, DojoRio, ForkinRio e PythOnRio. Entusiasta de metodologias ágeis e evangelizador das mesmas no ambiente acadêmico. Utiliza Python como linguagem principal de seus projetos. É estagiário da Myfreecomm e coordena um projeto pela InfoMarka, empresa júnior do curso de Ciência da Computação da UFF.
Na semana que vem falo como foi e, se tudo der certo, coloco uns vídeos aqui. Espero ver vocês lá!
Essa semana o meu Arduino que o Álvaro Justen havia encomendado chegou. Para quem não sabe, o Arduino é um micro-controlador open-source. Isso significa que, entre outras questões, todas as suas especificações são abertas e, se você quiser, você pode até não comprar um e montar um na mão! O Arduino pode ser usado para fazer várias brincadeiras com eletrônica e até robótica, como é o caso do Turiquinhas.
Comprei o Arduino porque sempre achei esse lance de eletrônica bem interessante, mas na UFF isso nunca foi ministrado de maneira interessante (até aqui nenhuma novidade…). Para começar a brincar, o Álvaro e eu resolvemos fazer um Hack n’ Beer relâmpago na sexta-feira a noite. Claro que um encontro de amigos com cerveja e comida sempre gera bate-papo. Então, antes de começarmos a brincar trocamos algumas figurinhas sobre a comunidade Python do Rio de Janeiro e do Brasil, sobre o trabalho e sobre o ensino de programação nos cursos de Engenharia.
Como esse período estou enrolado em muitas tarefas como o DojoRio, meu projeto final, a Myfreecomm e a InfoMarka, quis muito fazer algo logo com meu novo brinquedo antes que a agenda me sufoque. Então, resolvemos começar algum projetinho com o Arduino. Apesar de já ter participado de alguns encontros sobre a ferramenta, estava começando, então resolvemos fazer algo simples. A ideia original era simplesmente integrar o Dojotools com o Arduino. Para quem não sabe, o Dojotools e uma ferramenta criada pelo Flávio Amieiro e nós usamos durante as sessões do DojoRio para termos uma resposta mais rápida e simples com a execução dos testes.
A intenção era trazer o que nós chamamos de sinal – vermelho quando o código não está passando e verde caso contrário – para um meio físico. Então, conectamos o Arduino e usamos um LED de quatro pinos e bem potente que define sua cor por RGB. Dado que conseguimos criar as cores do sinal, não satisfeitos, resolvemos colocar uns sons! Então, agora se o piloto quebrar algum teste, além do sinal ficar vermelho ele ouve uns apitos de alerta só para ficar esperto. Além disso, quando acaba o seu tempo toca uma buzina. Fazer isso tudo não foi nada complexo por dois motivos. Primeiro porque o código do Dojotools estava bem organizado (espero não ter bagunçado) e segundo porque o conhecimento do Álvaro com o Arduino agilizou o processo.
Alguém pode pensar que isso não vá ajudar muito nas sessões de Dojo que fazemos, mas eu penso o contrário. O fato mais legal é que vai trazer o conceito do sinal, que é abstrato, para o mundo real ao vermos algo piscando e apitando. Segundo, vai ser algo que vai tornar o Dojo mais divertido. Afinal, vai ser engraçado ver a reação das pessoas ao quebrarem o código e fazerem um speaker ficar buzinando no seu ouvido. Assim, acho que são mais dois atrativos para o Dojo que podem ajudar principalmente quem é novato a entender melhor o processo dos testes.
Para não ficar tendo que executar o .py toda hora que eu quisesse rodar o Dojotoosl, eu criei um setup.py para poder instalá-lo no sistema. Entretanto, ainda não sei se todos os requisitos necessários estão no install_requireses. Para os que tiverem mais ideias ou então quererem dar uma olhada no código ou então querem ser cobaias para o setup.py, eu fiz este fork do Dojotools. Sintam-se a vontade para comentar, mudar, alterar e também a começar a brincar com o Arduino!
Faz algum tempo que comecei a usar o Vim. Para quem não sabe o Vim é uma derivação do Vi. Ele é um clone bastante fiel, mas possui algumas funcionalidades a mais. Por curiosidade, o nome Vim surgiu como “Vi iMitator”, mas depois de um tempo as pessoas começaram a chamá-lo de “Vi iMproved”.
O Vim é um editor de texto bastante poderoso que possui diversos modos de utilização. Entre eles temos o modo visual, o de edição e o de linha de comando. Saber combinar esses diversos modos e as operações que eles viabilizam agilizou muito a minha maneira de escrever código.
Outra característica do Vim é a de ele ser bastante configurável de acordo com as suas preferências. Você pode personalizar desde configurações de fontes e cor até o uso de plugins. Existem vários exemplos de configurações e plugins na Internet como o NERDTree e o Darkspectrum. Para configurar o seu Vim da maneira que você prefere basta você editar o arquivo .vimrc que fica na sua home.
Em Python, para debugarmos o código existe o pdb e o ipdb. A diferença entre os dois é que o segundo, ao invés de abrir o console Python para debugar o código abre uma sessão no IPython para fazê-lo. Para criar um breakpoint no código, sempre temos que colocar a seguinte linha de código onde queremos parar:
import ipdb; idpb.set_trace()
Ficar repetindo isso 20000 vezes no código para debugar é um pé no saco. Então, resolvi criar um scrip para o Vim que fizesse isso para mim e poupasse meu tempo. Dei uma pesquisada no Google e achei um cara que já havia feito algo parecido, entretanto, o código estava bem estranho e eu não me permiti deixar aquele código no meu .vimrc. Peguei o código, refatorei e botei a função de remover breakpoints para funcionar, coisa que não acontecia antes. O resultado está nesse guist que está na minha conta do Github:
python << EOF
import vim
import re
ipdb_breakpoint = 'import ipdb; ipdb.set_trace()'
def set_breakpoint():
breakpoint_line = int(vim.eval('line(".")')) - 1
current_line = vim.current.line
white_spaces = re.search('^(\s*)', current_line).group(1)
vim.current.buffer.append(white_spaces + ipdb_breakpoint, breakpoint_line)
vim.command('map <C-I> :py set_breakpoint()<cr>')
def remove_breakpoints():
op = 'g/^.*%s.*/d' % ipdb_breakpoint
vim.command(op)
vim.command('map <C-P> :py remove_breakpoints()<cr>')
EOF
Foi bastante interessante porque não conhecia esse módulo do Python para escrever scripts para o Vim. Para usar esse script para usar o ipdb basta copiar o código e colar no seu .vimrc. A partir de então o comando Control + I insere um breakpoint na linha acima da linha correte e o comando Control + P limpa todos os breakpoints que estão no arquivo. Espero que seja de bom uso!
Atualmente estou envolvido em vários projetos pessoais. Com a volta às aulas na UFF, esse número conseguiu crescer ainda mais. De todos, o que mais está me animando é a InfoMarka. A InfoMarka é a empresa júnior do curso de Ciência da Computação da UFF. Em um passado recente, a empresa estava numa situação em que o futuro dela não era nada animador. Hoje, uma nova diretoria assumiu com o intuito de tornar a InfoMarka uma referência no que diz respeito a empresas júnior.
Tudo bem, mas o que isso tem a ver comigo? Bem, essa nova diretoria me convidou para coordenar um projeto para uma outra empresa júnior da UFF, a Meta Consultoria. Aceitei a proposta por eles terem aceitado as minhas “exigências” de ter autonomia para ter a equipe que eu quisesse montar – com pessoas que eu confie e não com pessoas que algum processo seletivo non-sense me empurrasse – e também usar minhas metodologias. No caso estou usando um Scrum adaptado. Sobre tecnologia, esse projeto vai ser em Django porque vamos precisar basicamente usar o seu admin para resolver nossos problemas. Entretanto, não é sobre o projeto que quero falar, mas sim sobre as pessoas.
Como eu disse, estamos trabalhando com Scrum. Minha equipe é composta por 5 pessoas onde nenhuma delas já teve experiência com o Scrum ou qualquer outra metodologia ágil. O mais próximo que eles chegaram foram com as experiências que eles tiveram com os processos existentes do Dojo. Entretanto, o que acontece no Dojo não é igual ao uso de metodologias ágeis no dia-a-dia. Fora isso, o cliente também não estava familiarizado com a metodologia e os processos. Portanto, esse terreno que estou pisando está totalmente cru.
O fato de eu estar me relacionando com outros universitários ajuda muito a implantação pois não existem as barreiras e preconceitos que os gerentes ban-ban-bans das empresas possuem com a metodologia ágil. Consegui perceber isso somente na apresentação que fiz tanto para o cliente quanto para a equipe sobre métodos ágeis e sobre como desenvolver software sem pensar em suicídio. Logo após a apresentação, a animação das pessoas em vivenciar aquilo tudo era muito grande e pude comprovar ontem, durante nossa primeira reunião de planning, o quão diferente essa cultura é da convencional.
Durante toda a reunião, os dois lados, tanto da equipe quanto do cliente por várias vezes começavam a querer entrar a fundo em pontos críticos e muito técnicos do projeto. Por várias vezes me vi fazendo o papel de ter que controlar o pessoal para não entrarem em problemas técnicos. Esclarecer para a equipe que nós devemos ouvir o cliente e esclarecer para o cliente que queremos saber somente os problema dele e o que ele quer resolver com o software foi essencial.
O mais interessante é como as pessoas se moldam ao processo rapidamente. Depois de alguns alertas, tanto o cliente quando a equipe entenderam o propósito de estarmos ali. Entenderam que o propósito não era definir todo o sistema nos mínimos detalhes, mas sim uma visão dos requisitos iniciais e que estes não definitivos. Depois dessa reunião conjunta, tivemos a parte do cliente priorizar o backlog. Para mim, essa é a parte que a metodologia faz o cliente se sentir especial.
Não é raro encontrarmos projetos que lidam com o cliente com a visão de que ele tem que estar relaxando e não tem que ter “apurrinhação” com o projeto. A visão é até certa, o problema é o conceito de “apurrinhação”. Quando pensamos em apurrinhar como perguntar e envolver o cliente no processo, cometemos um grande erro que é o de assumir que o cliente não está interessado em como o software cresce. Agora, vamos pensar direito. O cliente investe dinheiro ali, então, será mesmo que ele não está interessado naquilo? Você, como pessoa, gasta o seu dinheiro em algo que você tenha interesse e simplesmente não acompanha o investimento depois? Espero que não. Então, com o cliente dizendo o que quer e depois priorizando o que quer, ele se vê como necessário ao processo e percebe que todo o processo está girando em função dele. O resultado é a satisfação por sentir-se necessário ao produto e contribuidor para o desenvolvimento do seu próprio produto! Toda essa visão foi passada para mim depois pelo próprio cliente e pude comprovar pelo depoimento dele que estar envolvido é importante também para ele.
Por sua vez, temos também a equipe. A decomposição em tarefas das histórias é um momento em que toda a equipe cria um conhecimento técnico do problema. Cada indivíduo se sente mais confortável com o trabalho que está por vir porque ele participou da discussão do que deve ou não deve ser feito para escrevermos aquela história. Mas, a parte que mais se mostrou interessante é a parte da estimativa e de montar o quadro do sprint.
Na estimativa, foi surpreendente a rápida concepção de esforço que a equipe definiu. Já na terceira história a estimativa de todos já estava bastante consistente. No momento de montarmos o quadro, propus uma brincadeira para mudarmos o nome das colunas de a fazer / fazendo / feito. O mais interessante disso é que as pessoas começam a brincar com aquilo e perdem a noção de que o que estão fazendo é o trabalho do dia-a-dia. Acho que isso é essencial em qualquer equipe e acredito que a facilidade em moldar os métodos ágeis para suas necessidades e para o formato da sua equipe torna isso ainda mais possível. Só por curiosidade, nosso quadro agora tem 3 colunas com textos e desenhos. Os desenhos não tenho como colocar aqui, mas os textos são Débito / Loading… / R.I.P. #FTW!
No final, vimos que todos estavam bastante satisfeitos com o processo e a animação para começar a meter a mão na massa era grande. O que mais me interessa nos métodos ágeis é o fato das pessoas estarem se comunicando o tempo todo. Essa comunicação é o que viabiliza a possibilidade de atingir uma entropia dentro da equipe em que torne o trabalho prazeroso e o alto rendimento se dê sem muitos custos.
Pretendo continuar relatando minhas experiências com esse processo na InfoMarka aqui no blog. Faço isso por dois motivos, primeiro para passar algo para vocês e segundo para consolidar na minha cabeça a minha vivência no processo. Sempre vivi os métodos ágeis, mas nunca tive chance de aplicar. Essa se mostrou ser uma oportunidade de ouro da qual desejo retirar o máximo de experiência possível. Então, o máximo de experiência que eu puder tirar é o máximo que eu poderei passar para vocês. Então, continuem acompanhando os próximos capítulos.
Durante essa semana estive participando do 11º Fórum Internacional do Software Livre. Para os que não foram, este post serve para explicar o que rolou durante o evento e o que foi bom. Mas, se você está pensando em ler algo sobre as palestras, sobre os estandes, sobre os brindes e tudo que envolve um evento deste nível, você pode parar por aqui. Porque o melhor do FISL não foram as palestras ou o que aconteceu dentro da PUCRS. O melhor do FISL foram as pessoas e o propósito de elas estarem unidas. Falo, principalmente, pelo barulho que o pessoal do #horaextra fez lá dentro.
O FISL começou com o pé direto com um encontro comunitário do pessoal do DojoRio. Não foi palestra, foi uma grande conversa em que nós pudemos apresentar para os presentes não só o DojoRio, mas também todos os outros grupos que temos aqui no Rio de Janeiro. É engraçado ver a reação das pessoas ao serem apresentadas aos grupos do Rio de Janeiro porque elas sempre entendem as nossas mensagens e, na hora, já começam a pensar como podem fazer os seus Small Acts. Isso rola principalmente com o Dojo.
Falando em Dojo, acho que essa foi a sensação do evento. Tivemos no mínimo 3 palestras da galera que falavam sobre Coding Dojo e sobre o DojoRio. Então, o pessoal ficou bastante aguçado com a ideia. Para satisfazer a necessidade do pessoal e apresentá-los ao Dojo na prática foi adotada uma tática de guerrilha. O engajamento da galera foi simplesmente sensacional e, trocando uma ideia aqui e ali, conseguimos montar 3 sessões de Dojo durante o FISL! Duas dentro de estandes de expositores e uma no telão principal do evento! Surreal!
Enquando isso, outra frente de trabalho foi com a galera do Arduino. Vale uma menção honrosa ao Álvaro Justen que, além de campeão no número de palestras, fez uma excelente para uma plateia lotada, inclusive com a presença do Jon ‘Maddog’ Hall. Dois dias depois da palestra, ele e o Flávio Amieiro tocaram um OpenSpace em que foi mostrado na prática o tal do Arduino.
Nesse FISL nós tivemos um espaço do #horaextra, onde eu passei a maior parte do tempo. Várias pessoas vinham perguntar o que eram aqueles papéis colados ali e o que era o tal do #horaextra. A gente explicava e convidava o pessoal a vir socializar com a gente. O resultado disso eram os bares superlotados com as pessoas que a gente conhecia durante o evento. Por nossas mesas passaram americanos, russos, gaúchos, gente de Curitiba, São Paulo, Salvador e até de Belém. Todos somente com o intuito de sentar, trocar ideia e fazer amigos.
Agora, o frenesi do FISL se deu no desafio que o pessoal propôs. Lançar uma aplicação web por dia de evento! Para isso, usamos os restaurantes, lanchonetes e até estandes abandonados como um grande headquarter onde nós desenvolvíamos e nos divertíamos. Superamos nossas próprias metas e colocamos 6 aplicativos no ar. São eles:
Eu, particularmente, participei bastante do #deressaca e a experiência no desenvolvimento dessa aplicação foi rica em tantos pontos diferentes que, ainda essa semana, farei um post somente sobre isso. Não conseguimos fazer o 100% do que queríamos do #deressaca, mas exatamente pela experiência que tive, ela se tornou o grande marco do FISL para mim.
Sobre as palestras? Bem, fui em algumas… Valem ser citadas a do Henrique Bastos que contou a história que rola com vários estudantes de computação do Brasil e a do bundão apresentadas pelo Sylvestre Mergulhão e o Henrique Andrade que poderiam até ter cobrado ingresso para as pessoas assistirem. Mas, sinceramente, para que todas as palestras se, no final do dia, você pode sentar com toda essa galera e ainda outros bambas na mesma mesa e trocar uma ideia sobre computação? É muito mais simples, fácil e agrega mais valor porque é uma conversa, ou seja, você se mantém como receptor e provedor de informação, o que é muito mais complicado de ocorrer numa palestra formal. Por isso, gastei a maior parte do meu tempo conversando com o pessoal.
De Porto Alegre ficam as lembranças e saudades dos momentos que todo o pessoal dividiu. Para o futuro, fica a ansiedade pelo próximo evento em que poderemos ir em massa para apresentar novamente todos os nossos valores, conceitos e tudo que nos leva encarar desenvolvimento de software como algo divertido e prazeroso.
![PythonBrasil[6]](http://www.python.org.br/banners-pythonbrasil/countdown_rectangle.gif)
