Desenvolvimento ELSA

Le BigoDay

2011-12-28T12:09:00.002-02:00

Dia do Bigode, Bigoday ou Mustache Day, são vários nomes para apresentar um movimento que dizem ter iniciado nos Estados Unidos após uma mobilização de alguns barbeiros pelo Mustache Day, este evento chegou ao Brasil por meio de publicitários, e é claro, que pessoas criativas e irreverentes como nós não podíamos ficar de fora.

No dia 19 de dezembro de 2011 aconteceu Le BigoDay Equipe de Desenvolvimento ELSA, sem medo de ser feliz, todos puderam participar do evento inclusive as meninas. Para registrar a data a Equipe dos Bigodões se reuniu em uma Comemoração de Fim de Ano no Instituto de Psicologia da UFRGS e fotografou esse encontro.

Atletas ELSA

2011-11-22T14:00:00.000-02:00

Fazendo parte de um estudo sobre saúde, estamos em continua preocupação com o bem-estar próprio. O esporte, então, acaba sendo uma das melhores opções para o mens sana in corpore sano. Alguns membros da equipe levam isso muito a sério e são também atletas. Dois deles foram documentados pelo RBS Esporte, em momentos distintos.

Tiago, o dançarino:

Gabriel, o "Runner" (a partir de 13:40):

Testes com Selenium WebDriver

2011-11-04T11:27:00.000-02:00

O Selenium WebDriver éa união de duas ferramentas e visa facilitar a criação de testes automatizadospara interfaces de aplicações web. A intenção das novas versões do Selenium (apartir da 2.0) é focar no desenvolvedor para que ele gere também os códigos dostestes. Neste post vamos explicar em alguns passos como começar a fazer seuspróprios testes.

No nosso exemplo vamos utilizar comolinguagem de programação o Java e como ambiente de desenvolvimento o Eclipse. Para executar os testes utilizaremos o JUnit.

O primeiro passo é adicionar os JARspara que consigamos utilizar o WebDriver. Para fazer o download da últimaversão vá até http://code.google.com/p/selenium/downloads/list. Descompacte o arquivo e adicione os JARs ao seuprojeto no Eclipse clicando com o botão direito do mouse em cima da raiz do seuprojeto e depois em "Properties".

No menu esquerdo clique em "JavaBuild Path", selecione a aba "Libraries" e clique em "AddExternal JARs...". Navegue até a pasta onde estão os arquivos que você fezdownload, selecione todos e clique em "Abrir". Depois clique em "OK".Pronto, você já pode começar a gerar seus códigos de testes!

A partir de agora começaremos o nossoteste. Neste exemplo vamos mostrar passo a passo como criamos um teste paraverificar a interface de autenticação do nosso sistema.

public class LoginTest {
 
 @Test
 public void loginTest() {
  WebDriver driver = new FirefoxDriver();
  driver.get("localhost:8080/elsa/login");
 }

}

Inicialmentenosso teste não verifica nada, apesar de ficar com a barra verde ele apenasabre uma janela do Firefox com o endereço do nosso servidor de testes.Roubamos... mas precisamos partir de algum lugar!

Apósverificar que a janela do navegador abriu corretamente a tela de autenticação dosistema vamos tentar realizar a autenticação.

public class LoginTest {
 
 @Test
 public void loginTest() {
  WebDriver driver = new FirefoxDriver();
  
  driver.get("localhost:8080/elsa/login");
  
  driver.findElement(By.id("username")).sendKeys("usuario");
  driver.findElement(By.id("password")).sendKeys("senha");
  driver.findElement(By.id("loginButton")).click();
 }

}

Como WebDriver buscamos pelos elementosexibidos na tela através dos seus identificadores e inserimos os valoresdesejados para usuário e senha. Além de buscar pelos elementos da página porseus id’s também é possível buscarpelo nome da tag, do name, do link e até mesmo do estilo CSS aplicado ao elemento.

Apartir daqui nos damos conta que em qualquer teste do nosso sistema teremos quepassar pela tela de login, então podemos utilizar o padrão chamado de PageObjects. Para tanto, criamos uma classe chamada LoginPage que inicialmente teráum método que fará login no sistema.

public class LoginPage {
 
 public void login(WebDriver driver){
  driver.findElement(By.id("username")).sendKeys("usuario");
  driver.findElement(By.id("password")).sendKeys("senha");
  driver.findElement(By.id("loginButton")).click();
 }
}

Eagora sim podemos realizar nosso teste, na classe LoginTest.

public class LoginTest {
 
 public LoginPage loginPage;
 public WebDriver driver;
 
 @Before
 public void setup() {
  loginPage = new LoginPage();
  
  driver = new FirefoxDriver();
  driver.get("localhost:8080/elsa/login");
 }
 
 @Test
 public void loginTest() {
  loginPage.login(driver);
  
  String welcomeMessage = driver.findElement(
    By.xpath("/html/body/div/div[4]/div/ul/li/span")).getText();

  assertEquals("Bem vindo ao Prontuário Eletrônico Online do ELSA.",
    welcomeMessage);
 }

}

Aqui já passamos a instanciarLoginPage e o WebDriver no método setupque está anotado com @Before e, destaforma, é executado sempre antes de cada método anotado com @Test. Além disso, buscamos o valor da mensagem de boas vindasatravés do método findElement eutilizamos como parâmetro a busca de um elemento presente na página pelo xpath correspondente. Finalmente,fizemos uma asserção para garantir que a mensagem que aparece é a esperada.

Agora que nosso teste estápronto executamos esperando a barra verde que instantaneamente fica vermelha,informando que o nosso teste falhou. Aqui vale uma breve explicação. Comoestamos trabalhando com ambiente web, devemos saber que nem sempre a resposta éimediata para as requisições feitas para os servidores onde estão asaplicações. Então o melhor a ser feito para contornarmos o problema éimplementarmos uma condição esperada de parada com um timeout, desta maneira o teste pode ser executado com mais confiabilidade.

Para tanto, será necessáriosfazer algumas mudanças no método loginTest.

@Test
public void loginTest() {
 loginPage.login(driver);
  
 ExpectedCondition<boolean> expectedCondition = new ExpectedCondition<boolean>() {
  public Boolean apply(WebDriver webDriver) {
   webDriver.findElement(By.xpath("/html/body/div/div[4]/div/ul/li/span"));
   return true;
  }
 };

 Wait<webdriver> wait = new WebDriverWait(driver, 15);
 wait.until(expectedCondition);
  
 String welcomeMessage = driver.findElement(
    By.xpath("/html/body/div/div[4]/div/ul/li/span")).getText();

 assertEquals("Bem vindo ao Prontuário Eletrônico Online do ELSA.",
    welcomeMessage);
}

