Café com Tecnologia

Archive for the ‘Notícias’ Category

Hoje em minha agenda havia um horário reservado para a entrevista para a certificação MPS.BR da empresa onde trabalho.

Esta entrevista era específica a um dos projetos em que atuo.

Mas você sabe o que é MPS.BR e qual seu propósito? Quais seus resultados atuais no Brasil?

O propósito do MPS.BR (acrônimo) é a Melhoria de Processo de Software Brasileiro, uma versão tupiniquim ao CMMi quem tem como desafios sua criação, aprimoramento, consolidação e adoção no Brasil. Os níveis das avaliação vão de A (maior) a G (menor).

Atualmente contam com:

• 13 Instituições avaliadoras
• 17 Instituições implementadoras
• 186 instituições com avaliações vigentes

Entre as instituições com avaliações vigentes, temos a seguinte distribuição dos níveis:

Números do MPS.BR 2010

Notem que a maioria das instituições ainda encontram-se no Nível G da certificação. Neste nível, as instituições precisam possuir os processos de:

• Gerência de Requisitos
• Gerência de Projetos

Neste nível, é garantido que o processo é executado e gerenciado.

A medida que o Nível vai se aproximando do Nível A, os atributos dos processos tendem a ser OTIMIZADOS CONTINUAMENTE.

Vocês devem ter ficado curiosos e se perguntando: quais são as 4 instituições do Nível A?

…

Elas são:

• BRQ
• CPMBraxis
• Politec
• Stefanini

Se sua empresa não possui ou não se interessa por esta certificação, pare e pense um pouco: 4 instituições com faturamento acima de R$ 200 milhões se importam.

As vezes, o uso de algumas combinações pregam uma grande peça.

Neste post, vou expor algo que acontece quando se usa ICEFaces para manipular datas através do componente selectInputDate combinado com o conversor convertDateTime.

O uso do trecho de código abaixo…

<ice:selectInputDate id="dataInicio"
    renderMonthAsDropdown="true" renderYearAsDropdown="true"
    title="Selecione a Data" renderAsPopup="true"
    required="true" value="#{meuBackingBean.dataInicio}"
    partialSubmit="true">
    <f:convertDateTime pattern="dd/MM/yyyy HH:mm:ss"/>
</ice:selectInputDate>

… produz um resultado BEM DIFERENTE do trecho de código abaixo.

<ice:selectInputDate id="dataInicio"
    renderMonthAsDropdown="true" renderYearAsDropdown="true"
    title="Selecione a Data" renderAsPopup="true"
    required="true" value="#{meuBackingBean.dataInicio}"
    partialSubmit="true">
    <f:convertDateTime pattern="dd/MM/yyyy"/>
</ice:selectInputDate>

E quando digo diferente, digo da pior maneira possível.

Antes de mostrar o resultado, perceberam a diferença entre as implementações?

A única diferença está na definição do pattern na tag convertDateTime.

Suponhamos que neste objeto seja selecionado a data de 03/02/2010, e isto foi feito as 17h52.

Para o trecho com o pattern indicando dd/MM/aaaa HH:mm:ss, o resultado da definição do atributo dataInicio no Backing Bean é “setDataInicio=Wed Feb 03 17:52:28 BRST 2010″. Correto, se o componente não tivesse exibido estas mesmas informações no input com o horário 2h a frente.

Para o trecho com o pattern indicando dd/MM/aaaa, o resultado da definição do atributo dataInicio no Backing Bean é “setDataInicio=Wed Feb 02 22:00:00 BRST 2010″. Errado, bem errado. Notem que aqui o componente, por algum motivo, criou ou formatou a data/hora usando o timezone GMT e subtraiu 2h (já que estamos no timezone America/Sao_Paulo).

O que fazer para solucionar isso?

Para resolver esta questão será necessário adicionar o atributo timeZone no formatador convertDateTime.

<ice:selectInputDate id="dataInicio"
    renderMonthAsDropdown="true" renderYearAsDropdown="true"
    title="Selecione a Data" renderAsPopup="true"
    required="true" value="#{meuBackingBean.dataInicio}"
    partialSubmit="true">
    <f:convertDateTime pattern="dd/MM/yyyy" timeZone="#{meuBackingBean.timeZone}"/>
