Roger Almeida's Opinion

São necessários 3 milagres para virar santo Para virar santo você precisa primeiro fazer 3 milagres. Se você começar numa equipe/empresa nova, lembre-se a não ser que você já seja um autor respeitado você vai precisar conquistar seu espaço/respeito. Para conquistar seu espaço/respeito você precisa fazer as coisas acontecerem. Se esforce e faça os milagres acontecerem, depois de 3 você vira santo e dai as pessoas passam a pedir sua benção.

Uma das coisas mais legais que aprendi nos últimos meses foi adicionar Vagrant no meu dia-a-dia de desenvolvimento. Hoje os meus primeiros passos para começar um projeto [green field] são: mkdir git init vagrant init ubuntu/trusty64  O que é? Camadas Vagrant é uma camada que facilita, MUITO, a interação com máquinas virtuais. Ele funciona falando diretamente com o seu gerenciador de máquina virtual (comumente chamados de Hypervisor). Com vagrant você consegue subir uma máquina virtual sem nem abrir o Virtual Box, por exemplo. Providers Para o Vagrant o Virtual Box é um provider. Virtual box é o provider padrão do Vagrant, ou seja, para subir uma VM virtual box com vagrant você não precisa fazer nada. Para subir uma VM VMWare você precisa instalar um plugin. Requisitos Como você pode imaginar tem um hypervisor instalado é um dos pré-prequisitos para usar vagrant na sua máquina. Benefícios Essa parte é interessante... Existe uma variedade de tecnologi...

Uma pergunta recorrente que me fazem é: - E ai, como é trabalhar na ThoughtWorks? Bom, vou tentar responder isso... Pra começar é muito diferente de tudo que já vi aqui no Brasil. Nenhuma das empresas pelas quais passei, ou empresas que ouvi amigos próximos falando sobre o dia-a-dia se aproximam do que eu vejo aqui na ThoughtWorks. Isso tanto para bom, quanto para "não tão bom". A ThoughtWorks te contrata para a Thoughtworks não para um projeto Isso pra mim é algo muito bom, a maioria das empresas de consultoria no Brasil quando querem te contratar falam algo do tipo: "Temos um projeto em Alphaville com duração de 6 meses e possibilidade de prorrogação..." Nesse cenário se tem projeto essas empresas contratam como loucas, e quando chega final do ano e os clientes tem um freezee elas demitem! Para em fevereiro do outro ano começarem a contratar de novo. Isso nunca fez sentido para mim. Na ThoughtWorks, quando você é contratado você vira um ThoughtWorker....

Se você estiver usando a seguinte tag nas suas páginas imaginando que seu site não será exibido no IE 7: Você está enganado!!! Para sites da zona 'intranet' o Internet Explorer 9 irá trabalhar em modo de compatibilidade. Para resolver esse problema você pode fazer duas coisas: Acessar o menu Ferramentas> Opções de modo de compatibilidade e desmarcar a opção de exibir sites da intranet como modo de compatibilidade. Alterar a tag das suas páginas para e ela deve aparecer antes de qualquer import de CSS. Ou seja, se tem de funcionar no IE... o preço muda.

So, you as I are tired of Evolution's problems in Ubuntu 11.10 ? Move on to Thunderbird... To have it working with Microsoft OWA following the these steps: Install DavMail Download and install  DavMail . It will act as a proxy between Thunderbird and your Microsoft webmail. Configure DavMail Some tips:  Exchange 2003: https://mail.company.com/exchange/ Exchange 2007 Webdav mode: https://mail.company.com/owa/ Exchange 2007 EWS mode: https://mail.company.com/owa/ Exchange 2010 EWS mode: https://mail.company.com/owa/ Exchange 2010 EWS mode with unsupported authentication form e.g. Windows Live login:https://mail.company.com/ews/exchange.asmx In my case as I'm behind a proxy I had to mark the option "Use system proxy settings" in the Proxy tab: Click save then you should see a message in your system tray, saying that DavMail is correctly configured. Configuring Thunderbird In Thunderbird main window click menu Fil...

Out of the blue my Evolution stopped working today. After browsing some forums with no success... I finally found a light:  sudo apt-get remove evolution  mv .local/share/evolution .local/share/evolution_bkp  sudo apt-get install evolution and... Voila! I don't know yet all the implications of this, but for now I'm so happy that I can see my messages again, and I don't have to use windows that I decided to post it here. If I find anything new I will update this post. Cheers... PS: Ubuntu 11.10