Agorasim, nosso teste é executado e temos a barra verde!

Basicamenteimplementamos a condição de parada esperada que, neste caso, é o surgimento daprópria mensagem de boas vindas do sistema. Depois, instanciamos o wait com o nosso driver e um timeout de 15segundos e esperamos que a condição seja satisfeita por no máximo 15 segundos,caso contrário o teste falhará.

Claroque o exemplo depende das credenciais utilizadas para realizar o login e apenasele não garante que a tela de login do nosso sistema está funcionando. Comoteste complementar podemos acessar o sistema com uma senha errada e fazer umaasserção em cima da mensagem de falha de login.

PrimeFaces autoComplete weird behavior

2011-11-01T16:34:00.000-02:00

A few weeks ago, while changing the behavior of an auto-complete field we have in our system, I came across a very weird bug. The field was supposed to suggest a list of Technicians, based on the name the user typed.

I was asked to have it accept not only the name of the Technician but also their ids.

To make the long story short: we are using a PrimeFaces AutoComplete component with the forceSelection flag set to true.The problem was that even tough the user did not selected any of the suggestions on the list, the value he typed was still being submitted to the form.

At first this was not a problem, because our Converter is using the Technician id, and when searching for a name, there was no match. But when the search includes the id, undesired thing happens, i.e. the field which as supposed to be empty, was filled with the Technician's information whose id the user typed.

With the help of Firebug, I found out that the hidden input Primefaces uses to implement the auto-completion, was not being cleaned when none of the suggestions was picked, thus, submitting a value the user didn't know was there.

To solve the problem, I hacked into Primefaces's jar, and, after formatting the autocomplete.js with the help of my friend Eclipse, I found this line:

jQuery(this).val("");

On a lucky/educated guess, I added the following line below that one:

jQuery(a.jqh).val("");

After repacking the jar, the problem was gone. I am not sure if this is a bug or the correct behavior, but it happened in Primefaces version 2.2.1.

Presentation Layer Validation: Bean Validation Within JSF 2.0

2011-09-22T18:29:00.000-03:00

This week, at Elsa Development, we’ve been implementing some customized validators using Bean Validation API. Everything was going fine, until the shadows of Murphy appear. OK, putting aside the drama, a few validators have been implemented successfully, passing all tests, all of them but one...

The Problem

Two constraints were created and for each one, a validator was implemented (which executes the validation logic). Both constraints were used at field-level on JPA entities, the Username and FloatRange constraints were annotated on fields of type string and float, respectively. However, just the Username constraint worked.. Hereunder you can take a look at the implemented code, or part of it :)

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = UsernameValidator.class)
@Target({
    ElementType.METHOD,
    ElementType.FIELD,
    ElementType.ANNOTATION_TYPE
})
public @interface Username {
    String message() default "{constraint.username.invalid}";
    Class<? extends Payload>[] payload() default {};
    Class<?>[] groups() default {};
}

Code 1. The working constraint.

public class UsernameValidator
        implements ConstraintValidator<Username, String> {
    @Override
    public void initialize(Username annotation) {}

    @Override
    public boolean isValid(String value,
            ConstraintValidatorContext context) {
        // validation logic ommited
    }
}

Code 2. The validation for @Username constraint.

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = FloatRangeValidator.class)
@Target({
    ElementType.METHOD,
    ElementType.FIELD,
    ElementType.ANNOTATION_TYPE
})
public @interface FloatRange {

    String message() default "{constraint.range}";
    Class<? extends Payload>[] payload() default {};
    Class<?>[] groups() default {};
    float min();
    float max();
}

Code 3. The “murphyfied” constraint (i.e. did not work).

public class FloatRangeValidator
        implements ConstraintValidator<FloatRange, Float> {
    private float min;
    private float max;
 
    @Override
    public void initialize(FloatRange annotation) {
        this.min = annotation.min();
        this.max = annotation.max();
    }

    @Override
    public boolean isValid(Float value,
            ConstraintValidatorContext context) {
        // validation logic ommited
    }
}

Code 4. The “murphyfied” constraint.

The Solution

After a lot of googling and force brute tests... A co worker (Marcelo Yamashita) came with the solution. He tried to use the @FloatRange constraint at property-level, man... that worked! Then, reading more carefully the Hibernate Validator documentation, more specifically the item 2.1.1. Field-level constraints, i noticed the note that says:

Static fields and properties cannot be validated.

Well, if i've got it right, by properties it means POJO fields which have getter/setter, or not? If so, then houston, we have a problem... both target annotated fields, belong to JPA entities thus, they have getters and setters! It doesn’t make them properties? Anyway, the workaround rocks, but if you have any idea about the why this happens, please, feel free to share it with the world :)

Test Party

2011-09-09T14:17:00.000-03:00

Inspirados em uma Lightening Talk assistida por alguns membros da equipe, realizamos uma Test Party (ou Testing Day, como também é conhecido). Uma Test Party consiste em um momento onde todos os envolvidos no desenvolvimento (desenvolvedores, QA, "gerência", e P.O.s) realizariam testes no sistema, em busca de possíveis erros, de forma que estes não cheguem à produção. O uso de pontuação e gratificação ao final serviriam como estímulo aos participantes.

No nosso caso, participaram as equipes de desenvolvimento e QA. O objetivo era deixar o sistema mais confiável e aumentar a interação das equipes com o sistema do ponto de vista de usuário e não de desenvolvedor.

Os participantes foram organizados em duplas através de sorteio. As regras foram então apresentadas para as duplas:

- O que testar? Deixamos livre a decisão sobre o que cada dupla iria testar, pois o sistema possui diferentes funcionalidades e, portanto, havia a possibilidade de que a intersecção dos erros encontrados fosse pequena.

- Como testar? Os testes seriam feitos manualmente, de acordo com um objetivo da dupla (realização de uma tarefa no sistema) ou focados na funcionalidade sendo testada. Casos de teste ou erros encontrados poderiam ter scripts de reprodução/automatização criados.

- Pontuação: 1 ponto para bug encontrado, 2 pontos para caso de teste automatizado, e 3 pontos para script que reproduza o bug. A ferramenta utilizada foi o Selenium IDE (pela facilidade e agilidade no uso).

- Gratificação: chocolate para a dupla vencedora.

- Juiz: uma analista de QA foi designada como juiza, confirmando se o comportamento encontrado era de fato um erro e atribuindo os pontos para cada dupla.

