Meu ambiente de desenvolvimento em 7 itens

O @abstractj e o @anderson_leite me intimaram a participar da brincadeira então aí vamos nós:

Máquina / Sistema Operacional

Há algum tempo atrás eu sempre me dividi entre usar Windows e Linux, confesso que nunca tive uma preferência entre um ou outro, então, eu tinha um Desktop com partições meio a meio e as vezes usava uma e por vezes outra.

Desde março de 2009 eu tenho um MacBook alumínio (não, não é o Pro e sim, ele saiu de linha 3 semanas depois q eu comprei) com o Snow Leopard. O coitado está ainda com 2GB e aguentando o tranco, mas vai ser trocado logo logo. Uso direto pra programar e no meu dia-dia (filmes, jogos e afins). Em casa tenho também um Dell, com meio Ubuntu 10.4 e uma outra partição com Windows Vista, mas esse quem vem usando é a patroa.

Editor

Depende da linguagem. Quando mexo com Ruby eu prefiro desenvolver no Vim mesmo enquanto que quando estou no Java eu utilizo o Eclipse (não consegui me habituar ao Eclim). Já mexi bastante com PHP no Zend e no próprio Eclipse e comecei desenvolvendo no Visual Studio 6.0 lá em 2002.

Em alguns momentos pra escrever materiais didáticos utilizo o vim com o plugin pra AFC: http://github.com/adrianoalmeida7/vim-afc

Terminal

Sempre preferi o bash, então quando usava Windows tratava de colocar um Cygwin.

Browser

Utilizava bastante o Firefox, mas hoje em dia tenho ficado mais no Chrome, apesar de preferir o Firebug ao equivalente nativo do chrome.

Software

Eclipse, Vim, as vezes o TextMate, Keynote, os post-its nativos do mac, Dropbox, Adium, Tweetdeck, Preview, GMail entre outros.

Source-code

Hoje em dia só Git, mas já foi o tempo do SVN, CVS e Source Safe.

Música

Não gosto muito de ouvir música enquanto desenvolvo / escrevo. Prefiro um ambiente mais silencioso, ou o barulho normal da rua. De qualquer forma, muitas vezes deixo o fone no ouvido, mesmo que não esteja tocando nada. Quando escuto música trabalhando prefiro música francesa, mas é raro.

Próximos ;)

E o invite pros próximos vai pro @davidpaniz, @gabaiel e a @hannelita

First impressions from a coding dojo

I know I’m quite outdated at this post from my first coding dojo (which was last friday), but never is too late.
I had never been at a coding dojo before, so at the start I felt myself kind of noob, on its formula.

What is a coding dojo?
Imagine a coding dojo as a meeting of programmers, where you put to work some of XP practices, like TDD and pair programming to solve any given problem. The main goals of a coding dojo is that you firstly have fun programming and seeing other people programming (the computer output is project to everybody at the dojo session). And also, acquire new skills, such as learning new techniques, languages, tools, frameworks and so on.

Coding Dojo formula
In a coding dojo, people are arranged in a way that 2 persons stays at the computer pairing for a certain amount of time (in our case, 7 minutes). Past this time, there’s a pair switch, where other pair take control from the computer, and also from the code, cotinuing from where the pair before were.
While the pair is working on how to solve the problem, the audience cannot take part on it suggesting ways of solving the problem or also suggesting refactorings to the code, while the tests developed under TDD are not passing (red).
And also the problem to be solved and the programming language to be used are chosen just before the dojo session starts.

The whole scenario
My first coding dojo was also the first coding dojo held at Caelum (where I do work), and like me, there were also some other people who was at a coding dojo for the first time. So for not pushing it too fast, we had chosen a common language (Java) and a really cool problem (How to divide a number represented as String without using the / operator?)

What I’ve learned
It’s interesting when you are in front of a crowd coding, and there’s everybody looking at what you’re doing. I’ve never had experienced that before, and it kind of intimidate myself a little bit at the beggining, but past some time I’ve got used to it, and it flowed pretty good.
Also, I’ve learned how boring it is to pair to someone who is tired, or whose mind is at the moon or mars. It just don’t work.
From the language there was nothing much to learn, because we used pure Java, which I work with everyday. So, nothing new on it.

What I’ve liked
It’s amazing when the crowd is all there looking at the problem and figuring out a way to solve it. Everybody, with the same goal and motivated. The feeling of being there was very intense and how the problem challenged us was also very interesting, and I really appreciated it.
By the way, when a test goes from red to green the feeling is very good.

What I disliked
I’m not sure if dislike is the best word to describe it, but I couldn’t figure out a better one, but I think that 7 minutes wasn’t time enough for a pair to fully participate on the problem. Maybe 10 minutes would be a best try (the ones who were there and also had experiences in a coding dojo said that 7 minutes are ok). Or maybe, It’s just a noob impression :).
By the way, sometimes people talked aloud when the tests where red, this can take away your mind and concentration on the problem. So silence while the tests are red is essential.
We also hadn’t prepared a source control environment (lack of time), so we couldn’t integrate our changes at each pair switch.

Future Coding Dojos
We scheduled to run a coding dojo every friday. With a github repo available, so we can integrate our code at each pair switch.
And now with different languages, so we can learn much more on it. After all, that’s what a coding dojo is about. Learning.

Get Involved And Participate

Recently, I’ve attended to Rails Summit Latin America, and among some brilliant talks, there was one which impressed me the most. It was from Dr. Nic Williams, a well-known Ruby on Rails programmer, talking about how can everyone participate at the open source community.

During his talk, he explained about some tips for those who wants to get involved and participate in the open source community, like doing unit tests, knowing a versioning system such as git and svn, and taking part at some open source project, independently at the role that you play on that project.
But the tip that made me considering write this blog post was: “write a blog”. :) It doesn’t matter that you sometimes make mistakes on what you’re posting, the most important thing is, someone will always know a subject more than you do, and will post a comment correcting you if you’re wrong, and that way, the blogger will be able to learn from it’s own mistakes. And if you’re not wrong, awesome, other people will be able to learn from your blog. So that writing a blog becomes a learning cycle. Always.

In this space, I’ll discuss agile, TDD, algorithms, programming languages, tools and some other random stuffs that comes to my mind. Feel free to join the blog, post comments and interact.

So lets go get involved and participate. :)

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.