Segundo um email que eu recebi ontem,

O programa do curso abrange as principais novidades da versão 5 da linguagem HTML até o momento e priorizará a apresentação dos novos elementos com o debate em classe da nova semântica. Alguns exercícios serão aplicados com o intuito de demonstrar as novas implementações. Nossa estrutura infelizmente não comporta a formação de diversas turmas do curso de HTML5 que nos permita atender o grande número de solicitações de interessados, inclusive para outras cidades. Por isso faremos uma seleção dos participantes segundo os critérios de compromissos:

• com a replicação do conteúdo do curso;
• com a publicação livre das aplicações geradas;
• com um projeto real de uso do HTML5;
• e com a participação efetiva em uma comunidade dedicada à melhoria da linguagem.

O propósito do W3C Brasil, mais do que treinar no uso da nova versão, é o de organizar uma rede de interlocutores, formadores e multiplicadores preparados para os debates em torno dos padrões web, gerando massa crítica na formulação das novas recomendações.

Eu tive o prazer de servir de guia para a delegação brasileira, novamente liderada pelo Prof. Anido da UNICAMP. Como o Canadá é um país de imigrantes, a organização tentou encontrar guias que falassem fluentemente a língua de cada país. Eles dizem que conseguiram, mas eu vi alguns guias que tiveram que se virar em inglês mesmo. Mas a idéia de ter um guia que conhece ambos os países é a de dar uma perspectiva mais compatível com os alunos sobre Waterloo e principalmente sobre o Canadá. Eu espero ter conseguido mostrar os lados positivos e negativos daqui, além de levá-los às compras, é claro. Ah, e o lado divertido da semana (pros guias pelo menos) foi “ter” que ir junto ao Canada’s Wonderland e ao  Maid of the Mist em Niagara Falls.

Mas voltando à competição, que imagino ser a parte divertida pros alunos, a primeira coisa que tive que aprender foi como funciona a premiação. Existem medalhas de ouro, prata e bronze, sendo que metade dos +/- 300 competidores recebem alguma medalha (1/12 ouro, 1/6 prata e 1/4 bronze). A equipe brasileira recebeu 1 prata e 2 bronzes, o que é bastante bom dado o nível elevado da competição.

E esse é o ponto principal desse post. Eu fiquei impressionado com o nível de conhecimento de algoritmos dos competidores. A equipe brasileira é jovem e 3 dos 4 competidores ainda tem idade pra voltar algumas vezes pro IOI. Esses meninos de 15, 16 anos manjam algoritmos e estruturas de dados que eu só fui aprender no 2o. ano de faculdade. E eles dominam o assunto! O campeão desse ano foi um bielorusso de 15 anos. Ele compete desde os 11 e já ganhou 1 prata e 4 ouros, sendo 2 vezes como campeão. Os dois pais do garoto são programadores, obviamente.

Se você duvida da complexidade das tarefas, tente resolver você mesmo, já que elas estão online. Cada dia de competição era uma prova com 4 tarefas pra serem resolvidas em 5 horas. Normalmente uma tarefa era bem fácil, só pra não desmotivar competidores menos treinados (tente fazer o Memory ou o Cluedo primeiro). Mas pra se ter uma idéia, a primeira submissão correta do Cluedo foi em menos de 3 minutos (eu nem consigo ler o enunciado nesse tempo!). Nesse ano algumas tarefas envolviam heurísticas (como Language) e algumas que pareciam triviais eram bem complicadinhas de resolver com pontos máximos (veja hotter/colder).

Parabéns ao time brasileiro e à Fundação Carlos Chagas que patrocina as seletivas, treinamentos e viagens! E toca preparar pra Tailândia ano que vem!

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!

Na outra ponta, poderíamos pensar o seguinte: que tal se, ao invés de ter uma equipe de 12 pessoas em um projeto, o que levaria ter 12 pessoas que tenham familiaridade com um conjunto de ferramentas (e aí, obviamente, nos levando a escolher um framework), que tal diminuir a equipe para 3 ou 4 que sejam (a) mais experientes/produtivos e (b) capazes de utilizar ferramentas mais poderosas?

Eu diria que o principal problema que eu vejo para não ter uma equipe de 12 pessoas medianas que tenham familiaridade com um conjunto de ferramentas e, no lugar disso, ter uma equipe de 3 ou 4 pessoas mais experientes e produtivas, capazes de utilizar ferramentas mais poderosas é porque é muito difícil contratar estas 3 ou 4 pessoas.