Todos entraram no clima de competição e cada ponto obtido era comemorado pelas duplas. A dinâmica foi bem recebida pela equipe, que se empenhou em fazer bons testes, com mais probabilidade de encontrar erros.

Algo interessante foi o pouco overlap que ocorreu entre os bugs encontrados, pois cada equipe explorou aspectos diferentes do sistema. Até mesmo em áreas exploradas por mais de uma dupla, diferentes bugs foram encontrados por cada uma. Isso ocorreu não necessariamente pela quantidade de erros naquela região, mas pelo tipo de abordagem de cada dupla.

Em retrospectiva com as equipes, após a "festa", reflexões sobre os pontos positivos e negativos foram feitas. A técnica ajudou os desenvolvedores a sair da zona de conforto e ter contato com problemas que os usuários enfrentam durante o uso. Mesmo com a reformulação do sistema e a aplicação de boas práticas de desenvolvimento, foi possível ver que somente estas não resolvem todos os problemas, e erros podem "escapar" e chegar ao usuário final. A ideia é que o raciocínio utilizado para encontrar os erros seja aplicado na programação, evitando que se repitam.

Sugestões para as próximas edições incluem:

- Cada dupla ter definidos os seus usuários e os seus participantes específicos para os testes, para não haver conflitos;

- A versão do sistema que será utilizada para os testes deve ser implantada com maior antecedência;

- Definir horário de início e fim, ao invés de aguardar que as duplas terminem suas tarefas;

- Fazer a "festa" fora do horário de expediente para que todos possam se dedicar sem ficar preocupados com as tarefas que "deveriam estar fazendo". Fazendo fora do expediente também permite um clima mais informal, sem pessoas entrando na sala e estranhando as tiaras coloridas e o "clima de festinha" em pleno expediente.

Os erros encontrados foram registrados na nossa ferramenta bug tracker (com seus respectivos scripts de reprodução), geraram tarefas para programação e estão em fase de correção.

A técnica gerou bons resultados e teve feedback positivo. Muitos dos bugs encontrados já foram resolvidos, o uso do Selenium foi incentivado e membros que ainda não o utilizavam com frequência passaram a usar.

Aguardemos então as próximas edições. :)

Tutorial de Instalação do dcm4chee

2011-09-06T09:12:00.000-03:00

O dcm4chee é um PACS open source que implementa o padrão DICOM. Ele é compatível com diferentes SGBD’s (MySQL, PostgreSQL, Oracle, etc.) e sistemas operacionais (Windows, Linux e Mac OS).

Neste tutorial vamos descrever a instalação do dcm4chee 2.17.0 em sua versão para o PostgreSQL na plataforma Windows 7 (32 bits). A instalação num ambiente diferente deste pode requerer configurações extras, não descritas neste tutorial.

1. Requisitos básicos

JDK versão 5 ou superior

As instruções de instalação da JDK 6 e a configuração da variável de ambiente JAVA_HOME estão disponíveis aqui.

PostgreSQL

Apesar de já disponível, a versão 9 do PostgreSQL exige configurações extras não abordadas neste tutorial. Recomendamos a versão 8.4, cujas instruções de instalação estão disponíveis aqui.

2. Downloads

JBossAS

O dcm4chee roda sobre o servidor de aplicação JBoss 4.2.3 GA, especificamente. Faça o download do JBoss do site oficial através deste link: jboss-4.2.3.GA.zip.

dcm4chee

Faça o download do dcm4chee em sua versão para o PostgreSQL do site oficial através deste link: dcm4chee-2.17.0-psql.zip.

ARR

O dcm4chee permite a auditoria das operações realizadas, como transferência de arquivos, buscas, etc. Porém esta funcionalidade está num módulo separado, o Audit Record Repository (ARR). Faça o download do ARR em sua versão para o PostgreSQL do site oficial através deste link: dcm4chee-arr-3.0.11-psql.zip.

3. Estrutura de pastas

Descompacte os arquivos baixados na seção anterior numa pasta de sua preferência. É importante o caminho da pasta não conter espaços, pois isto pode acarretar em erros na instalação.

No exemplo deste tutorial vamos extraí-los na pasta “C:\dicom”. Assim, teremos a estrutura de pastas da figura abaixo:

4. Bases de dados

pacsdb

Para criar a base de dados utilizada pelo dcm4chee, abra o prompt de comando e execute o comando “createdb” passando o nome da nova base de dados, “pacsdb”. No exemplo deste tutorial o comando fica assim: “createdb -U postgres pacsdb”.

O parâmetro “postgres” é o usuário utilizado para conectar no banco de dados, no caso o super-usuário, por questões de permissão. O mesmo será passado como parâmetro nos comandos seguintes.

O script de criação das tabelas e outras estruturas da base de dados “pacsdb” está disponível no arquivo “create.psql”, presente na pasta “sql”, dentro da pasta raiz de instalação do dcm4chee.

Execute o comando “psql” passando como parâmetros o nome da base de dados, “pacsdb”, e o arquivo que contém o script. No exemplo deste tutorial o comando fica assim: “psql -d pacsdb -U postgres -f C:\dicom\dcm4chee-2.17.0-psql\sql\create.psql”.

arrdb

O ARR possui sua própria base de dados, de nome “arrdb”. Para criar esta base de dados, no prompt de comando execute o comando “createdb” passando o nome da nova base de dados, “arrdb”. No exemplo deste tutorial o comando fica assim: “createdb -U postgres arrdb”.

O script de criação das tabelas e outras estruturas da base de dados “arrdb” está disponível no arquivo “dcm4chee-arr-sql.ddl”, presente na pasta “sql”, dentro da pasta raiz de instalação do ARR.

Execute o comando “psql” passando como parâmetros o nome da base de dados, “arrdb”, e o arquivo que contém o script. No exemplo deste tutorial o comando fica assim: “psql -d arrdb -U postgres -f C:\dicom\dcm4chee-arr-3.0.11-psql\sql\dcm4chee-arr-sql.ddl”.

Permissões

Para que o dcm4chee e o ARR consigam acessar as suas bases de dados é preciso configurar as respectivas conexões no arquivo “pg_hba.conf”, localizado na pasta “data” dentro da pasta raiz de instalação do PostgreSQL.
No exemplo deste tutorial é a pasta: “C:\Program Files\PostgreSQL\8.4\data”.

Neste arquivo adicione as linhas:

host    pacsdb      postgres    127.0.0.1/32          trust
host    arrdb       postgres    127.0.0.1/32          trust

Logo acima da linha:

