Eclipse / JBoss in Debug mode

Filed Under (Eclipse, JBoss, Uncategorized) by admin on 20-08-2008

Tagged Under : ,

JBoss configuration

Open file run.sh (or run.bat if windows) in <JBOSS>\bin directory, locate the line:

JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true"
replace by:
JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"

JBoss will start to listening on port 8787 for debug.

Eclipse configuration

Click on Run > Open Debug Dialog..
Select Remote Java Application, click on the first icon (New launch configuration)

Replace fields:

Project: your_project_name
Port: 8787

Click in Source tab and “Add” button, Select “Java Project” and “Select All” Button, OK.

If you did the JBoss steps and it is running (if JBoss is not running, that is a good time to put it to run) , click on Debug.

Ubuntu (Gutsy Gibbon) and Java Swing Applications…

Filed Under (Compiz, Java, Ubuntu) by admin on 17-08-2008

Tagged Under : , ,

+ +

There is a problem using Gutsy Gibbon + Swing Java Application + Compiz.

My libraries are:

  • Ubuntu 7.10 (Gutsy Gibbon
  • JDK 1.5.0_16
  • Compiz-Core 1.06
  • Compiz-Fusion 0.52

The problem

When an java application is executed, it simply doesn’t appear anything, no buttons, no fields, no menus, nothing!

Solving

I really like compiz fusin effects but they are the monsters inside the box, they are the ones who don’t let the java application works fine.

For now, I had disable compiz (Visual Effects = None) and applications like: Jude and Oracle SQLDeveloper that before that opened but don’t appear nothing, now they run fine!.

Yes, thats boring to use Gnome without compiz effects, but for now this is the way that I have found to work with Java Swing Application on Ubuntu.

Have a lot of fun!

Womp.us! - new URL Shortcut!

Filed Under (RubyOnRails, Uncategorized) by admin on 16-08-2008

Tagged Under :

I’m proud to announce Womp.us! new URL Shortcut, try: http://womp.us

VPS + Ruby on Rails

Filed Under (Linux, vps) by admin on 15-08-2008

Tagged Under : ,

Ubuntu Logo

Recently I decided to start to learn other language. Not that I’m stuffed of programm in Java, I just decided to try new paradigm of development.

So I sign a forum about Ruby, and started to develop some small thinks, and I enjoyed to do that in Rails!

Step 1 done! New program language and a small application done as a POC (prove of concept)

Step 2: Where will I put this apllication running? This was the hard work and didn’d find any place, so I decided to use VPS (Virtual Private Server).

The new task: Find a good and ship VPS. This was not realy hard work, a simple query in the Google and a lot of companies offering this kind of service, I found a good one that had total control on the server and had a good price ($15) A2 Hosting.

They have some official distros, like: CentOS, Fedora, Debian, Gentoo, Slackware and Ubuntu

I choose the core package, payed by Pay Pal, and Ubuntu 7.10 as my linux distro.

Five minutes after the payment, I already had an email with all the configuration settings, so ASAP I started ssh client to test the new home, and everything was fine!

I’m not receiving any kind of plus for this “marketing” about A2 Hosting, this is just a post to encourage every one who have average knowledge about linux to use VPS.

Soon, I’ll write my experience to install Rails environment on the server.

Enjoy!

Ubuntu and Apache2

Filed Under (Apache, Ubuntu) by admin on 19-07-2008

Tagged Under : , ,

I don’t know exactly why but last time that I reinstall Ubuntu and Apache2 on my server, I got the message error:

unable to create worker thread

So, I added the following to /etc/apache/httpd.conf

ThreadStackSize 1000000

Then restart apache:

/etc/init.d/apache2 restart

What happened?

This configuration sets the limits the size of threads to 1Mb and creates a much less memory intensive apache.

Instalando programas no Ubuntu a partir do Firefox

Filed Under (Firefox, Ubuntu) by admin on 14-06-2008

Tagged Under : , ,

A partir da versão 7.10 do Ubuntu, é possível instalar softwares a partir do browser.

Abra o Firefox, e por exemplo, para instalar o htop, digite na URL:

apt:htop

Daily Scrum pequena notável …..

Filed Under (Agile Development, Scrum) by admin on 08-06-2008

Tagged Under : ,

Basta apenas 15 minutos por dia e esta pequena notável faz uma enorme diferença para o desenvolvimento do sprint.

Funciona mais ou menos assim: todo o time se reúne, sempre no mesmo horário, no mesmo local, para responder 3 simples perguntas:

  1. O que você conseguiu desde a última daily scrum?
  2. O que você pretende conseguir até a próxima daily scrum?
  3. Existe algo que impeça o desenvolvimento até o próximo daily scrum?

Realmente, muito simples, se não fosse as pequenas pegadinhas e algumas dificuldades naturais, especialmente de empresas que estão tentando sair do modelo tradicional para o modelo ágil.

Só mais 5 minutinhos…..

Sabe aquela manhã chuvosa de segunda-feira que o despertador toca te lembrando que já é hora de se levantar e ir trabalhar e você pensa: “Só mais 5 minutinhos!”

Nas reuniões de Daily Scrum não tem espaço para tolerância, 5 minutos de uma reunião que demora no máximo 15 minutos é 1/3! Por tanto, é extremamente necessário que todos os membros do time conheçam o termo “Time-Boxed”.

Time-boxed, quer dizer que se a reunião começa as 10 horas da manhã com duração de 15 minutos, esta obrigatóriamente terminará as 10:15, sem atrasos (tanto para começar quanto para terminar).

Eu já passei por isso, resolva assim….

Somos brasileiros, muitos descendentes de portugueses ou italianos, temos “sangue nas veias”, e em algumas vezes a pessoa que está respondendo as perguntas não começa a discursar algum problema, e o pior dos casos, outro membro do time, responde: “Eu ja passei por isso, resolvi desta maneira…..”.

Excelente!

O time está se introsando, estão se ajudando e não apenas desenvolvendo suas próprias tarefas.

No entanto, a daily nao é para discutir a solução dos problemas e sim que os problemas sejam levantados e endereçadas ao SM, caso a reunião esteja tomando outro rimo, neste momento, é a hora do SM entrar em ação, e pedir educadamente que os membros do time se atenham a proposta do daily scrum, expor os problemas e informar o que fez e o que pretende fazer até o próximo daily scrum.

Vai ter reunião? Mas o SM não está presente!

Outra pegadinha típica das dailies são do time não começar a daily meeting até que o ScrumMaster não esteja presente.

A Daily Scrum não, é para que o ScrumMaster gerencie o projeto, o time é alto gerenciável, se algo não vai bem não é porque uma pessoa não está desenvolvendo a coisa da maneira que deva ser, e sim porque o time não foi capaz de identificar que existe um problema com determinado membro do grupo e não foi ajudar.

O papel do SM nas dailies é remover os impedimentos explicitos, quando são ditos pelos membros do time, e também identificar um problema oculto, por exemplo comportamento de algum membro do time, ou deficiência técnica, por experiência digo que pelo menos 80% dos impedimentos podem e serão resolvidos pelo próprio time.

É claro que para o time chegar ao nível de alto-resolução dos problemas de 80% ou 90% é necessário um alto nível de amadurecimento do time, acredito que em 5 sprints o time já está resolvendo boa parte dos impedimentos.

Hoje foi suco de limão com 4 cubos de gelo, raspas da casca do limão, açúcar, leite, mas amanhã será de abacaxi, frutas tropicais gelo adoçante, 3 pedras de gelo……

Um outro problema é começar a dizer o que foi feito e o que gostaria de fazer explicando detalhadamente como foi feito/deseja fazer, isso leva muito tempo da reunião e não é o escopo.

O time deve se ater as tarefas pregadas no quadro, se uma tarefa para uma história definida no Sprint Planning, foi:

  • 4 cubos de gelo

Basta dizer, “desde o último daily eu fiz 4 cubos de gelo e até o próximo daily pretendo raspar a casca do limão, tenho um impeditivo: não tenho ralador”

Tarefa do SM:

  1. anotar que o membro do time não tem ralador para concluir a próxima tarefa
  2. após a reunião: providenciar um ralador para que a tarefa não fique prejudicada.

Ontem 4 cubos de gelo, e hoje continuo nos 4 cubos de gelo….

Opa, problema à vista, se alguém está com uma tarefa a mais de um dia algo não está indo bem, tenha certeza!

Neste momento o SM deve notar e anotar que ali existe um problema, e existe algumas razões para isto:

  1. a tarefa foi subestimada
  2. existe algum impedimento não informado na tarefa

O SM deve estar atento, mesmo que quando não for possível participar da Daily Scrum, ao andamento das tarefas, se uma tarefa não passar do status: “Doing” para o status: “Done” em um dia, tenha certeza, ali tem um impedimento.

Uma boa tática para saber a quanto tempo uma tarefa está no determinado status é anotar a data em que a tarefa trocou os status: “ToDo” > “Ongoing” > “Done” e o nome de quem esta/estava trabalhando nela.

Hein? É comigo? Só um segundinho….

As dailies devem ser feitas no mesmo local, mesmo horário todos os dia e não pode durar mais que 5 minutos.

É importante que todos estejam diante do quadro com as histórias e tarefas do sprint, geralmente isso acontece bem próximo das mesas do time, algo que não deve acontecer de forma alguma é que alguns membros do time preste atenção na reunião e outros fiquem voltados para seus monitores.

É extremamente importante que o time todo preste atenção no que cada um está dizendo, para tanto, algumas atitudes simples, fazem toda a diferença:

  1. Todos de pé
  2. Todos visualizando as tarefas no quadro, se as tarefas ainda não migraram de um status a outro, esta pode ser uma boa hora.

E ae? Já acabou a reunião?

Para que fique claro a todos os participantes da reunião, quem começou a reunião (geralmente o SM) a termine dizendo formalmente que a reunião está terminada.

Treinamento Scrum - Boris Gloger

Filed Under (Agile Development) by admin on 31-05-2008

Tagged Under : , , ,

Nos últimos dois dias (28 e 29 de maio) tivemos um treinamento sobre Scrum / ScrumMaster com ninguem menos que Boris Gloger aqui em São Paulo, foi um evento fechado apenas para os funcionarios do UOL.

Estamos utilizando, a metodologia a algum tempo, por tanto já tinhamos conhecimento de várias táticas e organização de como as coisas devem funcionar, confesso que comecei o treinamento achando que ia ser apenas mais um falando sobre as mesmas coisas que é facilmente encontrado em livros.

Eu estava redondamente enganado, o treinamento foi extremamente dinâmico, com alguns exercícios práticos relacionado ao tema (claro!).

Boris foi extremamente focado, não repassou perguntas com respostas prontas do tipo: “You decide!”, “You tell me”, “What do you thing?”, pelo contrário, respondeu grande parte das perguntas com respostas práticas, sem rodeios.

Começando pelo começo, ele deu uma explicação resumida sobre, qual o papel do ScrumMaster:

- Break rules;
- Remove impediments for the team;

Também discursou sucintamente a respeito de Scrum, de forma mais resumida, mas muito direto disse:
“Scrum is not a silver bullet! Scrum is a good way to show the problems, but they will not be fixed by the methodoligy”

Foi apresentado uma breve explicação a respeito do fluxo do Scrum.

Como ele mesmo disse, ele adora metaforas, uma delas é que a melhor forma de transmitir a informação, é na forma de histórias, então, inclusive citou o Brasil como sendo o grande contador de historias do mundo, vendendo novelas para todo o globo, nós adoramos contar e ouvir hsitorias.

Falou a respeito do Manifesto Ágil, ainda nao convencido a respeito do valor do treinamento, eu achei que seria mais um bonito discurso sobre motivação, e mais uma vez eu estava completamente enganado.

Ele leu o manifesto e explicou a essencia deste, como é de conhecimento de muitos, alguns “bam-bam-bans” se reunirão para discutir nao sobre qual a melhor técnica ágil de desenvolvimento de software e sim, o que todas tinham em comum, o que todas pregavam como sendo os principais valores, e foi sobre estes valores que foi criado o manifesto ágil.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Scrum Team, mais um conceito do que é o Scrum Team, entre todos os stakeholders que existem na empresa, nem todos fazem parte do Scrum Team, existe apenas 3 papéis:

  • Product Owner
  • ScrumMaster
  • Team

Gerentes, Supervisores, Vendedores, Usuários finais, todos eles se nao estão inclusos em um dos ters papeis citados acima, não fazem parte do ScrumTeam.

Exercícios de Estimates, foram feitos inclusive clarificado muito bem a respeito de estimation:
“It’s not about the time, it’s about the complexity”

Responsabilidades, no inicio do dia 2, falamos a respeito de responsabilidades, ou seja, em cada etapa do processo, quem sao os responsáveis e quem são os responsaveis por dar suporte:

Nível estratégico
-------------------
- Visão            PO    TEAM
- Product Backlog  PO    TEAM
- Priorização      PO    TEAM
- Sizing           TEAM  SM
- Releasmanager    PO    TEAM

Nível Tático
-------------
- Sprint Planning 1     TEAM    PO
- Sprint Planning 2     TEAM    SM
- Daily Scrum           TEAM    SM
- Sprint Review         TEAM    SM
- Sprint Retrospective  TEAM    SM

Uma breve sugestão de como deve ser organizadas as reuniões dos Sprints

-------------------------------
            Sprint 1          |
---------|---|-------------|--|
         |   |             |  |
 Morning |SP1| Daily Scrums|  |
         |   |             |  |
---------|---|-------------|--|
         |   |             |RV|
 Evening |SP2|             |  |
         |   |             |RT|
-------------------------------

Alguns comentários:
- Ele não aconselhou fazer a Review Meeting na sexta feira, e sim na segunda feira, pois se algo der errado o time ainda tem o final de semana para acertar.
- A Retrospective tbem não é aconselhado, fazer na sexta feira, por motivos óbvios, especialmente por que o time nao estaria motivado suficientemente para uma conversa franca na sexta feira :) .