Já coordenei e participei como entrevistador em diversos processos de seleção e às vezes fico horrorizado com alguns currículos recebidos ou pessoas entrevistadas. Além disso, a quantidade de pára-quedistas que aparecem em processos seletivos é enorme. Pessoas que simplesmente não tem nada a ver com a vaga (e chegam a dizer isto explicitamente no currículo) mas que mesmo assim se candidatam a ela.

Por ser tão difícil de achar estes 3 ou 4, pelo fato de os projetos geralmente terem prazos apertados que não possibilitam perder muito tempo formando (ou contratando) uma equipe e, talvez, pelo preço de estes 3 ou 4 ser muito alto quando comparado com os 12 medianos, eu diria que provavelmente eu preferiria me manter com os 12 medianos se eles fossem capazes de entregar o projeto pronto do que gastar tempo e dinheiro buscando profissionais que talvez não apareçam, impactando, no fim das contas, o bom andamento do projeto que, no fundo no fundo, não precisava de pessoas qualificadas para ser entregue em um nível bom (mas não ótimo).

Agora, sinceramente, o que mais me preocupa não é está minha “equação” pragmática. O que mais me preocupa é realmente a dificuldade de se achar pessoas realmente boas. E isso eu acho que é culpa da formação e do interesse geral das pessoas naquilo que elas fazem. Coisa difícil de mudar num curto prazo.

Bem, não importa se você não sabe o que são tagless interpreters ou se não se importa com lambda calculus, o foco desse post é outro. Quando comecei a aprender Scala, eu vi que a linguagem realmente faz jus ao nome (Scala vem de SCAlable LAnguage, e o objetivo era ter uma linguagem que serve pra fazer desde pequenos scripts até grandes aplicações enterprise). Basta olhar a lista de features da linguagem que você percebe que Scala faz barba, cabelo e bigode!

Como não faz sentido discorrer sobre todas as features de Scala (isso merece um livro), eu vou me concentrar em duas pequenas coisas que deixam qualquer programador Java com inveja: Local Type Inference e Traits.

Local Type Inference (Inferência Local de Tipos)

Quantas vezes eu odiei ter que escrever tipos redundantes em Java (que já expliquei em alguns comentários anteriores). Imagine um método que devolve uma lista inicializada com um inteiro (é um exemplo estúpido, mas é só pra mostrar type inference in action). public List<Integer> getList() { List<Integer> list = new ArrayList<Integer>(); list.add(0); return list; }

Scala é staticamente tipada, o que significa que todos os tipos tem que ser verificados pelo compilador. Mas o compilador de Scala tenta ao máximo inferir o tipo que você está indicando. Você só precisa escrever o tipo se o compilador não conseguir determinar qual é o tipo correto. O mesmo código em Scala ficaria mais ou menos assim (Note que sou bem novato em Scala, então me perdoe se existem soluções mais elegantes): def getList() = 0 :: Nil

O código ficou pequeno não somente por inferência de tipos, mas vamos ver como que inferência ajudou (o que segue é como eu imagino o compilador pensando). Primeiro o compilador infere que Nil é uma lista vazia, então pode ter qualquer tipo. O “::” é na verdade uma chamada de método (o add) na lista Nil, passando zero (0) como parâmetro (em Scala, métodos que iniciam com “:” fazem bind à direita, então Nil – que é uma case class de List – é quem recebe o método). O compilador vê que 0 é um Int (o equivalente de Integer e int em Scala), então o resultado de chamar add em Nil é uma lista de inteiros (ou List[Int]). Finalmente, o compilador vê que essa lista é retornada pelo método, então o tipo do método é List[Int].

Com isso, ao invés de escrever o tipo de lista em 3 lugares diferentes, você não precisou escrever em lugar algum, pois o tipo foi inferido do conteúdo e essa informação foi propagada. Note que se a lista estivesse vazia, você teria que escrever pelo menos 1 vez qual é o tipo (pois não tem como inferir do conteúdo), mas é melhor que 3 vezes!

Traits

Traits são basicamente interfaces com implementação. Já é sabido faz um bom tempo que herança múltipla (multiple inheritance, MI) causa dores de cabeça enormes (o Google, por exemplo, proíbe uso de MI no desenvolvimento interno de aplicações C++). A resposta de Java foi o conceito de interfaces, que te dão um poder parecido com MI (porque uma classe pode estender diversas interfaces, então pode ser usada polimorficamente no lugar de qualquer uma delas), mas muito mais restrito (porque a classe tem que implementar os métodos de todas as interfaces).