host    all         all         127.0.0.1/32          md5

Conforme a figura abaixo.

Salve o arquivo. Esta configurção dá permissão de acesso às bases de dados pacsdb e arrdb para o usuário “postgres” (utilizado pelo dcm4chee e pelo ARR por padrão) para conexões solicitadas pelo IP local (127.0.0.1). Para outras conexões é solicitada a senha do usuário.

5. Scripts finais de instalação

O próximo passo da instalação do dcm4chee é rodar o script “install_jboss.bat”, localizado na pasta “bin” dentro da pasta raiz de instalação do dcm4chee, passando a pasta raiz de instalação do JBoss como parâmetro. No exemplo deste tutorial o comando para executar este script fica assim:
“install_jboss C:\dicom\jboss-4.2.3.GA”.

Este script vai integrar o dcm4chee com o JBoss, copiando arquivos deste último para a estrutura de pastas do dcm4chee.

Para completar a instalação, temos de rodar o script “install_arr.bat”, localizado na pasta “bin” dentro da pasta raiz de instalação do dcm4chee, passando a pasta raiz de instalação do ARR. No exemplo deste tutorial o comando para executar o script fica assim: “install_arr C:\dicom\dcm4chee-arr-3.0.11-psql”.

Este script vai integrar o dcm4chee com o ARR, copiando arquivos deste último para a estrutura de pastas do dcm4chee.

Pronto. A instalação está completa.

6. Testando a instalação

Para testar a instalação, execute o script “run.bat”, localizado na pasta “bin” dentro da pasta raiz de instalação do dcm4chee. Este script vai inicializar o servidor dcm4chee.

Se todos os passos anteriores deram certo, não haverá mensagem de erro (ERROR) na console, apenas informativas (INFO), como na figura abaixo.

Para testar o dcm4chee, acesse a URL “http://localhost:8080/dcm4chee-web” no seu navegador. Faça o login com o usuário “admin” e senha “admin”.

Para testar o ARR, clique no link “Audit Repository”. Forneça o usuário “admin” e a senha “admin”.

Para parar o dcm4chee pressione as teclas Ctrl + C na console onde o dcm4chee foi inicializado.

7. Configurações adicionais

Permissões do sistema de arquivos

Para configurar as permissões de escrita e leitura do dcm4chee no sistema de arquivos do Windows, acesse a URL “http://localhost:8080/jmx-console” no seu browser (o dcm4chee tem de estar inicializado). Forneça o usuário “admin” e a senha “admin”.

Selecione o link “group=ONLINE_STORAGE, service=FileSystemMgt”, sob o cabeçalho “dcm4chee.archive”.

Localize o cabeçalho “addRWFileSystem()”

Clique no botão “Invoke”.

Instalar o dcm4chee como serviço

Para não ter de executar o comando “run” a cada vez que for utilizar o dcm4chee, você pode instalá-lo como um serviço do Windows. Assim, ele será inicializado a cada vez que o Windows iniciar.

Para tanto, execute o script “install_service.bat”, localizado na pasta “bin” dentro da pasta raiz de instalação do dcm4chee, passando o parâmetro “service”.

Se receber uma mensagem de acesso negado, abra o prompt de comando como administrador (clique com o botão direito do mouse sobre o ícone do prompt de comando e selecione a opção “Executar como administrador”) e tente novamente.

Instalação do PostgreSQL

2011-09-02T15:07:00.000-03:00

Neste tutorial vamos instalar o PostgreSQL 8.4 no Windows 7 Professional.

Faça o download da versão 8.4.8-1 para Windows do PostgreSQL:

http://www.enterprisedb.com/products-services-training/pgdownload

Execute o instalador baixado (arquivo postgresql-8.4.1-1-windows.exe).

Aparecerá a tela de boas vindas.

Clique no botão “Next”.

Será solicitada a escolha de um diretório raiz para a instalação do PostgreSQL. Por padrão a instalação ocorre no diretório “C:\Program Files\PostgreSQL\8.4”.

Clique no botão “Next”.

Será solicitada a escolha de um diretório de armazenamento dos dados do banco. Por padrão a instalação ocorre no diretório “C:\Program Files\PostgreSQL\8.4\data”.

Clique no botão “Next”.

Será solicitada a escolha da senha do super-usuário do banco de dados. Digite a senha escolhida e repita-a no segundo campo para a confirmação.

Clique no botão “Next”.

Será solicitada a escolha do número da porta, a ser utilizado por outras aplicações para conectarem-se ao banco de dados. Recomenda-se deixar o padrão 5432.

Clique no botão “Next”.

Na próxima tela será solicitada a escolha da localidade, para as configurações de linguagem da interface e formatos de data. Selecione “Portuguese, Brazil”. Nesta mesma tela você também pode escolher se deseja que a linguagem pl/psql seja instalada.

Clique no botão “Next”.

A próxima tela apenas informa que o instalador está pronto para iniciar a instalação.

Clique no botão “Next”.

Aguarde a instalação terminar.

Clique no botão “Next”.

Pronto, a instação está conculída. Caso queira instalar complementos ao PostgreSQL deixe marcada a opção “Launch Stack Builder at exit?”. Senão, desmarque esta opção.

Clique no botão “Finish”.

A partir de agora você pode gerenciar seu banco de dados através da aplicação pgAdmin, que oferece uma interface gráfica pra tanto.

Você também pode gerenciá-lo através do prompt de comando, chamando o comando “psql” na pasta “bin” dentro do diretório de instalação do PostgreSQL (para o diretório padrão da instalação, é a pasta “C:\Program Files\PostgreSQL\8.4\bin”).

No exemplo abaixo, estou chamando o comando psql passando o nome do usuário “postgres” como parâmetro. Para maiores detalhes sobre os parâmetros, chame o comando “psql --help”.

Para mostrar a lista de comandos do psql digite “\?”. Para mostrar a lista de comandos SQL digite “\h”. Para sair do psql digite o comando “\q”.
Para executar o psql de qualquer diretório, adicione o caminho da pasta “bin” do PostgreSQL à variável de ambiente “Path” do Windows.

A mensagem de aviso da imagem acima ocorre porque a página de código padrão do prompt de comando do Windows difere da utilizada pelo psql. Para evitar este problema, temos de alterar a página de código do prompt de comando do windows. Para isso, antes de chamar o psql, digite o comando "cmd /c chcp 1252".

Isto vai recarregar o prompt de comando com a página de código utilizada pelo psql. Porém, a fonte padrão do prompt de comando não é adequada para esta página de código, tendo de ser alterada. Para tanto, clique com o botão direito do mouse sobre a barra superior da janela e selecione a opção "Propriedades".

