Como a página inicial do site diz, seu funcionamento é simples. Busque pelo nome do artista ou música, marque o trecho e clique em “Postar”. Em alguns segundos o trecho selecionado aparecerá com uma publicação em seu mural no Facebook. Se não encontrar a música desejada, clique no menu “Contato” e me deixe uma mensagem com o nome do artista e título da música que a disponibilizarei em breve.

Já estou trabalhando em uma atualização para o site onde será possível postar também o trecho pelo Twitter e paralelamente, em breve, publicarei uma versão mobile desta aplicação no Android Market, onde você poderá compartilhar o trecho de música através de email, sms e outros meios pelo seu celular Android.

Então, fique ligado! Abraços!

The code is open and free, download, install and use at will! It is hosted at GitHub.

Feedbacks are welcome!

This is the home screen:

This is the history screen:

Por que?

O desenvolvimento de software é um exercício intenso de colaboração. Um espaço aberto encoraja conversações e interações regulares entre as pessoas. Você pode ver o que todos estão fazendo e facilmente pedir ajuda quando necessário. Freqüentemente você consegue uma informação inesperada, porém bastante útil, por escutar algo que a equipe está conversando ao seu redor.

Ao ficar ciente disto, algumas pessoas ficam preocupadas com a quantidade de ruído e poderiam preferir escritórios que ofereçam maior privacidade. Na prática, acabei percebendo que as equipe não consideram o ruído como um problema muito sério. Geralmente há um som perceptível de conversação no ambiente, já que programação em par geralmente acompanha este estilo de desenvolvimento. Porém a conversação não costuma ser algo que distrai, particularmente se você está focado na conversação com seu par. O motivo pelo qual eu suspeito que isto não é algo que distraia, é porque a equipe tem um propósito em comum ao redor de uma atividade colaborativa. Não é algo que dê para comparar com um escritório de plano-aberto onde todos estão fazendo coisas diferentes.

Dicas para uma boa sala de equipe

Primeiro, certifique-se que a sala tenha o tamanho certo para a equipe. Enquanto uma sala de equipe deve ser aberta para sí mesma, ela deve ser fechada para todo o resto do pessoal. Em um mundo ideal, você preferiria paredes flexíveis que isolem uma equipe da outra, em um escritório que consista em células de equipes. Isto é algo difícil de se conseguir na prática. Nossos escritórios tendem a ser completamente abertos, com poucas barreiras entre as equipes. Isto parece funcionar bem o suficiente, apesar de que há algumas reclamações do ruído entre equipes diferentes.

Preste atenção à luz natural. Os humanos estão acostumados a ver o mundo exterior, e todos os tipos de ritmos naturais de trabalho são influenciados pela luz. Então não é surpresa que as pessoas fiquem facilmente irritadas quando não há luz suficiente. Eu mesmo já passei vários dias fechado em salas de conferência, e isto certamente drena minha energia.

Disponibilize espaço suficiente: aproximadamente 4,5 metros quadrados por pessoa.

Com o tipo certo de espaço, a próxima peça chave é certificar-se de que o time tem o controle sobre este espaço. Uma parte importante do pensamento ágil é que a equipe é responsável pela forma como ela trabalha, e a forma como ela organiza o seu espaço faz parte disto. Idealmente você deve preferir que a equipe tenha controle completo sobre seu espaço, com liberdade para configurá-lo como desejarem e reconfigurá-lo ao seu gosto. As coisas devem ser feitas de forma que seja fácil mover as coisas ao redor, porque durante o projeto o time precisará mudar coisas conforme ele for mudando.

Uma consequência imediata disto é livrar-se de qualquer tipo de mobiliário modular que exija um grupo de pessoas para mover, mesmo que seja apenas um centímetro. A maioria das equipes que observo usa mesas simples e com certeza você pode gastar o mínimo com isso.

O que mais atrapalha são os fios – principalmente para energia e pontos de rede. Idealmente você quer estes sob o piso ou pelo teto para que as pessoas possam facilmente levar os fios para as mesas onde quer que elas estejam.

