Seguem alguns links de posts interessantes comentandos as grandes diferenças e propósitos entre o Twitter e um blog:

* http://goo.gl/RmCp

* http://goo.gl/ZZjo

Sendo assim, não esperem posts frequentes por aqui – não vou enganar vocês desta vez, rsrsrs. O meu usuário do twitter é thaniaclair. É uma conta privada, mas caso você seja um usuário real tentando me seguir com boa índole, aceitarei a sua solicitação. =)

Das boas palestras que assisti, preciso dar meus parabéns a alguns palestrantes excepcionais: Scott Chacon (sobre Git), Arlindo Pereira e Samuel Vale (sobre OpenStreetMap). Palestras que agregaram bastante.

Bom, é isso aí. O evento não acabou ainda, faltam mais algumas horas. Mesmo assim já fica aí o meu desabafo sobre algumas coisas chatas deste evento. That’s the truth. Sorry, guys.

Essa semana ainda coloco no blog umas fotos do evento, ok?

Saudades de Floripa! Snif snif..

Serão muitos keynotes no FISL 11, com palestrantes super envolvidos no mundo de software livre. O John Maddog mesmo como sempre não perde uma oportunidade para vir ao Brasil, ahahaha.

É isso. Só queria lembrar os geeks de plantão. Nestes eventos sempre aprendemos muitas coisas e descobrimos muitas novidades da área de TI.

See you there!

De modo geral, posso dizer que o evento foi muito bom. O keynote com o Martin Fowler foi muito inspirador e abriu o evento como nenhum outro – isso que eu ainda estava bem cansada do vôo. Alguém me disse que o Martin não tira foto com seus fãs… Não que eu quisesse, mas fiquei intrigada. Why?!

Após o almoço, assisti a palestra do Branas sobre Kanban, que foi uma das mais importante pra mim do evento. Foi super prática, dinâmica e objetiva. O palestrante falou 100% do tempo com experiência de causa e deu muitas dicas importantes para o dia-a-dia. Em seguida, ouvimos a palestra sobre “Agile Adoption Anti-Patterns” com James Lewis e essa foi bem bacana também. Os anti-patterns que ele mostrou eram tão verídicos que chegavam a ser engraçados, ahahah. Tudo muito verdade.

O keynote de fechamento com o Klaus foi bem divertido (apesar dele ter passado os 15 primeiros minutos só falando dele mesmo, hehehe). Valeu, o rapaz tem bastante estória pra contar em termos de desenvolvimento e metodologia. Pessoas assim são raras de encontrar. Ele prendeu a atenção do público.

Ah, quase esqueci de dizer uma coisa muito ruim do evento: eu não fui sorteada nas entregas de brinde!

Ahahahaha.. Quem sabe na próxima!

O próximo evento que iremos é o FISL 11, também em Porto Alegre. See you there!

Dude's law

Palestra do Martin Fowler

A partir desta quinta (24), estarei lá em Porto Alegre acompanhando toda a programação de palestras do evento – também assistirei o jogo do Brasil! Pretendo postar aqui algumas de minhas considerações sobre as discussões.

Vale a pena conferir, galera! Vamos lá!

Não é fácil começar de novo dentro de uma empresa. Até que a empresa adquira confiança em você e vice-versa, leva um tempinho. Mas as coisas vão dando certo aos poucos. É sempre preciso esforço e força de vontade, e quando a gente gosta do que faz, tudo fica mais divertido.

Estou com muitas metas este ano, tanto pessoais quanto profissionais.  Acho que não consigo iniciar uma especialização em breve ($$), mas alguns cursos pretendo fazer. O importante é que estou aprendendo muito no meu trabalho e estou curtindo bastante. Ainda estou me adaptando em termos de relacionamento, time e metodologia, mas isso é com o tempo.

Estou de olho no Agile Brazil deste ano, em junho. Quero muito ir, pois está prometendo uma programação muito interessante. Alguns palestrantes conhecidos já foram confirmados, então o negócio é ficar atento para as inscrições.

Já o FISL 11 vai ser em julho e em POA novamente. Este ano eu não perco! Esses eventos empolgam bastante. Os profissionais precisam disso para se manterem motivados e cada vez mais atualizados. Sem falar do network.

Minhas atualizações diárias tem sido mais no Twitter. É difícil reservar tempo para falar sobre algo que realmente mereça um post. Com o Twitter ficou tudo mais prático, pois é bem objetivo. Optei recentemente por deixá-lo privado. Dependendo do que você escreve, não é muito interessante deixar público.