Na aba "Fonte", selecione a fonte "Lucida Console" e clique no botão "OK".

Pronto, agora você pode chamar o comando psql sem problemas.

All Tests?

2011-06-09T14:00:00.000-03:00

Uma das características mais presentes no nosso dia-a-dia de desenvolvimento é a interiorização de práticas de integração contínua. Todos temos o hábito de baixar para a própria máquina todos os códigos-fonte, no início do dia. Trabalhar sobre eles até que, ao final do dia, seja feito upload/commit das modificações. Sem erros, claro.

No entanto, acabamos descobrindo esses dias que algumas vezes a prática de subir para o servidor os novos códigos estava quebrando a regra de termos apenas códigos 100%. Nos cobramos mutuamente na retrospectiva, mas não tínhamos a detecção real do problema.

Eis que alguém resolveu dar uma olhada no AllTests e descobriu o real problema: nem todas as novas classes de teste estavam sendo adicinoadas lá. Com isso, alguns testes não estavam sendo executados, e erros não estavam sendo encontrados. Se uma solução rápida seria atualizar a suíte de teste, decidimos por uma ainda mais ágil: apagar a suíte.

Por mais que a decisão pareça radical, ela é simples: ao invés de mandar rodar o AllTests, usamos o botão direito em cima da fonte de código com os pacotes de teste e um "Run As..". Esse procedimento executa absolutamente todos os testes, no Eclipse. Agora, voltamos a ter certeza que o servidor está 100%.

Integração de Componentes PrimeFaces

2011-06-01T15:08:00.001-03:00

Esses dois trechos parecem equivalentes, né?

Trecho 1:

 
 <f:facet name="header">
     #{gen['th.user']}
 </f:facet>
 <h:outputtext value="#{entry.user.name}"/>

Trecho 2:

 
 <f:facet name="header">
     <h:outputtext value="#{gen['th.user']}"/>
 </f:facet>
 <h:outputtext value="#{entry.user.name}"/>

Mas não são. O primeiro vai mostrar na tela direitinho. Mas não vai necessariamente integrar bem com outros componentes Primefaces, como o exportador de pdf. Essa é um exemplo das várias recomendações da maioria dos tutoriais de JSF: sempre que for escrever algo na tela, use um componente pra isso. No mínimo vai facilitar a integração.

Fica a dica.

Brilhando no Facool

2011-04-11T11:02:00.001-03:00

Transitar entre o campus não é mais passar em branco, sem ser percebido. Agora, sair para pegar um sol é ser alvo de paparazzi. Nas fotos, Amanda, Carolina, Diogo e Luciano. Os originais estão em lá no site do Facool.

Seleção ELSA

2011-03-10T17:44:00.000-03:00

A seleção que está em andamento para o preenchimento de vagas, prevista para encerrar amanhã (10/03), será prorrogada por mais alguns dias, devido a grande procura.

Sistema de Coleta Versão 1.0

2011-01-11T20:47:00.001-02:00

A última implantação no servidor de produção de 2010 acabou sofrendo com final de semestre e festas de fim de ano e virou a primeira de 2011. Com ela, finalmente, a versão 1.0 do sistema de coleta de dados. Pensando que a primeira funcionalidade usada foi liberada em dezembro de 2008, essa distância de tempo é sucesso ou fracasso?

Do ponto de vista extremamente tradicional, poderia ser avaliado como fracasso, pois alguns centros do estudo já não estão coletando dados diretamente com os participantes. Contudo, a natureza incremental do desenvolvimento, associado a uma definição de prioridades pelo product owner, gerou diferentes implantações que foram agregando valor desde a primeira liberação.

O trabalho não acabou. A cadeia de produtos para estudos epidemiológicos que estamos criando sempre traz novidades para serem implementadas. No entanto, é bom saber que chegamos à totalidade dos formulários e funcionalidades de coleta. Que arredondamos o número da versão para 1.0. Porém, o melhor de tudo, é saber que os seis centros não estavam parados a espera da primeira versão do software. É comprovar na prática que o ROI já vinha sendo percebido a bem mais tempo.

Java programmer positions for foreign students / visiting professors

2010-09-21T15:02:00.000-03:00

The ELSA-Brasil project (Longitudinal Study of Adult Health - Brazil) is a
multi-center cohort study now completing its baseline visit of 15 000
employees of public universities and research centers of southern,
southeastern and northeastern Brazil: FIOCRUZ, UFBA, UFES, UFMG, UFRGS and
USP). Its objective is to investigate the development of chronic diseases,
especially cardiovascular problems and diabetes. Part of the project´s
activities has been and will continue to be the development of a web-based
data management system and an accompanying PACS for image transmission.

The data system is based on Java technology and has been developed in Porto
Alegre - RS - Brazil by a team using agile methods (Scrum+XP) in a
distributed architecture.

ELSA-Brasil is offering short term positions within the context of academic
interchange for Java software developers with experience in
building enterprise web applications. This will include coding, unit
testing, using design patterns, learning new technologies, and having
a lot of fun doing it.

We are looking for individuals in an academic setting
- with a bachelor´s degree in computer science or a related field or
- pursuing an undergraduate degree in computer science or a related course

Required Skills:
- OO design
- Java (J2EE)
- Unit Testing (JUnit)
- Fluency in English or Portuguese
- Teamwork and communication skills

Desired Skills:
- EJB
- JSF
- Selenium

We can offer financial support to cover plane flight and living expenses in
Porto Alegre.

If interested please submit a letter summarizing your circumstances and
explaining your interest, accompanied by your CV, in English or Portuguese,
to Emerson Hernandez in the address below.

ELSA no CBIS

2010-09-01T08:25:00.000-03:00

De 18 a 22 de outubro vai acontecer em Porto de Galinhas, Pernambuco, o XII Congresso Brasileiro de Informática em Saúde (CBIS). O ELSA vai se fazer presente lá com um artigo explicando um pouco da arquitetura do sistema dentro do contexto de sistemas de informação na área de epidemiologia. Se você não puder ir até lá prestigiar a apresentação, ou quer entender um pouco do que a gente faz, segue abaixo o nosso resumo.