O lugar certo para gastar dinheiro com mobília é em cadeiras de boa qualidade. Programadores passam muita parte do tempo sentados, e qualquer dano físico por conta de má postura afetará diretamente a produtividade da equipe – então não se restrinja aqui. Pode ser que algumas pessoas queiram cadeiras estranhas, como bolas ou cadeiras para ajoelhar. Faça o seu melhor para acomodá-los.

Alguns são grandes fãs de mesas ajustatáveis entre a altura para sentado ou em pé, já que acreditam que ficar em pé por um tempo ajuda a aliviar dores nas costas. Estas são mais difíceis de se encontrar, porém vale a pena procurar se sua equipe precisa delas. Dores nas costas é um problema comum, mas cada dor (e tratamento) é diferente.

Você precisará de muito espaço nas paredes, de forma que os agilistas adoram seus radiadores de informações. Você desejará bastante espaço para paredes de histórias, diagramas arquiteturais e qualquer coisa que as pessoas queiram pregar na parede. Boa parte deste espaço deve ser ocupado com quadros brancos para que as pessoas possam desenhar coisas sempre que sentirem vontade. Inclua alguns quadros brancos com rodinhas.  Certifique-se de ter uma câmera digital ao alcance para que as pessoas possam facilmente registrar o que há nos quadros. Agora que monitores são baratos, considere arranjar alguns para pendurar na parede – isto é particularmente útil para displays dinâmicos como status de builds. Certa vez eu vi uma equipe utilizavar projetores nas paredes para exibir vários tipos de informações.

O layout tradicional é ter as pessoas trabalhando ao redor de grupos de mesas. Esta disposição fornece contato visual regular com o resto da equipe. Entretanto ouvi falar de muita gente cantar os louvores do UPod.

Ocasionalmente as pessoas precisarão de um espaço privado, então assegure-se de que há uma ou duas pequenas salas de conferência disponíveis com telefones. Estas podem ser usadas para privacidade ou quando há alguma preocupação com distrações. Uma grande sala de reunião onde a equipe pode se reunir fora do espaço de trabalho também é útil.

Sempre fui um grande defensor de muito espaço de monitor. Softwares inteligentes com múltiplas áreas de trabalho virtuais são bastante interessantes, porém nada é mais rápido que simplesmente mexer seus olhos. No mínimo, cada estação de trabalho deve ter um par de monitores de 20 polegadas. Minha mesa tem um par de monitores de 20 polegadas para minha maquina Ubuntu e um monitor de 25 polegadas para meu laptop mac. Eu não acho que isto tudo seja, de forma alguma, excessivo.

O desenvolvimento de software é algo inerentemente criativo, assim, espere ver muitas distrações. Brinquedos são comumente encontrados ao redor de nossas equipes (como Neal Ford dizia: cada equipe precisa de um canguru de plástico). Há boas razões cognitivas pelas quais isto é de grande valia, tudo se resume a manter o cérebro criativo e estimulado.

Da mesma forma, disponibilize fácil acesso à bebidas e lanches. Isso incentiva pausas para conversas informais na área da equipe. É difícil ser criativo quando se tem que pagar para tomar um café horrível.

Se você está trabalhando com colaboradores remotos, faça com que seja fácil configurar um link de vídeo. De fato, muitas equipes gostam de ter links de vídeo permanentes para quaisquer colaboradores remotos para que se possa sempre manter um contato ocasional via vídeo.

Links Úteis

• Resumo de coisas para uma sala de equipe em InfoQ.
• William Pietri descreve uma sala de equipe que usou.
• Galeria de sala de equipe e quadros de Bill Wake.
• Conselhos de Rachel Davies sobre como construir um ambiente ágil.
• Joel Spolsky é talvez a melhor ilustração de como usar escritórios individuais ao invés de uma sala de equipe.

Meus agradecimentos para meus colegas da ThoughtWorks por me ajudar a compilar estas informações.

