Tuesday, March 13, 2012

InfoQ: Volte ao Trabalho! (portuguese)

Agustin Villena tem problema em convencer a gerência aceitar os limites do Kanban. Ele diz:
Eu estou atualmente atuando como um consultor, e eu estou preso ao gestores que apesar do fato dos quadros de kanban mostrarem claramente a sobrecarga de trabalho extrema de seus funcionários, eles não percebem o fator negativo no rendimento e o stress causado...
He também escreve:
O problema agora é limitar a grande quantidade de projetos atribuídos ao time. Mas os gerentes são quem nós não conseguimos convencer a filtrar os projetos que estão entrando.
E também existe o paradigma que folga é desperdício...
Por que não deveríamos considerar folga como desperdício? De acordo com Tom DeMarco, folga é "o grau de liberdade necessário para efetuar a mudança." Quando colocamos desta maneira, calmaria pode ser vista como um lubrificante dentro da organização que evita que as partes móveis fiquem presas. De acordo com Mary e Tom Poppendieck no livro Lean Software Development: An Agile Toolkit, folga serve a um propósito ainda mais fundamental quando vista da perspectiva da Teoria das Filas: "Assim como uma auto-estrada não pode fornecer um serviço aceitável sem algumas folgas na sua capacidade, você provavelmente não está fornecendo aos seus clientes o mais alto nível de serviço, se você não tem nenhuma folga na sua empresa." Amir Kolsky propõe esta respota à acusação de que a folga é desperdício:
Folga não significa que as pessoas ao seu redor estão ociosas.
Folga significa que as pessoas não estão trabalhando em coisas do principal gargalo.
Elas podem estar ocupadas fazendo outras coisas importantes.
Então, qual pode ser a causa dos problemas em relação aos limites do Kanban? Nader Talai sugere que possivelmente os gerentes resistentes podem ser parcialmente motivados pela maneira como a performance de seus times está sendo medida:
Você sabe o que é que os gerentes valorizam ou estão medindo? O quadro mostra para os valores que eles querem?
[...] Por exemplo um gerente pode medir a velocidade de seu time pelo "Desenvolvimento Completo" em vez de "Liberado sem defeitos". Eu trabalhei em uma empresa onde o time de TI era medido pela entrega dos projetos em um tempo baseado em datas que eram estimadas em 12 meses. Nesta empresa o foco era entregar no tempo independentemente do que era entregue ou da qualidade.
De acordo com Tomo Lennox, mais educação pode ser necessária:
Quando os gerentes tem o simples conceito que você produz mais quanto mais trabalha, eles não vão mudar até que você possa ensinar-lhes algo.
Mas nunca subestime o poder de uma piada para expor seus pontos: "Pessoas ouvem melhor depois de uma piada" escreve Lennox:
Um policial vê um garoto correndo ao lado de sua bicicleta, então ele encosta para oferecer ajuda. "Você tem um pneu furado?", pergunta o policial. "Não", responde o garoto e ele continua correndo com a bicicleta. O policial dirige até o garoto e tenta novamente. "Então o que está errado com sua bicicleta?" "Nada", diz o garoto e saí correndo. O policial dirige novamente até o garoto e tenta mais uma vez. "Então por que você não está pedalando na sua bicicleta?". "Eu estou muito atrasado para o colégio, por isso eu não tenho tempo para subir na bicicleta." ... e ele saí correndo.


Fonte: InfoQ: Volte ao Trabalho!

Sunday, January 15, 2012

Making Eclipse Fly on Mac

As David Salter posted:

On a Mac, the following procedure allows the JVM settings to be changed:


  • Find Eclipse in the Finder. Right click on Eclipse and choose "Show Package Contents"
  • Browse to the Contents | MacOS directory and edit the eclipse.ini file
  • In this file add JVM options, one per line.


The JVM options that make the biggest difference are the ones that specify how much memory Eclipse can use.

1
2
3
4
-Xms512m
-Xmx512m
-XX:PermSize=256m
-XX:MaxPermSize=256m

