Tá aí um video bem legal onde mostra a realidade das metodologias ágeis e waterfall.

Será analisado pela Comissão de Constituição, Justiça e Cidadania (CCJ) nesta quarta-feira (22), projeto de lei que regulamenta o exercício da profissão de analista de sistemas…

O projeto (PLS 607/07) determina que somente poderão exercer a profissão de analista de sistemas os profissionais com diploma superior em Análise de Sistemas, Ciência da Computação ou Processamento de Dados.

fonte: Agência Senado

Link: http://www.senado.gov.br/AGENCIA/verNoticia.aspx?codNoticia=79110&codAplicativo=2

Iniciando novo projeto, nada como buscar tecnologias a fim de tentar melhor a qualidade, performance e produtividade do projeto. Já que o momento é … ”planejar tecnologias” … resolvi fazer uns testes com eclipse Europa. Apesar dele já está disponível há algum tempo, eu ainda ouvia muitas opiniões contrárias a seu respeito, por exemplo uns acham ele pesado outros acham ele mais leve… então vamos ao teste.

Esta versão do eclipse está muito mais completa que a versão anterior, Calisto. A versão Europa tem 21 projetos integrados a IDE enquanto na versão Calisto tem 10 projetos.  Para mais informações, acesse.

Ahh ! Durante a instalação do Eclipse Europa … podemos escolher tipos dos IDE de acordo com o perfil desejado :

• Java Developers
• Java EE Developers
• C/C++ Developers
• Eclipse for RCP/Plug-in Developers
• Eclipse Classic

E é claro ! Caso já tenha o eclipse instalado é possivel fazer o ‘upgrade’ para qualquer das versões.

Eu instalei o eclipse no windows e minha primeira impressão foi as melhores possíveis gostei muitos dos projetos que já vem no pacote e achei que performance da IDE muito semelhante a versão 3.2. Do que eu não gostei nesta versão … bom … até agora nada, mas quando eu tiver, vou acrescentar aqui no post.

Quanto ao Weblogic

O eclipse Europa não vem com os adapters server para o weblogic, em outras palavras, não dá para utilizar o servidor weblogic integrado ao eclipse. Mas calma, não vamos nos desesperar, porque para resolver esses problemas nada como procurar algum plugin.  Já tem disponível o plugin  BEA WebLogic® Server Tools que resolve esse problema, ele tem suporte as versões 8.1, 9. x e 10 do servidor .

Agora … é adicionar esse plugin no eclipse e mãos a obra. 

Estive pesquisando formas de fazer ordenação de colunas na tabela, minha idéia era utilizar javascript para fazer o negócio bem dinâmico e que deixasse o servidor livre, nada de Ajax, fazer uma coisa simples mesmo. Então fiz uns testes com a biblioteca JQuery.

JQuery é uma biblioteca javascript que possui diversas funções e efeitos visuais para tornar nossas interfaces mais “rica”. Além de ser uma biblioteca pequena e as funções javascripts são compatível com diversos tipos de browsers.

Para ordenar os dados de uma tabela com JQuery utilizei o plugin TableSorter. Ele faz a ordenação de dados de uma tabela via javascript e é muito simples de usar.

Para iniciar o uso, basta adicionar os .js ao seu projeto.
<script type="text/javascript" src="/path/to/jquery-latest.js"></script>
<script type="text/javascript" src="/path/to/jquery.tablesorter.js"></script>

Na sua tabela vc vai adicionar as tags <THEAD> e <TBODY>
<table id="idDaTabela">
<thead>
<tr>
<th>Nome</th>
<th>Endereço</th>
<th>Email</th>
</tr>
</thead>
<tbody>
<tr>
<td>João</td>
<td>R. um casa 5</td>
<td>joao@gmail.com</td>
</tr>
<tr>
<td>Marcos</td>
<td>Av. 7 de setembro, 258</td>
<td>marcos@yahoo.com</td>
</tr>
<tr>
<td>Carla</td>
<td>R. quatro, 50</td>
<td>carla@hotmail.com</td>
</tr>
</tbody>
</table>

Note que a celulas dos cabeçalho da tabela tem que está entre as tags <TH>. Se vc utilizar <TD> ele não reconhece como cabeçalho da tabela mesmo estando entre as tagas <THEAD>.

Pode ser bloqueada a ordenação de uma ou mais colunas da tabela. Para isso faça:

<th ... class="{sorter: false}>

Para chamar utilizar a API :

