Antigamente, isso desde a idade antiga até mais ou menos a 2a guerra mundial, os pesquisadores eram aqueles seres mitológicos, geralmente um pouco malucos, excêntricos e isolados. Eles resolviam seus problemas separadamente, ficando muitas vezes anos escondendo o jogo até conseguir resultados interessantes. Por isso vemos várias vezes na história casos de descoberta simultânea por pesquisadores isolados. O grande problema desse modelo é que muitas vezes você fica empacado. É isso que acontece comigo quando eu faço sudoku sozinho, sem minha namorada. As vezes tem uma solução óbvia pra uma célula, bem na cara, e eu simplesmente não vejo (obviamente isso acontece com ela também, quando ela faz sozinha). E é exatamente assim que me sinto quando falta colaboração na minha pesquisa: eu as vezes encontro problemas que me travam ou, pior ainda, perco um bom tempo num caminho errado, o que poderia ser evitado se alguém com um “fresh look” no problema me desse um toque. Colaboração se tornou essencial em pesquisa principalmente a partir da 2a guerra, quando a complexidade dos problemas (e o preço das soluções!) começou a ficar grande demais pra um pesquisador solitário (ou um até um país sozinho, vide CERN). E com os meios de comunicação atuais, isso só está acelerando. Um bom exemplo é o My Experiment, um portal em que pesquisadores contribuem a metodologia de experimentos pra facilitar replicação.

Outro aspecto em que sudoku se parece com um problema de pesquisa é no seu lifecycle, ou ciclo de vida. Quando surge um novo problema de pesquisa, ou até uma nova área, é como um jogo de sudoku recém começado. As primeiras células são bem fáceis de serem preenchidas, assim como é bem fácil fazer progresso no problema. Você ataca antes as chamadas “low hanging fruits”, ou seja, faz antes o que é mais fácil de ser feito. Daí surgem aquelas lendas, e essa eu ouvi diretamente da boca do Alan Kay, de cientistas da computação conseguindo PhD em uma semana (nos anos 50, 60) por um algoritmo para alguma coisa que ninguém tinha feito antes (não me lembro exatamente pra que). Um outro exemplo é a invenção dos compiladores, provavelmente o desenvolvimento na área de computação que teve o maior impacto na produtividade, impacto que dificilmente vai ter equivalente no futuro. O ponto é que é mais fácil quando ninguém fez nada na área ainda. Depois a coisa começa a empacar, e tem-se uma fase de progresso incremental, em que problemas difíceis são resolvidos um a um, cada um merecendo um PhD. Depois, quando o tabuleiro já está mais cheio, fica mais fácil de completar. É nessa hora que os pesquisadores perdem o interesse na área, e geralmente os problemas que faltam sobram pra indústria. E é nessa hora que eu perco o interesse, viro pro lado e deixo minha namorada terminar o sudoku em paz!

O Wii é hoje talvez o vídeo-game de última geração que mais unidades vendeu. E muito disso certamente se deve ao novo modo de interação com o usuário que ele introduziu, já que em termos de inovação e evolução de tecnologia de processadores, por exemplo, ele fica bem atrás de seus concorrentes XBox 360 e PlayStation 3. Já falei um pouco sobre isso aqui. Nesse post, inclusive, disse que achava que esta nova forma de interação do Wii poderia introduzir novas alternativas para a computação de uma forma geral. Este post atual é sobre isto.

Todo este novo modo de interação com o usuário introduzido pelo Wii é responsabilidade do Wiimote, o controle do vídeo-game. O que talvez nem todo mundo saiba é que é possível utilizar o Wiimote para tarefas que não aquelas para as quais ele foi originalmente desenhado, ou seja, ser apenas um controle de vídeo-game.

Os vídeos abaixo mostram ao menos três coisas muito legais que são possíveis de se fazer com um Wiimote. Basicamente elas utilizam o fato de o controle ter uma câmera infra-vermelha embutida para captar movimentos e o fato de ele também ser um dispositivo bluetooth para enviar estas informações para um programa rodando em um computador. Este programa traduz as informações captadas pela câmera em ações no computador.

Mais informações sobre os projeto de Johnny Lee podem ser encontradas aqui.

