Gerentes de projetos inatos.

Sim... você é um, eu sou, todos nós somos gerentes de projetos por nascença. Ouso até em dizer que somos grandes gerentes de projetos, só não confundam com gerentes de grandes projetos.

Pense nos últimos projetos que você gerenciou, daqueles que você aloca e administra recursos, estima prazos, define características e prioridades, negocia com clientes, enfim, todas as atividades que um gerente (como nós) sabe executar.

Você vem com essa: "Ah, eu nunca gerenciei um projeto, aliás, nem sei executar todas estas atividades!"

Será? Aposto que você já gerenciou vários projetos, e digo mais, vários deles ao mesmo tempo. Também aposto que a grande maioria dos projetos tiveram êxito e muitos deles pleno sucesso. Cito exemplo:

Faltam 2 meses para acabarem as suas aulas na faculdade, datas marcadas para as entregas dos trabalhos finais de BD, Compiladores, Linguagens de Programação, SO (éca), além das provas finais, incluindo o temível Cálculo VII. Cara, você tá em apuros!

Você vai para casa, xingando os professores é claro, e pensa em tudo que deve ser feito. Em Linguagens de Programação você está bem na foto e logo define: "Vou deixar por último, se der tempo, faço alguma coisinha".

Em SO a coisa muda de figura, além da professora ser chata, você não gosta da disciplina. Sorte a sua que o trabalho é em dupla e um dos seus colegas manja muito. Você muito esperto, combina com este colega de fazerem juntos o trabalho. Como tem muita coisa a ser feita, já marcam para toda terça e quinta a noite o desenvolvimento deste trabalho.

Sobre BD e Compiladores você divaga: "Vou precisar de um compilador para o meu BD, então é melhor eu começar o meu trabalho de Compiladores para ganhar experiência, depois começo o de BD". Pelas suas contas você precisaria trabalhar umas 12 horas por semana nestes 2 projetos para conseguir entregar a tempo. Acho melhor você cortar as saídas de sexta a noite para conseguir estas 12 horas cara, afinal, são só 2 meses.

Para as provas você resolve estudar aos finais de semana, e no dia anterior à prova dar aquela revisada. Como você pode ver, tudo planejado.

Após 1 mês, o trabalho final de SO está de vento em popa, afinal o seu colega está mandando ver. O de Compiladores você teve vários problemas, já sanados, mas que fizeram atrasar o trabalho de BD. Lá foi você chorar as pitangas para o professor de BD, mas ele aceitou você não fazer os comandos "order by" e "group by". As provas melhor impossível, só o temível cálculo que não entrava na cabeça.

Prazos encerrando, SO entregue, Compiladores entregue, BD faltando pequenos detalhes, e Linguagens de Programação (você esqueceu ?). Sorte sua que o professor é gente boa, com 5 minutos de conversa você consegue mais 1 semana de prazo. Pra melhorar a história, o bicho é o maior matão, então qualquer meleca que você fizer está bom. Provas faltando apenas de cálculo, mas você prometeu se dedicar neste último final de semana.

Por fim tudo entregue e você no bar com os amigos comemorando o término do semestre. Só um coisa, lembre de voltar no próximo semestre para fazer Cálculo VII novamente. =PPP

Dada as devidas proporções, não te achasse um gerente de projeto?

Queries nativas em Java.

Na onda de sugestões para facilitar o desenvolvimento de aplicações Java, veio em mente um projeto que eu e o Vitor gostaríamos de ter feito um tempo atrás. A idéia é oferecer queries nativas em Java, acabando com algumas fraquezas de consultas baseadas em String. Na verdade este projeto era para ter saído no lugar no SnailDB, mas como o objetivo era a gente se formar, acabamos priorizando o Snail para fechar créditos na disciplina de BD.

1) Uma limitação de consultas baseadas em String é que a checagem sintática e de tipos é feita em tempo de execução, um exemplo SQL:

"SELECT nome FROM Pessoa WHER idade > 20"

O desenvolvedor saberia do erro sintático no "WHER" apenas em tempo de execução. Outra questão são os erros semânticos, supondo que o desenvolvedor atribua o retorno de um registro desta consulta a uma variável de tipo "Integer", este erro também só aconteceria em tempo de execução.

2) Outra grande limitação é que os atributos utilizados nesta consulta não participam de uma processo de refatoração, artifício muito utilizado pelos desenvolvedores, deixando o processo de manutenção do código oneroso. Pense em refatorar o código da classe Pessoa, para o atributo "idade" ser "idadeEmAnos". Buuummmm, esta consulta passaria a dar erro!

A idéia de queries nativas é simples, as consultas são escritas com uma sintaxe que faz "parte" da linguagem, permitindo que checagem sintáticas e de tipos possam ser feita em tempo de compilação, assim como os atributos utilizados na consulta participem em um processo de refatoração. Segue um exemplo de consulta sobre uma coleção em memória, retornando todos os clientes iniciando com nome "Java":

Collection(Customer) customers; // prevayler poderia manter esta coleção =D
...
Collection(Customer) result = FROM customers c WHERE c.name LIKE "Java%";

O objetivo do post é salientar o benefício de um recurso como este, deixando de lado a sintaxe a ser utilizada.

Quais seriam os benefícios de queries nativas ?

1) Checagem sintática e semântica: desenvolvedor teria um feedback rápido das "cagadinhas" feitas na consulta em tempo de compilação;

2) Facilidade de manutenção: as IDEs poderiam manter referência aos atributos utilizados na consulta, permitindo a refatoração e outros artifícios para manutenção de código;

3) Facilidade de aprendizado: este benefício vale aos desenvolvedores vindos de consultas SQL-based.

Meu deus, vamos alterar a especificação da linguagem ? Não.

1) Poderíamos fazer algo em cima do Java, que checasse as consultas no código antes do compilador Java, para então traduzir para um código Java válido;

2) Viajando um pouco mais, poderíamos traduzir esta consulta para algum banco de dados específico, talvez.

A galera do db4o fez algo muito legal, queries nativas através de código Java. Segue um exemplo:

Collection(Customer) result = database.query(Customer)(new Predicate() {
public boolean match(Customer customer) {
return customer.getName().startsWith("Java");
}
});

Eu gostaria de algo mais simples, que o desenvolvedor não precise escrever tanto e que você mais intuitiva para o recém chegados do SQL. Quem sabe juntar os dois mundos não dê frutos ?

Porque remexi nesta idéia novamente ? Foi lendo a a especificação do C# 3.0, os caras colocaram queries nativamente na linguagem, me parece ter ficado bem descente. O projeto deles é o LINQ. Um pequeno exemplo:

var result = from c in customers
where c.name == "Java"
select c;

E o mais legal é ver uma idéia que tivemos alguns anos atrás, sendo investida e dando frutos nas linguagens do momento.

Bom deixa eu ir, mulher ta em cima. Mas vou continuar pensando a respeito e postar algo mais concreto. Abraço.

Emprego: O que você responderia?

Lendo o folhetim de um grande guru de RH do país, me deparei com uma pergunta feita na entrevista de emprego para uma determinada vaga:

"Você está dirigindo seu carro numa perigosa noite de tempestade. Você passa por um ponto de ônibus e vê três pessoas aguardando o ônibus:
- Uma senhora idosa que parece estar à beira da morte;
- Um médico que salvou sua vida no passado;
- A pessoa amada que habita os seus sonhos.
Você só pode levar um no seu carro.
Qual você escolhe? Por favor justifique sua resposta".

Como farei um tour por SC neste carnaval, deixo a resposta do candidato escolhido para a próxima semana. Enquanto isso...

O que você responderia ?

Usar padrões é legal.

