 Bom, boa tarde a todos, então eu me chamo Eduardo Pitol, eu sou desenvolvedor Wordpress, há um bom tempo já, trabalho com a ferramenta desde 2008 e a partir de 2010, praticamente todos os trabalhos que eu faço é utilizando Wordpress. Eu sou aqui do interior do Rio Grande do Sul, moro em Lagiado e tenho uma empresa lá, a Citec, a Citec ela é focada em soluções de gestão de conteúdo e hoje a gente sabe que a melhor ferramenta que tem para gerir conteúdo é o Wordpress, então a gente utiliza muito do Wordpress lá e além de gerir sistemas de gestão de conteúdo a gente desenvolve algumas soluções customizadas para a empresa como plugins também e estou lá no Slack do Wordpress.org, quem não faz parte ainda do Wordpress.org quer saber mais sobre o ecossistema Wordpress e como ele funciona, não necessariamente precisa ser desenvolvedor, mas ele é muito legal, o pessoal lá debate diariamente sobre a evolução da ferramenta então o Slack tem vários canais desde a parte do core dele até a parte de tradução então todos convidados a entrar lá é público, é fácil de entrar. Faz parte aqui da comunidade gaúcha de Wordpress, ajudando a organização do ordem de camp, dos meetups, mensais e também sou facilitador do startup weekend que é um evento de educação empreendedora onde pessoas passam um final de semana inteiro tirando uma ideia de papel transformando em negócio, então quem nunca ouviu falar de startup weekend, tem uma pesquisada, é um evento que acontece aqui em Porto Alegre também, não sei quando vai ser o próximo aqui, mas eu tenho certeza que esse ano vai ter pelo menos mais duas edições e recomendo todos a participar e é para público geral. Bom, eu vim aqui falar sobre ferramentas de trabalho, de desenvolvimento para o Wordpress, então e o que me motiva a fazer isso é esse cara aqui, o 12 factor app é um conjunto, um manifesto criado que são 12 fatores que determinam se uma aplicação está pronta, se ela é moderna está pronta para ser escalável e a gente sabe que o Wordpress foi feito muito tempo antes de criarem esse manifesto e ele é uma aplicação web, mas a comunidade o que eu acho isso muito positivo tem trabalhado para manter a mesma base de código e em vez de estar lançando novas versões completamente diferentes o que faz com que a retrocompatibilidade de coisas criadas há muito tempo atrás seja mantida, então isso é um ponto positivo para mim da ferramenta, apesar de a gente, claro, se pegar desenvolvedores mais ferrens, aí os caras vão bater muito em design patterns e que o Wordpress não segue, mas ele funciona e para mim isso é o principal, em vez de ter que não tem todos os padrões de uma aplicação moderna, mas ele funciona e mais nós conseguimos injetar coisas nele que a gente consegue transformar ele numa 12 factor e aqui eu vou apresentar algumas ferramentas que ajudam isso acontecer e eu separei elas das que vocês devem começar a implementar antes até ok eu vou chegar lá então a ordem das ferramentas são o que? as primeiras ferramentas é que eu recomendo vocês começar quem não utiliza e as últimas é ok eu vou indo com o tempo eu vou chegando lá porque realmente se a gente for fazer tudo que a gente vai para evento e escuta a gente pira, a gente não trabalha, só fica pensando em melhorar o nosso ambiente e a gente precisa reunir na útil ao agradável. Então a primeira ferramenta é o Git, que ele é um sistema de versionamento de código simples criado pelo Linux Torval, o mesmo cara que criou Linux e ele tem como objetivo vocês conseguir manter o código de vocês com versões, ou seja, sempre que vocês fazem uma alteração, avisa o Git lá, fiz uma alteração e ele vai dar tipo uma congelada no código, então se vocês querem um dia voltar alguma informação ou recuperar o que vocês fizeram está lá no histórico das alterações, além de nfitters como por exemplo trabalho distribuído, vocês podem criar vários pedaços de dividir ele em vários, fazer um fork, então criar vários raízes do projeto e depois ir juntando, então isso ajuda muito também no desenvolvimento de cuido, que vários desenvolvedores estão fazendo seus pedaços de código e depois tudo isso precisa ser juntado num local principal. A outra é o WPCLI, que eu também não vou entrar em muitos detalhes aqui para não estragar a palestra do Marcos, mas é uma ferramenta excelente para vocês conseguir administrar as instalações de WordPress utilizando linha de comando e eu não preciso falar mais nada porque eu tenho certeza que o Marcos vai dar um show aí depois. E aí a gente começa a entrar em um dos fatores do 12 factor que é a gestão de dependências. Numa instalação normal de WordPress, a gente vai lá e começa a instalar nossos plugins pelo administrador, o que é uma facilidade, mas quando você começa a trabalhar a nível de código e a Anisa introduzi isso muito bem hoje, você começa a ter menos liberdade para poder alterar o seu projeto, então uma coisa é tu gerenciar o teu projeto a nível de usuário da plataforma em que vocês vão lá instalar plugins, temas, testam, usam o personalizar, trocam o tema e outra é a nível de código em que vocês precisam fazer todas essas alterações na base de código, porque vocês precisam documentar isso, enfim, no git e tudo mais e fazer isso via administrador acaba onerando muito. Então o compositor a gente consegue junto com esse outro cara que é o WPEC, que é o repositório tipo compositor para o WordPress. Então o pessoal criou uma ferramenta que pega todos os plugins e temas que estão no repositório oficial do WordPress e você consegue utilizar ali no compositor. E aqui a gente tem um exemplo então do arquivo composer.json, que a gente precisa então declarar o que é o nome, a descrição, adicionar o WPEC a gente como um repositório de fonte, onde ele vai consultar dados também e depois a gente diz quais são os plugins, temas que a gente quer utilizar. Pegando no próprio repositório, pega o slug do plugin e adiciona com WPEC a gente traça o plugin o nome do plugin. Também a gente pode fazer a instalação do core WordPress com ele. Então qual é a vantagem disso? Se nós estamos controlando o nosso código nós vamos colocar todos aqueles arquivos do WordPress dentro da base de código, ele fica mais limpo e toda vez que a gente atualizar um plugin alguma coisa a gente só troca a versão ali na segunda parte da declaração e a gente não precisa subir todos os arquivos do plugin lá o que acaba deixando o nosso repositório muito pesado e mais difícil de gerenciar. E na parte final do arquivo simplesmente a gente tem que setar algumas informações, onde é que na minha estrutura de arquivos fica o WordPress e onde é que ficam os plugins. Aí outra ferramenta que eu vi que a gente vai falar não deu tempo, então vou conseguir continuar a palestra dela aqui, que é o Grunge, que é um Task Runner, como a gente tem outras alternativas como o Gulp e ele serve para a gente executar tarefas. Nada mais é do que transformar comandos que a gente executaria em linha de comando, criando uma interface mais amigável utilizando JSON, utilizando JavaScript. Então a gente consegue um nível de configuração melhor e de dinâmica melhor para trabalhar. Então o Grunge é o Task Runner oficial do WordPress. Todas as tarefas que tem lá no make, no core do WordPress, são gerenciadas pelo Grunge. E aqui eu tenho um exemplo, então, em um arquivo que é lançado num projeto da Tenup, que é o make, que é tipo um scaffold para temas e plugins do WordPress. Então a gente simplesmente tem que... Eu não vou ficar entrando muito em detalhes aqui, mas a gente faz configurações e carrega as nossas tarefas. Aqui eu tenho um exemplo, então, de uma tarefa que o Grunge executa e nesse caso a tarefa que a gente utiliza para transformar o build em desenvolvimento. Eu crio os diretórios... Esse mkdir é um comando que tem uma configuração lá que diz que cria os diretórios que eu preciso para rodar a minha aplicação. O imagemin faz uma minificação das imagens, então para deixar as imagens mais leves e otimizadas para o web. E o sinlink é porque na nossa estrutura a gente utiliza alguns links de arquivos que estão fora da estrutura do WordPress para dentro da estrutura dele. E assim a gente consegue isolar código que precisa ser customizado e não fica dentro da instalação, como por exemplo o diretório do tema. E aqui uma das tarefas, então, que é o hot, que ali a gente define o que ele verifica quando tem uma alteração no arquivo e automaticamente executa uma tarefa. Então, para facilitar, então, tem um negócio bem legal que é o Live Reload. Então, quando eu faço uma alteração no arquivo de tema, ele automaticamente vai lá e recarrega a página para mim. No caso de CSS ele nem recarrega, ele só troca, eu troquei a cor e ele vai automaticamente lá trocar a cor para o resultado. Então, quando você trabalha em duas telas, por exemplo, cara, isso é fantástico, assim, porque você está trabalhando aqui, desenvolvendo uma tela e olhando o resultado acontecendo sem precisar ir no navegador e apertar F5. E aí a gente entra numa parte mais de infraestrutura mesmo e o Docker, assim, foi mais ou menos paixão à primeira vista, assim, quando eu comecei a utilizar a tela, ele é muito bom, recomendo a todo mundo a utilizar quem trabalha com desenvolvimento, porque ele facilita muita integração de ambiente. Então, ele vem para substituir o Vagrant. Ah, mas então tem que deixar de usar Vagrant e Zadok. Não, utilizo o que vocês acham melhor, mas dão uma olhada nesse cara, porque ele é bem mais leve, não precisa ficar levantando as telas inteiras para o negócio funcionar. Ele simplesmente cria containers, que são um pacote, que vai rodar como um processo lá dentro do Linux. Apesar de ser um que funciona em um processo Linux, ele tem para Windows, para Mac, que funciona super bem. E a gente tem o repositor oficial das imagens do WordPress e lá a gente tem, então, uma paixa que é sobre o Debian, um PHP, FPM, sobre o Debian e sobre Alpine, e também uma versão do WP-Cli em cima do Alpine. Então, é bem barbada lá, a gente consegue copiar as imagens e lá os containers e começar já a utilizar. Lá na empresa, a gente utiliza o FPM com Alpine. Aí, como eu fui falar na palestra da Alessandro, hoje em manhã. Alessandro falou de manhã sobre a utilização de Apache e Nginx FPM. A gente também prefere utilizar essa stack lá e achá-la bem mais performática. Mas aqui, então, a gente tem uma declaração de toda a nossa infraestrutura básica para rodar um WordPress. Então, acrescentando ao Nginx e ao FPM, que Alessandro falou bastante aqui, a gente tem acrescenta um banco de dados, que, no caso, a gente também utiliza a recomendação do WordPress, que é o MariaDB, mas ele funciona também utilizando o MySQL. O MariaDB nada mais é do que um fork da comunidade do MySQL, porque como a hora que eu compro a Sank mantia o MySQL, eles ficaram com medo de ser proprietário ou o projeto e eles optaram por ter uma versão independente. Então, só para exemplo, mas pode ver que ali ele faz todas associações, as dependências, aqui bem embaixo tem que o WordPress depende do banco de dados e o servidor Nginx, ali bem no meio, ele tem um link com o WordPress. Para aqui, a gente tem um arquivo de configuração no Nginx e quando a gente lá passa a configuração do NPM, a gente normalmente configura localhost e a porta 9000, que é a configuração padrão, porque o FPM normalmente roda na mesma máquina que o Nginx, mas nesse caso a gente troca para WordPress e ele automaticamente vai entender que WordPress é um outro computador, um outro host dentro da rede e vai fazer todo esse trabalho. E aí a gente começa a entrar na parte de front-end e lá na empresa a gente atualmente utiliza o stylus, a Anissa falou um pouco aqui do SAS, que é uma outra alternativa que a gente está estudando em migrar em vez de utilizar stylus, utilizar SAS, por causa do suporte, a comunidade do SAS está crescendo, cresceu muito, apesar de eu gostar muito de como a escrita de stylus e tudo mais, eu gosto muito da ferramenta, mas a gente está sentindo que ela está perdendo muito suporte e muitas features que a gente precisa, acaba penando como a integração com o webpack que eu já vou falar um pouco mais, mas todos eles têm a mesma ideia de um pré-processador de CSS serve para que a gente consiga escrever CSS de maneira mais clara e facilitar a manutenção do código. Então aqui a gente tem um exemplo do arquivo stylus e a gente pode ver que lá em cima tem variáveis, então eu posso dizer quase os tamanhos de quebra, os breakpoints para o meu site responsivo e aí ele automaticamente depois vai gerar o CSS com o valor no lugar aí. Aqui a gente utiliza o BAN, que é uma maneira de escrever CSS para poder organizar melhor a ele, separar em bloco, elemento e modificador, não vou entrar em detalhes nisso, mas aí a gente pode ver que a gente consegue estender então, tipo eu quero um drop down menu e um drop down menu active quando ele se torna ativo, então que ele vai ser mostrado. E o legal também desses pré-processador que a gente consegue separar em vários arquivos o nosso código de estilo, o que também facilita a manutenção do que pegar, que nem a gente estava mostrando lá um arquivo CSS de 1600 linhas, é muito mais difícil da gente manter, então a gente cria nesse caso um diretor de componentes que a gente chama de Widgets e cada componente do nosso site está lá dentro e quando a gente precisa mexer a gente já sabe o que é esse cara, é o componente que eu preciso mexer, eu vou direto nele, é muito mais fácil achar o que aonde a gente precisa mexer. E aí uma tecnologia até recente, sinceramente eu não sei o ano que ela foi criada, mas não deve fazer mais que três anos que o webpack existe ou pelo menos que ele se tornou popular e ele é um empacotador de arquivos de front-end, então ele vai fazer várias tarefas que permite a gente gerar artefatos prontos para ser usados tanto em produção quanto em desenvolvimento, então ele permite coisas como utilizar o ES6, que é a especificação de 2015 do Javascript, que enfim traz novas funcionalidades ao Javascript, que se a gente for programar e rodar direto um Javascript normal no navegador, isso provavelmente não vai funcionar, dependendo da versão do nosso navegador e do navegador ou extensões que a gente precisa para isso funcionar e aí a gente usa um cara chamado Babel, que permite fazer essa conversão, aí a gente também, no mesmo cara, a gente utiliza o pré-processador, que no caso a gente utiliza o stylus e ele vai pegar todos aqueles arquivos que eu criei e gerar um arquivo CSS, então a gente só tem que especificar qual que é o meu arquivo principal de aplicação, lá é onde está o meu arquivo principal do Javascript, meu arquivo principal do stylus e a partir daí ele faz tudo e vai largar dentro do meu diretório, que eu especifico ali em Output e ele larga lá e a única coisa que eu preciso fazer lá no meu WordPress da WP inqueue style e WP inqueue script nesses dois caras e está tudo pronto. Aí uma ferramenta que a Anissa já falou aqui, o PHP Code Sniffer, que é fundamental para a gente ter uma qualidade de código integrada, ele tem uma integração com o WordPress Code in Star, então de uma maneira bem simples, vocês instalam via uma instalação alone no próprio computador de vocês ou se não vocês podem utilizar o Composer também para adicionar ele e aí esse arquivo é quem diz o que a gente vai utilizar, o WordPress ele utiliza três regras que é o Core, o Vip e o Core Vip e o Docs, então você pode escolher quase o que é utilizar a gente utiliza o padrão todas e a gente só tira algumas funções do Vip porque são funções focadas do WordPress.com que só utilizando dentro da infraestrutura deles que a gente consegue trabalhar com elas, então a gente simplesmente pode dar um exclude e dizer ok essa regra está me enchendo o saco, eu não quero me preocupar com isso agora, vocês podem pegar e colocar lá dentro dessa relação de exclude e no final eu só digo, eu só digo então quais são os diretórios que eu quero que o Sniffer vá lá e verifica como está o nosso código, ele é bem legal, acabei botando um print aqui dos alertas que ele dá, mas ele diz ah cara, tu não deixou espaço entre os parênteses por exemplo, que é um negócio que a gente vê no padrão do WordPress que está lá na documentação, então o trabalho dele é pegar tudo que está lá na documentação de quais são os padrões que devem ser utilizados no WordPress e verificar se o teu código segue esses padrões, o que é muito bom, eu não quero entrar em méritos, mas é a melhor forma de escrever PHP ou não, de escrever JavaScript ou não, mas é o padrão e está documentado e para mim isso é o principal, eu prefiro utilizar coisas que às vezes não seja a que eu acho a melhor forma, mas ela está lá documentada, se eu for passar para um outro desenvolvedor ele vai saber, vai ter aquela documentação do que eu tenho que documentar alguma coisa porque eu acho legal, isso é um esforço muito maior. E aí para finalizar, então a gente tem duas ferramentas, que é o MailCatcher que ele faz com que ele funciona como se fosse um servidor SMTP, então vocês vão, por exemplo, lá no plug-in, por exemplo, no WP E-mail, WP E-mail, SMTP que você configura, vocês vão botar em endereço localhost 1025 e aí o próprio serviço do MailCatcher, em vez de mandar para algum e-mail, os e-mails que estão saindo do site, ele vai mandar para a própria máquina e aí no endereço localhost porta 1080, vocês vão ter um e-mail com todos os e-mails que foi enviado pelo site. Então para testar o serviço de e-mail, o template de e-mail que vocês estão enviando, não precisa mais ir lá e abrir o e-mail de vocês e verificar se está tudo certo. O próprio serviço faz isso e agiliza muito o trabalho. E para finalizar o ex-debug, que ele é muito mais do que deixar um var-dump bonitinho, os desenvolvedores devem saber aqui, né, tipo, ele troca as cores do var-dump e tudo mais, mas vocês conseguem integrá-lo com o IDE, o ambiente de desenvolvimento de vocês e conseguir trabalhar com breakpoints. Breakpoints é muito importante quando vocês precisam descobrir a causa de um bug que vocês não sabem de onde vem para onde vai, porque vocês conseguem executar o código de vocês linha a linha. Eu sei que eu já estorei o tempo aqui, mas acabou, galera. Muito obrigado e eu estou aberto a perguntas aí que ficam nos contatos. Arroba e depitoing nas redes sociais que eu tenho e realmente eu não tenho Instagram, porque eu sigo o que o Christian fala aí de, cara, não vou ter uma rede que eu não vou utilizar, então eu prefiro não estar lá. Mas galera, muito obrigado. Eu sei que foi um pouco corrido, mas também dá para tirar dúvidas aí. Mais de cinco minutos para dúvidas. Ô, o Christian me trolou, eu acho, cara. Não deu vinte minutos e paléssimo. Ah? Vinte e cinco? Meu relógio está atrasado, então. Com relação à IDE, você recomenda alguma para o desenvolvimento do WordPress? Eu pelo menos gosto de usar o sublime e eu uso algumas ferramentas que facilitam às vezes para encontrar funções do WordPress em si. Você que não abordou tanto esse tema, mas eu já me pergunto, porque às vezes nas agências que eu trabalhava, cada um podia usar um. A galera usava o sublime, tinha gente que usava NetBeans, e meu, tinha até gente que usava Dreamweaver, justamente só para dar um control F e buscar melhor as coisas. Então, gostaria de saber se... Mas essa tendência, se tem alguém usando alguma outra forma diferente. Certo, eu particularmente uso o sublime para front-end e o clipe para back-end, para PHP. Eu não gosto de, tipo, dizer que as pessoas têm que usar tal IDE, mas o importante é que eles sigam o padrão de código. Cara, se rodou o PHP CSS, funcionou eu, o cara é mais produtivo no NetBeans, ou é mais produtivo no VIM, por aí vai, entendeu? Eu acho que isso é o principal, é ele seguir os padrões de código e cada um utilizar o que ele achar melhor. Eu tentei testar o VSCode na corrida, assim, para um projeto, e eu achei que ele consumia muito memória, mas eu tenho curiosidade em testar ele. Eu era viciado em sublime, porque sublime era muito massa, podia instalar teus packages lá e tudo mais. Eu testei Atom, mas eu usava muito sublime. E aí, um amigo meu, o desenvolvedor disse assim, ah, cara, testa o VSCode e tal. O meu background de desenvolvedor é tecnologia Microsoft. Mas eu, pá, larguei isso aí, não quero mais ver Microsoft na minha vida. E aí, um dia, pá, todo mundo está falando que esse negócio vai instalar, cara. A moral da história é que eu abandonei todos, cara. Eu não uso mais sublime, eu não uso Atom, eu não uso mais nada, eu só estou usando o VSCode pela praticidade, pelas integrações que tu tem. Tu tem integração nativa com Git, então, de dentro da IDETO, já pode comitar coisa e tem uma muntueira de extensões. O que tu imaginar? Tem um bundle de extensões para desenvolvimento do Codepress. Tu tem snippets para pegar códigos, trechos de código de Codepress. Ele instala o PHPCS, que é o CodeSniffer. Então, tu já pode desenvolver o teu projeto em Codepress e já ir validando a qualidade do Códepress. Tu está obedecendo todos os padrões de desenvolvimento e por aí vai. Eu não sou entusiasta, eu estou usando há uns 8, 10 meses o VSCode, mas por enquanto, eu não abro mão dele, cara. Com relação ao usar memória, o que eu percebo é que na hora que eu aperto o botão para abrir, ele dá uma pensadinha ali, mas o uso é muito prático. E uma coisa máxima, uma coisa massa que tem dentro dele é a integração com o terminal. Então, por exemplo, se você está usando o GOOP, alguma coisa para automatizar a tarefa, GOOP, Grunt, tu roda lá de dentro um watt, por exemplo, tu pode compilar coisas de dentro da IDETO. Então, não precisa mais de uma janela para o terminal, uma janela para não ser inquieta. Roda tudo lá de dentro. Isso que me chamou mais atenção. Eu sei que dá para fazer com Sublime, eu sei que dá para fazer com Atom, só que ele já tem tudo pronto. Estalou, está tudo ali dentro, tudo funcionando. Boa tarde. Meu nome é Wagner. Eu sou programador back-end em PHP. É a minha primeira experiência com a comunidade de WordPress. Eu não me aventurei ainda no WordPress, e sempre tive um P atrás por causa das boas práticas. Até de parabenizar pela apresentação que abriu minha mente. Eu sempre trabalhei com integração contínua, com Laravel. Então, na integração contínua, rodava lá o GOOP, o Composer, tudo certinho. Provavelmente vou usar a WordPress também, pelo que tu mostrou. Mas a minha preocupação ainda é o banco de dados. Muitas coisas no WordPress ficam do banco de dados. Como é que vocês trabalham, se fossem usar uma integração contínua ou fazer um deploy em vários ambientes, como ficaria o banco de dados e as configurações do WordPress nele? Se eu quiser fazer... que ele fique igual em todos os ambientes, e o ambiente de desenvolvimento sempre estará frente do geomologação e de produção. Essa é uma diferença de sistemas como Laravel. Porque quando trabalha com sistemas normalmente do migra mais, a parte de estrutura de banco de dados tem menos conteúdo, que o próprio sistema vai alimentar depois. São as migrations. O WordPress trabalha muito com conteúdo de tabelas. Tabelas são sempre as mesmas, em série PostMet, em série PostMet, ou Options. E a gente teve um longo papo no almoço justamente sobre isso. E realmente é um dos grandes gargalos para conseguir uma integração continua utilizando o WordPress. Eu tentei até utilizar ferramentas como o MySQL e GIF para conseguir pegar as diferenças, mas aí não bate com chave primária, de tabela e tudo mais, e não rolou. Então, é um próximo passo. Eu sei que tem a Deletion Brands, Deletion Brands, que é a empresa que desenvolveu o WP Migrate DB, criou um serviço chamado MergeBot, que resolve um pouco desses caras aí, mas a licença deles é extremamente alta. E não existe ainda uma solução legal, dizer, cara, use isso aqui para a integração contínua. Eu também sou apaixonado por a integração contínua e deployment contínua. Inclusive, eu estou há uns três, quatro anos estudando, montando o meu ambiente, evoluindo ele. Eu tenho um negócio pronto para publicar. Eu acredito que essa semana saia, eu estava conversando com outros desenvolvedores como dar suporte também para a gente conseguir fazer isso. E eu quero que tudo é uma olhada lá, que a gente trabalha bem forte essa parte e conseguir entregar em produção que a gente tem colocado uma maneira mais rápida possível. E sim, cara, dá para fazer isso com o WordPress também, cara. Obrigado. Só mais uma sobre questão de padrão, de código e tudo mais. Trata o WordPress como uma biblioteca. Tudo que você executar para ele vai funcionar. Se você não funciona lá dentro, é outro ponto. Você tem que se preocupar com o que você está desenvolvendo. Que prática você está usando para fazer o seu desenvolvimento. Claro, se for contribuir para o core, isso é outra história. Mas pegue o seu código e organiza da maneira que você acha melhor e faz as chamadas de funções que tem que fazer. Eu sei que é um pouquinho diferente de não utilizar a PSR4 e tudo mais, mas ele é... Enfim, tem suas chamadas e funciona super bem. Garanto que todas as funções lá estão bem testadas.