Apesar de eu não conhecer nenhuma, imagino que existam ferramentas comerciais capazes de prover estas funcionalidades. O que mais me chamou a atenção nestes casos foi a simplicidade e a maneira quase prosáica com que foi possível montar sistemas de interação relativamento complexos e capazes de obter informações mais parecidas com aquelas que o ser humano está acostumado a lidar, como movimentos naturais do corpo.

Por outro lado, também é interessante pensar nos tipos de aplicações em que estas soluções podem ser utilizadas. Fico imaginando quantos artistas plásticos que trabalham com mídias digitais ou arquitetos e engenheiros que trabalham com desenho técnico conhecem estas tecnologias e o quanto elas poderiam auxiliar o dia-a-dia deles.

Estas soluções nos aproximam cada vez mais de cenários pensados em filmes e livros de ficção científica. Um outro salto nesta direção está sendo dado pelo Projeto Natal da Microsoft (que, por sinal, é liderado por Alex Kipman, um brasileiro — veja uma entrevista dele para a revista Exame aqui). O propósito é relativamente parecido com a proposta dos projetos do Johnny lee, mas agora são utilizadas imagens reais captadas por uma câmera normal. Inicialmente pensado para o XBox 360, certamente o Projeto Natal também será extendido para PCs no futuro. O primeiro dos vídeos é o vídeo institucional de lançamento do sistema. Achei ele bem marketeiro e tenho dúvidas sobre quanto do que é mostrado já é realidade. Já o segundo me parece mais com um tipo de aplicação demo que é desenvolvida para o teste de um sistema deste tipo. De qualquer forma, tendo uma empresa como a Microsoft por trás destas campanhas de marketing, é difícil dizer qual o estágio de amadurecimento deste sistema apenas pelos vídeos na Internet. Só vendo uma demonstração real para saber mesmo.

De qualquer forma, eu não ficaria surpreso se estivermos interagindo com computadores das maneiras como foram propostas acima em poucos anos.

Ano passado comecei a escrever a minha dissertação de mestrado. Percebi que para determinados autores é muito difícil encontrar referências bibliográficas, mesmo com a ajuda do santo Google Acadêmico.

Nesse contexto, ao fazer a limpeza de final de ano achei o link do programa Publish or Perish enviado por um amigo e resolvi finalmente testá-lo. O Publish or Perish promete medir o impacto da pesquisa de um determinado indivíduo e inclusive se auto-intitula como uma ferramenta para servir de avaliação para pesquisadores em geral. Nesse software são utilizadas tanto fontes ISI como não-ISI, ampliando as chances de encontrar os artigos de um determinado pesquisador.

(Clique na imagem para ver uma imagem ampliada. Fonte: Publish or Perish website)

A ideia geral do programa é: “Se um acadêmico mostra boas métricas de citação, é muito provável que ele/ela tem um impacto significante em seu campo de atuação“. Entretanto o próprio website do programa informa algumas razões possíveis para resultados numericamente ruins para bons pesquisadores:

• Pesquisa realizada em campo restrito (o que potencialmente gera um baixo número de citações);
• Publicações em língua diferente de Inglês, o que restringe os potenciais leitores;
• Publicação principal em livros.

Nos resultados apresento os cinco primeiros, levando em consideração quatro dos vários critérios que podem ser escolhidos no programa.

O programa pode ser utilizado como mais um critério de escolha para o seu orientador em uma pós-graduação ou como argumento sistemático na escolha da citação no seu trabalho acadêmico de um determinado pesquisador.

Motivação e Exemplo

No meu ponto de vista, AOSD não é algo que veio revolucionar o desenvolvimento de software, mas sim um avanço incremental do paradigma de orientação a objetos (OO). Todo bom programador sabe que se deve tentar distribuir as responsabilidades (concerns) do programa em módulos, de forma que cada módulo seja fácil de implementar, entender e reusar. Em C, por exemplo, funções podem ser consideradas módulos. Pra qualquer programa não trivial, você não vai criar somente uma função main(), vai separar a funcionalidade em muitas funções que se chamam pra realizar o objetivo do software. Já OO prega a modularização do software em uma hierarquia de classes e conta com polimorfismo, herança, etc. A motivação de AOSD é que existem algum concerns que entrecortam a hierarquia, ou seja, que mesmo criando essa hierarquia de classes, você não tem como separar dois concerns que deveriam ser separados (para serem melhor implementados, entendidos e reusados).

