Ext Direct–Um JSONRPC (parte 1)

Venho trabalhando com ExtJS esporádicamente no último ano e estou ainda aprendendo os truques e macetes desta bela biblioteca. A cada dia que passa eu descubro uma funcionalidade nova ou um jeito diferente de fazer as coisas que me deixa surpreso e, algumas vezes, fascinado com ela. Quero compartilhar com vocês uma dessas recentes “descobertas”, o Ext Direct.

Só para contextualizar aqui vão algumas das principais características do ExtJS:

• É um framework JavaScript “cross-browser” para o desenvolvimento de RIAs;
• Framework com mais de 4 anos, atualmente  está na versão 3.2.1 (versão 4.0 já esté em BETA )
• Suporte à Firefox, Chrome, IE 6+, Safari e Opera;
• Inúmeros componentes e widgets;
• Grande facilidade na criação de extensões.

Voltando ao Ext Direct, ao desenvolver minhas aplicações com ExtJS sempre utilizei JSON através do data stores para fazer a transmissão de dados do servidor para a aplicação, e para fazer o caminho inverso optava pelo cfcAjax (trabalho com Coldfusion) pela comodidade de ser uma biblioteca que já dominava. Mas eis que, ao iniciar um novo projeto, eu resolvo me aprofundar no tal Ext Direct e foi quando tive uma grata surpresa.

O Ext Direct é um pacote incluso a partir da versão 3.0 do ExtJS para comunicação entre a aplicação desenvolvida neste framework e o servidor, através de JSON. Algumas características:

• Métodos remotos por metadata;
• Configuração via JSON/XML;
• Conversão de tipos;
• Chamadas assíncronas;
• Upload de arquivos;

Segundo o site do Sencha (conjunto de frameworks JS no qual está incluído o ExtJS), o Ext Direct está integrado com PHP, Ruby, Coldfusion, Java, .NET e Perl. Para a comunicação com o servidor é necessário criar apenas 3 componentes no servidor, são eles:

1. Configuration: para especificar quais classes e métodos estarão visíveis à aplicação;
2. API: para que seja gerado à partir do Configuration a descrição dos métodos;
3. Router: para rotear as chamadas para as classes e métodos apropriados.

Pelo fato do Coldfusion ter a capacidade de fazer a instrospecção de seus métodos dinamicamente em tempo de execução, não precisei criar o arquivo de configuração em XML/JSON. Porém tive alguns problemas para usá-lo com o Railo (Servidor CFML open-source) mas nada que não seja possível resolver rapidamente (fica pra um próximo post).

Após a configuração do servidor, basta criar um provedor em sua aplicação e invocar os seus métodos remotos através de JavaScript, isso garante uma maior agilidade, segurança e rapidez no desenvolvimento da aplicação uma vez que o número de linhas para comunicação com o servidor fica muito reduzida.

Minha idéia é explicar aqui no blog como configurar e utilizar o Ext Direct, mas para o post não ficar muito longo vou ter que dividí-lo em partes, hoje ficamos por aqui mas em breve continuarei.

Antropologia em 3 camadas

MVC

Não se assuste com o título do post, não quero me passar por antropologista nem tão pouco sou um profundo conhecedor do comportamento humano, talvez um bom observador. O título é só uma brincadeira (talvez frustrada) com a famosa arquitetura de desenvolvimento em 3 camadas, o MVC.

Resolvi escrever sobre isso depois de perceber que está cada dia mais comum ver ofertas de emprego para a desenvolvedores que parecem mais uma sopa de letrinhas, são tantas diferentes linguagens, banco de dados e frameworks que chega a embaralhar os olhos. Apesar de a discussão sobre a importância de diplomas e certificados estar cada vez mais em cheque o que vemos são empresas que continuam contratando por checklist de tecnologias.

Mas será que o conhecimento técnico é o que realmente importa no momento de se buscar um novo funcionário? Para poder responder isso primeiro vamos entender quais e o que são as tais 3 camadas do profissional.