Como um bom amante das bases da computação, neste final de semana baixei o código do compilador Java da Sun, para dar aquela fuçada básica na implementação dos caras.

A função do compilador é algo muito simples: ler um arquivo ".java", verificar se tudo o que o arquivo está "falando" é correto, em caso afirmativo gerar o ".class" que será executado futuramente pela JVM. Apesar do objetivo simples, tem muita coisa para se divertir no desenvolvimento de um compilador, mas deixo esta parte divertida para um futuro tutorial "Eu quero o meu compilador".

Neste post, gostaria de destacar o quanto é legal usar padrões de projeto. Bastou algum tempinho fuçando o código, para entender o funcionamento do compilador. Porquê ? Malditos patterns espalhados pelo código, ajudaram a comunicar pelo que cada classe era responsável, aliás, este é um dos principais objetivos dos patterns na minha opinião, agilizar a comunicação entre desenvolvedores.

Outra coisa que me deixou muito feliz, é que a estrutura do compilador é muito parecida com que eu usei no SnailDB, inclusive com os mesmos tipos de padrões, principalmente Visitor. Ou seja, desenvolvedores do javac também entenderão tranqüilamente o meu código.

Use padrões, é legal !!!

Sem time, sem metodologia (parte II).

Dando continuidade ao último post e aliviando um pouco a dor dos defensores do RUP, vou contar a experiência de implantação do XP em uma "empresa", na qual fui um mero observador. Como vocês devem suspeitar, o final desta história é claro que não é vitorioso, afinal este é o objetivo do post: "Sem time, sem metodologia".

A implantação do XP foi feita na equipe que desenvolve os softwares internos de uma universidade, que nada tem de diferente de uma grande empresa, tirando a maior burocracia claro.

Como sempre, o ambiente era o mais amigável para a implantação, cliente sempre perto (eles próprios), grupo de 8 desenvolvedores, vários deles experientes, "diretores" dando carta branca ao projeto, enfim, tudo nos conformes para o XP.

Consultoria básica para treinar o pessoal, com direito ao Klaus e tudo, toda aquela euforia na equipe, "gerente" feliz com este clima, novatos adorando o contato com pessoal mais experiente, coisa mais linda do mundo !!!

Bom, terminada a consultoria, hora de caminhar com as próprias pernas. Passaram alguns meses, disciplinas do XP sendo levadas na ponta dos dedos, novatos já não poderiam mais ser chamados de novatos, estavam detonando. E foi neste ponto que eu perdi o contato com essa galera. "Ah Giovane, e o final ?"

Em conversa rápida estes dias com um dos desenvolvedores, ele me contou o final. Realmente um final que eu nunca tinha imaginado. Todo aquele ambiente, produtividade, euforia, já era. Mataram o XP naquela equipe e voltaram a desenvolver como nos "bons" e "velhos" tempos.

Os ditos desenvolvedores "experientes" (sabe aqueles analistas dos velhos tempos ?), puxaram o barco para trás, deixaram de aplicar várias disciplinas, deixaram de passar conhecimento, deixaram de participar de um time para montar o seu "auto-clã".

Benditos dinossauros, com sua vontade atrofiada, cérebros de amendoim que só pensam na aposentadoria e praticam o comodismo. Só pode ser auto defesa isso, vendo que a gurizada estava chegando ao seu nível, mas com uma diferença, a sede de mudança.

Uma pena isso, que essa é uma das maravilhas do XP, nivelar tua equipe por cima !

Sem time, sem metodologia.

Falar de experiências com metodologias de desenvolvimento estava entre as minhas prioridades neste blog. Na onda do post do Vitor, achei interessante priorizar e dar mais "pano pra manga".

Bom, deixando de lado o "poder" da metodologia X ou Y, eu gostaria de focar no "poder" das pessoas envolvidas neste processo. Contar uma pequena experiência.

