 Bom dia, bem-vindos a Track 2 do World Camp Lisboa 2023. Gonçalo Figueiredo é um jovem, como já vão poder confirmar, aliás, elas já podem fazer nesta altura, foi estudar economia e gestão, fez um estágio em entidades relacionadas com finanças e adorou, ou mesmo por isso. Aí decidiu que o caminho para a sua vida era o outro, o caminho da tecnologia, algo que o apaixonava. E então dedicou-se a aprender programação quando estava a desenvolver um negócio próprio e foi auto aprendendo ele próprio a criar projetos web. Hoje em dia um programador é freelancer, trabalha com projetos de WordPress e ao longo dos próximos minutos vai falá-los sobre como podemos garantir a conformidade do nosso código com PHP SEA, Gonçalo Figueiredo. Bom dia, então a PHP é muito importante porque nós, como freelancer em particular, não sei como é que vocês trabalham, mas eu trabalho numa agência, então somos sempre a mudar do projeto, a mudar do site, e o que acontece muitas vezes é isso, é que nos entrega um projeto, um web site já desenvolvido, mas que depois falha em imensos padrões de que é que são boas práticas no desenvolvimento de código. Por exemplo, nesta pequena pedata de código que só tem três linhas, o que encontramos 32 euros e quatro avisos sobre como o código não está de acordo com aquilo que são as boas práticas de escrita de PHP no ambiente do WordPress. Então, qual é a solução? A solução é nós usarmos programas que nos abertam, que nos corrigem, sempre que nós fazemos algum código em não conformidade, e uma dessas programas é o PHP CodeSniper, então é aquilo que é a utilidade em tudo que faz um projeto oficial do WordPress, e aquilo que é, então, um comandado de usar nos nossos próprios, nos nossos próprios websites. Não é o único programante, portanto, em todo o ambiente do PHP nós temos outras frameworks como o Symphony, o Arobelle e etc., e eu sinceramente só tenho experiência nessas duas no WordPress e Symphony, e isso aí que, ah, já começava a fazer a bocada no WordPress, usa texta de fragmenta, PHP CodeSniper, no ambiente de Symphony, no framework de Symphony, no projeto de Symphony, e nós usamos outros programantes, e isso para dizer que, para vos abertar, se por acaso vocês forem a avançar no outro tipo de frameworks, também tem que procurar quais são as boas práticas, quais são as famílias que são úteis nesses ambientes. Então, para nós usarmos o PHP CodeSniper, o que é que nós precisamos? São duas coisas básicas, não é? Que, provavelmente já temos, por estar a desenvolver um projeto em WordPress, que é a PHP, temos que ter o PHP instalado na nossa máquina, e temos que ter também o Compolt, que nos permite instalar parkas, instalar dependências, etc. São as únicas coisas que nós precisamos. O objetivo nesta tal, que é dar-vos um bocadinho todo o processo do inicio ao fim, de como vocês podem configurar o projeto para vos ajudar a se fazer essas boas práticas de código. Então, começando no início, o primeiro coisa que nós vamos fazer é criar o Compolt, portanto nós iniciamos o projeto com o Compolt, podemos coger este código, o Compolt da Init, e ele tem uma espécie de tutorial interativo, onde vai fazendo perguntas para nós configurarmos o projeto, ou podemos iniciar nós próprios, simplesmente queríamos um ficheiro chamado Compolt da Seitan, e abrimos um jeito, não é? A primeira coisa que nós fazemos é instalar o PHP CodeSniper, portanto, que pode ser instalado só para como um requisito de desenvolvimento, e logo ele revisita o Compolt da Seitan, e se aposente, utiliza esta parkas, esta dependência, não é? E ele faz essa atração no Compolt da Seitan, e depois instala naturalmente esta tal biblioteca, esta tal parkas, que inclui o PHP-CX, PHP-CX, CodeSniper, que é um executável, portanto nós vamos usar para garantir que o nosso projeto saia em conformidade. Nós usamos, colocando com o PHP, portanto, nós fazemos é que o PHP apontamos onde está o nosso executável PHP-CX, e colocamos o nome do ficheiro que nós queramos analisar, e o afegamento dá-nos um pequeno colatório de quais são os ergos, portanto, não termina o ficheiro encontrado 35 ergos, quatro vidas, e depois ele vista e os ergos e avisos, portanto, é assim que nós somos abertados dos ergos e avisos que nós temos no nosso protocolo. Este executável tem um conjunto de opções, portanto, estas opções podem ser úteis, dependendo do qual for o nosso objetivo, e uma das opções é nós vermos, se nós colocamos aqui o I aparente do executável, nós vemos quais são os standards que estão incluídos, que estão inseridos no ambiente do PHP-CX, e se nós encontramos aqui nós temos os standards clássicos do PHP, não temos nada relacionado com o WordPress, mas nós sabemos que o WordPress tem os seus próprios standards, são um carinho de vez um carinho ou são mais específicos do que o PHP em geral. Então, nós temos que inserir aqui os standards do WordPress para nós podermos utilizar-os no nosso projeto. Como é que fazemos? Nós, os standards do WordPress também estão numa package, portanto, tal como nós importamos o PHP-CX, também vamos importar os standards do WordPress, e então, no nosso projeto, dentro da pasta vendor, agora vamos ter vários standards específicos do WordPress. Os standards são diferentes no tipo de avis e no tipo de análises que eles fazem. Nós temos o Core, que é o principal standard, temos o WordPress Docs, que faz um conjunto de análises sobre a documentação de nossos códigos, de nossas funções, de nossas quadros, etc. Temos o WordPress que engloba esses dois, o Core e o Docs, que é o típicamente utilizado, e depois também temos o WordPress extra. Existem, no ecossistema, outros standards. Existe, por exemplo, do WP VIP, que não sei se vocês conhecem, mas é o servidor oficial do WordPress. Eu também tenho a sua própria biblioteca, a sua própria conjunto de regras de coding standard, mas e esses são aqueles, digamos, mais oficiais e que estão mais altamente disponíveis para a nossa utilização. E isso, só para dizer, isso também está disponível no seu repositório do GitHub. Então, se nós instalámos, como nós vimos anteriormente, se nós instalámos o WP CS, nós já temos esse conjunto de regras na nossa pasta vendor, no entanto, isso não é suficiente para ele estar disponível no executável PSP CS. Então, depois nós instalarmos, nós pesquisarmos por os coding standards que estão no ambiente PSP CS e ainda continuam a ser os básicos do PHP. Então, para nós, inserimos o WordPress, nós instalamos outra package com o Composer, que é essa, que fica com o CINIFER. No fundo, o que essa package faz é vai procurar, todos os standards estão instalados na nossa pasta vendor e vai inserir-los no ambiente PHP CS. Então, como nós temos o WordPress na pasta vendor e agora já inclui, já inclui as standards no PSP CS. Portanto, já estão disponíveis para nós utilizarmos, sempre que agora nós cogemos, mas o que está no PSP CS, não terminamos de fechar, na verdade, não terminamos de fechar uma pasta, já podemos especificar, ok, eu quero que vocês, quero que o PSP CS, anuíso o meu código, de acordo com as melhores práticas WordPress, WordPress Core, DOS, etc. Então, é só isso curiosidade, não vou pedir que ninguém me exponda. Quantos ergos e avisos nós podemos encontrar na classe do Epic Query? Portanto, uma classe, muito utilizada no WordPress. Podemos achar que seria zero, portanto, seria ideal, mas é verdade que encontramos cerca de 100, 49 ergos e 43 avisos. A questão que ocorrem com isso é porque, se nós formos ao detalhe de quais são esses ergos e avisos que nós encontramos nessa classe, nós vemos que muitas delas estão avisos sobre o lógico, sobre o boas práticas de segurança, etc. O que é que significa? O que significa que o PSP CS não é só o outro, para nós vermos o estilo do código, para nós conseguirmos standardizar o estilo do código, mas também para nós garantirmos que estamos a fazer comparações mais específicas, que nós não estamos a fazer o override dos variáveis iguais do WordPress, prontos, várias questões mais relacionadas com a lógica, mais importante para em termos de segurança, em termos de, para não causar bugs, etc. Isto, então o que é que nós temos até agora? Nós temos o executado a PHP CS que nós podemos utilizar, incluímos no PHP CS o conjunto de regras do WordPress, no entanto, nós próprios também podemos definir nossas próprias regras, por exemplo, nós podemos definir que as arrays, em vez de a pessoa ter que escrever array, depois abrir parênteses, fechar parênteses, podemos definir que, ok, no meu estilo de código, as arrays podem ser iniciadas como parênteses regras, ou seja, dependendo um bocadinho do estilo que a pessoa pretende para o seu código. E como é que nós fazemos isso? Fazemos ao adicionar um fichero a nosso projeto, PHP CS e GML, é um fichero que vai configurar as regras analisadas ou as regras utilizadas pelo PHP CS para analisar o nosso código. E depois é aqui que nós, o fichero é aqui que nós definimos quais são as regras. Em primeiro lugar, nós estendemos as regras que nós tendemos utilizado, portanto, vamos instaurir no nosso consumo de regras, no nosso loop set, vamos incluir as regras do WordPress Core, vamos incluir as regras do WordPress Talks, portanto, elas vão estar inseridas. E depois podemos configurar as regras que existem já nesse consumo de regras. Por exemplo, se nós sabemos que o servidor que o nosso website está a ter corrido com PHP 7.1, nós sabemos que nós configuramos isso no PHP CS de forma a não recebermos avisos, olha, essa função que está a utilizar ou esse padrão que está a utilizar só está disponível a partir do PHP 5.6. Isso não nos interessa, porque nós sabemos que o nosso servidor está a ter corrido com 7.1, 7.3, 7.4, então logo excluímos essas avisos que não estão resolvendo para nós. Outro caso de uso bastante comum é o definir o text domain, portanto, em tudo que sejam traduções, nós podemos dizer, ok, o meu text domain que eu sou a utilizar é o MySight, então a partir daí o PHP 7 vai verificar se nós estamos corretamente a definir a utilidade do text domain corretamente ou não. Isso é como nós configuramos regras que veem do consumo de regras que nós estamos a estender, nós também podemos excluir ficheiros ou pastas ou um consumo de pastas ou ficheiros determinados da regra, por exemplo, e eu, tipicamente, defino as minhas abstracts ou qualcos meus abstracts em ficheiros como estados por abstract, por exemplo, abstract, product ou abstract, qualquer coisa, e então isso como eu vai contra o padrão típico do WordPress, o que eu faço é tudo o que seja abstract, já não quero que seja validada esta regra sobre nomes de ficheiros, portanto nós podemos, temos esta flexibilidade para dizer o quando é que um determinado regras é utilizado ou não e depois as opções de opções de consumidação são enormes, portanto a pessoa pode, de facto, garantir que o PHP 5F não está a limitar a pessoa para fazer o que pretende, para utilizar os fios de qual que a pessoa pretende, mas sobretudo pode definir que que é um fragmento para garantir que o meu estilo está a ser respeitado. As nossas regras próprias, que nós estávamos a ver até agora, as exclusões, etc, configurações, podem ser colocadas pro projeto a projeto, mas também podemos nós próprios criar o nosso apacados, na mesma forma como o WordPress tem apacados de nós também podemos criar o nosso apacados e utilizá-los em diferentes projetos e podemos tornar isso público ou podemos tornar privado e importar no projeto através de esses sete ou seja, eu posso definir uma coisa de regras que eu quero que sejam por acaso de todos os projetos e posso fazer com que o compositor vá inserir essas regras na minha pasta de vendor, pronto, de uma forma privada, né, não tem que partilhar com o mundo. Isto, pronto, e configurar isto é um bocadinho, portanto temos que conferir a guita, etc, não vou por dentro disso, mas só para vocês saberem que isto é possível e que pôs para algum trabalho. Nós até agora temos corrido os relatórios analisados com este comando, né, para a API, depois apontamos onde está o API SPCS, no entanto é um bocadinho laboroso, portanto o que eu faço sempre é num composer, defino um script que eu agora semei lind e defino, ok, sempre que eu coloco o composer lind e ele vai analisar tudo o que está dentro desse passasplugging e tudo o que está dentro no meu tema, né. Portanto, é um bom atalho para a pessoa conseguir analisar o projeto inteiro numa forma fácil e rápida. Uma questão importante, portanto o API SPCS é importante, não só em projetos novos, mas como disse no início, muitas vezes nós recebemos projetos web sites de outros desenvolvidos por outros programadores, de outras agências e quando nós queremos inserir o API SPCS, definir o coding standard, sai tudo a vermelho, né. Portanto, quando o outro projeto não corresponde às boas práticas, depois é um bocadinho difícil nós conseguimos definir as nossas. Então, uma fragmenta importante é nós conseguirmos localmente dizer nesse pedaço de código por favor ignore esta regra específico ou todas as regras em geral e isso pode ser feito link a link, por exemplo, aqui ou pode ser feito como um bloco de código, né. Portanto, a partir daqui ele vai desativar esta regra e depois nós voltamos a ativar. Portanto, todo o código que está no meio destes dois comentários não é analisado, nós podemos finir isso, não é analisado nenhuma regra ou não é analisado alguma regra em específico. E isso começava a dizer é importante porque se nós estamos integrando nós estamos fazendo de facto um código que já que veio de trás então nós podemos incrementar o ambiente Pronto, em primeiro lugar nós ativamos todas as regras num bloco grande de código e depois vamos melhorando, melhorando e vamos diminuindo o âmbito de ativação. Por último, quase isso até agora nós temos visto como qualquer o PHP se é spontaneamente, né. Portanto, nós correndo no formato do Ibrada mas um fragmento importante é nós configurarmos o PHP 7 no próprio IDE portanto eu uso o VS Code e dizem várias plugins que integram com o PHP CS e eu uso esta PHP Sniper com uma pequena configuração no plugin, no Prozeta a partir daí à medida que eu vou escrevendo e ele vai melhorar na sublinha algo que não é e quando nós colocamos o cursor em cima da sublinha ele diz imediatamente qualquer regra que não está a ser respeitado e isso é fundamental porque estamos a ser abertados à medida que vamos escrevendo o código e facilita imenso o trabalho de garantimos que o nosso código corresponde às boas práticas por último o PHP CS também tipicamente todos os fragmentos vêm com um PHP CVF que é um formato portanto é um executable que automaticamente quando nós corremos o fato é um terminado ficeiro e ele vai automaticamente reformatar o ficeiro para corresponder a estas boas práticas vamos supor que nós temos demasiados espaços aqui definidos como diz a bocado e ele vai abortar para isso se eu quero que a correção seja automática ao invés de estar a mover este espaço com o PHP CVF e ele conquise isso para automaticamente é importante abortar que as correções naturalmente são muito conservadoras portanto nenhum afogamento iria tentar corrigir todas as regras e potencialmente cobrar o nosso código portanto tipicamente este afogamento só ocorre de informação coisas que claramente não têm qualquer impacto sobre a lógica do programa pronto isto é como nós ativizamos a PHP CS no projeto agora vou só falar duas mais coisas que é como incluir no github através do processo com o Continuous Enterprise Continuous Development e depois vou falar sobre o editor config portanto no github e no github é muito semelhante portanto o que nós fazemos partindo destes posts que nós temos este script que vai fazer a nave do código todo no Compose Edition a única coisa que eu tenho que fazer é criar um fissério de configuração de um workflow portanto um workflow é algo que é corrido em um determinado trigger é quando nós queríamos um público apontar para um determinado branch nós queríamos este fissério de configuração e isto para já é tudo Power Quart portanto é como a maior parte dos workflows isso é muito parecido com quando nós configuramos Docker não sei se vocês trabalharam muito com Docker mas fundamentalmente o que nós vamos fazer é especificar um ambiente, uma máquina não é um servidor e configurar de forma a concluir um determinado executável, um determinado processo no nosso fato ao nosso código portanto nós vamos especificar aqui a máquina que pretendemos que o github corre é um input e aqui começamos a definir os passos que nós queremos depois de esta máquina estar constituída o Ubuntu queremos que o github corre e as passos que façam esta máquina em primeiro lugar vamos instalar como se fosse no nosso próprio computador para instalar o PHP do apquete instalar PHP, é o que nós precisamos e a segunda coisa que nós precisamos é o Composer portanto vamos à documentação do Composer vemos como se instala e colamos aqui portanto esta é a forma como se instala o Composer instalamos as pendências portanto tal uma vez que o github tenha certo o nosso código e ele sabe que dependências devem instalar, estão no Composer de beta portanto instalamos as as pendências e logo pedimos para coger o script de o int que é o canal do nosso código se passar tudo ok tanto não há nada a ser abertado se não passar, espalhar significa que existe algum problema do nosso código que deve ser alguma boa prática que não está a ter correspondido e nós temos deverão estar a ter visto isto no github em alguns projetos este pequeno relatório este Brands pode ser fundido no target branch porque todas as analises passaram tanto todos os testes passaram por último, e este é muito rápido editor config o que estaria nesta apresentação porque novamente é algo extremamente fato e caso de imensos quando nós estamos a trabalhar em equipa porque o fundamento que faz é garantir que todos os nossos github os outros os outros estão definidos as mesmas regras para a formatação automática dos fichores o que nós temos a fazer é definir um fichore chamado editor config definimos as regras para os fichores, portanto, em primeiro lugar e os testes que o fim fica, todos os fichores vão usar as regras e o mais importante é definir o end of line nós temos programadores que trabalham com windows os programadores que trabalham com macOS ou windows e o mais importante para garantir que não existem problemas com o github é definir o end of line mas depois isto aplica todos os fichores e depois podemos ser mais específicos para PHP, CSS JavaScript para os fichores para os fichores ter o fichore não é suficiente naturalmente isto é o nosso definimento de configurações mas depois temos que ter uma forma de fazer com que o Nautide realmente interprete o fichore e apuica essas regras portanto, no vietco novamente é o que eu uso existe este plugin e existem outros também basta instalar e imediatemente o IDE e imediatemente o vietco faça qualquer fichore vai aplicar as regras nós definimos na configuração e espero que isto tenha sido útil o principal mensagem é começar a usar a PHP CSS fácil parece uma coisa difícil no início tem comando, sem biblioteca muito sinceramente está todo expoícito nesta apresentação e mesmo um projeto existente e torna-se um bocadinho mais compoer nós temos que tentar integrar a PHP numa coisa que não foi construída nas minhas práticas mas pode ter feito incrementalmente é importante fazê-lo e o principal exemplo é o que eu vou vender um bocadinho para a gente são as minhas competências como disse no início tem o trabalho em WordPress mas também o trabalho em Symfony, Angular e etc portanto se alguém tiver algum projeto se eles tiveram mais gente e etc por favor contactem-nos à procura de novos clientes e se estiverem interessados em investir se forem ao site tem lá um guia todo como investir e mandem-me não obrigado eu soudinho para questões de apenas uns 3 minutos alguma questão? um colega que é o caso disse que ia disponibilizar no site pessoal de ele e foi uma boa ideia portanto se guardarem algum Kvf.com alguns próximos dias vou colocar uma questão respondida mais alguma questão que estejam equacionar nesta altura para colocar aqui a Gonçalo este processo de realização que é feito sempre em cada projeto fazes quantas vezes dependendo da dimensão do projeto mas com regularidade eu como inclui aqui na apresentação eu o coloco até configuro sempre o GitHub para definir isso automaticamente e também configuro o meu VSCode para abertar uma medida que vou fazendo portanto é contínuo eu coloquei aqui os comandos a forma como a pessoa pode executar os comandos porque também é o outro ter calculatório mas é contínuo e acho que tenho que ser ser abertado à medida que vamos escrevendo o código e se é um porque algum código vai ser fundido em um determinado brand que seja importante e tem que ser analisado quando pegas em algum projeto que já está desenvolvido vai-se fazer uma avaliação que estamos a encontrar a muito tempo a questão por qual os projetos estão entregos a nossa agência é também por causa disso para encontrar programadores que o fundamento que fazem instalar plug-ins para fazer tudo funcionário depois no final do dia o site está cheio de bugs e muito pouco performance e acabamos por ter que entrar lá e entrar amanhã e apoiar as boas práticas e você agradecer obrigado bom salve querido