I also tell the JVM not to verify bytecode using the -Xverify switch

1
-Xverify:none


According to the NetBeans performance tuning tips, changing the garbage collection policies can also make a difference. I’m not sure that these make much of a difference, but I’m running with them at the moment to see if there is any difference.

1
2
3
-XX:+UseConcMarkSweepGC
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled

See the entire post.

Sunday, November 27, 2011

OSGi - Automated, unit and integration tests with JUnit


Article to show how to build automated integration tests with JUnit in a OSGi environment

OSGi is a brilliant architecture. Amazing softwares with complex architectures and hundred of components, like Eclipse Platform, are possible to build thanks to the OSGi architecture.

Test is essencial for software development, and continuos integration is what every profitful enterprise needs, because, when earlier the error is discovered, it's cheaper to fix it.

How does we can test the interfaces and behaviors of a encapsulated OSGi component? The answer is on this page.

Introduction

For CBD (Componente Based Development) and SOA, OSGi is a very good choice. In a lot of enterprises, the biggest problem is how to develop a system that fits all needs of all the customers. Some enterprises solve this with a kind of generic application that has hundred of parameters where you can customize the behavior and UI at runtime. So, this is not the best approach, it's a very expensive way. With OSGi, complex applications, like Eclipse, can be made in a cheap and reusable way, and this is what we look for.

There are several ways to test OSGi components, next it'll be demonstrated one of them. To understand what is being discussed, first you must to know these technologies. All used technologies are referenced with links at the bottom of the article. 

iPOJO and JUnit4OSGi


As in the project page
iPOJO is a service component runtime aiming to simplify OSGi application development. It natively supports ALL the dynamism of OSGi. Based on the concept of POJO, application logic is developed easily. Non-functional properties are just injected in the component at runtime.
iPOJO project is a set of some subprojects. What interest us for now is the JUnit4OSGi framework, that allowing the execution of JUnit tests in an OSGi environment.

To test your application, just follow these steps:
The fragment that will test the host bundle
  1. Prepare the OSGi environment. Put the JUnit4OSGi and JUnit bundles in the right folder ("plugin" folder if equinox, for example). Note that in JUnit4OSGi framework are two test runners, one graphical and other that show the results on the command line, choose one of them. The JUnit 4 is not supported by iPOJO for now, so, we must to use JUnit 3.
  2. You must to have at least two bundles. One bundle is the normal implementation, that solves a problem. Other bundle, is a fragment bundle that has just the JUnit testes. You need to create a Fragment bundle referencing the bundle you want to test. To do this, just put Fragment-Host: <host bundle symbolic name> in the MANIFEST.MF file of the fragment bundle. The fragment bundle will see all classes of the host bundle, even that are not declarated public in the manifest file.
  3. In the fragment bundle, create the JUnit Test cases and a normal JUnit Test suite.
  4. In the host bundle, inform the "Test-Suite" parameter. Ex.: Test-Suite: com.edpichler.test.MySuite.
To run the tests, start the OSGi environment and go to the GUI of the Test Runner you choosed, and start the tests. If you choosed a command line test runner, the tests will start automatically.

See a example running in this example on GitHub.

Troubleshooting

If you are under Mac OS X, maybe have some problems to run the Swing Test Runner. This is because some dead lock problem in SWT/AWT native implementation related here.
Solution: Just put this additional argument to run without problems: --launcher.secondThread

References

  1. RCP Quick Start Blog. Accessed in 29, november 2010.
    RCP Quick Start Blog
  2. Apache IPojo Framework. Accessed in 29, november 2010.
    Apache IPojo Framework
  3. CBD on Wikipedia. Accessed in 29, november 2010.
    Component Based Development
  4. GitHub, Address Service Component project. Accessed in 29, november 2010.
    GitHub, Address Service Component project
  5. JUnit Framework. Accessed in 20, november 2010.
    JUnit Framework.
  6. Apache Felix. Accessed in 29, november 2010.
    Apache Felix
  7. OSGi Alliance. Accessed in 23, november 2010.
    OSGi Alliance