< script>
$(document).ready(function() {
$("#idDaTabela")
.tablesorter( {sortList: [[0,0], [1,0]]} )
} );
</script>


No script acima, estou chamado a plugin tablesorter e ordenando a coluna 0 e 1 de forma ascesdente. Assim toda vez que a pagina for carregada já trás as colunas 0 e 1 da tabela ordenadas.

Para melhorar a vizualização da ordenação pode ser configurado CSS.

th.header {
background-image:url(../img/green_arrows.gif);
font-weight: bold;
background-repeat: no-repeat;
background-position: center left;
padding-left: 20px;
border-right: 1px solid #dad9c7;
margin-left: -1px;
background-color: #D1E6ED;
....
}

Configura o head da tabela, observe que tem uma imagem que serve para informa ao usuário qual ordenaçao deseja fazer.

th.headerSortUp {
background-image:url(../img/green_acending.gif);
background-color: #B0C4DE;
}

th.headerSortDown {
background-image:url(../img/green_decending.gif);
background-color: #B0C4DE;
}

Na pagina os plugin tablesorter tem mais exemplos e uma documentação bem legal.

Ahhh o JQuery tbm tem um plugin para paginação jquery.tablesorter.pager.js.

Mas para esse post vou encerrando por aqui.

Att.

Referências

http://tablesorter.com

Para ter acesso ao livro deve ser feito um cadastro antes.

Para quem, assim como eu, vai comerçar os estudos com Grails está aí a dica
http://www.infoq.com/minibooks/grails

• Quanto mais tarde um erro é detectado, maior o custo de corrigi-lo.
• Como garantir seu meu sistema vai atender a demanda e a expectativa dos usuários?
• Quantos usuários simultâneos minha aplicação suporta ?
• Quantas requisições por segundo ?
• Como a aplicação se comporta quando tenho 100 usuário utilizando-a?

Como obter respostas há essas perguntas sem “colocarmos nossa cara a tapa”, digo isso porque, ainda hoje muitas empresas ainda respondem essas perguntas com suas aplicações já em uso no cliente. E aí, acaba gerando clientes e usuários insatisfeitos e você fica com o “problemão” de ter que corrigir tudo isso na sua aplicação. E tendo que oferecer garantias para que isso não se repita.

Tipos de testes que garantem performance e robustez

Para oferecer desempenho e robustez em suas aplicações a melhor forma é TESTAR. E ainda bem que hoje temos muitas ferramentas para nos auxiliar nesta tarefa.

Mas antes vamos entender ou relembrar exatamente de que tipo de testes que estamos falando.

Teste de Performance

Antes de tudo, que fique claro, teste de performance NÃO É para encontrar bugs (bugs de código). Como o nome diz, medir performance, a aplicação tem que está estável, do que adianta medir performance de uma aplicação cheia de bugs ? E é claro, na hora de avaliar desempenho da sua aplicação tem utilizar ferramentas que serão utilizadas no ambiente de produção.
Para iniciar os testes de performance temos que ter em mente níveis de aceitação para poder avaliar o desempenho da aplicação, não adianta ficar testando a aplicação com 2 usuários por segundos se na vida real sua aplicação vai ter muitos mais acessos que isso. Isso também vale para a situação inversa. Focar no que realmente interessa é o diferencial para obter um bom resultado nos testes.
Então saber quanto de memória e processamento sua aplicação pode utilizar no servidor, tempo aceitável de resposta, quantos usuários posso ter na minha aplicação ao mesmo tempo … essas respostas servirão de métricas para você poder avaliar a performance da sua aplicação.

Teste de carga

Depois do sistema ter atendido ao níveis de desempenho exigido pelo cliente, é hora de avaliar como o sistema se comporta com sua carga máxima, e aumentando gradativamente a carga dos testes podemos ver como o sistema se comporta que sua carga máxima. A ídeia desse teste é manter o sistema funcionando com sua carga máxima.

Teste de stress

Levar o sistema ao caos, isso para avaliar seu comportamento, como ele se recupera. Em sistemas e principalmente sistemas web, pode ser difícil medir o numero exato de acessos, usuários num dado instante … por exemplo. Então para ficarmos preparados para esse tipo de eventualidade, temos que testar … o sistema não precisa necessariamente se manter estável mas tem que conseguir se recuperar de forma “elegante”, exibir mensagem amigáveis e voltar a sua normalidade.

Introdução ao JMeter