Em Scala, as Traits são como interfaces, mas elas podem ser parcialmente implementadas, normalmente com código default. Isso resolve alguns problemas de interfaces. Em Java existem várias interfaces pra receber eventos de GUIs que contém diversos métodos (um pra cada tipo de evento, veja MouseListener por exemplo). Quando você só tá interessado em um tipo de evento (por exemplo, Mouse Pressed), você tem que implementar todos os métodos (normalmente deixando em branco). Se você tiver sorte e sua classe não estende nenhuma outra, você pode usar um dos adapters com implementações em branco (como MouseAdapter), mas não é sempre o caso. Outro caso típico é quando um dos métodos pode ser derivado dos outros, como no exemplo direto do tour de Scala: trait Similarity { def isSimilar(x: Any): Boolean def isNotSimilar(x: Any): Boolean = !isSimilar(x) }

Nesse caso, classes precisam somente implementar isSimilar pois elas já ganham de graça o isNotSimilar. Note que traits, como interfaces, não podem ser instanciadas, e têm que ser adicionadas a classes ou objetos.

E agora?

Eu dei aqui só uma mostra do que Scala tem, e na verdade não cheguei nem perto da parte que eu considero mais importante, que é a junção (bem elegante por sinal) dos paradigmas funcional e orientado a objetos. Inclusive, umas semanas atrás eu fui à uma palestra do Simon Peyton-Jones, que é um dos caras por trás de Haskell. Depois da apresentação eu conversei (por ótimos 2 minutos) com ele sobre Scala e ele se disse feliz que Scala está trazendo linguagens funcionais pra desenvolvedores que estariam presos em OO (tanto por instrução – o que se aprende nas universidades em geral – quanto pelo mercado de trabalho). Eu acho que ele ainda prefere Haskell, mas Scala introduz “desenvolvedores comuns” ao paradigma funcional, sem abdicar de ser prática (não que Haskell não seja, mas o fato de se poder chamar código Java de Scala faz com que a adoção seja bem mais fácil).

O que me pergunto é se “desenvolvedores comuns” vão conseguir entender o que Scala oferece e usar de forma eficiente (isso depois que surgirem “Scala Design Patterns”). Sempre ouço que na indústria o average Joe mal entende Java direito, imagina então Scala. Estaríamos chegando em uma era em que uns poucos desenvolvedores excepcionais, usando linguagens e ferramentas ultra eficientes, seriam capazes de desenvolver “qualquer” sistema e suprir a demanda do mercado? Ou seja, o mercado encolheria em termos de número de programadores, mas os que restarem teriam uma produtividade muito superior?

Não sei. Mas sei que Scala faz barba, cabelo e bigode. E se bobear, tem algum jeito daquele pelinho no fundo da orelha ir junto!

Essa foi a parte propaganda para o evento, agora vem a propaganda para mim. Meu irmão comprou o ingresso para o evento quando eles estavam com uma promoção para ingressos adiantados, e pagou 300 reais. Depois eles criaram uma promoção de 100 reais para estudante. Como a organização disse que não tem como devolver o dinheiro, eles deram 3 opções pra quem comprou antecipado mas tem direito a estudante:

• ele pode transferir o ingresso antigo para alguma outra pessoa e comprar um de estudante;
• ele pode dividir o ingresso dele com mais 2 estudantes; ou
• ele pode desfrutar de um credito de 200 reais em serviços de um patrocinador do evento.

O problema é que meu irmão não conhece ninguém que esteja interessado, e também não está interessado em nenhum produto do patrocinador. Então, se alguém se interessar e quiser dividir a entrada ou comprar a entrada pelo preço antecipado, entre em contato comigo e a gente tenta ajeitar isso.

Vale lembrar que o preço (mesmo o de 300 reais) é muito barato pelo retorno que traz: palestras de altíssima qualidade, contato com gente interessante e ainda contando com almoço e coffee breaks. Queria eu estar no Brasil nesses dias!

É verdade que a língua dominante na Internet é o Inglês. Isso não se dá só pelo domínio cultural norte-americano, mas também por uma necessidade que surgiu com a globalização e com o avanço de tecnologia de telecomunicações: pessoas de pontos extremos do mundo precisam de uma linguagem comum se quiserem se comunicar e colaborar de forma eficiente. Alemães, indianos, chilenos, russos… não importando o idioma local, o inglês é necessário.