Pra não ficar somente no abstrato, vamos à um exemplo bem simples, que é utilizado constantemente pra apresentar AOP. Imagine que você tem uma classe que faz o controle do acesso ao banco de dados. O código abaixo é um esboço de como uma classe dessas seria implementada em Java. Você tem um gerente de transações e, em todos os métodos de acesso ao banco de dados, você chama o gerente pra iniciar uma transação e fazer commit se tudo deu certo, ou rollback se deu algum problema. Note que hoje em dia ninguém faria um código assim, já que existem soluções melhores do que ficar escrevendo SQL no seu código (como Hibernate), mas é bem ilustrativo do problema.

public class DB {
    TransactionManager manager = ...;

public void storeUser(User u) {
    manager.start();
    try {
        // write some sql code storing u into the DB
        manager.commit();
    } catch (DBException e) {
        manager.rollback();
    }
}
public void storeAccount(Account a) {
    manager.start();
    try {
        // write some sql code storing a into the DB
        manager.commit();
    } catch (DBException e) {
        manager.rollback();
    }
}
...


}

public interface TransactionalTask {
    public void execute();
}
public class TransactionManager {
    TransactionManager manager = ...;

public void executeInTransaction(TransactionalTask task) {
    manager.start();
    try {
        task.execute();
        manager.commit();
    } catch (DBException e) {
        manager.rollback();
    }
}
...


}
public class DB {
    public void storeUser(User u) {
        manager.executeInTransaction(new TransactionalTask() {
            public void execute() {
                // write some sql code storing u into the DB
            }
        });
    }
    ...
}

public aspect TransactionManagerAspect {
    TransactionManager manager = ...;

around(Object o) : execution(public void DB.*(..)) && args(o) {
    manager.start();
    try {
        proceed(o);
        manager.commit();
    } catch (DBException e) {
        manager.rollback();
    }
}


}

public class DB {

public void storeUser(User u) {
    // write some sql code storing u into the DB
}
public void storeAccount(Account a) {
    // write some sql code storing a into the DB
}
...


}

Esse exemplo mostra a parte dinâmica da história, isto é, como usar aspectos pra “interceptar” alguns pontos da execução de um programa e inserir (ou remover) funcionalidade (código) nesses pontos. Mas AOSD também trata da parte estática ou “estrutural” da coisa. Por exemplo, imagine que no nosso exemplo nós quiséssemos inserir um controle de concorrência bem primitivo, pra garantir que ninguém modificou o User no tempo entre eu buscar no banco e salvar. Pra isso, eu poderia adicionar um campo na classe User com um contador que é incrementado sempre que ele for salvo no banco. Desta forma, na hora de salvar, eu confiro se o valor do contador no objeto que recebi é o mesmo do banco de dados. Se não for, significa que alguém alterou o objeto e eu recebi um objeto inconsistente. Novamente, o problema é que esse campo não faz parte do concern persistência ou modelo de dados. Portanto, não faria sentido eu declarar o contador na classe User. Pra resolver esse problema, AspectJ usa intertype declarations, que permitem a declaracão de campos e métodos em outras classes. Por exemplo, o código abaixo declara e inicializa um campo counter na classe User, removendo dela o concern tratamento de concorrência.

public aspect ConcurrencyManagerAspect {
    long User.counter = 0;
    ...
}

Quando eu estava descrevendo o exemplo eu me referi à alguns conceitos de AOSD. Mas acho importante deixar um pouco mais explícito, então seguem algumas definições.

Existem alguns eventos que acontecem durante a execução de um programa que são interessantes de serem interceptados. Esses pontos são chamados join points. Nós vimos que a execução de um método é um ponto interessante quando o objetivo é substituir o método ou introduzir funcionalidade antes ou depois do método. Outros join points, por exemplo, são a chamada de um método (não confundir com a execução), a leitura ou escrita de um campo, ou a inicialização estática de uma classe. Mas esses join points são eventos concretos que acontecem em tempo de execução. Pointcuts são um jeito de especificar de forma abstrata (por exemplo, com regular expressions) quais join points você quer interceptar. AspectJ oferece pointcuts primitivos pros join points mais importantes (como execution, call, get, etc) e outros pointcuts usados pra identificar os objetos envolvidos nos eventos e ligá-los a variáveis. No nosso exemplo, args foi usado pra pegar uma referência ao objeto passado como parâmetro ao método. Outros pointcuts importantes são target (e.g., o objeto que é o destino de uma chamada de método) e this (e.g., o objeto que faz a chamada).

