Bugtracker – Como é possível não usar?

Fonte: http://inospito.com/2007/11/01/bugtracker-como-e-possivel-nao-usar/

Uma das ferramentas básicas para o desenvolvimento de software com qualidade é o bugtracker. Tal como um bom IDE, o bugtracker é uma das ferramentas das quais não prescindo de maneira nenhuma, e considero a sua utilização como um requisito obrigatório se queremos desenvolver software com qualidade.

Infelizmente, os cursos de Engenharia Informática em Portugal não abordam este assunto, pelo que (já) não me surpreende que tenha encontrado tantos programadores ao longo dos anos que não usam nem fazem ideia da sua utilidade. Para quem não sabe, um bugtracker é simplesmente uma ferramenta onde se introduzem os bugs que encontramos numa aplicação e onde podemos depois acompanhar e controlar a evolução de cada bug: se está a ser corrigido, se já foi corrigido, em que versão foi corrigido, etc. Claro que as ferramentas de bugtracking fazem uma miríade de outras coisas, como relatórios, envio de mails de notificação ou pesquisas, mas o que realmente interessa é permitir acompanhar/controlar a evolução de um bug. Como é que uma ferramenta tão simples pode ter um papel tão importante?

Quando não usamos um bugtracker, temos o seguinte possível cenário (imaginem dois developers X e Y):

  1. X recebe um telefonema de um cliente, desesperado com um comportamento estranho da aplicação quando se clica duas vezes no quadrado vermelho que pisca
  2. X já imagina qual a linha de código que estragou a coisa e começa a corrigir
  3. Y que não está junto de X, recebe um telefonema de outro cliente com o mesmo problema. Claro que nós (leitores) sabemos que é o mesmo problema, mas o cliente não sabe e muito menos Y. Ainda por cima, Y nem imagina onde esteja o bug, porque ele não desenvolveu essa parte da aplicação.
  4. Y começa a tentar descobrir onde está o bug
  5. X já quase resolveu o bug, mas está a demorar imenso tempo porque está permanentemente a ser interrompido por telefones e mails de clientes a refilar por causa do bug.
  6. X resolve o bug e faz uma nova versão da aplicação. Claro que a nova versão não tem só a correcção do quadrado vermelho que pisca. Tem outras correcções que foram feitas recentemente. Ele tem que compilar a lista de correcções: ver os mails trocados entre os developers, telefonar aos outros developers, etc.
  7. Y já encontrou o sítio onde está o bug mas entretanto recebe um telefonema de X, perguntando que correcções foram feitas recentemente. Y diz-lhe que está a resolver o problema do quadrado vermelho que pisca. X responde-lhe que já foi resolvido. Y desespera. Os clientes continuam a telefonar.

Se usassem um bugtracker, o cenário poderia ser algo diferente:

  1. X recebe um telefonema de um cliente, desesperado com um comportamento estranho da aplicação quando se clica duas vezes no quadrado vermelho que pisca
  2. X introduz no bugtracker a descrição do bug e comunica ao cliente o identificador do bug, para que o cliente possa acompanhar a evolução do mesmo através da web (outra hipótese seria o próprio cliente introduzir o bug no bugtracker).
  3. X já imagina qual a linha de código que estragou a coisa e começa a corrigir, mas primeiro marca esse bug como “Em Correcção” na ferramenta
  4. Y que não está junto de X, recebe um telefonema de outro cliente com o mesmo problema. Claro que nós (leitores) sabemos que é o mesmo problema e Y, após pesquisar no bugtracker, também sabe.
  5. X resolveu o bug rapidamente porque a maioria dos clientes, antes de telefonarem ou enviarem email a refilar, pesquisaram no bugtracker e viram que o bug estava em correcção.
  6. X faz uma nova versão da aplicação e consegue saber todas as correcções incluídas na versão com uma simples pesquisa “Bugs resolvidos na versão XXX”

Existem imensos bugtrackers no mercado, muitos deles open-source. E não existe razão nenhuma para não se usar um bugtracker. Claro que podemos usá-los de muitas formas, algumas mais correctas do que outra. Espero falar disso num futuro post. Mas uma coisa vos garanto. Quem já trabalhou com um bugtracker, nem se imagina a trabalhar um dia sem um.

Anúncios

As novas funcionalidades do Dreamweaver CS3

Leandro Vieira (e-mail) trabalha com desenvolvimento para web desde 2002, é Diretor da Plugsites.net e Administrador do projeto DWMX.

