Olá pessoal, "Codificação Criativa com Swift Playgrounds" Resultado de pesquisa do trabalho que vocês fizeram no ano passado para o Scholarship Challenge. Eu e o professor Binder e mais um ex-aluno nosso da noite, o Thiago Uma, a gente escreveu um artigo que a gente está trabalhando desde o ano passado, desde aquela época, trabalho acadêmico é meio demorado, um ano prazo. Eu vou compartilhar com vocês a versão atual da pesquisa, que pode ser que modifique com o passar do tempo. É com base aquele PDF que vocês passaram no Facebook lá? Isso, aquele PDF é a versão atual. Ok. Depois, se alguém se interessar, também pode voltar no PDF e ler mais sobre o assunto. É uma precisação rápida, acho que não vai passar mais de meia hora, tá? Com a discussão, inclusive. Beleza? Então, só lembrando que a codificação criativa é a utilização de linguagem e programação existentes para fins expressivos ao invés de fins funcionais. É o termo utilizado também para definir novas linguagens de programação com função específica para arte e design. Mas aqui acaba acontecendo uma certa ambiguidade. Às vezes você pode fazer codificação criativa com uma linguagem que não é feita para isso, às vezes você tem algumas vezes que codificação criativa significa somente linguagem desse tipo. Ou ambiente de programação para iniciantes ou hardware para instalações artísticas. Então, não tem uma definição muito precisa do que a codificação criativa, creative coding em inglês. Se vocês quiserem relembrar também o histórico e exemplos, tem os slides da aula do ano passado. Eu vou repostar eles no grupo para vocês darem uma olhada. Mas hoje eu não vou falar sobre codificação criativa em detalhes, vou falar mais sobre o estudo que foi feito aqui. A primeira coisa que a gente fez é entender a história da ferramenta. Então a história do Swift Playground, que foi a ferramenta que vocês utilizaram, está muito atrelada ao Processing. Na época que eu dei aquela aula no passado eu não sabia, mas o Processing foi a inspiração para o Playground. Eu encontrei documentos que demonstram isso. O Xcode Interactive Playground, como ele foi chamado pela primeira vez, lançado em 2016, teve como seu arquiteto líder o Chris Lattner. E o Chris Lattner menciona na página pessoal dele que uma das influências principais para fazer o Xcode Interactive Playground foi esse artigo escrito pelo Brett Victor, chamado Learnable Programming. É um artigo fantástico em que o Brett Victor analisa as ferramentas que existiam na época 2012 para aprender programação e ele desce muitas críticas contra o Processing. É um artigo muito crítico em relação ao Processing. Ele fala assim, o Processing é bom para você pintar coisas, mas se você quiser construir alguma coisa interativa e se você quiser aprender a programar, ele é péssimo. Ele não é bom para aprender a programar como muita gente acha. E aí ele fala, bom para aprender a programar é o logo. E ele faz uma comparação com o logo que foi criado pelo Simon Papert e depois deu origem também ao Scratch. Ele não menciona o Scratch no artigo dele, mas pode se entender que é diferente realmente do Processing. Agora ele faz sugestões de mudança no Processing. Ele usa a linguagem Processing para criar vários protótipos de conceitos do tipo visualizar resultados linha por linha e você poder ir voltar nesses resultados, que é o que está ali nesse protótipozinho em cima e é uma funcionalidade que foi implementada no Nextcode Playgrounds. Vocês têm uma coisa parecida com isso, não é exatamente igual, em função desse experimento. O Brett Victor na época, em 2012, ele trabalhava na Apple, ele estava terminando alguns estudos, não trabalhou nessa área especificamente. Ele não trabalhou com o Chris Lappner no Street Playgrounds, mas ele escreveu esse artigo. Ele escreveu outros artigos muito interessantes também, criticando a utilização indiscriminada do Touch. Tem um "Brief Rant on Interaction Design", um dos artigos mais influentes dessa época em design de interação e o trabalho dele é muito reconhecido. Apesar de ter publicado bem poucos artigos no site dele, ainda assim muitas pessoas visitam. Então vale a pena dar uma olhada. Voltando ao nosso artigo, a gente descobriu que o Street Playgrounds tem sua origem no Processing e a gente começou a se perguntar, "Será que o Playgrounds é bom para codificação criativa, já que ele foi inspirado no Processing, que foi criado para ser uma mídia de codificação criativa?" Essa é a pergunta de pesquisa que a gente tentou responder com o experimento feito com vocês. Antes de fazer esse experimento, a gente tem que desenvolver e definir o que a gente vai olhar, quais são as variáveis do experimento. E aí estudando na literatura de codificação criativa, a gente identificou práticas. O que seriam práticas? O que constituem o estilo de programação? O estilo tem boas práticas, por exemplo, você organizar o código por ele ser legível. Na codificação criativa, às vezes, esse estilo, essa prática não é tão comum. Então a gente definiu codificação criativa como estilo de programação, constituído dessas sete práticas que a gente achou na literatura. A primeira é escrever código tal como se esboça um desenho. O que significa isso? Que você não escreve o código final de cara, você escreve um primeiro código que é um stub, também uma palavra utilizada, um sketch no process, esse é o termo específico para os arquivos de processing. Então o que que é um sketch? É um esboço que você coloca alguma coisa ali para ver o que acontece, para quando você ver ou olhar para aquele esboço, você pensar qual vai ser o seu próximo passo. Você não faz uma arquitetura planejada inteira antes de começar a programar, você vai evoluindo por interações entre a programação, a desenvolvimento e a execução e o teste e a tua percepção estética do que você está construindo. Que é uma abordagem mais progressiva, mas também errática, porque significa que no meio do caminho você pode descobrir algo no seu esboço que você não imaginava e que te empurra para uma outra área da exploração de possibilidades que você nunca tinha imaginado antes de começar a codificar ou a esboçar. Então essa daqui foi a prática que já adiantando que mais vocês fizeram aqui na última challenge. Fazer replicolagem com código significa o que? Tal como você misturar um monte de objetos e lixos que você tem na sua casa e transformar eles em luxos, transformar em novos objetos, do it yourself, você pode fazer isso com pedaços de código, copiar snippets aqui, snippets ali, construir um protótipo rápido, um esboço rápido do que você está criando e depois você vai implementar uma versão viável, uma versão estruturada que não tenha bugs. A ideia é você brincar mesmo, uma espécie de experiência sensorial que você tem com o material que tem disponível. Uma carteira que existe na bricolagem é que você não compra um kit pronto de bricolagem. Aqui o kit para você fazer é uma cadeira. Você compra várias peças diferentes e vê se sai uma cadeira. Pode ser que não sai. Pode ser que no meio do caminho você decida "não, não vou fazer uma cadeira, vou fazer uma mesa". Então a ideia da bricolagem é essa relação mais sensorial e experimental com os materiais que você tem disponível. A nível de código, isso antigamente aqui na Cadmium era chamado de "code monkey". Era um termo pejorativo, depois desse estudo o Fábio mudou de ideia. Hoje ele não usa mais esse termo. Não sei se você tiver acesso a esse termo, mas antigamente quando os professores iam ensinar programação eles falavam "vocês não podem ser code monkey, vocês não podem ficar copiando e colando código da internet sem saber o que ele faz". Eu continuo achando que isso é verdade, porém a maneira como você aprende como faz é copiando e como faz. Hoje é visto como uma prática positiva para o começo, principalmente para quem está começando a programação. Mas, às vezes, algumas áreas inexploradas são o único recurso que você tem. Tem aquele livrinho também da O'Riide, que é... Como é que é o nome? Tem um gatinho que é "modify things and see what happens". Não é esse? É a melhor maneira de aprender a programar. É uma série de livros ou só um capo? Não, tudo mesmo. Tem o Go Horse Programming também. Tem níveis, mas tem livros também. Então, eu sei que tem um livro, mas a série de livros são bons. Tem um site que você gera essas capas e os livros. A terceira prática é expressar sentimentos e ideias através de código, tal como Fanhor, que é esse pintor holandês, expressou de maneira brilhante na pintura. Recentemente foi lançado um filme-animação sobre a vida do Fanhor, que é... Cara, imagina essa pintura, ela foi feita pelo Fanhor e tal, ele pintava muito rápido, era um estilo de pintura rápido, mas mesmo assim, uma precisão incrível, uma expressão magnífica. Imagine você fazer um filme, um longa-metragem, desenhado quadro a quadro, dessa maneira. Foram mais de 30 artistas envolvidos nesse projeto. 115? 115 artistas. 115, foi quase 10 anos, um negócio assim para fazer. Nossa, já assistimos três vezes, eu ainda não consigo parar de assistir. É Netflix agora. É incrível. É o amor Vincent van Gogh. É, Vincent van Gogh. O amor Vincent é alguma coisa assim. Cara, é incrível. Em inglês é Love In Vincit, em português é Amor Van Gogh. E então isso é possível fazer com código também, vocês poder expressar. Eu acho que esse daqui provavelmente foi um dos fatores mais importantes para quem conseguiu ser selecionado, de conseguir mostrar uma parte de você mesmo. Expressar, a expressão está ligada muito às suas convicções, às suas questões mais suas, que não são necessariamente lugar comum, que todo mundo fala, ou que é lugar comum, mas que você acredita tanto que aquilo ali se torna original para você ser seu. E nessa época que o Van Gogh ele pintava, era uma época que as pessoas eram mais contritas, elas não expressavam as expressões, ainda mais na sociedade holandesa, até hoje. É um pouco mais, a pessoa é muito mais fechada que aqui no Brasil. E as obras dele mostrava essa possibilidade de você ser esfusiante, digamos assim, nas suas expressões. Prática número quatro, projetar performances emergentes. Isso é um termo técnico que eu utilizo para falar de um projeto que a pessoa vai usar de maneira que você não espera. Emergente porque você não sabe exatamente como que o usuário vai interagir com aquele seu playground, com aquela sua criação. E os exemplos que a gente já analisou também no passado tem a ver com a dança, né? A dança que usa esse termo performance. A performance quem faz no caso de um play game interativo é o usuário, não é a dança, ou o artista, nesse caso. Então, o que você faz como programador? Você cria um ambiente como se fosse um palco, como se fosse uma ambientação, para que o usuário execute a performance dele ali. E qual vai ser a natureza, o conteúdo? Aí vai depender da experiência desse usuário que vai trazer para aquele momento e fazer relação entre esse ambiente e a interação que ele está obtendo com aquele recurso. Então, isso é uma maneira de você gerar múltiplos sentidos diferentes e as pessoas verem coisas diferentes na sua própria criação. É um pouquinho diferente do expressar sentimentos, porque aqui a ideia é que você expressa um único sentimento ou você expressa um grupo de sentimentos. Aqui você dá um espaço para que a pessoa expresse infinitos sentimentos, né? Uma quantidade muito grande de possibilidades. Em código isso significa que você dá mais opções de interação para o usuário, principalmente dá opções que as pessoas misturem coisas e vejam efeitos que você, como programador, nunca teria imaginado que seria impossíveis. E você fica, obviamente, muito interessado, quer dizer, se você estiver adotando essa prática. Fica interessado em ver que tipo de criações os usuários estão fazendo com a sua plataforma, com o seu playground. Número 5, cometer erros felizes de programação. Happy coding mistakes. Eu trouxe aí um meme. Quem conhece esse cara? Bob Ross. O que você sabe sobre ele? Ele geralmente vai pintando e fica assim "não, ele é uma nuveizinha feliz aqui". Ele tinha um programa de televisão nos Estados Unidos onde ele ensinava a pintar. Eu acho que era meia hora. Só que ele era uma pessoa muito divertida, bem tranquilão, ia falando, aí você faz isso aqui. Só que tinha aqueles momentos em que ele fazia algo que parecia bem esquisito na tela, uma tela toda harmonizada, e de repente ele pegava uma faca e começava a cortar a tela. Aí ele fala assim "don't worry, don't worry, we don't make mistakes, we just have a happy accident". Então era uma filosofia de vida, ele repetia muitas vezes e as pessoas transformaram no meme. E aí uma característica que tem a ver com programação é que quando você está programando, muitas vezes tem gente que fica brava, quebra o teclado e grita com os bugs, eventualmente que isso acontece, e tem as outras pessoas que encaram isso como happy mistakes, ou happy accidents. "Pô, que legal esse bug, olha só que interessante". Exatamente, não é um bug, é uma feature, você transformar um bug numa feature. Claro que eu não estou falando de erros fatais, happy code mistakes não são fatais, são erros em que você compila, começa a interagir, acontece algo que você não esperava na execução e que teoricamente destrói o seu conceito original. E aí você pode ver isso como um ruído, como um desvio do teu conceito original, você pode olhar para esse novo, pelo que emergiu, e falar "puta, aqui tem uma ideia interessante, acho que é mais interessante para esse caminho". Happy code mistakes foi um elemento bem comum também entre os trabalhos que foram selecionados, muita gente inclusive falou isso nos próprios textos que mandaram para a Apple, sobre os erros eventuais que tiveram de programação e que como eles tinham sido importantes. O Shift Playgrounds é uma ferramenta que instimula você a cometer erros, de uma certa maneira, porque ele vai te dando ali resultado em tempo real, para você ficar olhando para a execução, não para a estruturação do código. Número 6, implementar aleatoriedade. Por que que aleatoriedade é tão interessante na codificação criativa? Porque ela dá uma sensação de organicidade para a sua criação. O que você cria e coloca, você cria a partir de parâmetros randômicos, eles adquirem uma sensação orgânica, natural, algo que não foi criado por um ser humano. E isso gera uma certa sense of wonder, maravilha o usuário, porque o usuário olha aquilo como se fosse um objeto vivo, mesmo que seja muito distante de ser um objeto vivo, mas você sente a mesma sensação que você sente ao entrar, para aqueles que gostam de natureza, entrar no meio de uma floresta e ver a pujança da natureza, porque ali você vê variedade, só que é uma variedade organizada por regras. E essas regras são fractais, são regras da matemática do caos e outras estruturas que antigamente se achavam que eram completamente aleatórias, mas hoje se entende que existem algumas regras já documentadas, umas leis. A aleatoriedade é uma espécie de hack que você faz para não implementar essas leis. Se você não sabe quais as leis existem para um determinado domínio da natureza que você quer reproduzir, mas você quer que ele pareça da natureza, você implementa a aleatoriedade. Então é uma espécie de complemento para a ignorância, jogar o randômico ali para você criar algo que pareça interessante, coerente, consistente, mas ao mesmo tempo também demonstra que você não sabe como programar aquilo ali por completo. Então fica a dica para quem tiver alguma dificuldade, não sabe como terminar o projeto, tasca um parâmetro randômico no meio e vê o que acontece. Número 7, apreciar a estética do código. Isso aqui é uma contradição bem curiosa dos programadores, eles são mais hardcore, assim começam aqueles que falam "não, não, arte é coisa para design, não tem nada a ver com arte, eu não gosto de arte, não gosto de música, não gosto de dança, não gosto de pintura, não gosto de nada, não gosto de história, mas gosto de ver arte no código, gosto de ver o ratuque da indentação e vários outros elementos, por exemplo, escrever código com menos linhas também é uma característica da estética do código, porque código com menos linhas não é mais eficiente. Hoje em dia, os computadores não fazem muita diferença se você utiliza um número x ou y de memória ou de linhas no código, é a maneira como você usa a memória. Então o tamanho, o número de linhas de código continua ainda sendo um fator relevante e interessante, os programadores costumam falar "consegui fazer tal coisa com 10 linhas de código", porque é uma questão estética, tal como você como designer gráfico pode falar "olha só consegui resolver essa composição com apenas 3 elementos". Minimalismo é um estilo, é um estilo de caráter estético, não de caráter funcional. E existem várias outras características, eu estou só comentando esse estilo minimalista, mas tem os estilos verbosos também, tem pessoas que gostam de escrever códigos extremamente compridos, Esse é um verboso. Esse é um verboso. Tem a galera do estilo obscuro, que gosta de escrever um código que ninguém mais consegue ler. Essa galera geralmente fica empregada por muito tempo. Essa galera pode ser um excelente programador indie, por exemplo, um cara que programa sozinho, mas realmente é uma dificuldade muito grande quem escreve código obscuro para compartilhar com os outros. E por aí vai, tem vários estilos, eu não entrei muito em detalhes dentro dessa questão estética do código, mas eu notei que várias pessoas, vários programadores já escreveram sobre isso, e vocês também demonstravam, apreciaram a estética do código. Então vamos ver como é que foi a identificação dessas práticas aqui dentro no Scholarship Challenge do ano passado. Eu peguei essas sete categorias e apliquei no contexto dos dados que eu tinha disponível. Foi depois que vocês fizeram o challenge que eu comecei a ler sobre o assunto, e aí a gente começou a analisar os trabalhos. Esses aqui são alguns dos trabalhos que foram selecionados para receber a bolsa da WWDC. Eu peguei só uma captura de tela que estava disponível, acho que estava dentro do próprio Playgrounds, como exemplo. A gente enviou um questionário para vocês logo depois que vocês terminarem, talvez duas ou três semanas depois, perguntando dessas práticas. Tinha uma citação assim descrevendo que era prática, e aí perguntava "Você fez isso com o seu projeto?" Claro que muita gente não entendeu, porque do jeito que eu estou explicando aqui eu não saberia explicar naquela época. Eu nem tinha noção direito desses detalhes dessas práticas todas, porém a gente queria subverter um artigo que estava com prazo na tampa, então a gente fez uma coisa meio rapidona só para ter algum feedback. Então muita gente não descreveu certas práticas que provavelmente essas pessoas fizeram por não entender ou linguajar a maneira como a gente descreveu. Vocês podem até comentar se vocês lembraram de alguma coisa que vocês descreveram. Tinha algumas coisas que pareciam bem repetitivas assim, das perguntas da Teodomir. Mas responde isso no outro, deve ter alguma coisa que você não conhecia. Aí a gente pegava e mandava a tua resposta por um lado e por outro. A gente interpretou as respostas. Por exemplo, se você respondeu para uma prática, você fez aquela prática, mas o teu texto dar e entender que você fez uma outra prática, a gente movia sua resposta para uma evidência e dar uma outra prática. A gente não tomava face value, tipo exatamente o que vocês falaram, até porque vocês não tiveram contato suficiente para entender essas práticas. A gente não deu esse conteúdo na aula, por exemplo, de codificação criativa. Aí muita gente grava o vídeo. Eu dou destaque para o vídeo da Loryen, que ficou muito detalhado. Ela descreveu como é que foi todos os detalhes desde a primeira ideia que ela teve. E ela vai mostrando também os primeiros códigos que ela escreveu, as versões. Depois, como é que ela interagia, executava o código, mexia e encontrava vários... Como é que é? Erros, mistakes da vida, erros felizes da vida. E como eles acabam se tornando uma funcionalidade, como o Bruno mencionou, acaba guiando o processo criativo dela. A maioria de vocês não fez um vídeo tão completo, fez mais de um minuto, dois minutos, mas também serviu muito para entender as decisões que vocês tiveram nos seus projetos e principalmente os efeitos que vocês obtiveram com os usuários, porque o vídeo tinha que gravar com os usuários usando. Não sei se vocês lembram. A gente pegou todos esses dados, inclusive as reflections que vocês escreveram depois, e colocamos dentro de uma tabela de evidências, um spreadsheet, basicamente. Cada vez que a gente tinha uma evidência de uma prática de codificação criativa, a gente inseria um comentário ou copiava e colava um texto da sua reflection ou da sua resposta lá do questionário. Então, no final, a gente fez um levantamento de quantos porcentos dos projetos tinham a presença daquela prática de codificação criativa. Claro que essa porcentagem provavelmente é menor do que a real, porque muitas vezes vocês não reportaram para a gente coisas que vocês fizeram e não entenderam pelos canais que a gente utilizou. A gente poderia ter feito uma pesquisa muito mais aprofundada se a gente tivesse acompanhado vocês um a um, vendo o que vocês estavam fazendo no projeto, mas naquela época não foi possível, até porque nem estava previsto fazer um estudo. A gente fez um estudo pós, mas até que ficou bacana, eu acho. Resultado. Então, aqui a gente faz uma comparação dos projetos que tiveram a bolsa, foram 8 projetos analisados e dos que não tiveram a bolsa, foram acho que 24 no total analisados. Então, nem todo mundo participou dessa pesquisa, porque como vocês podem ver, tem menos projetos no total do que realmente foram feitos. Muita gente não quis participar do questionário, ou não entregou o vídeo, não entregou nada. Tem variedades aí. Então, o que a gente percebe aqui são diferenças significativas em duas práticas. E aí é bom vocês prestar atenção, porque provavelmente devem ser práticas que a Apple deve valorizar quando ela faz o julgamento dos trabalhos. Uma delas é a projetar performances emergentes, que quem ganhou a bolsa teve 50% a mais. O que significa isso? Quem ganhou a bolsa pensou muito no que o usuário ia fazer quando estivesse interagindo com o Playground. Que no vídeo mostra muito claramente uma pessoa muito interessada e olha que legal que está fazendo, nossa, que bacana que está fazendo isso aqui. Caraca, nunca imaginei que isso fosse possível. Fica bem claro que o pessoal que ganhou a bolsa focalizou muito nisso. Ou, por exemplo, o Alexis, que gravou um vídeo do filho dele tocando o negócio que ele fez para o filho. Quer dizer, o foco total dele era satisfazer o filho e isso é uma performance emergente. Como que o filho se satisfaz? Ele não sabe. Por isso que ele se diverte ao ver o filho brincando e fazendo zoeira, sacaneando, porque na verdade o filho dele não toca uma música, o filho dele faz uma bagunça no vídeo. E isso para um pai coruja como o Alexis é motivo de satisfação. Mas para um programador chato seria "pô, você acabou de estragar o meu barilho musical". E um componente que ajuda muito a ter uma performance emergente é a leitoridade. Então um está linkado ao outro. Então 50% dos estudantes que receberam bolsa utilizaram a leitoridade. Eu acho que na verdade é maior esse número, só que eu não posso dizer com certeza. E por outro lado, quem não teve bolsa não usou a leitoridade. Então fica a dica. Fica a dica forte. Use a leitoridade nos seus projetos que você tem chance, tem mais chance. Eu não entendi de todos os números que a soma não deveria dar 100%, qual é a do combo? Não, porque não é dividido assim por essa ou aquela prática. Essas práticas podem se acumular, entendeu? Então um projeto poderia ter todas essas práticas, entendeu? Sim, 50% de quem ganhou bolsa usou aquilo, né? Isso. 58% de quem não teve bolsa usou aquilo. Não, os dois não tem que ser mais 100%, entendi. Não dá como lembrar. Beleza? O que você tinha cometeu um erro feliz de programação? Você estava programando, deu um bug de execução. Não é um bug final, não é um bug que impede a execução do projeto. Mas você vê aquilo ali, está diferente do que você tinha pensado, e você gosta daquilo e está transformando numa fítica. Seria um erro feliz de programação. Assim, eu acho que desses números só vale destacar mesmo esses dois diferentes, porque a diferença entre 50% e 46% é mínima. Inclusive no tamanho da amostra deveria ser desconsiderada. Pode ter tanto desvio nessa análise estatística que nem leva muito em consideração. Leve mais esse take de que a diferença é maior do que do projetar performance emergentes e implementar aleatoriedade. E aí a gente pegou essas práticas, viu os comentários que vocês deram sobre o Xcode Playgrounds, que tinha no final uma pergunta, o que você acha do Xcode Playgrounds para codificação criativo. Vocês fizeram críticas muito interessantes. E a gente fez um... na verdade no artigo nem tem esse bom médio aí. Isso eu estou fazendo só para resumir, no artigo a gente dá uma análise detalhada de cada um desses itens, por que que é bom, por que que é médio, mas aqui eu estou sintetizando apenas para vocês terem um acesso rápido à pesquisa. Então, para escrever código como esboçar é bom, para fazer bricolagem é médio, expressar sentimentos médio, projetar performance emergentes ruim curiosamente é aquilo que faz a diferença. Mas o que é ruim? Que demora um tempão para você, embora seja interpretado ali o código, ele demora um tempo para carregar para você interagir. Às vezes você interage de um jeito diferente, tinha uma galera que tinha que pegar o código, criar uma gambiarra para colocar no outro arquivo que já impedia de fazer execução em tempo real, que era toda a ideia vinha a partir disso, né, ideia do Playgrounds. Então, foi muito criticado. Não sei se melhorou desde então, faz um ano, já tem uma versão nova do Xcode. Vocês estão um pouquinho mais robustos? Não melhorou. Continua pesadíssimo. Thanks, but no thanks. Eu joguei para fora, as coisas que nem no anterior, porque ele fica carregando ao mesmo tempo, daí às vezes você está fazendo mais trabalho, fica pau. Entendi, que pena. Porque eu acho que tem um potencial muito grande dessa ferramenta, vocês mesmos disseram, né? É legal, é bom ter live code, só que do jeito que está, está muito devagar, não está live porcaria nenhuma. Agora, o legal é que muita gente elogiou o code syntax e a organização do código, as ferramentas que tem para refatorar o código, para organizar, para deixar bonitinho, que são ferramentas que ajudam você a apreciar a estética do código. Então, por enquanto, avaliação geral, que o Playgrounds serve para codificação criativa, e está melhorando muito, pelo amor de Deus. Por outro lado, a linguagem Swift é melhor do que a linguagem Java para codificação criativa, isso não falo só com a experiência de vocês, mas com a leitura também dos textos sobre processing, dos textos que avaliam o Swift, porque ela é orientada a objetos, isso permite que você copie e cole código de maneira mais inteligente do que quando você usa o processing. Só que, por outro lado, não tem código para você copiar praticamente, porque não tem uma comunidade de desenvolvedores muito forte, software proprietário, essa ênfase toda que a Apple está dando, que está mudando, o Swift hoje já é uma linguagem formação aberta, o Playgrounds tem código fonte aberta também, mas o Xcode como um todo não. Então, por enquanto, ele não tem uma comunidade gigantesca como tem do processing, por exemplo, aquele site Open Processing, que serve justamente para compartilhar código, o Xcode foi super influente entre vocês, várias pessoas fizeram coisas, transportaram códigos de processing em Swift como uma ideia inicial para testar no código de vocês, ou de repente se inspiraram no algoritmo, e não tem nada parecido hoje em Swift, mas deveria ter. Então, uma das sugestões e recomendações que a gente dá no artigo é isso, que o Swift se torne uma, o Playgrounds me está dizendo, se torne uma ferramenta mais fluida para a criação, que ele seja mais intolerante a erros, não, melhor, tolerante a erros, desculpa, é tolerante a erros, que ele seja mais tolerante a erros, que ele deixe a pessoa mais de boa para criar, que ele tenha um ciclo de interpretação mais rápido e que tem uma comunidade de software livre, uma comunidade que compartilhe códigos na internet. Eu acho que a Apple está querendo fazer isso com o Swift Playgrounds no iPad, mas não está ainda lá, e de novo, resolveu fazer o Scholarship Challenge com esse mesmo tema, eu imagino porque ela está querendo provocar esse tipo de movimento. Vocês tiveram aquele encontro outro dia aqui vendo os códigos da galera que tinha sido reunido no GitHub, você mostrou, né Veloso? Mostrei alguns, na verdade não cheguei a mostrar. Não mostrou o GitHub, né? Então, tem um GitHub que algumas pessoas que foram para o Scholarship organizaram um GitHub para reunir os códigos da galera que foi ano passado, inclusive alguns de vocês aqui da Academy compartilharam códigos lá, e já é uma evidência de que deu certo esse estímulo que a Apple fez para que a galera compartilhe código na comunidade do Swift, mas nada nem próximo do que já tem com o Processing. Então, é bom vocês entenderem esse contexto até para estratégicamente saber o que vocês vão criar, né? Se você criar alguma coisa que faz sentido nesse tipo de comunidade, você tem mais chances de ser selecionado. O que é que chama a atenção? São códigos que têm efeitos visuais, primeiro lugar, efeitos visuais impressionantes, que você olha e fala "Caraca, como é que fez isso?" Aí você vai olhar o código, você vai estudar aí, o código está legível, um código que você consegue copiar e colar, tem alguma brincadeira no código, tem comentários no código, todas essas coisas eles vão estar olhando, eles não analisam só a execução e o texto, eles analisam o código também. Então, teve algumas pessoas que eu acho que foram selecionadas porque o código estava muito bem escrito, muito bem comentado, no caso do Rodrigo Long e Marense. Eu achei o trabalho dele de código impressionante. E os comentários e a maneira como ele conversa também com o leitor do código dele, vale a pena dar uma olhada. Ele disponibilizou nesse GitHub, uma das pessoas que fez isso. Prédio, será que a primeira impressão não faz eles olharem ou não com os restos, por exemplo? Você tem razão. Se eles não gostavam dos primeiros 10 segundos, eles não falam que eles nem vêem os outros. Não sei se eles não vão ver, mas concordo com você que eles vão ver com menos atenção. Então você tem que criar uma espécie de um processo de funil. Primeiro você atrai a atenção da pessoa de um modo geral para algo mais geral que está no seu texto. Você dá uma mensagem, seja piegas, porque a Apple é muito piega nas comunicações quando eu vou falar de storytelling, seja você também piegas. Como dramatiza sua história, você não pode inventar história, mas você pode aumentar a emoção dessa história. Sejam honestos, mas sejam latinos. Aproveitem a nossa cultura para isso e contem uma história bem bacana no texto. O texto vai levar a pessoa a interagir com a execução e depois eu acho que ela vai olhar o código fonte nessa ordem. Pode ser que eu esteja só especulando, pode ser que cada juiz aja de maneira diferente. A gente não tem dados nenhum sobre isso, totalmente secreto, nem sabemos quem avalia. A gente sabe que eles fazem isso no App Store, porque já foi nos dados de informação. Agora, se eles fazem isso no Playground, não sei, mas é bem provável. Então, isso significa o que? Se você utiliza certos mecanismos novos que estão disponíveis no Playground, por exemplo, não sei se você consegue fazer alguma coisa com Cormel, sei lá. É uma tecnologia, por exemplo, que está nas bocas da Apple, a Apple está querendo propor, se você utilizar no seu Playground, mais um pontinho. Agora, não utilize isso se não precisar, porque a gente viu que ano passado os Playgrounds mais selecionados não eram os mais complexos, não eram os que tinham tecnologias mais avançadas, eram aqueles que tinham um conceito muito bem amarrado. E esse conceito estava amarrado com o texto, estava amarrado com a execução, estava amarrado com a escrita do código. As três mídias de expressão que você vai ter disponível para convencer o júri estavam embebidas do mesmo conceito. Vocês já viram os trabalhos, reviram os trabalhos no passado, então eu não vou rever eles, vocês sabem o que eu estou falando. E se vocês precisarem de ajuda para criar ideia, vem falar comigo, tá bom? Vocês têm mais algum comentário? Não? Ah, tem uma parte engraçada dessa história toda. Essa apresentação foi baseada num artigo que está em avaliação num período chamado Computers and New Behavior, já mencionei os autores. Só faltou falar que a primeira versão foi rejeitada sumariamente no Simpósio Brasileiro de Engenharia de Software no passado. Nós tivemos três ou quatro revisores, agora não me lembro, são revisores num processo científico que você não sabe quem são, são anônimos. E um deles falou assim, nossa que legal, a gente na engenharia de software precisa mesmo estudar um pouco mais esse aspecto artístico, que é uma realidade da prática que a gente ignora, e aí outra pessoa vem e não entende nada. A gente não tem um artigo, não está estruturado, não tem uma narrativa como coerente e tem falhas no tratamento estatístico. Pô, o cara não entendeu que a proposta não era ser um experimento com validade estatística, né? E o outro revisor falou assim, olha, a ideia é boa, mas foi mal implementada, a metodologia está fraca, até concordei com esse revisor. E o quarto eu não me lembro o que falou, acho que detonou também, que falou, coisa assim, bem destruiu o projeto. Aí a gente teve que escrever uma, como é que fala, uma resposta, uma réplica, né? E isso não adiantou, daí acabaram rejeitando. A gente sabe que foi rejeitou porque é muito fora do que normalmente se trabalha em engenharia de software, até porque a história da engenharia de software, agora eu estou entendendo isso melhor, porque naquela época eu não entendia, ela surge para superar uma visão artística da programação que existia nos anos 60 e 70. Então, já ouviram falar de um tal de Dextra, é... Dijkstra. Dijkstra, não, é Dextra, eu falo holandês. Eu não. Então, é Dextra, pode aprender, porque Dijkstra é como falam no Brasil, mas E e J na verdade é uma letra só no holandês, que eles mudaram no alfabeto deles recentemente e a pronúncia é E. Então, Dextra, e tem um outro cara chamado Donald Nutt, que escreveu The Art of Computer Programming, uma coisa assim, The Art of Computer Algorithms, eu não me lembro agora, mas é uma bíblia da programação, um negócio gigante assim, todos os dois falavam naquela época de maneira bastante eloquente que programação não era uma atividade que poderia ser otimizada tal como uma fábrica, era uma atividade artística, criativa, não era uma geraria, e depois nos anos 70, os anos 80, na verdade cresce um movimento de gente que fala "não, a gente tem que estruturar isso", aí começa um movimento de Rational Unified Modeling, modeling outras coisas que eu não sei exatamente os detalhes, mas um grupo muito forte que define um ML, define vários padrões de projeto e tal, e começa a surgir, digamos assim, nascente essa noção de programação ou engenharia. E ainda hoje existe esse embate entre pessoas que definem programação arte, programação ou engenharia, mas a engenharia hoje é a visão mais comum na computação. Então, por isso que a gente foi rejeitado. Mas quem sabe nesse outro periódico isso não acontece, de repente você cai na mão de outros programadores que de repente tenham tido experiências parecidas com o que vocês têm aqui na Academy, onde você realmente pode ser artista na hora de programar, tem um ambiente que você não pode ser artista, você é contratado para desenvolver um programa que você nem sabe para que que serve, às vezes. Então é difícil ser artista desse jeito. Beleza, galera? Então é isso. Se precisarem de mim, me chame, tá bom? Boa sorte! Obrigado, é isso aí.