A reprodução do artigo original no formato traduzido foi devidamente autorizada pelo autor Martin Fowler.
Link para o artigo original: http://martinfowler.com/bliki/TeamRoom.html

One day i had to change a page (WebPage) in a way that it would allow me to persist a simple attribute of an entity. First i tried to use an Enum, however i’m using JPA persistence with Hibernate and was a little bit concerned about how Hibernate would deal with this Enum in searches or some other more advanced stuff. So i decided to create a simple Integer attribute and set a constant on it.

This is a sample of code using a Map to exhibit a list of options (DropDownChoice) in a Wicket application to persist a constant (Integer) in an entity.

Code of ControlSerum entity where the attribute status will be persisted:

@Entity
public class ControlSerum {
  private Integer status;

  public final static int STATUS_PREP = 0;
  public final static int STATUS_ACTIVE = 1;
  public final static int STATUS_INACTIVE = 2;
  private final static Map<Integer, String> statusMap = new HashMap<Integer, String>();

  static{
    statusMap.put(STATUS_PREP, "Em preparo");
    statusMap.put(STATUS_ACTIVE, "Ativo");
    statusMap.put(STATUS_INACTIVE, "Inativo");
  }

  @Column(nullable=false)
  public Integer getStatus() {
    return status;
  }
  public void setStatus(Integer status) {
    this.status = status;
  }

  @Transient
  public static Map<Integer, String> getStatusMap(){
    return new HashMap<Integer, String>(statusMap);
  }
}

At ControlSerumEditPage page class, i implemented a IChoiceRenderer to renderize correctly the options of select tag using the Map key as the value of option tag and the Map value as the name for exibition of option tag.

ControlSerumEditPage class constructor snippet where a renderizer for DropDownChoice is instantiated and added to Form:

IChoiceRenderer choicesRenderer = new IChoiceRenderer() {
  @Override
  public String getDisplayValue(Integer object) {
    return ControlSerum.getStatusMap().get(object);
  }
  @Override
  public String getIdValue(Integer object, int index) {
    return object.toString();
  }
};

IModel optionsModel = new Model(){
  @Override
  public Serializable getObject() {
    return new ArrayList(ControlSerum.getStatusMap().keySet());
  }
};

IModel statusModel = new PropertyModel<Integer>(controlSerum, "status");

DropDownChoice<Integer> status = new DropDownChoice<Integer>("status", statusModel, optionsModel, choicesRenderer);
form.add(status);

To download the full code of this application (still in development):
http://github.com/ziglee/biomedcalib

Please post your doubts or comments and i’ll promptly answer you!

Um dia desses precisei de mudar uma página (WebPage) para que permitisse persistir um atributo simples em uma entidade. Primeiramente pensei em usar um Enum, porém estou usando persistência JPA com Hibernate, e fiquei com receio da forma como o Hibernate iria manipular esse Enum ao fazer buscas ou coisas mais complicadas. Então decidi criar um atributo do tipo Integer e setar nele uma constante.

Este é um exemplo de código usando um Map para exibir uma lista de opções (DropDownChoice) no Wicket para persistir uma constante (Integer) em uma entidade.

Código da entidade ControlSerum onde vamos persistir o atributo status:

@Entity
public class ControlSerum {
  private Integer status;

  public final static int STATUS_PREP = 0;
  public final static int STATUS_ACTIVE = 1;
  public final static int STATUS_INACTIVE = 2;
  private final static Map<Integer, String> statusMap = new HashMap<Integer, String>();

  static{
    statusMap.put(STATUS_PREP, "Em preparo");
    statusMap.put(STATUS_ACTIVE, "Ativo");
    statusMap.put(STATUS_INACTIVE, "Inativo");
  }

  @Column(nullable=false)
  public Integer getStatus() {
    return status;
  }
  public void setStatus(Integer status) {
    this.status = status;
  }

  @Transient
  public static Map<Integer, String> getStatusMap(){
    return new HashMap<Integer, String>(statusMap);
  }
}

