19 02 2014

Semana passada eu fui reprovado na audição da Pluralsight. Vamos entender o porquê de isso ter acontecido.

Por quê a Pluralsight?

Antes de qualquer coisa, por que eu participei de uma audição da Pluralsight? Bom, como eu já mencionei nas minhas resoluções para 2014, neste ano eu gostaria de me tornar um autor de cursos da Pluralsight, caso seja possível. E isso se deve ao fato de que eu gosto muito de gravar screencasts. Porém, como eles demandam um bom tempo para produzir e editar, fica praticamente impossível conseguir arrumar umas horinhas para gravar vídeos no pouco tempo livre que me resta.

A Pluralsight é uma empresa que produz treinamentos online para desenvolvedores e profissionais de TI. Ela tem investido pesado na estrutura de vídeos e autores, e também tem recebido grandes investimentos de terceiros. Além disso, ela é definitivamente líder no segmento de treinamentos online em tecnologias da Microsoft.

Por isso, pensei em unir o útil ao agradável. Caso aconteça de eu me tornar um autor da Pluralsight, obviamente serei remunerado pelos cursos que eu produzir. E então a atividade deixa de ser um hobby para virar um “side job“. Com isso eu conseguiria dar seguimento a essa atividade que eu gosto tanto de fazer: ensinar. Basicamente esse foi o motivo de eu ter buscado iniciar todo esse processo.

Como funciona a audição da Pluralsight?

A audição da Pluralsight não é tão simples. Você precisa gravar um vídeo de 10 minutos, contendo slides e demonstração, abordando um tópico técnico qualquer. Não é fácil gravar um vídeo que tenha apenas 10 minutos com começo, meio e fim, slides, demonstração, conclusão e tudo mais. Eu escolhi o tema “Consuming ASP.NET Web API Services from Windows Store Applications“. Nos slides do vídeo eu apresentei os motivos para usarmos uma camada de serviços entre o banco de dados e a aplicação, e na demonstração eu comecei com uma solução com três projetos (uma portable class library como camada de negócios, uma ASP.NET Web Application como camada de serviços e uma Windows Store Application como camada de apresentação), e mostrei como expor os dados através do serviço e consumi-los na aplicação para a Windows.

Além de todo o trabalho de gravar o vídeo, temos também que aplicar um processo de edição e produção que estão especificados no manual da audição da Pluralsight. Existe todo um conjunto de configurações que devem ser utilizadas no Powerpoint, na gravação do vídeo com o Camtasia, marca d’água na hora de produção, e muitos outros detalhes.

Parece fácil, não? Pois não é. A primeira versão do meu vídeo passou do limite de tempo (estava com 16 minutos), então, tive que sair cortando alguns pedaços. Nesse processo de cortar conteúdo, acabei não me atentando corretamente aos detalhes e vacilei em alguns pontos.

Por que eu fui reprovado?

Quando assisti a versão final do vídeo (que consegui reduzir para 9 minutos e 50 segundos), achei que estava perfeito. Afinal de contas, eu até que tenho certa experiência gravando vídeos (antigamente eu gravei vídeos para o portal Linha de Código, já publiquei vários vídeos
para o portal MSDN, além dos vídeos que eu gravei como complemento de artigos aqui no blog). Nada podia sair errado, não? Claro que podia!

Duas semanas depois de mandar o vídeo para avaliação, recebi a resposta que eu tinha sido reprovado. Pedi maiores detalhes e eles me mandaram um verdadeiro relatório com as minhas falhas (incluindo os minutos e segundos do vídeo onde eu cometi cada falha). A propósito, gostaria de deixar meus parabéns para a equipe de revisão da Pluralsight. O relatório foi muito útil para conseguir aprender com os meus erros.

Enfim, em resumo, esses foram os seis itens em que eu “tropecei”:

1) Inglês – Eu considero o meu inglês fluente. Estudei desde pequeno, durante onze anos. Depois fui até professor de inglês por quase três anos (meu primeiro emprego, a propósito). Desde 2008 só trabalhei em projetos internacionais em que o inglês era o idioma utilizado para se comunicar. Como que eu consegui ter a moral de gravar o vídeo com um inglês “ocasionalmente estranho”, segundo o relatório? Ao assistir o vídeo novamente eu realmente consigo perceber alguns pontos em que eu dei umas deslizadas. Mas, enfim, acredito que se essa fosse a única falha, não teria problema, já que quando gravamos um curso completo, existe todo um processo de revisão e esses erros podem ser consertados sem stress.
2) Slide com “Table of contents” – Não sei se você já assistiu algum vídeo da Pluralsight, mas, em todos os cursos deles, o autor sempre apresenta um slide com a “tabela de conteúdos” antes de começar cada módulo. Eu quis fazer o mesmo no meu vídeo e acabei me dando mal. Segundo eles, não faz sentido ter um slide com tabela de conteúdos em um vídeo de dez minutos. E, pensando bem, concordo com eles. Eu poderia ter cortado esse slide e utilizado esse minuto e meio de forma mais eficiente.
3) Slide “demo” – Mesmo problema do item anterior. Entre os slides e a demonstração, eu coloquei aquele famoso slide “Demo” e falei “agora nós vamos ver uma demonstração disso que acabamos de aprender“. Claro que esse slide foi totalmente desnecessário e, novamente, eu poderia ter aproveitado esse tempo para mostrar algo mais útil.
4) Explicar melhor – Como dez minutos é muito corrido, eu optei por utilizar code snippets ao invés de digitar todo o código durante a demonstração. O problema é que eu passei muito corrido pelo código e acabei explicando muito superficialmente. Dessa forma, a pessoa que está assistindo o vídeo acaba não assimilando o que estou explicando e aí o vídeo acaba não servindo para nada. Outro exemplo disso ocorreu quando fui, durante a apresentação, adicionar um Controller no projeto Web API. Existem inúmeras opções de Controllers quando escolhemos “Add Controller“. E nessa hora eu simplesmente falei “vamos utilizar esse tipo de Controller”, e não expliquei o porquê aquele tipo de Controller era o mais indicado naquela situação. Também concordo com a Pluralsight nesse item.
5) “Más práticas” – Aqui vem o único item que eu não concordei 100% com a revisão. Segundo o relatório, eu não utilizei “boas práticas” em alguns pontos da demonstração. Especificamente em dois pontos. Primeiro eu recuperei a connection string de um arquivo de texto (ao invés de adicionar um arquivo de configuração ao projeto e ler as configurações desse arquivo). Eu optei por essa solução porque eu não queria mostrar durante o vídeo a connection string, e como na primeira versão do vídeo eu começava com uma solution vazia, não tinha como eu criar o arquivo de configuração durante o vídeo e não mostrar o meu usuário e senha do banco de dados (algo que eu definitivamente não queria que acontecesse). É claro que se eu fosse desenvolver um sistema de verdade não iria armazenar a connection string em um arquivo texto, mas, como isso não tinha absolutamente nada a ver com o assunto do vídeo, eu achei que não teria problema. Bom, o revisor não gostou muito disso.
O segundo ponto relacionado a “más práticas” foi que eu utilizei ADO.NET (com simples DbConnections e DbCommands) para acessar o banco de dados. E isso, segundo o revisor, não representa as boas práticas utilizadas no mercado. Acho que eles estavam esperando que eu utilizasse algo como Entity Framework ou algum outro ORM para acessar os dados. Mas, nesse caso eu optei por utilizar ADO.NET puro para mostrar que você consegue expor os dados até mesmo utilizando tecnologias mais antigas, e consumir normalmente em uma Windows Store Application. Afinal de contas, tenho certeza que muita gente pelo mercado ainda utiliza ADO.NET puro para acessar dados. Enfim, o revisor não entendeu dessa mesma forma e eu respeito a opinião dele de qualquer maneira.
6) Ter assumido conhecimento prévio – Em uma parte do vídeo, eu utilizei o conceito de ViewModel do framework MVVM Light. Utilizei também um RelayCommand do MVVM Light. E o problema foi que eu não detalhei esses conceitos (é claro, não dava tempo em um vídeo de dez minutos). Ou seja, quem não conhece esses conceitos de MVVM e o framework MVVM Light, pode ter ficado um pouco perdido. Ao invés de ter utilizado toda essa parafernália, eu poderia ter feito algo mais simples, sem ViewModel, sem Command e direto no code behind da janela (mas aí será que sairia das “boas práticas” do mercado? não sei).

Enfim, apesar de ter ficado triste por não ter sido aprovado nessa primeira tentativa, fiquei também feliz por eles terem dado tanta atenção ao processo de avaliação. Um relatório tão detalhado como esse só tem a agregar. E como o meu objetivo é sempre produzir conteúdo de melhor qualidade a cada dia, esse relatório cai como uma luva. Fica também essas dicas para caso alguém passe por esse processo no futuro. Agora é corrigir esses pontos e submeter o vídeo para uma nova avaliação daqui a três meses. Espero não dar nenhum vacilo na segunda versão. Desejem-me boa sorte!

Até a próxima semana.

André Lima

Modo apresentador no Visual Studio 2013 Minhas features favoritas do editor de XAML do Visual Studio 2013