Recentemente participei de um projeto que é fortemente baseado no componentes de relatórios da
Telerik, empresa forte em desenvolvimento de componentes RAD e outros. Aqui vai um pequeno resumo da experiência:
- A Telerik é muito forte na documentação. O site deles dá um show em várias outras empresas, tanto na documentação das APIs quanto nos fórums.
- A Telerik certamente não prioriza o Telerik Reporting para desenvolvimento de novas funcionalidades ou correção de limitações. Isso é notável quando se olha posts antigos no fórum requisitando recursos que até hoje não existem.
- Implementação de front end nos relatórios é bastante poderosa, mas ao mesmo tempo um tédio!!! Gasta-se muito tempo formatando, e se você precisar alterar a largura de uma coluna depois de tudo pronto (para mostrar um número com mais dígitos, por exemplo), tem que mexer em todas as demais colunas à direita da alterada para que não haja sobreposição.
- O report designer é o componente que permite configurar o layout dos relatórios. No meu caso, trabalhando com Visual Studio 2008, vários crashes ocorreram, e em um caso específico tive que recorrer ao SVN para recuperar meu arquivo.
- O componente tem um report viewer feito para Web que usa Session como cache para o streaming de dados que vem do data source. Vou repetir caso você não tenha entendido: ele usa Session!!! O resultado é que a sua capacidade de desenvolver uma aplicação escalável usando este componente fica comprometida por causa deste detalhe de arquitetura do componente, que só descrobri na última semana antes do deployment.
- Por causa do item anterior e outros, o componente tem um glitch de performance tenebroso: à medida em que novos usuários vão rodando relatórios no seu website, o worker process do seu website vai usando cada vez mais memória e não há o que se fazer para limpar estes recursos. Tentei de tudo: limpar session, chamar GC.Collect() (apelei mesmo!), colocar o processamento do relatório numa thread separada, parar de usar o report viewer e construir um na unha, e nada funcionou. Sendo assim, se você pretende usar este componente, recomendo fortemente que coloque os módulos de relatórios em um application pool separado e que as sessões sejam out-of-process.
- Eu já tinha trabalhado com o Microsoft Report Viewer como alternativa ao Telerik. há alguns anos Muitos dos problemas reportados acima também existem nesse componente.
O objetivo deste artigo não é convencer ninguém a usar outros componentes, como o Microsoft Report Viewer ou Crystal. É só para alertar que nem tudo são flores como se apresenta no website deles. Meu recado final é: gaste um tempo com uma prova de conceito bacana e com a arquitetura do seu projeto antes de escolher seu componente de relatório!
Meu primeiro projeto usando WCF foi em 2008, quando fui contratado como freelancer para escrever material em um curso sobre o assunto. Pra variar, tive que aprender pra escrever. E não é que esta é a melhor forma de aprender? Para não escrever besteira, tive que ir fundo na tecnologia detalhando muito cada aspecto, e gostei do que vi.
Olhando os últimos 12 meses, trabalhei em cerca de 20 projetos na empresa em um time que é voltado ao desenvolvimento web, e 6 destes projetos foram "WCF-driven". Não vou entrar em detalhes neste único post, para deixar mais assunto para adiante, mas segue aqui um pequeno resumo do que WCF resolveu pra gente:
- Problema: documentos contento informação financeira sensível de clientes precisavam ser disponibilizados em uma aplicação web hospedata em um servidor localizado em uma DMZ. Quando o departamento de TI viu que os arquivos ficariam armazenados em um disco físico conectado a este servidor na DMZ, eles só disseram: not gonna happen (forma interessante de dizer "nem que a vaca tussa"). Pelos mesmos motivos argumentados pela TI, não adiantaria colocar os arquivos em um servidor atrás de firewall e compartilhá-los pelo Windows. Solução: um serviço WCF foi criado para encapsular "System.IO" (apenas os métodos necessários para ler os documentos). O serviço foi exposto em um servidor fora da DMZ, mas visível para o servidor web em uma porta obscura (não óbvia), com segurança através de certificado e binding net.tcp (por questões de performance). Na aplicação web, as referências a System.IO foram substituídas por uma referência ao serviço, e foi assegurado que os arquivos nunca seriam salvos no disco (nem temporariamente), mas deslocados para um byte array na memória e escritos diretamente no output to browser para os clientes.
- Problema: telas para gerenciamento de documentos feitas em asp.net (C#) com funcionalidade que levou mais de 2 meses para ser construída, precisava ser migrada para uma aplicação cliente-servidor em C++, e estimava-se 3 meses para a migração. O orçamento do projeto era de 3 semanas apenas. Solução: como a aplicação foi bem desenvolvida em camadas, portou-se a camada de persistência e negócio para dentro de uma class library, que foi exposta como um serviço WCF. Uma façade para acesso a esta class library foi criada para serializar todos os parâmetros em XML, já que C++ não gerenciado não consegue usar WCF proxies out-of-the-box. Uma COM-visible library foi criada para atuar como proxy para o WCF para a aplicação C++ (sendo distribuída para os computadores-cliente junto com a aplicação C++). Assim, apenas a camada de interface teve que ser reescrita em C++.
- Os outros projetos também são interessantes: envolvem integração com softwares de terceiros, transferência de arquivos enviados por clientes do data center para o sistema de gerenciamento de documentos na intranet, e mais.
Parece que é sina: nunca gostei muito de Sharepoint e sempre tentei evitar trabalhar com ele, mesmo sendo obrigado em situações passadas com o Project Server 2003 e o Team Foundation Server. Mas a questão é que meu primeiro pequeno projeto foi justamente reconstruir um team site todo customizado com Sharepoint.
Mas desta vez a situação é outra: estou falando de Sharepoint 2007. Realmente a nova versão é muito superior à 2003, que foi a com que mais trabalhei. Outra coisa que me fez revisitar o conceito é que por aqui nas terras geladas qualquer empresa tem um intranet site, e normalmente com um bom nível de maturidade. E 90% dessas intranets são Sharepoint based, e para isso a empresa tem que dedicar de 0,5 a 1 desenvolvedor .NET para o projeto para a coisa funcionar (lembrando que 0,5 desenvolvedor equivale a 50% de dedicação, e não um desenvolvedor meia boca :-).
Bem, mas a questão é que me atualizei na tecnologia, e tive a oportunidade de desenvolver user controls, custom fields, web parts e workflows para esta completíssima ferramenta. E o resultado é espetacular: a intranet tem um aspecto super profissional e impressiona novos e antigos funcionários da empresa pela melhoria de processos que a ferramenta impõe. Se eu tivesse tempo e oportunidade há alguns anos para trabalhar tão próximo do sharepoint, talvez eu teria revisto algumas das iniciativas que fiz para controle de projetos no passado.
Nos últimos meses minha vida mudou bastante. Um choque instantâneo de ambientes: de um dia para o outro, deixei de conviver com os amigos, com a empresa na qual estive nos últimos 7 anos, a cidade, a casa... Tudo é diferente. Pouco disso é surpresa para mim, pois pesquisei bastante antes de sair do Brasil, mas acaba que sempre tem coisa que te pega de surpresa... E eu acabei esquecendo um básico: por ter trabalhado tanto tempo na mesma empresa, eu estava totalmente enferrujado pra buscar emprego!
Não adianta ir pensando que currículo bacaninha é o suficiente não, porque não é mesmo! Nem no Canadá, nem no Brasil. Então segue a compilação de algumas considerações que aprendi ou revisei nos últimos meses.
- O objetivo do currículo não é conseguir um emprego. O mais perfeito dos currículos não consegue a vaga para você. E não estou entrando no mérito do dono do currículo realmente ter aqueles conhecimentos descritos naquele documento ou não. Ter um currículo com bom conteúdo, e principalmente bem elaborado, só serve para conseguir uma entrevista. E é ali que se resolve a vaga (depois da entrevista, você conseguindo a vaga ou não, seu currículo vai pra lixeira).
- Pelo menos para quem tenta um emprego no exterior, não interessa se você formou na UFMG, na USP ou UBE (Universidade da Beira da Estrada) ou em qualquer outra que o pessoal de fora não conheça. Portanto, por mais que você tenha orgulho de ter formado em uma universidade top, ela vai estar na última linha do seu currículo, e ponto final.
- Falar de soft skills é essencial, quase mais importante do que seus conhecimentos. Principalmente para quem quer uma vaga júnior! Soft skills são suas habilidades pessoais não vinculadas aos conhecimentos profissionais, como ser amigável, solucionador de problemas, fidelidade à empresa, etc. Na entrevista tem que falar disso e mostrar com exemplo cada uma destas habilidades (tem que contar uma historinha de um parágrafo para cada uma dessas!).
- Para quem vem para o exterior, vale a pena fazer um curso rápido de procura de emprego antes de começar a procurar emprego. Esses cursos na verdade ensinam comunicação em negócios, e de quebra você ganha proficiência extra em idioma, consultoria grátis pro currículo no formato do país, vários testes de entrevistas para prática e ainda faz networking. E ainda conhece alguns detalhes sórdidos da cultura local no ambiente de trabalho.
Bem, esta foi a minha experiência, e cada pessoa que passa por isso tem um caso diferente para contar. Por enquanto meu aprendizado valeu muito a pena, pois consegui minha oferta de emprego exatamente 3 semanas depois do fim do curso de job search, que foi quando realmente comecei a procurar. Totais: 20 aplicações de vagas, 3 entrevistas e depois disso alguns convites para entrevista que neguei após o meu aceite da oferta de emprego. Sinal que estudei muito no meu curso de job search! :-)
Como já tem muita gente falando de TI nesta comunidade, vou me propor a escrever de vez em quando para falar não só de TI, mas das coisas que eu vir por aqui que eu achar interessantes para contar, que tenham relação com nosos mundo profissional.
Pode deixar que vou evitar ficar tirando onda sobre meu PC do trabalho, que é duas vezes mais rápido que meu laptop, e os dois monitores lcd widescreen de 22' e os fones de ouvido plantronics. Vou tentar ser estritamente profissional!!! :-)
No final de semana eu posto!