Felizmente trabalhei em uma grande empresa que aceitou o desafio de implantar uma metodologia de desenvolvimento em todos os seus departamentos. O ambiente era o melhor possível, juntava a "fome com a vontade de comer", os desenvolvedores e gerentes loucos por um processo de desenvolvimento, enquanto os diretores tinham paciência e dinheiro para implantar este projeto.

Sucesso ? Nem tanto !!!
Diretores fomentaram a implantação do RUP em todos os departamentos, e a escolha por tal metodologia foi recebida com "sorrisos amarelos" pelos líderes do meu departamento (tecnologia), afinal, estes líderes achavam o RUP "burocrático" demais para a tecnologia. Mas, vocês devem saber o que é uma ordem de diretoria, certo ? Então vamos a implantação.

Dado o devido treinamento é hora de colocar a mão na massa: especificação, casos de uso, diagramas, testes, ... enfim... tudo aquilo que o RUP disponibiliza, certo ? Errado.
Reuniões e mais reuniões entre líderes discutindo para que serve o tal "caso de uso". Debates filosóficos e intermináveis para (re)definir o objetivo de uma especificação. Atividades e mais atividades fora da metodologia, baixando ainda mais a produtividade no início da implantação.
Eu me perguntava: "Que tesão o 'Joãozinho' tem em criar o seu caso de teste, ouvindo o seu líder dizer que aquilo não presta ? É como ser incentivado a transar com uma mulher por alguém que não gosta de mulheres."

Então, depois de meses de "trabalho", adivinhem o que a diretoria viu de retorno ? Exatamente o que os líderes queriam, NADA, apenas mostrar que o RUP era um bixo papão e não servia para a tecnologia, sem ao menos vestir a camisa e tentar extrair o que de bom ele poderia oferecer. Na minha humilde opinião, a metodologia foi engolida pelos líderes logo no seu início.

A conclusão com este tipo de experiência, onde o insucesso acontece pela falta de TODOS vestirem a camisa, acredito que seja generalizável a qualquer ramo, atividade, idéia, objetivo, mudança. Isto vai de encontro as conclusões que o Bernardinho chegou, que o Vitor mencionou, e que qualquer pessoa com senso de grupo chegaria:


"Sem time, sem metodologia... sem time, sem mudanças !!!"


PS: Fica pra próxima uma histórinha sobre XP

Feliz Ano Novo !!! Sim, isso mesmo.

"Estamos em 1º fevereiro e tais me desejando feliz ano novo ? Taxxx doido mermão."

Sim, eu sei. Porém eu considero que meu ano esteja começando hoje, 1º de fevereiro. Por isso as felicitações a todos.

Depois de um 2006 com relações restritas a comunidade free soft, tenho como meta voltar a contruibuir ativamente neste "novo ano". Galera que enfrenta mestrado sabe como é, né Vitor !!! Saiu das costas uma bagatela de 50 horas por semana investidas nas disciplinas do ano passado, acho que dá para usar isso de alguma forma útil para a comunidade, heheh !!!

Como ? Bem, incentivado pelo últimos posts (Vitor Pamplona, "Shoes", DFJUG) pretendo estar ajudando através tutoriais, artigos, forum, codando, sinal de fumaça, enfim, qualquer forma !
O blog, claro, servirá como um dos meios de comunicação, através de experiências, idéias, insatisfações, opiniões, relatos, mente feminina... calma, calma... é que estou morando com a mulher agora, então estou em processo de entendimento desta mente, então qualquer informação que contribua nesta área acho que também é bem vinda.

Ah, também não poderia deixar de mencionar a "memória viva", o Vitor. Divido apartamento com o "cara", quer maior incentivo que esse ? =ppp
A comunidade se beneficia com o conhecimento do guri. Eu, além disso, me beneficio com a seus conhecimento em limpeza, limpa um ap que é uma beleza.

Bom, por hora é isso !

Abraço galera