Quando um join point acontece em runtime e ele faz match com um pointcut, então se executa o advice relativo ao pointcut (se tiver algum). Nós vimos como um advice do tipo around funciona. AspectJ também tem advices before e after (que pode ser after throwing ou after returning), que servem pra introduzir código antes ou depois do join point. Intertype declarations também são disponibilizadas por AspectJ pra introduzir novos campos métodos em outras classes, como vimos no exemplo.

Um aspecto é então um módulo usado pra encapsular todas essas construções, do mesmo jeito que uma classe encapsula métodos e campos. O objetivo principal de um aspecto é de modularizar um interesse (concern) que não faz parte da decomposição normal da hierarquia de classes. Esses concerns são chamados de crosscutting concerns, porque eles entrecortam a hierarquia. A implementação de um concern é dita espalhada (scattered) quando ela não está localizada, e entrelaçada (tangled) quando ela está misturada com outros concerns.

Pra quem tiver interesse, o AspectJ Programming Guide é um excelente tutorial com bons exemplos e referências pros diversos tipos de pointcuts, além de explicar alguns problemas que você pode encontrar quando não tiver muita experiência com aspectos.

Discussão

No texto acima eu tratei AOSD e AOP quase como sinônimos, mas eu quero enfatizar que são distintos. Orientação a aspectos surgiu como AOP, pois trazia soluções pra problemas diretamente ligados ao código, como no exemplo sobre controle de transações. Contudo, percebeu-se que seria interessante elevar o nível de abstração e que crosscutting concerns podiam também ser encontrados em design, arquitetura, análise de requisitos, etc. Então AOSD trata não só da programação, mas também de todo o conjunto de metodologias, processos, etc, ligados ao desenvolvimento de software usando a idéia de que crosscutting concerns devem ser tratados como “first class citizens”.

Na minha experiência, AOP como encontrada em AspectJ é utilizada quase que exclusivamente em círculos acadêmicos. Existem algumas empresas que adotam AspectJ para alguns projetos, mas a linguagem está longe de ser adotada em larga escala. Porém, alguns conceitos de AOP são muito usados em alguns frameworks e application servers como Spring e JBoss. Spring, por exemplo, tem o conceito de interceptors, que nada mais são do que pointcuts e advice, mas menos poderosos (não permitem interceptar join points de pouca granularidade, como getters, se não me engano).

Eu acredito que existem atualmente dois grandes impedimentos pra se usar AOP em larga escala. Primeiro é a tecnologia do compilador. Hoje em dia ninguém aceita trabalhar com um compilador que não seja incremental. Quando você usa Eclipse e faz uma alteração no código, o JDT só compila o necessário. O similar para AspectJ, AJDT, tenta fazer o mesmo. Porém, a tarefa é muito mais difícil, pois uma pequena mudança tem que ser verificada perante todos os pointcuts do seu sistema, pois de repente o que você mudou pode agora ser interceptado pelo pointcut. Assim, apesar de ter uma performance relativamente boa, trabalhar com AspectJ usando AJDT não é tao agradável quanto trabalhar com Java usando JDT.

Segundo, AOSD não vai acabar com todos os seus problemas. É difícil pros programadores entenderem os conceitos e leva tempo pra comunidade desenvolver design patterns e entender o que tirar de melhor do paradigma. Pointcuts são atualmente regular expressions, então eles são frágeis e qualquer mudança de nome de um método pode fazer um pointcut não mais interceptar aquele método, e você não tem como perceber que isso aconteceu. Suporte de boas ferramentas é então essencial. Além disso, eu tenho dúvidas de que aspectos sejam bons pra modularizar concerns heterogêneos como “logging”, que foi sempre um dos principais exemplos. O problema é que cada instância de logging é muito específica pro contexto, então não faz sentido você remover todas as chamadas de log e encapsular em um advice, pois o advice teria que ser diferente pra cada ponto que ele interceptasse. Controle de transações é homogêneo, pois o advice sempre faz a mesma coisa, então é um exemplo mais apropriado. Existem estudos que apontam que Mixin Layers são melhores pra concerns heterogêneos como logging, mas isso seria assunto para um outro post.

