A quick setup to upload files using SpringMVC.

Dependencies

Usando o Maven, o primeiro passo é incluir duas dependencias: commons-io and commons-fileupload:

Application Context

Segundo passo é configurar o application context para fazer uso de multiparts:

Controller

Terceiro passo: criar o seu controller. note the existe um parametro do tipo: MultipartFile.

View

E o último passo: sua JSP.

The Go Programming Language

Primeiro passo para ter um ambiente de desenvolvimento em um Mac é instalar o DVD que vem junto com sua maquina com o pacote de desenvolvimento chamado XCode. O próximo passo é ter o Python e o Mercurian instalados.

O Python provavelmente será instalado juntamente com o XCode, portanto não ha com que se preocupar demais. Já o Mercurian você precisará instalar na sua maquina, mas o processo é simples, fácil e limpo. No worries.

Passo 1: Checagem inicial

Verifique se os pré-requisitos estão atendidos, verificando o Python, XCode e Mercurian:

Passo 2: Váriaveis de Ambiente

Tendo o Python e o Mercurian instalados é hora de definir algumas variáveis de ambiente: Edite o seu arquivo ~/.profile ou ˜/.profile_bash (vim ˜/.profile ou vim ~/.profile_bash) e inclua as seguines linhas:



Neste caso eu pretendo instalar o go no diretorio go que está dentro do meu $HOME ou seja: /Users/mg/go. Mas fique a vontade para colocar onde você bem entender.

Salve o arquivo e feche-o (dentro do vim :x)

Re-carrege as variáveis em seu ambiente com o comando source:

Passo 3: Baixando o Go

Digite o comando:

Passo 4: Gerando os binários

Neste momento o código fonte já está em sua máquina. Agora é necessário gerar o compilador.
Crie um diretório (se ainda não estiver criado) chamado bin dentro de $GOROOT/src e de permissão de execução:

Dentro do diretorio src ($GOROOT/src) execute o seguinte comando para gerar o binário da linguagem:

Atenção: Este processo será necessário acesso a Internet, pois alguns testes fazem uso da rede.

Os arquivos gerados para a arquitetura i386 são os 8g e 8l. Se voce informou amd64 na variável de ambiente GOARCH estes serão: 6g e 6l.

Crie um link para esses dois arquivos em seu diretorio /bin:

Passo 5: Hello World.go

Este . Crie o arquivo hw.go com o conteúdo:



Compile:
Link:

Execute:

Recentemente eu precisei de trabalhar em um projeto onde toda a comunicação entre o frontend e o backend era feita através de requisições HTTP. A princípio consideramos utilizar um Servlet com alguns helpers que mapeava os parâmetros de URL para um Map e internamente esse Map era “injetado” em todas as classes de recurso.

Era uma solucão a ser considerada, mas como essa era a primeira idéia que o time teve, resolvemos descartá-la.

Por uma requisição do cliente, tinhamos que utilizar Maven e Spring e isto era ponto fechado. As demais bibliotecas eram por nossa conta (e risco).
Surgiu então a segunda idéia de utilizar RESTful simplesmente para facilitar o trabalho entre o mapeamento dos parâmetros vindos da URL com o código.

Pesquisamos a primeira Lib, Jersey já quer esta é a implementação padrão do JSR-311 e também pesquisamos a API do Restlet.
Resolvemos nos contrapor a ideologia de rejeitar a primeira opção a fim de conseguir novos recursos.
Ambos frameworks possuem aspectos únicos e muito bem documentados. Cada uma com suas particularidades, por exemplo no Restlet é necessário criar uma classe com as rotas (uma classe que extende a classe Application).

Mas os principais motivos que nos levou a decidir a utilizar o Jersey foram:

1. Ser a implementação modelo da especificação
2. Menos burocracia na implementação dos resources
3. Integração quase que natural com o Spring para a injeção de classes nos resources.

Este “walk through” tem o objetivo de exemplificar como criar uma aplicação simples utilizando as ferramentas: Spring, Maven e Jersey de forma prática.

Setup

1. Incluir o repositório do jersey-spring no pom.xml



2. Incluir as dependencias das libs: jersey spring


3. Configurar web.xml

It’s time do code!