Daily Scrum, regra numero 1, não apenas do Daily, mas para todo o Scrum: “Time boxed” a Daily deve ser feita no mesmo lugar, todos os dias, no mesmo horário e nao pode durar mais que 15 minutos.
O principal envolvido é o time, a daily não é simplesmente de acompanhamento dos trabalhos pelo PO ou SM, e sim para o time, inclusive, a presença do SM não é obrigatória, como a do time é.
O SM ou o primeito membro do time não deve perguntar (como dito em várias bibliografias):

  • What have you ACHIEVED since last meeting?
  • What will you ACHIEVE before next meeting?
  • What is in your way?

E sim:

  • Who will start?

Claro, nas primeiras dailies, as perguntas devem ser feitas, mas durante o projeto, não é mais necessário, pois todo o time sabe o que deve ser dito na meeting, se ocorrer de alguem “esquecer” o que deve ser feito, basta colocar na parede as perguntas :) .

Monitoring the Sprint, formas de se monitorar o sprint, utilizando os graficos, que podem ser relacionados a progresso de tarefas, progresso de historias e quantos pontos do product backlog já foi “queimado”.

Scaling / Distributed Teams / Larger Scrum, bom este tópico merece um post só para ele, no entando de forma bem resumida, é posivel ter times em localidades diferentes, para evitar “guerra” entre os times, a idéia é misturar os times, ou seja, time1 com membros da localidade A e B time2 com membros da localidade A e B, assim evita a competitividade entre os times.

Fechando o treinamento fizemos um exercicio de 4 sprints, com cartas, baloes, dados e papel, muito interessante e “fun”.
“Fun” foi algo que o Boris fez questão de perguntar depois de todos os exercícios, “Was it fun?”, e o recado no final foi claro, sempre que o time se sente parte da solução e se diverte fazendo algo, a produtividade e qualidade será bem mais satisfatória para todos os envolvidor.

Após com tradicional comprimento “wulf”, nos tornamos os mais novos Certified ScrumMasters!

Agile Programming in some companies…

Filed Under (Dilbert, Fun) by admin on 08-05-2008

Tagged Under :

Agile Programming

Eclipse and Permsize

Filed Under (Eclipse) by admin on 13-04-2008

Tagged Under :

Are you getting problem with PermSize on Eclipse?

Try this arguments on eclipse start:

-vmargs -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M