========================== Nota no dia 5/11

Conversando com o Miguel eu acabei percebendo algo que talvez não tenha ficado muito claro. AspectJ é uma extensão de Java e precisa de um compilador especial que compila as classes como se fossem Java e depois analisa os aspectos do sistema e faz diretamente as modificações no código (ou introduz testes de tempo de execução quando não tem como verificar estaticamente o resultado). Esse último passo, “introduzir os aspectos”, é chamado weaving.

Existem duas alternativas principais de compiladores pra AspectJ. O ajc é parte do AJDT, que é uma extensão do JDT do Eclipse. Como o JDT, o AJDT contém editor, compilador, debugger, e tudo o mais, implementados em plugins pro Eclipse. O principal objetivo do projeto é que a compilação seja rápida pra que você tenha a mesma experiencia que programando em Java, ou seja, ele tenta ser incremental e o código do compilador em si é otimizado (leia-se, não-facilmente extensível).

A outra alternativa é o abc (Aspect Bench Compiler), que é um compilador acadêmico cujo objetivo principal é ser extensível pra que se possa fazer pesquisa com linguagens de programação, otimização de código, análise estática, etc. Dessa forma, compilar um sistema grande com abc, principalmente usando as otimizações disponíveis, é bem demorado. O ideal é programar usando o AJDT e usar o abc pra gerar o bytecode de produção, já que ele é bem mais otimizado que o gerado pelo ajc.

Além disso, AspectJ não é a única linguagem orientada à aspectos derivada de Java. No site da aosd.net, por exemplo, tem uma lista com alguns sistemas (derivados ou não de Java) e algumas ferramentas orientadas a aspectos.

