 Oi pessoal, obrigado a todos por terem aqui na sessão de hoje, é um prazer estar aqui com vocês. Tive o prazer também de acompanhar o Edson e ver a sessão dele. É sempre interessante ver o Edson a falar e obrigado o Edson pelas palavras gentis que dirigiu para mim. Tenho uma boa sessão, Edson, obrigado também por isso. Por isso, como o Edson também disse, vou falar aqui um pouco sobre o Quarcos, como o Elder também disse ao trabalho na Engenharia do Quarcos. E então, qualquer coisa que tenham relacionado com o Quarcos, podem sempre falar comigo. Então, a coisa que vou fazer aqui é partilhar aqui o meu ecrã para ver aqui uns slides. E depois, vou fazer aqui uma parentorotória de Quarcos, falar aqui um pouco de algumas motivações que temos com o Quarcos. E depois vou mostrar o código no final, que é aquilo que toda a gente gosta de ver. Vamos ver se consigo desplaçar esta parte rápido para poder fazer mais demos e mostrar mais código. Como podem ver, uma portuguesa um pouco diferente, não é um portugueso brasileiro, é um portugueso portugueso mesmo. Espero que consigo entender, vou falar mais de bagarro, passei que normalmente o pessoal que sou mais brasileiro tem mais dificuldade a acompanhar quando a dizem que eu falo muito rápido para ter portugueso. E se não estiverem a acompanhar, digam que tento falar mais de bagarro. Bom, falar um pouco sobre Quarcos. Então, para quem nunca ouviu falar de Quarcos, ou mesmo para quem já tenha ouviu falar, podem sempre lembrar-o de algumas coisas. O Quarcos é um projeto completamente open source e com a familiaridade principal de escrever aplicações em Java que sejam cloud native, sejam para microserviços, ou sejam serverless. Apesar de esta ter sido a multiplicação inicial, como vamos ver um pouco mais da frente, temos visto desenvolvedores a utilizar Quarcos para fazer outro tipo de aplicações, sejam aplicações monolíticas, sejam aplicações de cliente, sejam aplicações para dispositivos em beta como Raspberry Pi, ou seja, acabou por superar um pouco as expectativas no sentido de termos visto Quarcos ser aplicados em outros vertentes pelos quais não estávamos provavelmente à espera. O que acaba sendo muito bom e que acaba sendo muito positivo significa que Quarcos fez um bom trabalho nesse sentido. Agora obviamente aquilo que vocês podem estar a perguntar é porquê Quarcos, porquê mais um projeto open source pode desenvolver aplicações, ou mais uma framework, ou quer que seja. Bom, para respondermos à questão porquê Quarcos, vamos fazer aqui um andar um pouquinho para trás e vamos começar a olhar um pouco para o histórico de como nós fazemos deploy de aplicações, como é que isso afeta tudo a nível de cloud e o que acontece nos containers e o que acontece na própria modelha da JVM. Então, por exemplo, uma das coisas que podemos ver é sempre que qualquer aplicação está ser executada na JVM, há sempre isto sempre para mostrar um overhead de memória, porque obviamente o que estamos a fazer é nós estamos a carregar as vossas classes da aplicação, estamos a carregar as classes da framework quando vocês desenvolveram a vossa aplicação, estão a ser carregadas classes da própria JVM e existe sempre um overhead de memória associado a tudo isto que está a ser executado, está a ser carregado na BA. Isso não só tem impacto na memória que é utilizada, mas também tem impacto no próprio tempo de discussão da vossa aplicação iniciar até estar disponível para poder responder ao primeiro pedido de um vosso cliente. Como todos vocês talvez já devem saber, típicamente, aplicações de Java, coisas como a da JVM acabam por utilizar bastante memória, por tudo isto tem que carregar. Se compararmos a estes gráficos não estão propriamente à escala, mas típicamente se compararmos com outras coisas tipo node e go, conseguimos encaixar mais aplicações de node e mais aplicações de go ou nos mesmos recursos que poderíamos encaixar com uma aplicação valida, por exemplo, em uma JVM ou de spot. Isto acaba de ser um problema, não é? Principalmente para quem gosta de fazer coisas em Java, nós não queremos ter que mudar até com o JVM de fazermos as coisas, simplesmente porque existem outras tecnologias que utilizam menos memória que nós. No entanto, obviamente, eu não quero entrar aqui em discussões de por que acusa mais, por que acusa menos e quais é a defensa de um ou de outra defensa de um. Neste momento, este é o Estado. Existem razões para isso e existem muitas razões para isso, mas este não é o afinalado principal para o qual nós acabamos de fazer o quarto. Existem outras coisas que nós podemos melhorar antes que queira de entrar em um debate tecnológico entre todas estas tecnologias. A verdade é que se começarmos a olhar para o Poco Artes em si e utilizarmos uma abordagem tradicional para desenvolver aplicações web, pode ser um crédito, um crédito da Petite Elite, ou seja, um banco de dados para ampliar uma bookstore, de dados, uns endpoints restos para podermos investigar esses dados. Típicamente, uma aplicação feita exatamente no meu formamento com Arcos, conseguimos encaixar muito mais nós a executar essa aplicação de Arcos dos mesmos recursos que teríamos numa aplicação tradicional, por exemplo, desenvolvida com o BuzzFly ou Liberty, ou até mesmo Spring. E isso parece bastante... parece ser demasiado bom para ser verdade, não é? E é, e já vou explicar como é que nós conseguimos fazer isso. No entanto, nós não conseguimos apenas convencer os desenvolvidas a mudar para um tipo de aplicação, só apenas a dizer, ou só apenas a prometer que vão usar menos memória e vão usar menos GPU, por exemplo. Tem que ter alguma vantagem de lado deles. E, então, nós também conseguimos tentar, aponemos isso para que o nosso objetivo com Arcos, tentar trazer um ambiente de desenvolvimento mais produtivo e mais interessante para que tenha prazer a desenvolver aplicações. Então, uma das coisas que nós prometemos, só pelo menos pensamos que nós conseguimos fazer é, chamamos isto de Valparajoy, que é a Alegría Desenvolvedor, talvez seja essa forma a melhor forma de introduzir, onde temos, já, uma configuração com Live Reload, sempre que vocês adesentam o código à base da aplicação, ou seja, vocês não têm que estar a fazer restart com um servidor de corcos, sempre que vocês, e eu vou mostrar isso, sempre que vocês escrevem um código novo, corcos carregam esse código automaticamente e vocês não têm que estar a fazer nada relativamente a isso. Somos baseados em standard, ou seja, muito que vocês vão ver o corcos, provavelmente vocês já utilizaram no passado, o que significa que a barreira da entrada pode ser uma aplicação de corcos bastante repetida, e provavelmente vocês conseguem fazer uma aplicação de corcos já a seguir desta apresentação, se quiserem. Tentamos trazer com que a maior parte do código que vocês tenham de fazer seja o menor possível, para o 80% dos casos, e obviamente depois, por acaso mais complexos, vocês podem usar as APIs nativas que nós temos para simplificar esse tipo de coisas, e depois, obviamente, temos toda a parte da discussão com o grau DM, que eu também vou mostrar mais à frente, mas a ideia é que vocês não sequer tenham de se preocupar com toda a configuração que é necessária para isso, nós próprios enfreímos tudo o que é necessário e geramos a discussão nativa para vocês automaticamente. Bom, eu falei que havia ganhos de memória e ganhos de CPU, mas não quando fiquei. Aqui é apenas um exemplo, por exemplo, se nós compararmos uma aplicação tradicional de Java, podemos estar a usar 130 megas de memória, mais ou menos, com quatro que nós vimos, típicamente, de utilizações a nível de metade, ou seja, de 70 e pouco, e se usarmos grau DM com a execução nativa, conseguimos até deixar isso para um décimo da memória, e aqui falamos, mais ou menos, 10 megas de memória para aplicação deste Java. Se formos ver uma aplicação com o resto mais grave, e aqui estamos a falar, por exemplo, com iBurnate, como banco de dados, seja pós-crash, seja hora, seja before, uma aplicação tradicional para estar a usar 200 megas de memória, enquanto com aplicações de quartos, já o ganho já não é tão grande como era no anterior, que era quase metade, e é bastante significativo, menos 50 megas de memória, mas se olharmos para a execução nativa, mais uma vez vemos um de crescimento de memória, e temos quase um décimo a ser apenas utilizado. Nós conseguimos ver exatamente a mesma questão no startup time, ou seja, no tempo de execução da aplicação, típicamente vemos, quase, abaixo de um segundo, o tempo de startup time, até o servidor está pronto a responder a um pedido, enquanto, típicamente, numa aplicação tradicional de Java, vocês veem 4 ou 10 segundos, nós, na parte, vemos coisas como 1 segundo, 2 segundos, e então se for inétimo, até vemos coisas como 20 mil segundos, 30 mil segundos, 40 mil segundos, e por aí. Agora, vocês podem também estar a perguntar qual é a grande importância disto. Bom, pagando também naquilo que foi a apresentação do Yanaga, posteriormente ao Cloud Native, e a rodar coisas na Cloud, se vocês pensarem um pouco como antes, nós fazíamos dipoleios de aplicações, onde, típicamente, tínhamos um REC, ou vários RECs, não provés a qualquer, e o hardware era comparado, e era colocado lá, ou era alugado, típicamente, o que aconteciera, nós, quando fazíamos essa acessição, típicamente, sempre colocávamos muito mais recursos daquilo que a gente precisava, porque fazer essa compra era uma coisa cara, e não queríamos estar sempre, ter que fazer o pegrejo, ter que estar sempre a comprar mais hardware, não é? Então, típicamente, havia esta preocupação de fazer estes cálculos iniciais, para saber quanto tempo olharíamos precisar, mas, depois disso, não nos preocupámos muito, porque já sabíamos que a memória estava lá, se a gente precisava, a gente poderia utilizar, ao menos os CPUs, e daí o custo já tinha sido feito, inicialmente, depois, obviamente, havia os upgrades, mas, típicamente, era um custo e, ao início, de quando queríamos fazer essa instalação, ou esse deploy, e, depois, ficava lá e era a voz que parecia sempre, para vocês utilizarem como entenderiam. Se olhámos para o Paco Laos, as coisas são um pouco diferentes, não é? Típicamente, o que acontece, é que vocês compram e apagam aquilo que vocês consomem, ou seja, se vocês tiverem uma aplicação que esteja a consumir 200 MB de memória, vão pagar por esses 200 MB de memória que estão a utilizar. Se vocês tiverem uma aplicação que só apenas está a consumir 50, apenas pagam 50, ou seja, tem logo um benefício imediato. Agora, mais uma vez, isto pode não ter grande relevância quando tem apenas uma aplicação executar, não é? Agora, se vocês tiverem, quiserem mesmo escalar a sua aplicação, e tiverem sem nós ocorrer em que cada um precisa ocorrerem 200 MB de memória, isso já vai ser um custo bastante elevado. Então, por isso, se vocês conseguem reduzir a memória que é utilizada aí, o custo que vocês vão ter na atual vai ser bastante mais reduzido, compartilhamente a este. E eu mesmo preciso aplicar o CPU. Se vocês pensarem que precisam de 10 ou 20 segundos para a vossa aplicação estar disponível para poder responder aos vossos utilizadores, são 10, 15, 20 segundos, ou até mais, daqueles que vocês estão a pagar ao vosso Cloud Provider por uma utilização da vossa aplicação que não é útil para vocês. Se vocês tiverem algo que rende apenas em 2 ou 3 segundos, mais uma vez vocês vão estar a poupar valor, ou vão estar a ganhar valor naquilo que é a vossa aplicação. E então, estes... estes melhoramentos, estas performance de memória e de CPU não podem ser propriamente desprezadas no ambiente Cloud porque têm um impacto bastante grande naquilo que vai ser os nossos custos com a Cloud no final do mês ou no final do ano. E é isso também que nós tentamos fazer com o Cloud, por isso é que nós chamamos o Quarkus que é completamente cloud native por estes tipos de coisas. Mais alguns benefícios que queremos também dar ao desenvolvedor, sabemos que o mundo Reactive é algo que muitos desenvolvedores estão a olhar agora e querem fazer as aplicações de forma reativa e então nós trazemos a País de Reactive também para dentro do Quarkus e até de uma forma onde vocês podem misturar ambas as formas de desenvolver. Se quiserem fazer algo para ti, podem fazê-lo. Se quiserem fazer em Reactive, podem fazê-lo. E até podem fazer um aponte entre os dois, se for necessário. Então significa que nos casos em que se justifica podem usar um modelo Reactive, nos casos em que não se justifica podem usar o mestre final imperativo e o Quarkus te considera bastante bem com os dois e podem usar o nome exatamente da mesma aplicação que não terão problemas com isso. E depois vocês tiverem a ver nós obviamente não queríamos estar a começar o Quarkus com uma API completamente nova em que vocês tivessem que estar a aprender algo por aí e que teram um choque e que teram um custo de entrada pode ser um pouco assim no Quarkus bastante elevado, poderem aprender uma coisa nova Então nós até usamos aqui uma pilhada que é o Quarkus apenas tem vai fazer agora 3 anos mas vocês todos provavelmente já têm 5, 6, 7, 8 até mais anos de experiência com o Quarkus isto porque tudo o que nós temos da País e poemas da País do Quarkus apesar de termos almas à País nossas vocês podem usar-os a País já existentes para dar uma aplicação neste tipo de ambiente podem usar a País de camel, de hibernate vertex, rest easy microprofile, cafca até a País do sprint podem utilizar e por aí adiante então provavelmente se vocês pularem suas a País e se fazerem uma coisa de Quarkus que fazerá uma coisa e não tem que aprender propriamente uma País nova Ok, então algo que eu vos queria falar também é como é que o Quarkus nos faça internamente para vocês perceberem como é que nós conseguimos fazer tudo isto que eu acabei de dizer a nível, por exemplo de usar menos memória usar menos CPU e até reutilizar estas a País todas Bom, então para isso vocês temos que pensar um pouco em como é que uma framework adicional opera, não é? Tipicamente o que acontece é vocês fazem um build da aplicação, pode ser usando uma avena ao grado ou outro build to rocker e depois este resultado deste build um jar, um or, ou o que seja é passado por um container, ou por um servidor ou o que seja, e tipicamente o que acontece é quando esse servidor está a arrancar é aí que ele vai ler a vossa aplicação e aí que ele vai fazer uma data de coisas que são necessárias, por exemplo, vai dar configurações do sistema, vai fazer um scanner ao classe pad para ver as classes que estão anotadas para os serviços restos, para criar serviços basados e proediante, pode criar modelos em memória, por exemplo para os metamodels do wibernate queria fredpools, ou seja existe uma data de operações que são feitas anos, mas uma coisa engraçada para vocês pensarem que isto é quando assistem vários nós a arrancar seja num ambiente físico, ou seja num ambiente cloud estas operações são sempre iguais isso significa que vocês estão a desperdiçar sítulos de CPU a executar essas operações de igual forma em todos nós então uma das coisas que nós estamos a adequar que foi inverter um pouco isto e tentar prepressar o máximo da aplicação possível, de forma que a grande parte destas operações já tenham sido feitas durante o build para que quando a aplicação arranque, grande parte isto já foi feito e não tenha que estar a repetir estas operações então nós chamamos isto a passar a uma parte das operações de run time para build time então por exemplo, aquele exemplo que eu dei em que estamos a ler configurações o Quarkus lesa as configurações em build time, leia os modelos em build time leia todas as anotações quando está a compilar vergera bytecode para dar a anotação destas anotações e faz muitas outras coisas por meio e então no final é que tenha o vosso aplicativo, que depois é executado no run time e aí como tem muito menos operações para fazer e muito menos coisas para fazer por isso é que conseguimos um start up time muito mais rápido paralelamente se vocês pensarem em algum tipo de coisas, para vocês perceberem como é que nós também conseguimos copar memória ou usar menos memória, é vamos imaginar que nós estamos a carregar um sucesso de xml e para isso vocês têm que ter ocupado xml o riso de xml e uma data de outras classes de xml que estão na vossa jbm então o que acontece é, se nós já leemos o xml durante o build então já não vamos passar dessas classes no run time então significa que nós podemos remover-las do aplicativo final o xml já foi ligado já não citamos daquilo, então significa que é menos coisas que temos que carregar no jbm run time e então menos memória que vamos utilizar. Obviamente que este exemplo para o xml parece pequeno que são só meio de 10 classes mas obviamente se agora nós aplicarmos isto tudo o que acontece na vossa aplicação, isto tudo vai percentando e no final o que vamos copar de memória vai ser em um número interessante aqui isto é um pouco uma conclusão daquilo que foi dizendo, tanto que a ideia é que nós tentamos mover o máximo possível de coisas que acontecem enquanto a aplicação está executar para o compile ou quando estamos a compilar produzimos ao máximo o número de dependências que vão estar disponíveis quando a aplicação está executar para também reduzir a memória e para ser carregada no jbm maximizamos também aquilo que é que chamamos de data code elimination que não é executado durante o run time da aplicação e estas optimizações foram bastante pensadas principalmente para a grau vm porque existem limitações para compilar algo para nativo já vou falar um pouco sobre isso mas obviamente isto também funciona qualquer jbm tradicional como um hotspot um g9 ou o que seja então vocês podem ter sempre este tipo de coisas ok, há luz de municípios que eu já fui dizendo mas talvez não tenham sido claros o que acontece ao fazer este tipo de coisa em build time fazemos este trabalho apenas uma vez e não cada vez que iniciamos a aplicação imaginamos que temos sem nós em uma clave a executar isto ele vai sempre repetir estas operações 100 vezes e se fizerem restartos que são mais 100 vezes e se fizerem outro restart são mais 100 vezes e tudo isto vai sempre acrescentar não só o tempo isso que são na clave como o custo na clave que vocês estão a utilizar há claves que não são necessários então nós podemos removê-los em menos memória então tudo isto vai sempre justificar temos menos claves para ser carregadas menos memória a ser utilizado menos tempo de discussão ao menos tempo de de startup de discussão porque todas estas operações a grande parte das operações já foram discutadas durante o build algo que também nós fizemos foi tentar como fazemos isto também conseguimos remover muito o que também faz com que os colos que nós fazemos internamento sejam bastante mais rápidos do que como a aplicação tradicional bom, penso que esta explicação é relativamente mesmo que seja posa ser difícil entender como é que isto está implementado internamente por corpos pelo menos o conceito, penso que é fácil de entender e é fácil de perceber como é que nós conseguimos a seguir estes espaços conseguimos efetivamente a obter menos CPU e a obter menos memória na aplicação de Quarrocos e penso que isto é claro usando este tipo de de arquitetura como é que isto é efetivamente possível agora aquilo que nós fazemos também que a gente chama de São Quarrocos Extensions as ONGs dações do Quarrocos o que acabam de fazer fazem toda esta lógica que eu acabei de descrever para conseguir efetivamente mover tudo isto para build time e fazer todo este tipo de operações grande, nós o Quarrocos Ensino, o que se chama de Quarrocos Javos dá um grande conjunto de extensões que vocês podem utilizar vocês também podem comentar a vossa tipicamente penso que não tem sido necessário grandes implementações fora do ecostemo de Quarrocos porque nós já damos praticamente para as tecnologias e para as librerias mais populares que existemos já agora isto não significa que vocês podem usar com a libreria que eram o Quarrocos a única mudança que existe aqui é se vocês usarem uma libreria que não seja uma extensão do Quarrocos podem não ter os benefícios que eu acabei de descrever porque a libreria pode não estar preparada para isso então quando fazemos a extensão do Quarrocos é isso que nós fazemos para borrarmos esta libreria para ter todos estes benefícios que acabem de descrever agora aquilo que possivelmente possam ter ouvido é que o Quarrocos é um compilador nativo ou apenas para coberne cobernetes ou apenas para aplicações de micro serviços ou aplicações mais pequenas bom, na nossa opinião passemos que o Quarrocos é bastante mais quise não é só para estes tipos de coisas mas é muito mais nós já vimos outras vezes ao usar isto por exemplo para as filipais até por simples fato de usar-me para utilizar-me nos memórios então é perfeito para este tipo de dispositivos mas vocês conseguem ter isso benefício também em monolitos e então já vimos utilizadores também emigrar os monolitos antigos deles para os Quarrocos acabam sempre por ter um ambiente realmente um pouco melhor bom, imagem nativa isto também é um conceito novo não é já não é tão novo, já tem, já começa a ter alguns anos este conceito de imagem nativa foi introduzido com o GrauVM que é um projeto da Oracle Ops em que a ideia é que existe uma visão de mundo rechado sobre o vosso aplicação para que se possa traduzir num binário executável em que vocês já nem sequer precisam de JVM para correr a vosso aplicação ainda existe uma VM por trás para executar isto, que é a substrato de VM, mas não é um JVM não tem-as com o acesso de JVM tem, simplesmente é a VM utilizada para correr binários notivos e então o que é que acontece como nós temos esta visão fechada da vosso aplicação há algumas amitações que temos quando estão a desacompilar para este ambiente nativo, por exemplo, não podemos ter o Anamic Class Loading ou não podemos ter o Envolte de Anamics da que a JVM tem e isto é auto-explicativo se nós temos um binário executável nós podemos correr esse executável como corremos qualquer aplicação no vosso sistema então nós não podemos carregar coisas genicamente como fazemos com uma aplicação de Java tradicional a mesma coisa, por exemplo, quando pensamos em APIs como Reflection quando nós estamos a fazer um compáculo para nativo típicamente esse compáculo nativo tenta otimizar o tamanho de binário e incluir apenas aquilo que vai ser necessário para a nossa aplicação começando em um Reflection Call ou se estão tão forçados com o Reflection API de Java se nós podemos chamar qualquer método de Java usando esta API de Reflection significava que se não houvesse este tipo de implementações significava que o código nativo teria que sempre incluir a JVM toda por que não sabia durante o compáculo qual é que tiveram quais eram os Reflection Calls que tinham ocorrido então por isso existe esta alimentação que para fazer um binário nativo nós temos que viver a grau VM estes vão ser os Reflection Calls existentes e então durante o binário nativo a grau VM inclui estes pedaços de JVM para podermos executar mas não se preocupem isto obviamente tem alguma complexidade mas essa é a ideia que o Quartus vos trouxe que é simplificar toda esta configuração e então apenas com um simples comando para fazer o binário nativo no Quartus e conseguimos perceber tudo o que é necessário da aplicação e então damos as instruções a grau VM para fazer o que é necessário sem vocês terem que ter que mexer nas configurações da grau VM obviamente que isto está sempre disponível se quiserem customizar alguma coisa mas não é expectável que seja necessário claro que então existem obviamente cenários onde é mais interessante ver a JVM tradicional em vez de ser imagem nativa obviamente que a JVM tradicional terá sempre uma performance muito melhor quando tem VMs com grandes tamanhos de memória ou precisam de high throughput e por aí adiante obviamente a imagem nativa se vocês quiserem coisas como software as a service ou serverless típicamente é aí que vocês querem fazer isso porque o start up também é tão preciso que vocês podem simplesmente arrancar a aplicação quando se estão dela fazer o resposta da polícia e depois podem fazer a shutdown ou encerrar a aplicação e não tem que estar a pagar um custo fixo para ter isso na colado é isso que está sempre à espera que tal uma coisa apareça então existem vários casos dá para um ou dá para o outro também podem mostrar os dois vocês têm que ver qual é que acham que se dá melhor aquilo que querem fazer bom, acho que ainda tenho alguns minutos e agora aí quero mostrar aqui um pouco do código e mostrar aqui um pouco como o quarto se funciona como fazer com o vando de quartos então deixe-me aqui mudar aqui para o meu ideia e aqui temos várias aplicações, este é um projecto que está disponível no link-up e no final da apresentação vocês podem pegar na lista e utilizar como quiserem e aqui temos uma aplicação de quartos bastante simples é apenas um serviço de resto que gera um número é um número que por exemplo pode ser usado como identificador para criar um livro ou um dbd ou que seja e pronto, tem aqui um tempo de espera só para simular que é um tempo de serviço que mora algum tempo a executar e uma coisa que eu posso mostrar é isso que eu fizere aqui um find todo isso eu não sei porquê porque vocês vão ver que nem sequer encontraram nada de quartos e provavelmente aquilo que vocês estão a ver neste código aquilo que vocês estão a ver neste código é que nos imports vocês não veem nada de quartos, o que veem são imports de cdi de jrs alguns de microprofal tudo o que estou a fazer é completamente standard não tem nada de específico de quartos se olharmos para o próprio Shares Build neste caso o POM e aqui tanto pode ser maven como pode ser gradele o quarto se porta a ambos tipicamente o que precisam é o polovim do quartos para maven é isto que vai fazer grande parte da magia de fazer as coisas a acontecer em build time do current time e depois se vocês virem as dependências já são as tensões do quartos que depois o que tem internamente são as dependências para o jrs ou cdi ou o que seja no entanto se vocês também virem eu posso incluir dependências para outros projetos, neste caso o Raster Shares ou seja nada me impeda de usar qualquer coisa que esteja disponível no ecossistema de Java as únicas imutações podem acontecer e isto varia de livraria por livraria vai depender muito do como é que essa livraria está escrita mas o que acontece é se vocês estiverem usar uma extensão do quartos tenho toda a garantia que esta extensão vai ser possível compilar para o native e vai ser possível obter todos os benefícios que eu falei do quartos se for uma livraria que não estiver dentro do ecossistema do quartos não pode funcionar ou não por exemplo se ela tiver a usar coisas como como disse há pouco o dynamic class loading então a extensão que nós deveríamos fazer é de remover essa parte de escrever isso de outra forma então essa livraria não poderia ser compilada para a nativa não por causa do quartos mas pelas imutações da grau vm então aqui agora uma coisa que eu posso fazer é executar aqui o meu a minha aplicação do quartos usando o plugin de maven posso executar o que este quartos deve e então isto vai executar o quartos neste modo de desenvolvedor e para aqui já executou vamos ver que o quartos arrancou aqui em um pouco mais de dois segundos bastante rápido apesar de isto também ser uma aplicação relativamente pequena e então agora aqui eu posso ver o que está a executar aqui na minha no meu localhost e podemos ver isto é a parte da entrada do corpos quase ainda não tem clima resórcio mas eu não assovia a resórcio onde ela está então estamos aqui a dizer que estes são os antepanches tão disponíveis e tem que ir mais de outras coisas por isso podemos ver aqui a sua UI e então eu posso aqui até invocar diretamente o meu serviço e tenho aqui a minha resposta funcionou bem mas agora que eu posso chegar aqui e fazer posso por exemplo mudar aqui o que eu posso ver e então posso ver aqui ao lado DevNation e então agora se eu fizeram uma nova invocação deste restante ponto que vocês venham aqui ao lado DevNation não fiz nenhum restart da aplicação não fiz nenhum restart ao quarto simplesmente o corpos tentou as alterações que eu fiz e recargou-as e então significa que agora posso estar aqui alterar o que eu quiser no meu código e simplesmente invocar os antepanches novamente e ver qual é que foi o resultado da alteração do código que fiz não tem que estar a compilar, não tem que estar a fazer nada o que o corpos faz tudo isso por mim bom isso foi um caso simples e se vocês quiserem também poder acrescentar um novo endpoint que deveria funcionar exatamente da mesma forma o mais interessante que tudo é que isto se puderem também conseguimos usar um remote de app para fazer isto exatamente usando cobranetes ou cobranitos então agora aquilo que vou fazer é eu vou fazer este comando que é um quartos não é um caso de acessão e depois passe estes estes próprios que a quartos contém na imediativa e a quartos que a quartos deploy e isto ou seja, não precisa de grande configuração apenas dando estes parâmetros para o quartos ele sabe que tem que fazer uma imagem docker e tem que fazer deploy disto em um cobranete neste caso eu vou usar o cobranete local que eu tenho instalado no ambiente e agora aqui até foi o teste porque eu mudei aqui isto ou seja, é bastante interessante isto vamos voltar a ficar contestáveis vamos voltar a executar isto mas algo interessante que vocês vão ver até aqui quando eu executo este comando é que quando o quartos executa a imagem, quando o quartos cria a imagem do docker o quartos vai usar a própria imagem do docker para executar os meus testes e a própria estão a testar a imagem docker que criaram e não tem que se preocupar que a imagem docker possa estar bem se virem aqui quando está este testes veem que ele fez aqui um pull deixe-me aumentar um pouco aqui isto fez aqui um pull do docker registry e fez um grande disto e depois executou testes diretamente ali e agora só com isto já tenho este serviço a executar no meu no meu Kubernetes está aqui um número API se fizer aqui um Cuxetel Logs do Number ele está aqui a executar e então se eu vier agora aqui exatamente ao mesmo princípio tem exatamente a mesma coisa mas neste caso agora está comendo no Kubernetes então agora por exemplo muitas vezes acontece por exemplo temos um serviço de carro que é o Kubernetes e depois teremos que testar alguma coisa de aquilo desenvolver para aquilo ou uma base de dados que decidimos ligar então vocês podem correr o quartos em remote ver o que vai fazer vocês mantêm exatamente a mesma experiência de development que eu mostrei antes eu posso fazer exatamente a mesma coisa e vindo Hello neste caso eu estou fazendo de queijo DevNation e agora vocês venham aqui se eu posso enfocar isto diretamente no browser até eu não sei por si, por só ir away e aí tem o ala DevNation vou outra vez recebirem aqui até agora vou cancelar isto mas vermos aqui os blogs vocês vão ver que o quartos fez aqui um library load antes de tudo o que lá está então o próprio library load funciona se que hiverem o quartos a covarem Kubernetes então agora vou só pagar o panho ali na minha coragem vou fazer o build nativo nesta imagem vou fazer o build nesta imagem faço apenas como o normal do build do Maven packups com um profile de metibil e agora vai compilar zando de grau dm para um binário nativo este build mora algum tempo para quem e já vi que temos alguns desenvolvedores com alguma idade talvez se lembrem de como é que compilar a aplicação sem ou até mesmo alguns desenvolvedores que até usem ser diariamente onde no fundo o processo que acontece aqui é bastante parecido com o compile de C e então se se lembram disso, típicamente quando fazemos um compile desse vamos embora tomar um café e depois voltamos e típicamente às vezes nem se quer estar compilado ainda a ideia da imagem nativa não é algo que vocês não passam para fazer o quarto para mítulos de estarem um a outro a minha recomendação por exemplo é que possam ter um continuous integration como um ditabares um Jenkins que possam fazer o build nativo e depois possam rodar os testes para não terem que estar sempre para passar por este processo no desenvolvimento que é uma coisa que mora algum tempo e estão a ver, típicamente pode morar entre um minuto e meio a dois minutos enquanto isso está aqui a deputar eu vou te mostrar aqui uma outra coisa que é eu como não sei isto do core tenho aqui um isto aqui um shelf visto este demorou demorou um minuto e meio a correr quando deixá-lo a bom joelho que eu queria mostrar a seguir então agora como é que eu exploto algo que é completamente binário para já vou fazer uma coisa que vocês nunca devem fazer vou fazer um bocado para isto ok isto é completamente binário não tem nada especial então tenho que usar o .slash aqui neste meu ambiente para fazer isto agora corromo isto arrancou em 24 milissegundos e funcionaram exatamente no meu formato porque posso ver aqui um que é o direto 80, 90 quando quisem ele ia ao lado de Abnation quero que obviamente que agora como temos um build antivo vocês não podem mudar o código porque teriam que passar talvez pelo recompile não entendo tanto se vocês agora direm vou mostrar aqui quem mais vai fazer aqui no meu monitor das aplicações e para o próprio número e vou aumentar aqui um pouco isto então vocês podem ver que está aqui na memória que a memória deste são 14 megas com o número de carras muito menos que qualquer aplicação de Java de sinal Roberto, rapidinho você tem 2 minutos, está bom? sim, está bom obrigado, posso mostrar mais esto muito rápido para quem gosta de Spring pode usar as aplicações de Spring nativas vou deixar aqui para fazer aqui o on-shelf visto então se vocês têm aqui um Spring resource no fundo é um press-controller do Spring com Request Mapping com uma aplicação de Spring e então se eu vier aqui no momento para fazer tem ali um greeting aquele que está ali de Spring aquele endpoint de Spring tem um Hello Hello Pad Nation se você está então se vocês estiverem apenas realizados com as APIs de Spring também podem usar as APIs de Spring no ambiente de quartos ou seja, tentamos tornar quartos o mais a ver de possível a nível de APIs para que vocês não tenham que aprender de APIs novas para fazer uma aplicação de quartos pronto no fundo existe aquilo que eu queria mostrar para onde falamos um pouco como é que o quartos funciona como é que o quartos tenta responder a todos estes desafios de cláudas tentar ter aplicativos com menos memória e menos CPU e que tenham mais mais amigáveis para o desenvolvimento do fazer e que tenham uma API que todos possam utilizar e seja fácil de aprender e não tenham de compreender uma coisa totalmente nova há muita coisa do quartos que eu poderia mostrar mas agora vocês podem explorar por vocês próprios se vocês depois quiserem perguntar alguma coisa em concreto podem falar comigo no Twitter por e-mail como preferirem tenho todo o gosto em ajudar a seguir Muito bom Roberto, tem uma pergunta Vinícius achei alto o uso de CPU e de RAM para gerar o build de pequenos apps há alguma configuração que possa ser feita para reduzir essa utilização minha preocupação em relação a RAM visto que meus runners são pequenos mas isso é para bilo nativo? isso, para biljo nativo há algumas configurações que podem usar onde podemos otimizar algumas coisas aquilo que está com os set em default no entanto, vai ser sempre um processo que vai utilizar muito CPU, muita memória porque no fundo o que está a fazer é analisar toda a aplicação e todo todo mundo da aplicação para saber tudo que vai ser incluído não é propriamente como fazer um build em Java o Java source é traduzido para bytecode e com esse bytecode é quem dictado passar por todo esse processo para transformar em binário é uma coisa que demora não é nada que a gente possa fazer nesse aspecto mas há algumas configurações que podemos ver temos uma montação no porto tem a ver com o connectivity passa por lá e vê por que você pode gostar algumas configurações de memória algumas settings que podes remover para não incluir na grau-bm e na discussão da grau-bm que podem ajudar aí mas vai ser sempre um processo que vai consumir bastante CPU e memória a melhor demandação é que por exemplo isso seja feito quando não conseguimos integrar como um gitabaxi, não ingênuos e não tenham de passar por isso você não fica fazendo o build e toda hora que você vai testar perde muito tempo é, aqui a nossa demandação é usar a versão JVM para desenvolver e testar e depois fazer o build em um continuous integration ok Roberto, obrigado de novo obrigado mesmo por estar com a gente obrigado Will e pessoal, quem quiser depois procura o Roberto no Twitter um cara super bacana de bater um papo aí sobre o arco e sobre tecnologia em geral tá obrigado, boa sorte por resta beleza, obrigado cara, até mais bom dia para você um grande abraço