Requisitos mínimos

Perfil técnico: é o perfil do profissional com relação a expertise, sua capacidade de resolver problemas e seu conhecimento sobre uma ferramentas, processo, linguagem ou qualquer coisa com que ele trabalhe no seu dia-a-dia.

Perfil profissional: é o perfil do sujeito quanto ao comportamento dentro da empresa, como responsabilidade, cumprimento de prazos, pontualidade, comunicação, trabalho em equipe, generosidade no compartilhamento de conhecimento, entre outras qualidades que envolvem seu comportamento.

Perfil pessoal: este perfil talvez seja em alguns casos considerado irrelevantes, já que algumas empresas só se interessam pelo funcionário no período entre ele entrar pela porta para o início de seu expediente até o momento em que vai embora. Este perfil é aquele que representa a humildade, dedicação, perseverança, educação, carisma e etc.

Vale lembrar que nenhum dos perfis é completamente independente dos demais e dificilmente você encontrará alguém que tenha somente um deles desenvolvido ou com um único pouco desenvolvido. E que as pessoas são mutáveis, mas cada um dos perfis tem um custo e tempo diferente para que se desenvolva.
Analisando cada um deles separadamente, acredito que o perfil pessoal seja o mais difícil de ser moldado dentro da empresa, até mesmo a identificação deste perfil é complicada de se conseguir. O jeito mais fácil (e talvez único) de se conseguir estas informações do candidato é através de indicação feitas por pessoas de confiança, uma vez que o tempo de contato durante entrevistas e acertos de contratação são muito curtos. Contratar alguém sem ter um conhecimento básico sobre seu lado pessoal é um grande risco, embora se tenha o período de experiência, que como o próprio nome diz, é um tempo para que a empresa conheça o empregado e ele à empresa, todos sabemos que uma quebra de contrato neste período livra a empresa de alguns encargos mas o prejuízo já aconteceu, afinal a empresa investiu 3 meses de salário e treinamento, além de que, provavelmente, terá que reinvestir isso em uma nova tentativa. Pelo mesmo fato de ser um perfil que não se molda dentro de uma empresa, insistir em alguém confiando que ele irá um dia mudar pode ser uma aposta ainda mais perigosa.

Em contrapartida, o perfil profissional talvez seja o perfil em que a empresa mais tem poder de modificação pois pode agir diretamente sobre o comportamento do empregado. Com algum jeitinho a empresa consegue treinar os seus funcionários para serem mais responsáveis, pontuais ou comunicativos. Cabe ao gerente do setor saber buscar as melhores formas de incentivar e recompensar cada indivíduo. Com aquelas conversas a sós na sala de reunião ou uma conversa descontraída e indireta se é possível transmitir a visão da empresa e apresentar pontos a serem melhorados. Claros que existem medidas mais drásticas mas que muitas vezes são mais efetivas, descontos salariais por atraso ou o compensação de horas sempre transmitem a mensagem.

Já o perfil técnico é muito mais dependente de atitudes próprias do funcionário, a busca pelo conhecimento e crescimento deve partir dele sempre, o que se pode fazer para ajudar e ter uma equipe generosa que não se omita no momento de transmitir o que se sabe. Trocas de ideias, conversas técnicas, explicações sobre suas soluções ajudam ao novo funcionário a aprofundar seu conhecimento mas isto só será realmente efetivo se ele quiser e estiver pronto a aprender. A dedicação e a humildade pode fazer toda a diferença neste momento. Isso nós mostra que o “perfil pessoal” do sujeito pode ser o fiel da balança para sucesso ou insucesso do funcionário dentro da empresa.

Podemos então dizer, que para a empresa, a técnica se constrói, o profissional se molda e o pessoal se escolhe. Pense nisso na sua próxima contratação, talvez você comece a olhar os currículos com outros olhos.

Manter o foco. Mas até quando?