Na classe da página ControlSerumEditPage, implementei um IChoiceRenderer para renderizar corretamente as opções do select, utilizando a chave do Map como sendo o valor a ser submetido pelo option e o valor do Map como sendo o nome para exibição do option.

Trecho de código do construtor da classe ControlSerumEditPage onde é instanciado e adicionado ao Form, um renderizador para o DropDownChoice:

IChoiceRenderer choicesRenderer = new IChoiceRenderer() {
  @Override
  public String getDisplayValue(Integer object) {
    return ControlSerum.getStatusMap().get(object);
  }
  @Override
  public String getIdValue(Integer object, int index) {
    return object.toString();
  }
};

IModel optionsModel = new Model(){
  @Override
  public Serializable getObject() {
    return new ArrayList(ControlSerum.getStatusMap().keySet());
  }
};

IModel statusModel = new PropertyModel<Integer>(controlSerum, "status");

DropDownChoice<Integer> status = new DropDownChoice<Integer>("status", statusModel, optionsModel, choicesRenderer);
form.add(status);

Para baixar o código completo desta aplicação (ainda em desenvolvimento):
http://github.com/ziglee/biomedcalib

Façam seus comentários e envie quaisquer dúvidas que prontamente responderei!

É… eu sei eu sei… o pessoal que mais utiliza o transporte urbano não vai sair por aí comprando celulares Android em peso em 2010, apesar disso, existe um problema ainda não resolvido da parte da RMTC, que é a falta de utilização dos ônibus executivos, mais caros e confortáveis. Acredito que esta aplicação cairia bem como um impulsionador da utilização desta categoria de transporte.

Mudando um pouco de assunto, minha irmã que é biomédica com pós-graduação em auditoria de qualidade de saúde, sugeriu uma idéia de um serviço web que parece ser economicamente interessante. Então é possível que venha um novo projeto pessoal por aí.

Enquanto isso, o foco atual está sendo no desenvolvimento do meu artigo da pós-graduação. Já está entrando na reta final, aguardando uma segunda revisão por parte do orientador. Provavelmente estará terminado antes do final de Dezembro!

Finalmente poderei dar atenção aos projetos pessoais, e pretendo também poder colaborar como commiter no projeto Apache Wicket.

Desse jeito vamos começar 2010 com tudo!

A aplicação foi batizada de Urbtransp e responderá pelo domínio http://urbtransp.com.br assim que estiver pronta. Também estou levando em consideração a usabilidade desta aplicação através de dispositivos móveis (Google Android à vista!).

O ambiente e a arquitetura já estão definidos e foram pensados de forma que o desenvolvimento seja produtivo, fácil de testar, amigável a TDD, suporte a integração contínua, modular e escalável. Para alcançar isto escolhi as seguintes tecnologias:

• Apache Wicket (MVC)
• Spring (IoC e Injeção de Dependências)
• Hibernate (Persistência JPA)
• TRG (DAO Genérico)

Para a gerência de configuração e integração contínua planejo utilizar:

• Apache Maven (Gerenciamento de dependências de projetos)
• Apache Continuum (Integração Contínua)
• Artifactory (Repositório de artefatos)

Ainda tenho minhas dúvidas com relação a utilização do Hibernate que me está forçando a fazer algumas modificações nada elegantes para satisfazer seus caprichos. Talvez o substitua pelo iBATIS.

Desde já, agradeço ao pessoal da freecsstemplates.org pelos templates, já que meu forte não é design!

Onde trabalho não temos problemas relacionados a gerência de configuração mas temos problemas relacionados a automatização de testes. Então por um lado seria de grande valia escrever um artigo sobre TDD, mas pelo outro lado, seria mais fácil falar sobre gerência de configuração, já que tenho uma grande parcela de colaboração para a definição da gerência de configuração que utilizamos hoje, o que me benificia com uma grande facilidade para expor o assunto e até chegar a novas elucidações sobre coisas que poderíamos melhorar neste processo.

Ainda vou fazer algumas reflexões em conjunto com meu orientador para desenrolar isso, já que tenho que finalizar esse artigo até o fim deste ano para obter meu certificado!