During the last week I had start creating a test suite for a existing web-application which my team is currently working on. So now is good time to share some experience: The application A normal old java web application: Java 1.4, Struts 1.1, EJB 2.1, JDBC to persist the data and the anemic design (VO+BO+DAO) but I will talk about in another post... Page Object Pattern To map the web page's components inside the test code I used the page object pattern. This patterns helped me to eliminate duplicated code to access web-page's components. Basically it consists of classes that maps web-pages, so that if you want to fill a login form from your test classes instead of doing this: @Test public void someTest() throws Exception { WebElement userNameField = driver.findElement(By.name("j_username")); userNameField.sendKeys(username); WebElement passwordField = driver.findElement(By.name("j_password")); passwordField...

The aim of this post is to organize my ideas and also share 3 aspect of my day that I believe helps me to became more productive. Pomodoro Technique Since I first listen about the pomodoro technique I got   really interested in it. I always had the feeling that I could produce more if I work less. Since I started using it I came studying the  physiological side of the technique and the more I use more I feel that I'm productive working less. Organize the goals But there's another point that I keep in mind, is that I have to produce a certain amount of work per day, and not necessary I have to work 8 hours per day to produce it. This is another rule that I try to follow, normally in the very begging of my day I ask myself: What do I have to do today? Normally I write the goals down in a piece of paper, then that becomes my goals for the day. I try to be fair to myself in the definition, I don't have to show it to any boss or manager, so if I put more ...

Two teams in my current company decide to give git a try. So in the last weeks I have expend sometime talking about DVCS. One item that I have seen that is difficult to understand about git is that it has many "areas". To explain the movement of changes between the areas normally I draw a picture in a paper with many arrows, showing the movement of changes for each git command... Gladly I found the site that taught me this: http://www.ndpsoftware.com/git-cheatsheet.html If you have to explain any git command to someone, definitely I recommend you to use this site. cheers...

In a Agile project when we plan the work for the project, we split it in small pieces, a.k.a. User Stories. Then in the begging of the project we prioritize the small pieces in order to do first the most important pieces ("how" to prioritize is a subject to another post). But all of this doesn't matter if the team decide to work in all the story at once. The whole idea of breaking down the work and prioritize it, is to be able to keep delivering some business value along the development time. And more than that is a way to follow up the project progress. Suppose that we have a project that will have 1 week iterations. In the first day of the 1º iteration the project board was with this status: Stories                          In Dev                         In Tests                 Done 1         ...

Last week I got involved in a project and while I was studying the scheduled dates for the project I remember the Lean concept that says: Managing Workflow is a lot easier than Managing Schedules . Managment people like the idea of managing dates for a project, and they have a false-positive impression that this is enough to set the base for a project, i.e., the project should be build on top of it. I agree that this is the starting point, but this is not enough. We need a workflow in place to be able to delivery a reliable project. This workfow should be repeated during the project and improved to suite the project reality. All the people involved in the project should be able to see the current status of each task in the workflow and see the results of each task in the end of the workflow. Some examples of workflow can be: Analysis -> Development -> Control Quality -> Integration or Ready to development -> Development-> Test or Whatever is suitable to your project. A v...

It's quite common to some business/manager people come to us and say: I'm trying to find ways to increase our production capacity... I would like to go faster. How quick can we  go? (...) The point is: Software development is not about how quick, but about how far. We always should think about how long our current solution will survive.

Lately I have been in some meetings to discuss if we should automate the tests scenarios or not. After some discuss with my colleagues we came up with this pattern: When reviewing a story instead of asking if we should automated the tests for the story ask: Why not to automate the tests scenarios for this story? If we don't have a really good reason to not automate, let's automate. If the reason is related to the size of the test scenarios, the difficult to write all the scenarios or quantity of scenarios then we should break/rewrite the story. If there's any technical reason, apply the 5 whys analysis to find the root cause, that in most of the cases will be a technical debt . What will left will be just real manual test, like visual validation.

This morning I got a great tip... I typed a command in my terminal but I wanted to run another command before executing the line that I just typed without loosing the information in the current line. For instance: I typed in my terminal the command: git commit -am "Unit test for scenarios A, B and C" But I was not sure if I was committing just the scenarios A, B and C that I have changed, I would like to run a git diff before committing but also without losing my committing message... Then my friend Duck told me to put a # in the begging of the line and...  voilà! # git commit -am "Unit test for scenarios A, B and C" It transform the line in a comment, so that I could hit enter without executing the commit and that line went to my history so that I could recovery it. Thanks Duck.

Some weeks ago I gave a talk in the office about How to influence people. My experience in this topic comes mostly from three books: How to win friends and Influence people by  Dale Carnegie , The 7 habits of highly effective people   by  Stephen R. Covey  and the Holy Bible by God . If you already read the Dale Carnegie's book, you will see that the topics for the deck came from there, but while talking I was browsing the three book ideas on this subject. Here is the deck: Influencing people View more presentations from Roger Eduardo P. de Almeida . I'll not describe the deck here as each slide deserves a whole blog post. Some day I'll write more about it.

Remote Pairing In the last few weeks I had an effective remote pairing experience. I'm locate in Brazil and my pair is located in USA. That experience gave me some thoughts about remote pairing that I would like to share here. Tools To share the screen, we used VNC (TightVNC to be more specific). It works well and you can config the compression and color resolution, what helps with slow connections. To voice chatting we have used Skype, with a two-ear head-set. In my opinion the two-ear is very important, because it helps you to don't be disturbed by any noise from your local office. Normally I use a two monitors set-up with a virtual-box filling one of the monitors, that helps to you not open your personal e-mail in a shared screen. The pairs were in different timezones. Brazil is 4 hours ahead of USA ET. For this reason we did not pair for the entire work-day. And it was a good thing, as both sides had time to do other work which is not related to the story at hand. A...

This week my colleague Guilherme Motta  and I did a presentation about Pair Programming, that were really fun, we learned a lot. During our research I noticed that there are few posts, wikis or sites about Pairing Practices, so I'm sharing with you some practices that we found. Ping Pong In this technique the first programmer writes a minimal failing unit test, the second programmer modifies the code to pass the unit test(s) than the second programmer writes a new minimal failing unit test and gave the keyboard back to first programmer, and so on. This loop continues as long as any programmer is able to write failing unit tests. The technique can result in the driver role switching as often as a few minutes or less. Pros: CV  taught me this one and was really fun, because you don't have to discuss a lot, although you keep conflicting the programmer's ideas.   Cons: I don't know. Chess Clock Using a chess clock the pair define a time inter...