Esta brincadeirinha, disponível para acesso aqui (http://www.google.com/search2001.html) permite fazer duas coisas interessantes. A primeira é relembrar como era a Internet de 2001, quais os assuntos na moda e quais os termos que ainda estavam por vir. A segunda é ver como o design das páginas evoluiu nestes 7 anos, pois é possível ver a versão atual da página e a versão da época.

Fiz a busca pela palavra iTunes, e comparei os dois primeiros resultados. O primeiro é o site da Apple, versão 2001 e versão 2008 . O outro é um artigo da revista Business Week, sobre o tocador, O texto original continua lá, mas o design da página mudou bastante, de 2001 para hoje.

Mais informações podem ser encontradas no Official Google Blog.

======================================================

Correção: como foi bem anotado pelo nosso leitor esquentadinho Luis, digno habitante do mundo real (porque o meu aparentemente é o mundo de Alice, quiçá da Lua) , o cache das páginas vem do Internet Archive que, confesso, eu não conhecia. Mas é culpa da mídia do meu mundo, um tanto quanto lerda….

A idéia é parecida com a que foi citada pelo Alexandre: hoje pode ser muito difícil ter acesso ao conhecimento científico publicado em revistas e congressos. Além disso em alguns campos do conhecimento como é o caso da criptografia existe um outro agravante: é necessário publicar idéias o mais rápido possível para evitar que outros a patenteiem antes. E, para completar, o site ainda funciona como um crivo não-oficial para idéias novas, isto porque não existem muitos requisitos para publicar no site: ou seja, se você tem uma idéia mas não sabe se ela é boa o suficiente você pode publicá-la (correndo é claro o risco de compartilhar sua idéia com outros antes de ela estar completa) e ver o retorno que a comunidade dá em relação a ela. Se for bom, com o tempo esta idéia pode amadurecer e virar um artigo em um congresso internacional.

O interessante é ver que na área de criptografia muitas coisas interessantes são publicadas no ePrint. Tem inclusive cientistas bons que estão defendendo abertamente a idéia de se publicar o conhecimento sem restrições sempre, como é o caso de Daniel Bernstein.

Já ouvi falar que existem portais parecidos para artigos em Física, além dos já citados pelo Alexandre. Enfim, um movimento muito interessante, que de certa forma força os pesquisadores a se importar mais com a qualidade e menos com a quantidade, já que seu artigo é “mais público” neste tipo de site. Algo que vai um pouco contra a “ditadura” de números que regem muitos institutos de pesquisa no mundo atualmente, onde é melhor quem publica mais e não necessariamente quem obtém melhores resultados.

P.S.: Editor-chefe, eu disse que eu postava algo este mês ainda!

Fato é que o ser humano é curioso, voyeur por natureza. O ser computeiro mais ainda. E a dúvida que bate na cabeça de muitos de nós é “Quanto ganha um engenheiro de SW numa empresa top como Google, Apple ou Microsoft?”

Bem, o site GlassDoor.com tem como proposta amenizar esta dúvida cruel, trazendo informações de funcionários anônimos das próprias empresas como salários por posição, opiniões sobre CEOs e nível de satisfação. Fico só imaginando o funcionário chegando no site, com sua voz de pato e a cara quadriculada…

Ja é possível dar uma espiadinha em empresas como Google, M$ e Yahoo.

Ultimamente tenho ido diariamente de bicicleta pro trabalho, o que leva em média uns 30 minutos, mais uns 10 minutos entre descer no elevador, destravar a bicicleta, travar de novo no trabalho e ir até o chuveiro. Isso faz com que eu tenha 80 minutos “livres” por dia, praticamente sem pensar em computação! Como bom computeiro, eu não podia deixar essa situação perdurar, então comecei a gravar podcasts no iPod e ir ouvindo no caminho. Por enquanto os assuntos não foram absorventes o suficiente pra me tirar a concentração no transito, e eu ainda não me matei…

Atualmente eu estou ouvindo as entrevistas do Markus Voelter na Software Engineering Radio (se-radio). Tem bastante coisa interessante por lá e eu to achando uma boa pra ter uma noção por cima de assuntos diversos. Eu acho que um podcast não é a mídia ideal pra passar os detalhes, mas você sempre pode correr atrás de saber mais sobre os assuntos que te interessaram mais.

A primeira pesquisa do post é : Que outros podcasts interessantes vocês conhecem, além do stackoverflow que foi mencionado no post anterior?

Naquele post foi discutida também a idéia de criar um podcast do log4dev (pod4dev ou cast4dev, quem sabe até podcast4dev). Eu particularmente acho que seria muuuito trabalho e acho que algumas características teriam que ser muito bem pensadas, como:

• Assuntos: que tipo de assuntos seriam tratados no podcast? Se o intuito é somente dar a opinião sobre algum assunto, porque não usar o log4dev mesmo? Quero dizer, pra agregar valor, o podcast tem que aproveitar o seu diferencial, que é o som, então o conteúdo provavelmente tem que ser diferente do log4dev.
• Duração: qual vai ser a duração média de uma transmissão? O Lucas comentou no post anterior que o ideal seria 25 minutos, pois não fica cansativo. Os podcasts da se-radio são entre 40 e 50 minutos, o que é OK pra mim, mas não funcionaria pra todos. Apesar das entrevistas dele não ficarem cansativas, eu acredito que se eu não tivesse tanto tempo “disponível”, eu não iria parar o meu trabalho pra ficar ouvindo (e olhando pra onde?). É claro que a duração também é muito influenciada pelo assunto: uma entrevista de 25 minutos é muito curta, principalmente quando o entrevistado é bem interessante, mas 50 minutos falando em monólogo sobre algum assunto qualquer fica maçante.
• Equipamentos: que equipamentos teriam que ser adquiridos? Como o Evandro disse, não adianta fazer um podcast com um som porcaria, pois isso só iria irritar quem está tentando ouvir. Logo, alguns equipamentos de áudio teriam que ser adquiridos de alguma forma. Na se-radio, depois de um bom tempo com o som ruim, eles compraram um equipamento melhor, e depois conseguiram algumas doações e sponsors pra manter a radio funcionando, mas eu não acho que essa seja uma possibilidade realista.
• Periodicidade: com qual periodicidade seria publicado o podcast? De novo, o se-radio garante que publica a cada 10 dias. Vale a pena o editor-chefe definir uma garantia dessas? Com certeza essas garantias agradam ao público, pois eles sabem o que esperar. O difícil é honrar o compromisso….

E esta idéia de termos um podcast é algo que está martelando na minha cabeça há algum tempo. Não sei bem o formato ainda, e sei que daria bastante trabalho. Mas imagino que seria bem divertido (como diriam os americanos, lots of fun!!!).

Seguindo uma sugestão do Raphael, gostaria de abrir a discussão para a “comunidade” deste blog: o que vocês achariam de termos um podcast (cast4dev, ou pod4dev)? Comentários, sugestões e nomes serão bem vindos.

E aproveito a deixa para sugerir o novo podcast criado pelo Joel Spolsky, chamado stackoverflow.com, que discute temas interessantes de computação e de quebra ainda ajuda a aprimorar a compreensão do inglês.

Este post nasceu de um email que eu mandei para amigos esta semana. O objetivo é de abrir uma discussão sobre a validade de se fazer uma pós graduação em área técnica. O que eu vou escrever aqui é a minha percepção, e eu gostaria que vocês comentassem, já que depois da nossa graduação muitos de nós seguiram caminhos bem diferentes na carreira.

Existem basicamente 4 “opções de carreiras” pra quem se formou em Engenharia ou Ciência de Computação (sem contar mudar totalmente de área). Você pode entrar na área de consultoria não-técnica (financeira, management, etc): neste caso, acho que o que mais vale a pena eh fazer um MBA. Pelo que tenho visto, Stanford é a melhor opção, mas eu não tenho experiência pra comentar muito sobre isso.

A segunda opção seria você continuar na área da computação, mas partir pra algo mais gerencial. Nesse caso, o ideal talvez fosse fazer algum MBA mais voltado pra TI, talvez um mestrado em área técnica, desde que voltado pra gerência de processos, qualidade ou coisa assim.

A terceira opção seria ficar na área técnica mesmo. É claro que é bem difícil você ficar programando low-level a sua carreira inteira: alguma hora você vai ter que subir pra algo mais gerencial. Mas de qualquer forma, o foco seria tecnologia.

Finalmente, a quarta opção seria você fazer uma carreira “acadêmica”. Eu coloco entre aspas pois eu considero que hoje em dia ninguém vai ser professor de universidade e ficar num mundo paralelo, mas vai ter contatos com a indústria pra manter os pés no chão (e o dinheiro entrando). Eu também considero trabalhar em centros de pesquisa privados como carreira “acadêmica”.

Nesses dois últimos casos, eu vejo pós-graduação em área técnica como algo essencial. Eu tenho alguma experiência em universidades e empresas no Brasil, na Alemanha, no Canadá e conheço historias sobre EUA e outros países europeus. Na Europa praticamente todos saem da universidade com mestrado. O doutorado dura somente 3 anos e é bastante voltado pra indústria, que absorve essa mão de obra qualificada. No Canadá e nos EUA muitos fazem mestrado e os PhDs são muito bem vindos pela indústria. O diploma é essencial para entrar em grandes laboratórios de pesquisa (como IBM, Sun e Google), e inclusive já ouvi histórias de algumas empresas européias em que você simplesmente não sobe na carreira (mesmo em área gerencial) sem ter um PhD (nem que seja um PhD em Física ou Antropologia).

Em resumo, MSc e PhD são títulos muito bem vistos não somente por universidades, mas também por empresas.

Me parece que no Brasil as coisas não são bem assim: um profissional com doutorado é visto como alguém muito caro, que não vai trazer mais benefícios pra empresa do que um recém-graduado (que é muito mais barato). Por isso, a única opção pra doutores é tornar-se professor de universidades ou fundar a própria empresa (provavelmente uma consultoria técnica). Eu tenho a impressão que mestrado já não é mais visto como um problema, pois tenho visto bastante gente obtendo o título e depois indo para empresas.

Mas eu acredito que o mercado pra PhDs vai aumentar conforme o Brasil cresce e entra no mercado global em que o conhecimento e a tecnologia são as coisas mais importantes. Então as empresas vão aprender, como já o fazem as empresas indianas e chinesas, que um PhD pode trazer um conhecimento de ponta importantíssimo pra aumentar a competitividade da empresa.

Esta é a minha percepção. Vocês concordam com isso? Críticas? Sugestões?

[Bart é Eng. de Computação formado pela UNICAMP, ex ponta esquerda e central do glorioso time de Handball da Computação e atual doutorando da Universidade de Waterloo, do Canadá.]