Foco!!!

Resolvi compartilhar aqui um pensamento que me veio à mente em uma das minhas comuns divagações internas. Outro dia me peguei pensando sobre foco no desenvolvimento de projetos.

A questão é que nos últimos tempos convivi com reclamações sobre excesso na troca de foco dos integrantes da equipe em que trabalho, reclamação esta que, apesar de não ser causada por mim, eu compreendia (até certo) a sua necessidade. Mas acontece que recentemente tive a oportunidade de trabalhar em um projeto mais longo e com a equipe totalmente (ou quase) focada neste único projeto e então notei que após algum tempo os integrantes da equipe começaram a ter uma queda de produção. Observando alguns sintomas e colhendo informações nas entrelinhas percebi que estava acontecendo era uma certa estafa com relação ao projeto, em outras palavras todos estavam de saco cheio de estarem focados o tempo todo nas mesmas telas, de analisar e programar o mesmo produto em cima de um mesmo conjunto de regras e características.

 O que eu tenho me perguntando é: como manter a equipe motivada e focado sendo que temos esses dois lados da moeda? Até onde devemos se focar totalmente em um único projeto? Como lidar com a fadiga causada por longos projetos? 

O que se lê normalmente quando se fala em metodologia de desenvolvimento é sobre foco total, redução nas interrupções da equipe, scrum master blindando a equipe, etc. Embora eu acredite que está queda seja natural e até certo ponto aceitável eu não creio que seja inevitável. Trazendo para realidade da empresa onde trabalho, onde sempre há aqueles projetos secundários esperando por algo a ser melhorado, reforçado ou incluído, visualizei uma alternativa, que me parece interessante para este problema. Seja de forma previamente organizada ou quando se perceber a necessidade, sinto que é possível promover trocas de foco na equipe sem que o projeto prioritário seja prejudicado.
Uma forma disciplinada de se fazer essas trocas é uma idéia já batida e que me parece ser bem comum: um período (uma tarde ou manhã) na semana, ou até mesmo um dia todo é escolhido (por exemplo a sexta-feira) para que toda a equipe trabalhe em algo diferente do projeto em que foca durante todo o resto da semana, seja esse algo diferente uma melhoria ou novo recurso para um projeto que já esteja em produção, alguma inovação que foi previamente discutida pela equipe ou até mesmo refatorações em alguma parte mais antiga do sistema.

O primeiro pensamento que surge é que alocar a equipe um dia todo para um projeto secundário representaria que o projeto principal teria uma perda de 20% do tempo na sua produção. Correto, mas se visto mais calmamente isso pode acabar trazendo grandes benefícios não só para o projeto principal mas para toda a empresa.
Para tentar ilustrar de forma simples vamos considerar que a equipe produza 20 pontos por dia para o projeto e com o tempo ela vai tendo uma queda motivacional e um desinteresse pelo projeto que faz com que ela chegue a produzir somente 10 pontos diários. Então por que não fazer essa troca de foco, deixar de produzir os 10 pontos no projeto principal e produzir 20 ou 15 pontos em algo secundário mais que ainda traga valor para a empresa? Pois se pensarmos que isso possa ser uma melhoria ou inovação o cálculo já se mostra vantajoso, e se esse novo foco for refatorações ou melhorias técnicas que ajudaram não somente nos projetos atuais mas em também nos próximos, o "lucro" pelo dia investido não se torna ainda mais surpreendente?

Claro que esse meu pensamento se baseia na realidade de onde estou trabalhando e que em um primeiro momento parace ser complicado ver isso acontecendo em grande parte das empresas, principalmente em fábricas de software onde os projetos, em geral, possuem prazos apertados e as equipes costumam focar apenas um projeto de cada vez, o famoso "tempo é dinheiro". Mas a reflexão vale até mesmo para estas empresas, afinal nada como uma equipe satisfeita e motivada para cumprir metas e prazos apertados.