Mas isso não significa, entretanto, que é razoável abandonar a nossa língua-materna e passar a usar um idioma estrangeiro como forma exclusiva de produção de conteúdo. Nem por nacionalismo irracional e cego, como o dos franceses que não aceitam termos estrangeiros, mas por uma questão mais básica: a Ciência mostra que nossa capacidade de expressão está ligada ao domínio da linguagem que usamos para transmitir nossas idéias, sentimentos e conceitos abstratos; ao usarmos uma língua que não temos pleno domínio, a nossa capacidade de comunicação e expressão fica prejudicada. Tente imaginar um esquimó tendo que explicar a um morador do sertão nordestino as diferenças entre os (mais de 30) tipos de neve, usando inglês. Difícil, né?

É verdade que o propósito de blogs e microblogs é o de dar voz-própria para cada indivíduo, sem que dependam de canais previamente estabelecidos que atuem como editores do conteúdo produzido. Também é verdade que o fluxo aparentemente caótico de informação que corre nos blogs podem produzir ferramentas interessantes. Por exemplo, podemos analisar a massa de blogs de muitos usuários da internet que escrevem sobre as suas impressões sobre os produtos ou serviços que são lançados, para ter um feedback coletivo e usar como um termômetro para medir a repercussão e aceitação de uma campanha de marketing.

Sendo assim, falar em “formas adequadas para se escrever” parece uma coisa antiga, retrógrada. Na maior parte do tempo, atuamos mais como filtros e repetidores de sinal do que produtores de novas unidades de informação. Mas, se atuamos como filtros, é porque há muito ruído no rio de informação que passa por nós todos os dias. E se há muito ruído, poderíamos muito bem fazer um pouco de auto-análise e vermos se nossa atuação é sinal (conteúdo que dá novas informações, claro, preciso, eficaz) ou se é ruído (repetição, inócuo, redundante, que apenas toma tempo do receptor).

O idioma escolhido acaba sendo parte dessa auto-análise. Os blogueiros brasileiros que buscam acabam escrevendo em Inglês podem muito bem perguntar: “Será que aquilo que eu quero falar é relevante para essas pessoas que já fazem parte da conversa global, ou estou apenas usando um idioma com maior número de receptores para ter a sensação de que terei maior alcance?”

Ao passar por essa auto-análise, podemos muito bem perceber que a maior parte do conteúdo não teria razão para ser escrito em inglês. Muito do que discutimos ou apresentamos no blog são informações que já são conhecidas, ou podem ser facilmente encontradas, entre pessoas que trabalham com tecnologia e falam em inglês. E querer ficar falando ou escrevendo para quem já tem meios de ouvir a informação da fonte original é uma ação, no fundo, vaidosa e sem propósito. É apenas uma forma moderna e high-tech de querer ouvir a si mesmo. O produtor do conteúdo não se beneficia (além da auto-massagem no ego) e os consumidores potenciais não se beneficiam, pois já possuem a informação – de melhor qualidade – em outro lugar.

É por conta de tudo isso que fazemos questão de escrever em Português. Há muita gente por aí que até gostaria de buscar formação e informação para trabalhar com tecnologia mas que esbarra no problema de falta de material que não seja em inglês. Espero que, ao fornecer um pilar de material na língua nativa, o caminho para essa formação seja mais fácil e menos desencorajador.

Primeiro vamos à palestra do ministro da pesquisa e inovação de Ontario, Honorable John Wilkinson. Ele falou durante o almoço, o que não é muito agradável, mas a minha primeira impressão foi: como os políticos sabem falar bem! Não que os outros palestrantes não soubessem falar ou tivessem problemas no palco, mas o políticos são especialistas em falar as coisas de um jeito que parece até que eles realmente estão entendendo detalhes de todos os assuntos, mesmo que seja somente um texto escrito pelo assessor.

Mas falando do conteúdo, duas coisas me chamaram muito a atenção. Primeiro foi que o evento contava com enviados das embaixadas da China e da Índia. Nisso eu fiquei pensando: onde estaria o representante brasileiro? O governo brasileiro envia representantes para eventos os mais esdrúxulos possíveis, mas será que ninguém da embaixada em Ottawa ou do consulado em Toronto sabia desse evento e/ou se interessou por ele? Qual seria o motivo da missão brasileira no Canadá, somente dar suporte à cidadãos brasileiros, ou participar mais ativamente em parcerias que podem trazer benefícios enormes para o país? O Canadá não tem uma economia comparável, em tamanho, à dos EUA ou da Europa, mas é não é de se desprezar, como nossos concorrentes chineses e indianos sabem muito bem. Segundo o ministro, Ontario é o distrito do G8 (e possivelmente do mundo) com maior densidade de graduados em universidades (distritos seriam estados ou províncias, já que provavelmente existem focos menores com maior densidade). Isso significa um grande potencial de crescimento na região, já que conta com muita mão de obra qualificada (e um governo que, apesar de todos os problemas, tenta ajudar).