O Dia 27 de março de 2007 foi marcado pelo lançamento da Adobe Creative Suite 3. Entre os integrantes dessa novidade, está a nova versão do Dreamweaver: o Adobe Dreamweaver CS3. E neste artigo pretendo lhe contar as novas funcionalidades que foram adicionadas a essa versão.

Spry framework para Ajax

Spry é um framework desenvolvido pela Adobe e através dele, o Dreamweaver oferecerá suporte ao Ajax. Como ele é um framework client-side e em forma de bibliotecas JavaScript, qualquer outro editor de HTML poderá utilizá-lo.

Através desse framework, o Dreamweaver CS3 através de sua interface oferecerá possibilidades para se trabalhar com os recursos do Spry de forma fácil e prática. O Spry se divide em três principais especificidades: Spry data, Spry widgets e Spry effects.

Através do Spry data, poderemos Integrar dados à uma página através de arquivos XML (esses arquivos podem ser um Feed RSS ou um banco de dados) com opção de filtros e ordenação.

Utilizando o Spry widgets, adicionaremos elementos de interface à página como listas, tabelas, abas, validação de formulário e repetição (loop) de regiões determinadas em uma página.

Já com o Spry effects, você adicionará efeitos visuais nos elementos de suas páginas. Com tais efeitos, os elementos de sua página poderão: crescer (grow), encolher (shrink), esmaecer (fade), realçar (highlight), entre outros efeitos.

Mas o Spry framework não é uma maravilha como esperávamos, tal framework utilizada atributos proprietários nas tags HTML, resultando num JavaScript obstrutivo (quando deveria ser não-obstrutivo), inacessível e na invalidação da página. Espero que Adobe trabalhe arduamente para corrigir esses consideráveis detalhes.

Abaixo há uma ilustração da aba Spry na Insert bar do Dreamweaver CS3.

Visualização da aba Spry na Insert bar do Dreamweaver CS3Visualização da aba Spry na Insert bar do Dreamweaver CS3

Suporte completo a CSS

Se tratando de Cascading Style Sheet, o Dreamweaver CS3 incorporou inúmeros recursos que merecem ser mencionados. Começando pela disponibilização de vários layouts CSS e cada um deles com extensivos e completos comentários a respeito das declarações CSS utilizadas.

O novo painel CSS Styles ficou super interessante, funcional e focado em importantes facilidades. Agora, você poderá mover as CSS de várias maneiras, ou seja, mover as CSS inline para o head; mover do head para um arquivo, CSS, externo; mover entre um documento e outro; e muito mais.

O novo painel CSS Styles ficou unificado e inteligente, agora visualizar as declarações CSS aplicadas em um elemento em específico ficou super fácil, e você poderá alterar tais declarações de forma visual, rápida e de forma consistente.

Através do CSS Advisor website, você encontrará soluções para os bugs de navegadores específicos se tratando de CSS, e tais soluções são postadas pelos membros dessa comunidade. Há dicas interessantes e importantes por lá.

Através da própria interface do Dreamweaver, será possível verificar a compatibilidade da página entre os navegadores disponíveis; o que significa dizer que você economizará tempo, terá certeza que a visualização da página será consistente entre os navegadores e os sistemas operacionais. E tudo isso sem a necessidade de abrir o navegador no seu computador.

Integração entre os programas

O Dreamweaver CS3 terá uma integração eficiente com o Adobe Photoshop CS3 e o Fireworks CS3, afinal de contas, todas agora são parentes e ambos se conhecerão cada vez mais.

Suporte ao formato de vídeo FLV

Agora, com apenas cinco cliques e sem nenhum conhecimento do Adobe Flash, será possível inserir vídeos em sua página de forma fácil e customizada. Uma vez que tal vídeo, tenha o formato FLV.

Suporte as principais tecnologias

Como é de seu conhecimento, o Dreamweaver oferece suporte as principais linguagens utilizadas no desenvolvimento web, ou seja, HTML, XHTML, CSS, XML, JavaScript, Ajax, PHP, Adobe ColdFusion®, ASP, ASP.NET, e JSP.

Minha expectativa, ainda não tive informações a respeito, é quanto a melhoria no suporte ao PHP. Tenho conhecimento que o suporte será melhorado, fato comprovado pela comprada da Interakt pela Adobe. Vamos ver o que nos aguarda.