O projeto ELSA (Estudo Longitudinal de Saúde do Adulto) é um estudo de coorte multi-cêntrico que incluirá em sua totalidade 15 mil funcionários de instituições públicas de ensino superior das regiões sul, sudeste e nordeste do Brasil (FIOCRUZ, UFBA, UFES, UFMG, UFRGS e USP). Seu objetivo é investigar o desenvolvimento de doenças crônicas, principalmente problemas cardiovasculares e o diabetes. Dentro das atividades do projeto está incluído o desenvolvimento de um sistema de coleta de dados, cujo objetivo é dar suporte às atividades do projeto. Este sistema foi construído por uma equipe utilizando métodos ágeis em uma arquitetura distribuída. Esta arquitetura é dividida em módulos que compõem o sistema e foi sofrendo contínuas evoluções conforme as necessidades do usuário e da implementação. Com a evolução do sistema e da equipe, foi possível perceber como o desenvolvimento incremental e iterativo de software auxiliou na criação de uma arquitetura consistente.

Treinamento Java

2010-08-05T17:52:00.000-03:00

Dos dias 12 a 27 de julho, dois membros da equipe tiveram a oportunidade de passar adiante um pedaço do conhecimento adquirido no desenvolvimento do sistema ELSA, ministrando um curso para a CR Sistemas e Web, de Taquara. O pessoal presente ao curso era composta de analistas, programadores e testadores, assim como pessoal de suporte. Os assuntos abordados incluiram tópicos desde as bases de Orientação a Objetos até JEE usando tecnologias como JBoss Seam.

Atividades de apresentações internas já foram usadas algumas vezes na equipe de desenvolvimento. Essa, porém, foi a primeira vez que a colocamos em um ambiente externo. A experiência foi extremamente gratificante e agora estamos na espera dos resultados práticos deste treinamento no dia-a-dia da equipe da CR.

Desenvolvimento ELSA no Agile Brazil 2010

2010-06-29T20:16:00.000-03:00

Nos dias 24 e 25 de julho, Porto Alegre sediou o Agile Brazil 2010. É sempre muito interessante ter cabeças pensantes reunidas em um mesmo lugar para trocar experiências. Ainda mais com visitas ilustres como Martin Fowler, que fez o primeiro keynote do evento. Sendo em Porto Alegre, foi também uma ótima oportunidade de reencontrar alguns amigos que acabo vendo pouco.

A equipe do desenvolvimento estava presente quase que em sua totalidade. Números oficiais do evento informavam cerca de 800 inscritos, fazendo com que o ELSA representasse 1% de todo mundo. Na foto ao lado, metade do time em um pequeno registro feito pelo @flaviosteffens: Émerson, Nadjia, Daniel e Diego.

Passado algum tempo do evento, acho que o principal efeito que ficou na comunidade que participou das atividades foi a vontade de fazer. Todos com muitas ideias e empolgação. Acho que até por isso a expectativa de que o do próximo seja ainda melhor que esse, principalmente nas trilhas praticante/experiente.

Animação sobre Motivação

2010-06-07T13:49:00.000-03:00

Em agosto do ano passado escrevi um post sobre um vídeo que havia assistido sobre Autonomia, Domínio e Propósito. Agora descobri uma nova versão, em animação, que vale muito a pena: "RSA Animate - Drive: The surprising truth about what motivates us".

Foco nas Pessoas

2010-04-28T13:25:00.000-03:00

O Chaos Report do ano passado mostrou que apenas 32% dos projetos em TI são bem-sucedidos. Segundo a tabela comparativa (e aqui embaixo reproduzida em apenas uma linha) retirada de uma entrada do site Project Smart, houve um decréscimo em relação a 2006 (de 35% para 32%), mas uma melhora significativa em relação à década passada (de 16% para 32%).

As explicações são muitas. O post de onde essa tabela foi retirada aponta como uma das grandes vantagens o aumento de profissionais certificados. Esse argumento é base pra uma briga boa que encontra como principal confrontador o Uncle Bob. Ninguém tem dúvida que existe muita gente a favor das letrinhas mágicas (uma rápida olhada nos seus contatos do LinkedIn prova isso). Mas, será que são as certificações que fazem diferença?

O sucesso de nosso último release foi, para mim, baseado em dois aspectos. Primeiramente, diferente de algumas outras vezes a iteração foi bem-definida e executada. Adicionalmente, criamos o desafio de mudar algumas tecnologias para outras que já havíamos avaliado como melhores do que as que estavamos usando. Depois de muito tempo de "nessa iteração não temos tempo para migrar", definimos em conjunto pela mudança. Esse motivador surgiu da equipe. Resultado final: software entregue no prazo, com todas as funcionalidades e com melhora no processo de desenvolvimento, através de novas práticas e tecnologias. O que será que mudou? Ninguém foi certificado em nada de um release para o outro...

Para mim, a resposta para o sucesso está em uma das bases do Manifesto Ágil foi cumprida: "valorizar: 1. Indivíduos e interação entre eles mais que processos e ferramentas". A equipe tinha uma clara ideia do que deveria ser feito, sem pendências de requisitos. As funcionalidades foram entregues para teste em tempo hábil e está sendo colocado a campo para gerar feedback em situações reais. A comunicação entre essas duas "equipes" e o trabalho que elas devem executar para garantir um bom software foi valorizado acima de tempo ou prazo. Mesmo havendo troca de ferramenta, ela foi feita como desafio para os desenvolvedores, ou seja, foi encaminhada como motivador da curiosidade natural de quem trabalha com programação, ao invés de imposição de alguém. Ou seja, independente de como é feito, de qual tecnologia é usada, os sistemas sempre serão baseados em pessoas e elas são o verdadeiro kernel de qualquer projeto.

Acentos no século XXI

2010-03-18T15:56:00.000-03:00

É incrível como alguns serviços ainda não conseguem trabalhar com acentos. Minha surpresa, hoje, foi descobrir que eu baguncei a vida do SVN para todos os arquivos que fiz upload. Assim, para você, que como eu, acabou colocando acento e tem de voltar atrás para trocar o seu nome na integração Eclipse + SVNKit a dica é a seguinte:

apague o arquivo .keyring que fica no diretório ECLIPSE_HOME/configuration/org.eclipse.core.runtime/

Outras alternativas como eclipse.exe -vmargs -Duser.name=”usuario” NÃO vão funcionar. Ele até troca o valor do @author, mas não atualiza a conexão com o servidor.

Burj Al Arab e a casa do cachorro

2010-02-25T17:17:00.000-03:00

Esse é um assunto que está batendo na minha cabeça faz algum tempo e acho que agora consegui dar uma certa forma, encontrando a metáfora correta: Burj Al Arab e a casa do cachorro.

O Burj Al Arab é um dos pináculos da engenharia. Belo, sofisticado, bem planejado, robusto, seguro e pensado para satisfazer aos mais exigentes. Enfim, um pedaço do paraíso (para os que acreditam).