1. Configuração do Spring (applicationContext.xml)
Crie o arquivo applicationContext.xml no diretório META-INF de sua aplicação. Este código informa ao engine do Spring para que o pacote com.mng.jerseydemo esteja disponível para a injeção de dependencias. Segue o modelo do arquivo:

2. Criação do primeiro resource.

Neste trecho de código existem algumas anotações, entre elas:


1. @Path
Este é o padrão da URL que será tratado pela classe. Pode ser informado variáveis utilizando o modelo: {nomeDaVariavel}. Por exemplo: @Path(”/user/{username}/{password}”).

2. @Autowired
Injeta um objeto do tipo informado na váriavel.

3. @GET
Responde as requisições do tipo GET, existem ainda: @POST, @PUT e @DELETE que podem ser utilizadas da mesma maneira que o @GET

4. @Produces
Informa o tipo de retorno do método. Esta anotação pode ser informada tanto no método quanto na classe, junto com o @Path. Informando na classe o tipo de retorno será propagado para todos os métodos que não tenham um @Produces específico.

5. @PathParam
Traduz as variáveis mapeadas na URL para um objeto. Este será mapeado para uma variável informada na assinatura do método.

Acessando

Para acessar o recurso recém criado voce pode utilizar o próprio browser (Chrome ou Firefox), com eles fica fácil de simular o GET. No entanto, se você está no mundo X (Linux, Unix ou mesmo Mac) faça bom uso do cUrl. De forma rápida e prática este comando é simples de ser utilizado.
Através do parametro “-X” especificando o método que deverá ser enviado é possível testar a maior parte dos serviços:

E com o parâmetro -F você pode especificar os parâmetros (@QueryParam) do método post.

Desde um pouco antes de minha passagem pela Austrália tenho me dedicado a estudar sobre código e formas de codificar. Melhores e piores técnicas. Na época que passei na Austrália essa dedicação foi amplificada, pois como não estava trabalhando e nem a procura de um emprego passei muito tempo apenas lendo a respeito e aplicando algumas técnicas em códigos pessoais.

Nomes Significativos.

Se você ainda não teve uma experiência como esta, você é uma pessoa de sorte, mas em alguns casos você é obrigado a trabalhar com a restrição de oito caracteres para nomes. Essa “lei” se aplica para banco de dados antigos que não evoluíram.