O segundo ponto interessante tem relação com os incentivos do governo provincial para a criação de novos negócios. Existem inúmeros projetos, mas dois chamam a atenção. Primeiro, o governo tem um projeto com um fundo de alguns bilhões de dólares pra investir em empresas de tecnologia. O interessante é que, se você tem um projeto e aplica para conseguir fundos, o governo garante que responde em 45 dias. Isso é realmente impressionante, pois avaliar um projeto desses sempre requer contatos com especialistas e outras milhões de burocracias atrapalhando. Segundo o ministro, o governo quer ser um “parceiro” que anda na “velocidade da nova economia”. Segundo, novas empresas que são baseadas em tecnologia própria tem 10 anos de isenção fiscal. Isso é o governo trabalhando pra ajudar as empresas, não pra chupar o sangue delas! Na minha última ida ao Brasil eu conversei com um amigo que abriu uma empresa de tecnologia. Ele me disse que cerca de 40% dos gastos da empresa eram impostos, desde taxas diretas da venda até encargos para os empregados. Se o governo cortasse esses impostos para empresas recém criadas, ele teria 40% mais investimento pra crescer! E depois o governo poderia reter 20% de impostos de um bolo muito maior. É claro que tem-se que tomar muito cuidado com essas medidas, senão vão surgir milhares de empresas se recriando a cada dois anos pra ficar sempre na categoria de “novas empresas”, mas eu imagino que algo bem pensado nessa direção seja muito proveitoso.

Bem, vamos ao painel então. O título era “Failures on the Road to Success” (literalmente, fracassos no caminho do sucesso). A proposta era basicamente discutir como fracassos fazem parte da busca por sucesso, principalmente em áreas muito imprevisíveis (veja no último texto sobre os Black Swans). Os palestrantes não entraram muito em conflito e todos eles defendiam a tese de que fracassos anteriores são considerados positivamente no vale do silício por analistas de investimento. Isto é, quando alguém vai analisar se vai pôr dinheiro na sua idéia, você ter feito uma besteira anterior é positivo, pois você ganhou experiência, talvez perdeu dinheiro (dos outros), mas tem mais chance de dar certo agora. Infelizmente, e isso eu achei o ponto fraco da discussão, nenhum dos palestrantes admitiu realmente ter fracassado feio. Somente um deles contou um caso em que o fracasso inicial no fim se transformou num sucesso (ele apostou na moeda errada, mas depois de alguns anos ela se tornou a certa). Ou seja, não sei até que ponto é só glamour essa idéia de glorificar o fracasso passado.

Mas outras duas mensagens curtas do painel também foram legais. Primeiro, eles pisaram e falaram mal de venture capitalists. Disseram que eles não estão nem aí para o seu negócio, tudo que querem é retorno do investimento, etc, tudo aquilo que a gente já sabe, mas é sempre bom repetir: no melhor dos mundos, cresça o quanto der, até sua empresa ter o máximo possível de valor de mercado antes de procurar investidores. Segundo, eles disseram nua e cruamente: cientistas da computação não sabem fazer negócios. Isso não significa que não existam computeiros que possam ser ótimos homens de negócios, mas simplesmente que o tipo de treinamento e skills necessários pra ser um bom manager, para negociar com clientes, etc, não é exatamente o que é ensinado em um curso de computação. A dica é, se você entende muito de tecnologia e sabe muito bem como desenvolver produtos, se concentre nessa área e se associe com uma pessoa que é especialista em vender a sua tecnologia e o seus produtos. Mais uma que a gente já sabia!

Aproveitei que as coisas deram uma acalmada pra tentar responder eu mesmo à minha última provocação. Há sim gente boa escrevendo no Brasil e buscando a comunidade dentro do próprio país. Nas minhas andanças, já encontrei e foram parar no meu RSS os seguintes:

• 1up4Developers
• Bruno Dulcetti
• Bruno Pereira
• Mergulhando no Caos
• Motor Curiosidade
• Pythonologia

http://www.codinghorror.com/blog/archives/001108.html

Dizem por aí que se você lê regularmente blogs e sites especializados em desenvolvimento, tecnologia, mercado e afins, você já é um profissional diferenciado. Existe até um número descrevendo isso: 20% apenas dos desenvolvedores se interessam por este tipo de material (eu vi este número em vários textos. Infelizmente não tenho as referências comigo agora, portanto terão que acreditar na minha palavra).