</ice:selectInputDate>

Neste caso, adicionamos #{meuBackingBean.timeZone} como valor do atributo timeZone.Por algum motivo, esta definição torna-se obrigatória para que a data não seja criada com horário incorreto.

No Backing Bean, o que devemos implementar é:

@Component
@scope("session")
public class MeuBackingBean.... {

private java.util.Timezone timeZone = TimeZone.getDefault();
...

public TimeZone getTimeZone() {
    return this.timeZone;
}

}

Esta semana surgiu uma demanda relacionada à elaboração de questões a serem aplicadas a candidatos em entrevista de emprego. A intenção é que a equipe de RH possa avaliar com mais detalhes o nível de conhecimento técnico dos profissionais que possam ser contratados e evitar demissões relacionadas à baixa produtividade.

Antes de mais nada é preciso entender e separar os assuntos: o candidato conhecer JAVA não quer dizer que será produtivo.

Nada impede um candidade ir muito bem em uma avaliação técnica incial na entrevista com a equipe de RH, respondendo questões exclusivamente de JAVA se é sabido que NENHUM projeto hoje em dia utiliza JAVA puro. Todas as aplicações criadas partem de frameworks existente e consolidados no mercado.

Outra questão: de que adianta aplicar uma prova de JAVA 6 em um candidato se muitas das aplicações serão executadas em servidores de aplicação que utilizam JAVA 5, JAVA 4 e até mesmo (sim sim salabim) JAVA 3?

O resultado dessa avaliação inicial tornar-se-á irrelevante diante destes cenários.

É preciso especializar mais estas abordagens.

Cada Cliente de sua empresa permite ou restringe o uso de tecnologias e fornecedores, o que faz com que esses testes tenham que ser dinâmicos ao ponto de poderem absorver estes requisitos.

E se o candidato então for ótimo em todos os testes de JAVA aplicados, é garantia que o mesmo será altamente produtivo no projeto?

NÃO.

De que adianta o profissional conhecer JAVA de modo, teoricamente, satisfatório se não há empenho em absorver o conhecimento do négocio, não for proativo em busca de otimizar os códigos, propor soluções eficazes, etc. É preciso que este profissional saiba andar com as próprias pernas o máximo possível.

Muitas vezes fiquei pensando no quão legal seria eu construir um framework. Afinal, a cada mês um novo framework aparece no Google, por que não mais um? Imaginem um framework chamado “Fabiowork” ou “FazTudoWork”. Aposto que pelo menos meia dúzia de acessos o site teria só pela curiosidade da galera em descobrir quem é o responsável por tanta “criatividade”.

Calma, não vão sair digitando esses nomes no Google. Perda de tempo, podem apostar. Bom, o termo “fabiowork” encontra 542 resultados fabiowork (0,36 segundos). Impressionante.

Não estou aqui para falar mau de frameworks, até porque uso e recomendo, como o bom e velho Struts, Spring, bla bla bla work, etc.

Eles são úteis, muito, economizam tempo com implementações e definições repetitivas para a maioria das aplicações comerciais que são construídas.

Agora, construir um? Não, obrigado.

Por que?

Bom, prefiro continuar a usar frameworks já conceituados no mercado que possuem equipe altamente especializada e dedicada a manter tudo na mais perfeita ordem a harmonia. Prefiro continuar a ler documentos e usar aplicações de referência onde é realmente REFERÊNCIA. Prefiro, mais ainda, focar no entendimento do negócio.

Não estou muito afim de usar frameworks construídos por profissionais que dizem para não fazer A mas mantém a aplicação de referência e sua respectiva documentação fazendo A.

Não estou afim de ouvir dos profissionais que construíram o framework que eu ter 1 classe abstrata (com apenas algumas implementações) no momento 1 da aplicação é “aumentar a complexidade da aplicação prematuramente”, que eu posso “fazer um refactory mais pra frente”.

Você quer construir um framework? ÓTIMO. Mas por favor, não construa Frameworkenstein nem se torne um Arquitetoenstein. Combinado?