E a casa de cachorro? Bom, é aquela singela construção que lembra uma casa mas que, bem, só serve ao cachorro e não imagino agradar nem a ele.

Mas porque trazer essas duas imagens? Porque quero abordar desenvolvimento de programas e sistemas que muitas vezes oscilam entre o Burj Al Arab e a casa de cachorro. Nos falta (me refiro aos desenvolvedores) uma melhor organização e (agora para pânico de muitos) regulamentação. Por que temos tanto preconceito com a regulamentação da profissão? Alguém já imaginou comprar uma casa (ou mesmo morar numa) que não tenha uma planta baixa? Que não tenha um engenheiro responsável? Alguém aceitaria ser operado por um pedreiro (infelizmente sim com as inúmeras cirurgias espirituais, mas estou digredindo)? A resposta, para a maioria das pessoas, seria não para ambas as perguntas. Todos querem que alguém assuma as responsabilidades e que os profissionais tenham sido aprovados por um órgão regulamentador. Então por que se aceita que alguém não cientista da computação faça o sistema web da sua empresa?

A razão é simples, o cliente quer um Burj Al Arab mas para isso pagar como se fosse uma casa de cachorro.

Outro ponto em que esta metáfora se aplica é quanto ao processo de desenvolvimento. É razoável que se espere o concreto secar para se iniciar os trabalhos de interiores. Ninguém, em sã consciência, aceitaria que se levantassem paredes sem que as fundações estejam prontas e devidamente verificadas. Não se coloca o telhado antes das paredes. Não se assume que: "bom, se não ficar de pé tentamos mais uma vez" seja uma metodologia aceitável. Posso mandar o meu "faz-tudo" de plantão montar uma casa para o meu cachorro e se não der certo, bom, faz-se outra. Se a entrada ficar pequena para o cachorro? Desgaste-se a entrada até ele passar. Se na primeira chuva a casinha se enterrar na lama do quintal? Azar, amanhã colocamos umas pedras para ver se resolve.

Acho que ficou claro o paralelo. Hoje vemos sistemas sendo construídos como se fossem casa de cachorro: sem planejamento, sem uma visão de vida útil, sem responsabilidade. O que é nosso é de ninguém. Qualquer um que sabe um pouco de estrutura de dados se julga desenvolvedor de programas. O mercado está tão saturado de "faz-tudo" que ninguém está prestando atenção nos verdadeiros engenheiros. Mas o que observo é que todos esperam um Burj Al Arab. Ainda não se entendeu que isso só é possível quando o profissional é capacitado e experiente e que custa caro, MUITO caro. Qualquer um faz uma casinha de cachorro. Basta ver as atrocidades cometidas em JavaScript, PHP, Java EE, etc.

Para mim é uma aberração escutar que site X e Y foram vitimas de SQL Injection. A reação que tenho é a mesma que tive quando soube do caso do Palace I e II no Rio de Janeiro. Como é que pode um sistema sofre com um ataque tão ridículo? É o mesmo que um prédio cair por erro de cálculo estrutural (o B-A-BA do engenheiro civil). É como um médico amputar a perna errada de um paciente.

Isso deveria ser visto como uma aberração e o profissional ser afastado pelo resto de sua vida de suas funções.

Não acho natural aceitar que se desenvolva sistemas como se fossem casas de cachorro. O que parece ser a prática comum, principalmente com prazos no mínimo otimistas que gerentes de projeto impõem. Este normalmente são dotados de um total desprendimento ou mesmo noção da realidade do que é desenvolvimento de software.

A realidade está batendo na porta: 1.000.000 de "faz-tudo" não irão construir um Burj Al Arab e os melhores engenheiros do mundo tampouco o farão em 2 anos. No final das contas não existe mágica: o teu sistema será tão bom quanto os profissionais que se tem a disposição e que condições se aplica ao desenvolvimento.

Abraços,

Gustavo

Retrospectiva do Ano

2009-12-21T10:54:00.000-02:00

Se você está acostumado aos métodos ágeis, sabe que feedback é um dos valores fundamentais. Ele é dado em diferentes momentos e, de forma sistemática, aparece a cada final de iteração no que se convencionou chamar retrospectiva.

Fora da informática esse termo não é incomum. Todos os meios de comunicação, por exemplo, fazem retrospectivas do ano. Ali eles apresentam todos os fatos que consideraram relevantes. No contexto de desenvolvimento de sistemas, a ideia é pegar a informação do time de desenvolvimento. Sem limitação sobre os assuntos.

Normalmente as nossas retrospectivas são feitas verbalmente com auxílio de papel e caneta. Pela primeira vez, resolvemos fazer um período maior que o sprint e usando post-its. Dessa vez, fizemos para o ano todo, separando a parede em três grandes colunas rotuladas como: "Boas", "Não Funcionaram" e "A Melhorar".

O funcionamento da atividade é simples. Vários post-its e canetas a disposição de todos. Cada um do time escreve o que quiser. Todos tem direito de ler o que os outros escreveram, assim como repetir o que já foi apontado, para reforçar alguma ideia. Depois do número de colagens na parede ter estabilizado, vem a rodada de comentários sobre os pontos levantados.

O resultado foi ótimo. O fortalecimento das relações da equipe foram repetidamente ressaltadas. Mais do que isso, aquilo que não funcionou além de identificado, foi analisado. Sem exceção, tudo relacionado a segunda coluna recebeu propostas de alteração para que efetivamente sejam melhor praticadas. Ainda estamos compilando os resultados para que possamos decidir, entre todas as possibilidades, quais atacar prioritariamente.

2010 promete!

E você, tem feito retrospectivas?

JBoss, JProfiler, Eclipse e Linux

2009-12-08T17:36:00.000-02:00

Para usar o JProfiler no Eclipse dentro do Linux (testado no Fedora 12) são necessários os seguintes passos:

1. Instalar o Fedora 12
2. Instalar o Eclipse
3. Instalar o Web Tools Platform
4. Instalar o JBoss Tools
5. Instalar o JProfiler

Uma vez feita a integração com o Eclipse (leia a documentação do JProfiler) e também a integração do Eclipse com o JBoss Tools (configurado) é necessário adicionar as bibliotecas do JProfiler na carga de bibliotecas do sistema:

#---
cat > /etc/ld.so.conf.d/jprofiler.conf << __END__
/opt/jprofiler6/bin/linux-x86/
__END__
ldconfig
#---

Adicionar a linha: "-agentlib:jprofilerti=port=2025" a execução do JBoss no Eclise:

Ao executar o JBoss disparar o JProfiler e conectar à uma nova seção remota na porta 2025

Problemas com Eclipse no Fedora 12

2009-12-07T18:07:00.000-02:00

Descrição do problema:

Alguns botões, especialmente OK e Finish, não respondem ao clique do mouse. É necessário manter o foco no botão (mantendo o mouse sobre o botão, por exemplo) e pressionar a tecla ENTER.

Solução (simples):

É necessário sobre-escrever uma variável de ambiente antes de executar o eclipse:

#---
GDK_NATIVE_WINDOWS=true eclipse
#---

solução (para atalho no desktop):

Crie um script shell e o use como comando no atalho:

#---
cat > ~/bin/eclipse.sh << __END__
GDK_NATIVE_WINDOWS=true eclipse
__END__
chmod 755 ~/bin/eclipse.sh
#---

Fonte: http://forums.fedoraforum.org/showthread.php?s=a3c988d542abeeb3b04991ab5c12070d&p=1301362#post1301362

DICOM

2009-10-27T13:23:00.000-02:00

A transmissão de imagens médicas vem sendo feita há algum tempo. Nada mais natural, então, que surgissem alguns padrões nessa área, como o DICOM. Aqui, o estamos usando no manuseio de alguns exames, como Ecocardiografia e Retinografia. Tenho certeza que mais empresas e estudos brasileiros também estão. Assim, criamos uma lista de discussão para que diferentes pessoas possam trocar experiências e dúvidas. Se te interessa, dá uma conferida:

* Nome do grupo: DICOM - Brasil
* Página inicial do grupo: http://groups.google.com.br/group/dicom-brasil
* Endereço de e-mail do grupo: dicom-brasil@googlegroups.com

Autonomia, Domínio e Propósito

2009-08-31T15:16:00.000-03:00

O Gustavo me mandou um vídeo muito interessante sobre motivação. O apresentador reflete sobre a obsolência do sistema de recompensa e apresenta uma solução para o século XXI. Para ele, uma melhor abordagem para a resolução de problemas é baseada em "Autonomia, Domínio e Propósito". Eu estava mesmo lendo esses dias um material que citava como um dos valores centrais da comunidade ágil a autoridade sobre os assuntos técnicos. Segundo os autores, os desenvolvedores estão sempre batalhando para manter seu código simples e direto. Eles avançam sempre para estar de acordo com o que há de melhor em solução tecnológica.

Olhando para os quadros com tarefas (presentes em XP, Lean/Kanbam e afins) onde cada membro da equipe escolhe o que fazer, vemos um bom exemplo de autonomia. Ora, quer melhor exemplo que a livre escolha, sem microgerência, para desenvolver o coeficiente de viração própria e a responsabilidade? Ter o poder de decidir qual tarefa atacar, podendo se basear no que já conhece para ganhar tempo, ou no que não sabe para ganhar conhecimento, fortalece toda a equipe. Longa vida ao nosso quadro!

Aqui no Elsa, é fácil ver o propósito do projeto. Ajudar a ciência e a população são causas muito nobres. Domínio, é uma busca individual, coletiva e diária. Acho que estamos no caminho certo. E você, também está?

Segurança ou paranóia

2009-08-27T17:22:00.000-03:00

Quando se trata de segurança normalmente existem dois grupos de pessoas: os paranóicos e os otimistas. Eu faço parte do primeiro. Mas a questão é até que ponto a paranóia é realmente paranóia e quando ela passa a ser necessária? O que se observa em metodologias ágeis é que se deve fazer aquilo que é estritamente necessário para o funcionamento do sistema/programa. Mas puxando a "brasa" para o meu lado: quando o sistema deixou de funcionar porque houve um problema segurança, isso não entra no estritamente necessário? Afinal deixou de funcionar.

A questão vai além da definição mais clássica segurança, que é a proteção do sistema contra acesso não autorizado. Mas isso se aplica também a questões de acesso indevido mas autorizado. Como uma funcionalidade que deveria ter acesso restrito à alguns usuários mas por descuido ou relaxamento do programador não teve a sua restrição imposta. Além disso existem as questões da chamada "programação otimista", onde se confia que as coisas irão funcionar, sem que se busque verificar se elas realmente funcionam. Lógico que "blindar" cada parafuso do sistema é bobagem, assim como tentar aplicar alguma validação formal em todos os métodos (nada a ver com TDD). Mas existem momentos em que sim a paranóia não somente é necessária mas como pré-requisito para que se evitem dores de cabeças no futuro (nem tão) distante.

Cliente Presente

2009-08-24T13:56:00.000-03:00

Fui a uma formatura esses dias e o paraninfo tinha uma frase de cumplicidade com seus afilhados que era algo como "Tamo junto". A origem da frase remetia ao fato de tanto o professor como os alunos estarem no mesmo lado, trabalhando pela formação acadêmica todas as sextas a noite e sábados dia todo. Alguns dias depois, fui a um evento de testes onde o palestrante pediu para os presentes se apresentarem. Após um membro da platéia se definir programador, surgiu a piadinha "Temos um inimigo na trincheira."

Essas duas situações me fizeram refletir um pouco sobre algumas práticas ágeis e como elas são importantes para o sucesso do sistema. Uma delas, definida como Cliente Presente (do original em inglês On-site Costumer) e preza que todos os colaboradores de um projeto devem sentar juntos, formando um time. Com isso, absolutamente todos são contribuintes em uma equipe ágil. Vale para equipe técnica e para clientes. Principalmente para o segundo grupo, essa atuação vale em qualquer ponto onde a possam exercer, como na definição de prioridades e/ou criação de testes. Assim, acaba acontecendo que cada um dos papéis possíveis não seja necessariamente propriedade exclusiva de um indivíduo.

Aqui no ELSA, essa prática é bastante real e fácil de ser observada. Temos uma equipe epidemiológica perto e sempre presente nas definições, análises e testes, facilitando muito o trabalho da equipe de desenvolvimento. Sendo a estrutura organizacional do projeto construída sobre um modelo de colegiado, possuir pessoas capacitadas a garantir o papel de Product Owner geograficamente vizinhas às atividades de análise, programação e testes é fundamental. No caso específico dos releases, seus testes de aceitação, complementares aos testes feitos pela equipe durante o desenvolvimento, nos garantem o sucesso das novas versões do sistema que são visíveis aos outros centros do estudo.

É bom saber que aqui estamos mais de acordo com o paraninfo. Se todos os membros da equipe querem o sucesso do mesmo software, a quem serve criar inimizades no grupo?