Fico por aqui com uma frase motivadora da Diana Ross:
“You can’t just sit there and wait for people to give you that golden dream; you’ve got to get out there and make it happen for yourself.”

See u!

Bom, gostaria de compartilhar com vocês o pdf da apresentação. Todos os códigos exemplificados funcionam. Baixe o pdf aqui.

Enjoy!

Trabalhar em dupla provê uma maior proximidade entre os desenvolvedores de um time. Consequentemente, isto nos faz conhecer muito mais nossos colegas de trabalho, desde seus os pontos fortes aos pontos fracos. Afinal de contas, não há o que esconder quando estamos codificando lado a lado…

Trabalhar com pessoas significa trabalhar com todos os tipos de pessoas e a trabalhar ainda mais com a nossa própria pessoa. O nosso comportamento expressa quem realmente somos e, dependendo de como nos expomos, podemos gerar problemas de relacionamento interpessoais.

Existem pessoas com temperamento forte, teimosas ou então de difícil entrosamento. São indivíduos que necessitam dentre várias coisas, que os companheiros tenham um tato muito refinado no convívio do dia a dia e um grande jogo de cintura para relacionarem-se sem que o estopim seja aceso e tudo vá pelos ares. Trazem desgaste para a equipe e principalmente para eles próprios, haja vista que além de estragarem o dia dos outros, por fim, o seu também é prejudicado.

Programar em par exige que as pessoas envolvidas sejam receptivas, compreensivas umas com as outras, engajadas e, sobretudo, humildes. É necessário aceitar que somos falíveis para que possamos programar em par.

Assim como o erro, a razão também é parte do ser humano e deve sempre ser invocada para avaliar aspectos e danos da idéia formulada. A medição das palavras além de um bom exercício mental é aliada neste comportamento que deve ser trabalhadada todos os dias.

Desenvolvedores tem diferentes ritmos e momentos. Alguns são mais pensativos e tranquilos, outros são mais comunicativos e ansiosos por tentar concretizar uma solução. Às vezes, irritações são geradas por conta disso e é preciso ter paciência, sempre lembrando que em todas as situações alguém tem que ceder. Inconcientemente, as afinidades podem acabar por dividir um time de desenvolvimento em mini-grupos e, após isto, fica cada vez mais difícil fazer os pares serem trocados naturalmente, pois o desenvolvedor acaba se sentindo mais confortável com alguns colegas em específico. Alguns até mesmo evitam o par. Neste momento, é preciso definir algumas regras para a técnica caminhar. Algumas coisas não funcionam bem se forem deixadas por conta do bom senso. Como sugestão para ajudar nesta questão, algumas pessoas sugerem a técnica pomodoro ou a “promiscuous programming”, para que a troca de par seja mais formal e dinâmica.

Em um par, sempre existe um piloto e um co-piloto. Os dois precisam sempre estar interagindo ativamente para que uma tarefa possa progredir com sucesso. Uma vez que um dos dois começa a atingir uma posição mais passiva, é preciso inverter os papéis. E o colega que estiver momentaneamente mais ativo, é claro, precisa ser paciente e compreensivo.

Um outro ponto importante, é que o código-fonte deveria ser um tanto “egoless”. De maneira que alguém que visse, não pudesse identificar o autor. Para isto, ajudaria ter padrões de código bem definidos. O código precisa ser visto como algo que não representa a personalidade de alguém. Em um par, isto se torna mais fácil, pois o código é a contribuição de várias pessoas e não de uma única. Se o desenvolvedor imaginar que o código representa a si próprio, dificilmente irá buscar problemas e falhas.

A retrospectiva realizada em toda iteração é um momento muito importante para repassarmos feedbacks aos nossos colegas de trabalho. Temos o dever de relatar qualquer tipo de problema de relacionamento que estiver dificultando a nossa produtividade e qualidade de trabalho. Muitos desenvolvedores de software trazem problemas de interação e comunicação e impor uma cultura de Pair Programming sem que este lado seja melhor trabalhado em cada indivíduo da equipe pode trazer problemas e perdas a um projeto de software.

Resumindo: o Pair Programming é uma técnica simples que pode se tornar beeeeeeem complicada (uma vez que envolve pessoas!). Só tentando para conferir tudo isso de pertinho.