O JMeter é uma ferramenta open-source do grupo Jakarta Apache, desenvolvida 100% com tecnologia Java, atualmente é uma das principais ferramenta para realização de teste de performance, carga e stress. Originalmente, foi desenvolvida para execução de testes de aplicações web mas já pode ser extensível a outros tipos de testes como em aplicações distribuídas, desktop, acesso a banco …

Instalação e utilização

Para a instalação da ferramenta basta fazer o download no site da apache e executar o arquivo jmeter.bat na pasta bin.

Conhecendo a ferramenta

A interface da ferramenta é de fácil utilização.

Todos os casos de teste estão no Test Plan.

Todo Test Plan é formado por ThreadGroups. No ThreadGroup pode ser configurado quantidade de usuários(request) e período(segundos).

Em um ThreadGroup vc pode adicionar os controles que neste caso utilizei sample para simular requisições http. Adicionado um sample para requisição, por default é http mas pode ser utilizado https. No sample tbm é configurado ip servdor, porta, path da aplicação, parâmetros que serão enviado no request …

Depois é só rodar os testes.

Resultados (Listeners)

Os resultados podem ser visualizados de forma sintética ou detalhada. Existem vários tipos de listerners para que possamos verificar as informações em angulos diferentes.

A quantidade de informações que vc pode obter chega ser impressionante.

Conclusão

A ferramenta é muito interessante e muito bem documentada. Isso sem falar nas possibilidades de gerar testes customizados e poder gerar tarefas no Ant com JMeter.

A idéia aqui é falar um pouco sobre a ferramenta e a partir daí poder fazer novos estudos. Tentei abordar o assunto de forma bem resumida e a ferramenta em si já facilita bastante por ser simples de usar. O desafio aqui agora é tirar o máximo das informações geradas.

Porém, desenvolvedores odeiam testes, isso incluse eu. Para muitos a tarefa de teste não é de responsabilidades dos desenvolvedores, mas até teste unitário ?!? Na grande maioria das empresas, o teste unitário fica na responsabilidade dos desenvolvedores (ou às vezes … de ninguém).

Mas é legal vc implementar uma classe e poder oferecer garantias que essa classe funciona. Então, minha sugestão aqui é … porque ao invés de pensarmos em ter que fazer essa atividade tediosa não pensamos em automatizar. E para começar … vou começar automatizando os testes unitários. Aqui vou utilizar o JUnit4 para isso.

JUnit é um framework open-source java que automatiza os testes unitários. A maioria das IDEs suportam seu uso.

Agora vamos ao que interessa.

Um exemplo prático com JUnit

1 – Adicione a lib junit-x.x.jar ao build path;

2 – Aqui vou criar uma classe bem simples para depois criar os testes para ela.

public class HelloWorld {


public String digaHello(String name){

return "Hello World " + name;

}

}

3 – Agora criando os testes … adicionar uma nova classe com o nome HelloWorldTest, por convenção a classe de teste tem o nome da classe a ser testada mais a palavra Test, resaltando que isso não é obrigatório. Agora os métodos deve sempre começar com testNomeDoMetodo. O JUnit só executa os métodos que são começados por test.

A classe HelloWorldTest vai extender de junit.framework.TestCase

import junit.framework.TestCase;


public class HelloWorldTest extends TestCase {


public void testDigaHello() throws Exception{

HelloWord helloWord = new HelloWord();
assertTrue(helloWord.digaHello("Usuario").equals("Helo World Usuario") );

}

}

Agora é só rodar a classe de teste, no eclipse, selecionar a opção como run as -> JUnit Test.

Tipos de Assertions

Para testar seu código vc pode usar os seguintes tipos de assertions:

• assertEquals(expected, actual)
• assertEquals(message, expected, actual)
• assertEquals(expected, actual, delta) – used on doubles or floats, where delta is the difference in precision
• assertEquals(message, expected, actual, delta) – used on doubles or floats, where delta is the difference in precision
• assertFalse(condition)
• assertFalse(message, condition)
• assertNotNull(object)
• assertNotNull(message, object)
• assertNotSame(expected, actual)
• assertNotSame(message, expected, actual)
• assertNull(object)
• assertNull(message, object)
• assertSame(expected, actual)
• assertSame(message, expected, actual)
• assertTrue(condition)
• assertTrue(message, condition)
• fail()
• fail(message)
• failNotEquals(message, expected, actual)
• failNotSame(message, expected, actual)
• failSame(message)

Na classe de teste vc tbm pode implementar os seguintes métodos:

/*Como esse método roda antes do caso de teste ele pode preparar o ambiente para o teste.*/
protected void setUp() {


System.out.println("Chamado antes de todo case method");

}


/*Pode ser usado para finalizar o ambiente de teste.*/
protected void tearDown() {


System.out.println("Chamado depois de todo case method");

}

Test Suite

Aqui neste exemplo estou usando JUnit4, em relação a versão anterior ele trouxe algumas inovações como anotações. Mas, algumas ou muitas coisas foi retiradas, como por exeplo Test Suite onde é possível realizar vários testes juntos. Distinção de erro, onde é verificado os erros antecipados e erros não antecipados, tbm foi retirado nesta versão. Por esses motivos alguns textos classificam o JUnit 4 como um novo framework, ao invés de uma versão atualizada o JUnit3xx.

Como eu acho bem prático a utilização do Test Suite com JUnit. Vou colocar aqui o código de como ficaria o codigo do Test Suite para a classe citada no exemplo. Lembrando que neste caso, teria que ser usado o JUnit3.

import junit.framework.Test;
import junit.framework.TestSuite;


public class AllTests {


public static Test suite() {

TestSuite suite = new TestSuite("Test for default package");//$JUnit-BEGIN$
suite.addTestSuite(HelloWorldTest.class);
//$JUnit-END$
return suite;

}

}

Essa etapa foi finalizada, e agora? Para esse ano eu não quero mais nada, mas para o ano que vem … espero muitas coisas.
E falando sobre a prova, estudei pelo livro Head First no qual dou referencia em um dos primeiros post aqui. Neste mesmo post também dou referencia há várias outras fontes de estudos. Na prova ao contrário do que eu pensei … caíu muito EL mas também caiu um pouco de tudo. Tudo que caíu na prova eu estudei … ou achei que tinha estudado … porque algumas coisinhas, eu simplesmente não me lembrava mais, talvez seja porque eu passei muito tempo estudando mas estudando aos poucos e ainda quando terminei de estudar tudo, demorei para marcar a prova. Então para mim ficou a lição aprendida: “quando for estudar para (principalmente) uma prova definir prazos que não seja muito longo e seguir, não ficar adiando o que foi planejado”.
E por hoje é só pessoal.
Valeussssss

Enfim … encontrei meu voucher que havia perdido. Ele foi com minha mudança para um deposito mas agora de posse do mesmo marquei minha prova para amanhã. Ainda tenho alguns simulados para fazer, mas para fazer a prova para esse mês amanhã é o último dia. E sem contar que depois da prova quero dar um tempo para curtir minhas férias.

Então a sorte está lançada é amanhã. SCWCD ou não )

PS. Este é um resumo para prova SCWCD

Filtros são componentes utilizados para interceptar um resquest antes de chegar ao servlet ou interceptar um response antes de chegar ao cliente. O container decide a ordem para invocar o filtro baseado na ordem da declaração no DD.

Um filtro deve implementar a interface javax.servlet.Filter

Em exemplo de filtro

package minhasClasses.filtros;

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import java.io.*;


public class MeuFiltro implements Filter{


private FilterConfig filterConfig;

//tem que implementar esse metodo
public void init(FilterConfig config) throws ServletException{
this.filterConfig = config;
}

public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws ServletException, IOException{
// o que o filtro vai fazer
chain.doFilter(req, resp);
}
public void destroy(){
// tem que implementar esse metodo. Lembre-se ... a interface.
}
}


Mapeando um filtro no DD

<filter>
<filter-name>meuFiltro</filter-name>
<filter-class> minhasClasses.filtros. MeuFiltro</filter-class>
<init-param>
<param-name>param1</param-name>
<param-value>algumaCoisa</param-value>
</init-param>
</filter>

Mapeando um filtro para uma url

<filter-mapping>
<filter-name>meuFiltro</filter-name>
<url-pattern>*.do</url-pattern>
</filter-mapping>
Mapeando um filtro para um servlet

<filter-mapping>
<filter-name>meuFiltro</filter-name>
<servlet-name>meuServlet</servlet-name>
</filter-mapping>

Um filtro também pode funcionar em caso como dispatcher, include, forward ou erro, mas deve ser colocado no DD

<filter-mapping>
<filter-name>meuFiltro</filter-name>
<url-pattern>*.do</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

<dispatcher> também pode ser INCLUDE, FORWARD ou ERROR. Caso não tenha declarado o <dispatcher> o default é REQUEST.