Mas isso não quer dizer que o seu código (Java, C#, Ruby….) deva seguir este modelo. Os nomes das variáveis, métodos devem ser ao menos significativos.

Veja o seguinte trecho de código:
Este é apensa um exemplo, mas tais variáveis não dizem nada, absolutamente nada sobre a intenção das mesmas. Além do mais, você como um programador deve codificar mentalmente o que significa as variáveis cor e pal dentro do contexto. Agora leia o código a baixo:



Não é mais simples? Foi necessário alguma decodificação mental a respeito da intenção das variáveis?

Nomes de Métodos e Construtores.

Outra regra muito fácil aprendida na faculdade é de que o nomes para métodos devem ser verbos, expressando uma ação. Como por exemplo: get / set / is / do…..

Mas e com relação a construtores? Estes não são nada próximos de amigáveis ou mesmo significativos.
Uma boa saída é criar métodos estáticos dentro da própria classe informando o motivo para aquele construtor estático, por exemplo:



Este é um exemplo muito pequeno e sem nenhum contexto. Ainda neste código o nome do método construtor createComplete poderia ser renomeado apenas para create, caso existisse uma convenção em toda a aplicação de que o método chamado create precise de todos os parâmetros do objeto para ser criados.
Uma outra alternativa seria criar um construtor static ao invés de informar o parâmetro faltante - state - que não é algo muito legível, utilizar um contexto para esta criação, como por exemplo: createForSelect, sendo utilizado para a criação de um objeto City para ser utilizado em um campo html select.

Segue um script que gera via Ant os relatórios:

• Findbugs
• Cobertura
• Testes Unitários

Recentemente o Renato Carvalho teve problema com seu MBPro, após fechar a tela e hibernar a máquina simplesmente não acordava.

Depois que eu comprei um Might Mouse sem fio comecei a enfrentar o mesmo problema.

Encontrei a pouco em um forum a possível solução: Desabilite a opção: “Allow Bluetooth devices to wake up this computer” nas configurações avançadas do Bluetooth.

Aparentemente agora está tudo funcionando.

Guia expresso para instalação de um ambiente de produção RoR/Apache/Passenger no Ubuntu

sudo apt-get install rubygems
 
sudo gem install rails
 
sudo apt-get install ruby
 
sudo apt-get install ruby rdoc irb libyaml-ruby libzlib-ruby ri libopenssl-ruby
 
wget http://rubyforge.rubyuser.de/rubygems/rubygems-1.3.1.tgz
 
tar xzvf rubygems-1.3.1.tgz 
 
sudo ln -s /usr/bin/gem1.8 /usr/bin/gem
 
sudo mv /usr/bin/gem /usr/bin/gem-old
 
sudo gem update --system
 
sudo gem install rails
 
sudo apt-get install build-essential ruby1.8-dev
 
sudo gem install mongrel
 
sudo gem install capistrano
 
sudo apt-get install mysql-client mysql-admin mysql-query-browser libmysqlclient15-dev
 
sudo apt-get install sqlite3 swig libsqlite3-ruby libsqlite3-dev
 
sudo gem install sqlite3-ruby
 
echo "export RUBYOPT=rubygems" >> ~/.profile
 
sudo apt-get install build-essential apache2-mpm-prefork apache2-prefork-dev libapr1-dev
 
sudo gem install passenger
 
sudo passenger-install-apache2-module
 

O BlipBadge foi escolhido pelo Mergulhão e pela HostNet para ter um ano de hospedagem grátis!

Obrigado pela confiança e vamos que vamos dar uma melhorada no Badge e colocá-lo na casa nova!

Obrigado Mergulhão!

Obrigado HostNet!

Segue o link do resultado: resultado-da-promo-o-de-natal-da-hostnet

My Wordle.net delicious:

First:

Second:

Em um time de projetos utilizando a metodologia Scrum, seria um pouco “estranho” perguntar:

Qual o papel de XX departamento em um time de Scrum?

Afinal, em um time de Scrum o princípio é de que o time seja multidisciplinar, qual seria a dúvida por tanto?

Bom, talvez em empresas focadas em desenvolvimento de software ou em empresas de menor porte isso seja uma realidade, onde todos do time tenha suas preferências técnicas e sejam melhores em determinadas áreas que em outras, mas no final das contas todos fazem de tudo um pouco, desde html até codificação de EJBs no backend.

Em empresas cujo a herança seja o tradicional departamento/áreas, como: Qualidade (QA), Administração de Banco de Dados (DBA), Layout, Design, Usabilidade, etc….. fica praticamente impossível de se quebrar este paradigma, que na verdade está muito mais atrelado a vaidade dos departamentos (vaidade não no termo pejorativo, afinal, precisamos de especialistas) do que em quebra de paradigma propriamente dito, especialmente se a empresa for de médio a grande porte, afinal a primeira preocupação de quem não acredita/gosta de desenvolvimento ágil seria de medo, pois o status quo está sendo ameaçado. Claro!

Este post foi originado após uma conversa com um grande amigo meu, Fábio Brandão na noite do dia 01/01/2009, (pois é, viciado que é viciado só melhora após a terceira ou quarta linha de código compilado ) a respeito de alguns problemas com papéis/departamentos X Scrum, vou tratar neste post, um detalhe mais específico a respeito do Papel de QA (Qualidade) em um time de Scrum e as idéias que me perturbam a respeito.

Qualidade em Casa (QA em time de QA)

Fique claro que quando digo: papel de QA estou me referindo ao contexto que disse logo acima, onde existe um departamento de Qualidade e que o time de desenvolvedores não necessariamente faz o trabalho de QA.

Eu sempre trabalhei em empresas onde existia um time de qualidade verificando o sistema de forma manual ou automática, navegando pelo sistema, algumas vezes com uma planilha com os pontos de atenção, estes são os pontos que não poderia haver nenhuma fala, chamado risco 0 (risco zero), outra planilha com as novas features implementadas que não precisavam ter necessariamente risco 0, e uma terceira planilha com as issues, onde seria devidamente registrados os erros encontrados.

Após o programador (algumas vezes eu) sinalizar no sistema ou face-2-face que o desenvolvimento estava concluído, entrava em campo o pessoal da qualidade, agora lendo o documento que utilizei para desenvolver o sistema, retestando o sistema, testando as novas funcionalidades e apontando os erros, enquanto o programador (…..eu) já estava em um novo caso de uso, esse cara algumas vezes nem se lembrava mais do código do caso de uso passado, estava com foco total no novo caso de uso.

Passado algum tempo, o produto estava todo codificado e com vários bugs, logo, hora de corrigir os bugs.

Aqueles programadores que mal se lembravam o que haviam jantado na noite passada (provavelmente pizza, pois ficou até tarde na empresa, gerando mais algumas linhas de código sem testes) deveriam começar a corrigir os erros que eles mesmos causaram, que foram levantados pelo pessoal de QA. Agora com um documento mais “enxuto” que continham os erros encontrados.

Após a maratona de correções, com alguma sorte, o pessoal de Qualidade não encontrariam os mesmos erros quando executassem os testes novamente.

Qualidade em time de Scrum?

Acho que em um time de scrum a abordagem de QA em time de QA é totalmente fora de propósito, afinal a equipe de qualidade estaria fazendo apenas o papel de apurador de erros, seria realmente este o propósito de um time de qualidade? Encontrar erros?

Pensando em uma abordagem um pouco mais prática, ágil e proporcional aos excelentes técnicos que trabalham com qualidade, a tarefa devesse ser a de garantir a qualidade de produto como um todo, assim como um programador está apto a desenvolver: frontend, backend, testes unitários, integrados, modelagem de tabelas em objetos, QA deveria minimizar os problemas relacionados ao sistema como um todo, por exemplo: erros visuais, problemas técnicos relacionados a código não performático, erros de escrita em banco de dados, arquitetura, e também negócio.

O trabalho estaria terminado, se fossem encontrados erros nestas esferas.

Mas então o trabalho de QA seria apenas de encontrar erros no sistema? Seria aquele primo chato que sempre aparece quando menos se deseja?

O programador receberia com alegria a notícia de que seu código está errado? Ou que o código recém entregue não está performático?

Eu não acredito nisso, definitivamente eu acredito que esta já é uma evolução do “QA em time de QA”, mas acredito que esteja longe de ser uma boa abordagem.

Qualidade!

Como descrito acima, QA deveria ser um supertime, com:

• Arquitetos da informação, para assegurar de que os textos estão colocados corretamente;
• Webdesigners e Webmasters, para assegurar que o layout esteja de acordo como foi desenhado e implementado por eles e requisitado pelo Product Owner.
• Arquitetos de sistema, para assegurar que a aplicação esteja performática e que todas as regras corporativa para acesso a legados estejam sendo cumpridas.
• Programadores: para assegurar que o código está bem feito, com cobertura de X% de testes unitários, funcionais
• Analistas de negócio: para assegurar que o que foi pedido pelo Product Owner esteja de acordo com o que está sendo codificado.
• Administradores de Dados: assegurando que o modelo desenhado esteja coerente com os padrões da empresa e esteja normalizado
• Administradores de Banco de Dados

Com este super time de qualidade, acho que ficaria difícil justificar financeiramente este time.

Mas se o problema é dinheiro(falta de), o que fazer então?

Eliminar a qualidade do time?

De forma alguma!

Acredito cegamente que se o time, TODOS do time estiverem motivados, balizados com o que deve e o que não deve ser feito especialmente nas áreas em que não são especialistas o time deve servir de seus próprios QA’s.

Em um ambiente propício, onde existe motivação isso acontece de forma natural, onde um programador dá palpite no código do outro programador, o administrador de dados está disposto a alterar o modelo de dados para melhorar o desenvolvimento, o webdesigner trabalha de forma parceira com o programador para definir o que será retornado no JSON da chamada Ajax, o analista de negócio está ao lado do desenvolvimento alertando para os erros cometidos (ainda em tempo de desenvolvimento)

Em um ambiente como este será que é valido se quer o questionamento sobre o papel de QA em um time de Scrum?

Acho que não, pois todos estão AGINDO de forma a assegurar a qualidade técnica e não técnica da solução que está sendo implementada.

Talvez a pergunta correta desde o início desde post devesse ser:

Como motivar um time?

Isto será uma conversa para outro post, mas acho que resposta de forma bem curta seria…………….. Paixão!

PS: Utilizei o time de QA apenas para exemplificar, fica a critério do leitor substituir QA, por AD, DBA, Business, ou qualquer outro time que achar interessante.