Acredito que com essas informações foi possível ter uma noção do que o Dreamweaver CS3 irá nos proporcionar. Então lhe pergunto: o que você achou desses novos recursos? Qual o mais interessante para você, por que? Vamos discutir a respeito. Comente ou me envie um e-mail. Um abraço a todos.

JMeter – Executando testes de desempenho

por Miguel Fornari

Uma ferramenta fundamental para entender o funcionamento de um determinado SGBD é execução de testes de desempenho. A primeira etapa é construir um esquema composto por tabelas e índices. O esquema pode ser o da sua aplicação ou um um padrão disponível. Para este segundo caso, no artigo anterior foi apresentado o benchmark TPC-C e um software para gerar o esquema, popular as tabelas e criar os índices. Neste artigo apresentamos um software para executar os testes e monitorar o desempenho do SGBD.

Utilização do JMeter

O software chama-se JMeter, é uma das ferramentas desenvolvidas dentro do projeto Jakarta. Ele esta disponível em http://jakarta.apache.org/jmeter. JMeter permite testar diferentes componentes de um ambiente servidor, como servidores HTTP, FTP e SGBD. Obviamente, aqui nos concentraremos na análise de SGBD.

Após baixar o software e descompatá-lo em um subdiretório, basta clicar no arquivo chamado JMeter.jar para executar o programa. A tela de entrada esta apresentada na figura 1.

03-01-07pic01.JPG
Figura 1 – Tela inicial do JMeter

A primeira tarefa é configurar a conexão JDBC. Para tanto, clique com botão direito em Test Plan, e escolha Add –> Config Element –>JDBC Connection Configuration. A figura 2 mostra a tela que deve ser preenchida. O principal é definir o string de conexão. Para quem não esta acostumado com Java, do exemplo da figura 2, basta alterar a parte final, depois do arroba, com a seguinte sequência IP:PORTA:SID, não esquecendo dos “:” entre uma informação e outra. E, claro, usuário e senha. Porém, cada SGBD tem uma string de conexão diferente, então, se não estiver utilizando Oracle, é necessário dar uma olhada pela Internet. Importante e fundamental, o driver JDBC deve ser colocado no subdiretório /lib do JMeter. É mais fácil que alterar o classpath no arquivo de execução. Se não for feito, o JMeter não dá mensagem de erro.

03-01-07pic02.JPG

Figura 2 – Tela de configuração da conexão

A terceira etapa é definir a consulta SQL que será executada, no menu Add –> Sampler –> JDBC Request. A janela a ser preenchida pode ser vista na figura 3. O usuário pode escolher três tipos de consultas: Select, Update e Callable. A opção Select já é autoexplicativa. A opção Update inclui qualquer comando de modificação em tabelas, portanto, Insert, Update e Delete. E Callable pode ser utilizada para executar Stored Procedures.

03-01-07pic03.JPG

Tela 3 – Configuração do comando a ser executado no banco.

A quarta etapa é configurar os parâmetros da configuração. Na figura 4, os parâmetros básicos são:

Number of threads (users): número de usuários concorrentes a simular

Ramp-up period (in seconds): é a diferença entre iniciar um usuário e outro. Zero indica para o JMeter iniciar todos juntos no início da simulação. Outro valor, mairo que zero, indica um certo escalonamento, Por exemplo, 5 usuários e 10 segundos, resulta em um usuário a cada 2 segundos.

Loop-count: número de vezes que o comando SQL será repetido. Marcando Forever indica que o comando será repetido muitas vezes, até todos usuários concluírem

03-01-07pic04.JPG
Figura 4 – Configuração do teste.

Para monitorar os resultados, o melhor é acrescentar um gráfico de resultados, na opção Add –> Listener –> Graph Result.

Resolvida a utilização do software, o próximo ponto crítico é decidir o que medir e como. Um tanto de método científico é importante:

  1. identifique seu problema ou dúvida;
  2. execute o comando SQL de maneira individual;
  3. configure, inicialmente, valores baixos para número de usuários e repetições, de modo a não sobrecarregar seu servidor já na primeira vez, até achar valores interessantes;
  4. se for alterar parâmetros de configuração do SGBD, altere um parâmetro de cada vez, sempre guardando os resultados, até encontrar a configuração mais adequada para sua situação.

Conclusão

E, finalmente, paciência para verificar várias alternativas, pois os parâmetros de configuração se influenciam mutuamente. As vezes, alterar apenas um deles pode surtir pouco efeito, mas combinado com um segundo parâmetro, pode dar um efeito mais significativo.