Forem: Thiago Luna

Liderando em tempos difíceis

Thiago Luna — Fri, 29 Sep 2023 10:46:53 +0000

“O mercado de TI cresceu 65% em 2020…”
No período da pandemia centenas de notícias como essa foram veiculadas na internet mostrando uma nova realidade no mercado de TI.

Com isso, muitos times cresceram, novas squads foram formadas e novos líderes contratados para desempenharem um papel de conexão e influência alinhados à visão do negócio da empresa.
O momento era positivo para as empresas que cresciam, para os profissionais que tinham um emprego garantido em meio ao caos da pandemia e para os líderes que, em um ambiente corporativo movitado pelo crescimento, encontravam um ótimo clima organizacional que os ajudava bastante no desenvolvimento de suas atividades.

O tempo passou, muta coisa aconteceu, muita coisa mudou e, infelizmente, as notícias também mudaram. Passamos a ter notícias dos temidos Layoffs.
Segundo um estudo feito pela Layoffs.fyi, 24.151 mil funcionários foram demitidos nos primeiros 15 dias de 2023 em 91 mil empresas de tecnologia ao redor do mundo.
Agora o clima é outro. Mudou completamente. Para os líderes que continuaram em seus empregos ficou a grande e difícil responsabilidade de manterem os times focados, engajados e motivados. Mas como?

Influenciando Positivamente
Servindo de modelo, influenciando de maneira positiva seus liderados, seja através do alinhamento de expectativas tornando as novas regras e fazendo novos acordos de forma explícita, ou através da segurança psicológica, gerando um ambiente tranquilo, livre de práticas nocivas e adequado ao trabalho.

Sendo Solícito
Observando as necessidades das pessoas a sua volta procurando atendê-las.

Tendo Iniciativa
Analisando as circunstâncias e atuando de forma a promover resolução.

Agindo com Criatividade
Não se acomodando diante das situações, sempre buscando fazer o que ainda não foi nem tentado.

Bom Humor Sempre
Independente da situação pessoal/profissional, o líder precisa promover positividade.

Tendo Empatia
Compreender a forma de pensar e agir do outro, gerando uma liderança mais humanizada, promovendo um ambiente empático onde as pessoas se sentem livres e seguras para expressarem seus sentimentos sem a preocupação de serem mal interpretadas.

Motivando
O bom líder mostra àqueles que estão desmotivados que eles podem ir além de suas expectativas.

“Ser um bom gestor não significa ser o grande amigo da turma ou o linha dura da equipe. Um bom líder é aquele que consegue manter seus liderados motivados e traz os resultados necessários.” Lucas Oggiam

Que este pequeno artigo possa nos ajudar a sermos bons líderes formais ou informais, influenciando os demais, seja por causa da confiança estabelecida com os colegas no dia a dia, pela capacidade técnica, história e exemplo de vida, ou pelo comprometimento com o trabalho.

Que possamos ser agentes de mudança, promovendo um ambiente seguro e saudável.

Aproveito para deixar um forte abraço para meus/minhas colegas que infelizmente viveram essa experiência de Layoff. Tenho toda certeza de que logo logo estarão de volta no mercado, pois, são excelentes profissionais.

Há braços e até o próximo artigo!

Thiago Luna - Linkedin

SOLID no Laravel - Aplicando princípios e boas práticas para entregar melhores soluções.

Thiago Luna — Wed, 03 Nov 2021 13:22:05 +0000

Olá pessoal!

Neste artigo, trago um assunto bastante importante e presente no nosso dia a dia como desenvolvedores e que, inclusive, tem sido bastante requisitado em entrevistas de emprego, sobretudo para as vagas de Sênior: Princípios do SOLID.

SOLID é um acrônimo para os 5 princípios da programação orientada a objetos e design de código teorizados por Robert C. Martin (Tio Bob): Single responsability; Open-closed; Liskov substitution; Interface segregation; Dependency inversion.

Existe bastante conteúdo na internet e meu objetivo neste artigo não é explicar detalhadamente cada princípio, mas mostrar alguns exemplos de como podemos usá-los para tonar nosso código de fácil entendimento, testável e de fácil manutenção.

Vou utilizar nos exemplos o PHP usando o framework Laravel.

Vamos começar com o S

1. Princípio da Responsabilidade Única

Este provavelmente é o mais conhecido. Diz que toda entidade, toda classe ou todo método deve fazer apenas uma tarefa, ter apenas uma responsabilidade, apenas uma razão para ser modificado.

No Laravel, ao invés do Controller fazer todas as tarefas, ele deve ser responsável por controlar a requisição, recebendo os parâmetros, chamando o método necessário de classes externas e, então, retornar o resultado ou fazer um redirecionamento.

E um bom exemplo disso é não ter os Controllers carregados de tarefas.

Na imagem acima, podemos observar 2 métodos de um Controller, onde ambos têm apenas a responsabilidade de distribuir as tarefas. No caso da function quotation, a responsabilidade de validação dos dados é do FormRequest. A tarefa principal fica sob a responsabilidade do método getQuotatiion que está em um serviço (classe externa). O envio de email para o usuário fica sob a responsabilidade de um outro serviço externo disparado por um Job. E, por fim, o Controller retorna para a view uma mensagem.

Dessa forma separamos as responsabilidade e não temos mais um Controller enoooorme. Outra vantagem é termos um código menos complexo e mais fácil de entender e manter.

O seguinte é o...

2. Princípio do Aberto/Fechado

Este princípio diz que entidades de software, sejam elas classes, módulos, funções, etc, devem ser abertas para expansão e fechadas para modificação. Um bom exemplo disso são as bibliotecas ou os pacotes que instalamos via composer. Tudo que for instalado na pasta Vendor permanece na pasta Vendor e não pode ser modificado.

Como exemplo: digamos que eu instalei um pacote para conversão de moedas e que em algum momento vou precisar da descrição da moeda. Na imagem ao lado temos a classe Currency que possui somente 1 atributo. E agora? Altero a classe na pasta Vendor? #sqn

De acordo com este princípio vamos estender a classe Currency para, aí sim, termos a liberdade de fazer o que for necessário.

Agora podemos definir uma descrição para a moeda através dessa nova classe que estendeu a classe original.

Com isso, permanecemos fieis a este princípio, mantendo a classe Currency fechada para modificações e aberta para expansões.

Vantagens? Sim! Facilidade para criar novos comportamentos e dar manutenção.

Próximo princípio:

3. Princípio da Substituição de Liskov

Este princípio criado pela Barbara Liskov pode ser um pouco difícil de se entender no começo, mas podemos dizer que as classes devem ser intercambiáveis. Se temos 2 classes fazendo a mesma coisa, um cálculo, por exemplo, devemos ser possíveis de trocar uma classe pela outra sem parar a aplicação. Podemos, então, pensar que todos os parâmetros, tipos de retorno e exceções esperadas devem ser idênticos em ambas classes.

Neste exemplo, temos 2 classes que calculam a taxa para pagamento em diferentes meios de pagamento. Segundo Liskov, podemos chamar o método calculate() de qualquer classe passando o mesmo parâmetro (float) e obtendo o mesmo retornor (float) sem quebrar a aplicação.

Para a aplicação deste princípio, Type Hinting e Return Type são fundamentais, permitindo que as classes sejam verdadeiramente intercambiáveis.

As vantagens aqui são código facilmente reutilizável, mais fácil de se ler, entender e manter.

Chegamos no 4º princípio:

4. Princípio da Segregação de Interfaces

Vemos aqui que classes não devem ser forçadas a depender de métodos que não são utilizados. Já teve que declarar algum método e colocar apenas um "//" ou comentário dentro dele só porque precisou usar um outro método de uma Interface implementada na sua classe?

Pois é, este princípio orienta a segregar, separar métodos de uma mesma interface em novas interfaces com métodos específicos.

No exemplo acima, podemos observar que a classe ReportActivatedCurrencies precisa apenas usar o método getData() da interface ReportInterface. Contudo, é obrigada a declarar o método download também, mesmo sem utilizá-lo.

“Muitas interfaces específicas são melhores do que uma interface única.”

Já no exemplo abaixo, veremos como o princípio Interface Segregation trata essa questão.

Agora temos 2 interfaces distintas, cada uma contendo seu próprio método, e a classe concreta que precisar utilizar algum desses métodos implementará apenas a interface que contém o método.

O próprio Laravel utiliza bastante este princípio, como por exemplo as interfaces Jsonable, Responsable e Htmlable.

E por fim, o 5º:

5. Princípio da Inversão de Dependência

Basicamente vemos aqui que não devemos depender de implementações, mas sim de abstrações, pois elas sofrem bem menos alterações ou praticamente nenhuma. Na prática, as classes devem depender de Interfaces e não de outras classes concretas.

Na imagem abaixo, podemos observar um exemplo da classe concreta CurrencyService que, através da injecçao de dependência, depende de uma interface, que nesse caso é o CurrencyRepositoryInterface.

Os métodos dessa interface utilizam o Eloquent ORM para operações que envolvem acesso ao banco de dados.

Se por algum motivo eu tenha que utilizar o Doctrine, ao invés do Eloquent, basta apenas criar uma nova classe concreta com os métodos utilizando o Doctrine e, no Laravel, alterar o bind da interface com essa nova classe concreta.

Dessa forma, com esse princípio aplicado, a classe CurrencyService não sofrerá nenhuma alteração. Tudo continuará do mesmo jeito, pois ela depende da Interface e não da classe concreta que implementa os métodos. Um detalhe é que as 2 classes concretas (CurrencyEloquentRepository e CurrencyDoctrineRepository) precisam ter os métodos exatamente iguais.

Neste exemplo vemos também o Repository Design Pattern em ação.

Conclusão

Seguindo esses princípios podemos entregar um código mais adaptável às mudanças de escopo, de fácil entendimento e manutenção, testável e bem mais reaproveitável no futuro.

Quando codamos precisamos perguntar a nós mesmos 2 coisas: quem e como alguém usará meu código no futuro? O que pode mudar no futuro?

Digamos que daqui a algum tempo seja preciso alterar o gateway de pagamento da empresa X para a Y. A implementação já feita está de fácil entendimento? Será fácil para outro Dev alterar o meio de pagamento?

Os princípios do SOLID nos ajudam com isso.

No entanto, como o próprio Tio Bob disse, vale ressaltar que esses princípios não são uma regra, mas sim um norte que contribuirá para a entrega de um bom código.

"Os princípios SOLID não são regras. Eles não são leis. Eles não são verdades perfeitas. São declarações na ordem de "Uma maçã por dia mantém o médico longe." Este é um bom princípio, é um bom conselho, mas não é uma verdade pura, nem uma regra.” - Tio Bob

E com isso chegamos ao final deste artigo com exemplos práticos do SOLID e espero que tenham te ajudado a entendê-lo um pouco melhor.

Há braços e até o próximo artigo.

Thiago Luna - Linkedin

Xdebug 3 no PHPStorm com PHP 7.4

Thiago Luna — Thu, 23 Sep 2021 21:56:08 +0000

Olá Devs! Muitos bugs? Que bom que temos o Xdebug para nos ajudar!

Existem vários tutoriais mostrando como configurar o Xdebug em diferentes versões do PHP no PHPStorm.

Nesse artigo trago um Direto ao Ponto para configurar o Xdebug 3 no PHPStorm com PHP 7.4 e Docker - Linux.

Primeiro, vamos instalar o xdebug no container.
Em seguida, configurar o PHPStorm.

Vamos lá!

1- Criar o arquivo docker-php-ext-xdebug.ini.
Pode ser na raiz do projeto ou em alguma outra pasta de sua preferência.
Entrar no container e rodar find / -name xdebug.so para saber o path certo e colocar no zend_extension conforme abaixo:
[xdebug] zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so xdebug.mode=debug xdebug.client_port=9003 xdebug.start_with_request=yes xdebug.discover_client_host=0 xdebug.client_host=host.docker.internal

OBS: Se tiver algum problema com o Xdebug não conseguir se conectar ao host.docker.internal, verificar qual é o ip da máquina local rodando o comando ifconfig (sudo apt install net-tools) e colocar esse ip no xdebug.client_host

2- Adicionar no Dockerfile:
# Xdebug RUN pecl install xdebug && docker-php-ext-enable xdebug

# Conferir os paths corretos da pasta php dentro do container ADD docker-php-ext-xdebug.ini /usr/local/etc/php/conf.d/ RUN echo "include_path=/usr/local/etc/php/conf.d/xdebug.ini" >> /usr/local/etc/php/php.ini

OBS: Entrar no container e rodar php --ini para saber os paths certos e colocar nessas linhas acima.

3- Adicionar no docker-compose.yaml a variável de ambiente dentro do serviço que vai rodar a aplicação:
extra_hosts:
- "host.docker.internal:host-gateway"
environment
- PHP_IDE_CONFIG=serverName=XdebugServer

Agora vamos seguir com as configurações no PHPStorm

4- Iniciar no PHPStorm a configuração clicando no combobox que fica do lado esquerdo do ícone Play.
Em seguida seleciona a opção Edit Configurations...

Na tela seguinte, em Configuration > Server, clicar no ícone … para adicionar um novo server.

5- Preencher conforme imagem abaixo:

A Port deverá ser a que é usada no browser para rodar a aplicação
No caso da aplicação ficar dentro do container na pasta /var/www, a mesma deverá ser usada no path mappings.
Em File/Directory > Project files > path do projeto, na coluna Absolute path on the server adicionar o caminho da pasta www de dentro do container conforme imagem acima.

6- Após essas configurações, voltar para a tela da Imagem 2
Clicar em Validate.

O resultado esperado deve ser conforme imagem abaixo:

Com isso, o Xdebug deverá funcinar.

Clique aqui para ver um exemplo de container configurado como descrito neste post.
Use e abuse!

Agradeço ao meu parceiro de Pair Programming Juliano Fritz que me ajudou a montar essa configuração.

Há braços e até o próximo Direto ao Ponto!

Thiago Luna - Linkedin

Otimizando com Doctrine - find vs getReference

Thiago Luna — Mon, 02 Aug 2021 04:03:52 +0000

Nesse post quero compartilhar com vocês uma maneira de otimizarmos uma busca utilizando o ORM Doctrine.

find()

Considerando uma aplicação que trabalha com Categoria e Post, se eu tiver que consultar uma determinada Categoria para relacioná-la com Post, posso usar o find() como vemos abaixo:

Colocando uma lupa nessa busca, podemos observar o seguinte resultado:

Até aqui, tudo certo. O resultado trouxe todos os dados da entidade Categoria desejada (id=1).

O ponto é que para relacionar essa Categoria a um Post, preciso apenas do id dela. Os demais campos, bem como as informações de posts, association, collection e outros são desnecessárias para este caso.

getReference()

O Doctrine nos oferece um outro método chamado getReference().

Olhando agora para o resultado gerado pelo getReference(), vemos também a entidade Category, porém, tendo apenas o campo id hidratado.

Ou seja, o getReference é bem mais rápido que o find()!

E isso é muito útil em casos onde é preciso ter apenas o id da entidade para realizar uma ação, como por exemplo a deleção, onde não preciso ter no resultado da busca todos os campos da entidade, mas apenas o id.

Comparando o tempo de resposta entre o find() e o getReference() em nosso ambiente de desenvolvimento não vamos perceber praticamente diferença alguma.
Contudo, no ambiente de produção, que certamente existem entidades com muito mais campos e relacionamentos e dezenas de centenas e até milhares de registros, essa diferença será significativa.

Com o getReference() o processamento é menor, o uso de memória é menor, o aceso ao banco de dados é muito menor, pois o Doctrine se preocupará em pegar apenas o id.

E isso é crucial para a aplicação que está rodando em produção. Imagine uma página que tem uma quantidade enorme de acessos simultâneos que realiza essa busca...

Outro benefício está no custo. Se a aplicação está hospedada em algum Cloud Service Provider como o GCP, AWS ou Azure, usar menos processamento e memória significa ter uma conta menor no final do mês para pagar.

E assim termino este post. Usei exemplos bem simples para demonstrar o getReference() e o benefício de usá-lo nos casos em que só precisamos ter o id da entidade.

Agora é só por em prática!

Há braços e até o próximo artigo.

Thiago Luna - Linkedin

Mensageria com Apache Kafka

Thiago Luna — Thu, 25 Feb 2021 12:42:18 +0000

Nos dias atuais, com tanto recurso tecnológico disponível, cada vez mais sistemas computacionais geram dados e trocam esses dados entre si, ou seja, os usuários dos sistemas são os próprios sistemas.

Um exemplo seria um sistema de monitoramento de frotas de caminhão.

Vamos imaginar um caminhão que tem instalado em seu painel um Sistema A que fica enviando/publicando sua posição de latitude e longitude a cada 5 segundos para um Sistema B. O Sistema B, por sua vez, fica recebendo essas mensagens e marcando no mapa onde o caminhão está.

Agora, se o Sistema B parar de funcionar por alguns minutos ou horas? Fatalmente, quando ele voltar a funcionar não vai conseguir saber por onde o caminhão passou e pode, provavelmente, ter causado algum problema no Sistema A que, por não conseguir falar com o Sistema B, também deu erro e parou.

Uma das maneiras de resolver essa questão é ter um Broker, ou seja, um intermediador entre esses 2 sistemas, que vai receber essas mensagens do Sistema A e mantê-las guardadas até que o Sistema B as consuma. E é aí que entra o Apache Kafka.

Apache Kafka, um Message Broker de Respeito!

Com esse Broker, agora, o Sistema A envia seus dados de localização através de mensagens para o Kafka e o Sistema B as consome. E se ele cair novamente, as mensagens permanecerão no Kafka até que ele volte e as consuma, podendo assim marcar no mapa todo o trajeto feito pelo Caminhão.

Então, uma das principais atividades do Apache Kafka é ser esse Broker.

Basicamente, o Kafka trabalha com streaming de dados, com o conceito de Tópicos, onde existe o Produtor e o Consumidor. O Produtor envia suas mensagens para o Tópico e elas ficam lá guardadas até o Consumidor ler esse tópico e pegá-las.

Mas o Kafka vai muito além disso. Na verdade existe todo um ecossistema funcionando, com vários recursos disponíveis.

Alguns Recursos

- Armazena Mensagens já Consumidas

O Kafka não elimina as mensagens que já foram consumidas, armazenando-as no banco de dados. Se por alguma razão o Consumidor precisar reprocessar as mensagens que já foram lidas, isso é totalmente possível.

- Atua de Forma Distribuída

Não foi fornecido texto alternativo para esta imagem
Quando cria um Tópico é possível criar partições para ele, onde cada partição vai guardar as mensagens do tópico. Além disso, cada partição pode ficar em uma máquina diferente, onde que, se uma máquina cair, as outras estão no ar permitindo que as mensagens continuem sendo lidas.

Fonte imagem: https://whimsical.com/kafka-EbWjeGL3gDg9apxewMyGhB

- Zookeeper

Com ele é possível gerenciar erros e fazer recuperação, como por exemplo, se o Broker A cair, ele pode redirecionar para o Broker B. Se precisar subir um novo Broker, o Zookeeper atua e faz a comunicação entre todos, ou seja, ele atua para manter tudo em perfeita ordem.

- Kafka Connect

Com este recurso, através de conectores é possível se plugar em fontes externas e consumir as mensagens, como por exemplo, se conectar ao Twitter, ficar lendo as mensagens e quando encontrar alguma de seu interesse, enviar para o Tópico correspondente.

Com certeza ainda tem muitos outros recursos como as Keys, Compacted Log, Replication Factor, Partition Leadership, Data Compatibility, REST Proxy, Confluent ksqlDB, pois o ecossistema do Kafka é bem grande, mas este artigo traz uma visão geral dessa ótima ferramenta.

Quem usa?

Não foi fornecido texto alternativo para esta imagem
E se você está pensando em alguma solução para fazer seu sistema se comunicar com outros de forma segura e eficiente, com a possibilidade de reprocessar as mensagens, ou se está pensando em alguma solução para trabalhar com Microserviços, o Apache Kafka é uma solução para você considerar.

Referências

Apache Kafka Documentation - Acesso em: fevereiro de 2021. Disponível em: https://kafka.apache.org/documentation/
Apache Kafka - FullCycle - Wesley Willians - Acesso em: fevereiro de 2021. Disponível em: https://youtube.com/playlist?list=PL5aY_NrL1rjt_AZxj11kQjiTNLGg4ZaZA
Infográfico Apache Kafka - FullCycle - Wesley Willians - Acesso em: fevereiro de 2021. Disponível em: https://whimsical.com/kafka-EbWjeGL3gDg9apxewMyGhB
Apache Kafka Crash Course - Hussein Nasser - Acesso em: fevereiro de 2021. Disponível em: https://www.youtube.com/watch?v=R873BlNVUB4&list=WL&index=22

Há braços e até o próximo artigo.

Thiago Luna - Linkedin

Resolvendo problema de Access-Control-Allow-Origin (CORS) no Laravel

Thiago Luna — Fri, 15 May 2020 18:35:19 +0000

Quando estamos desenvolvendo APIs RESTFULL, é comum esbarrarmos com erro de CORS do tipo

Esse bloqueio se da por conta do protocolo HTTP e precisamos resolver.

Existem várias soluções na internet, como alterar o .htaccess, instalar pacotes como o barryvdh/laravel-cors entre outros.

A solução que compartilho com vocês é bem simples e resolveu o meu problema no Laravel 6.
Vamos lá!

1- Crie um novo Middleware
php artisan make:middleware Cors

2- Adicione neste novo Middleware, localizado em app/Http/Middleware/Cors.php, o seguinte:
Dentro do método handle
public function handle($request, Closure $next) { return $next($request) //Acrescente as 3 linhas abaixo ->header('Access-Control-Allow-Origin', "*") ->header('Access-Control-Allow-Methods', "PUT, POST, DELETE, GET, OPTIONS") ->header('Access-Control-Allow-Headers', "Accept, Authorization, Content-Type"); }

3- Edite o arquivo app\Http\Kernel.php da seguinte forma:
Dentro de $middleware acrescente o middleware que acabou de criar:
protected $middleware = [ \App\Http\Middleware\TrustProxies::class, ... ... \App\Http\Middleware\Cors::class, //acrescente essa linha ];

4- Teste novamente sua aplicação e vida que segue!

Tem muito conteúdo bom na internet explicando sobre CORS, porque acontece isso, n maneiras de resolver. Então, quis trazer um conteúdo curto e direto ao ponto, pois nosso prazo anda bem curto para as entregas, né?!

Agora, vamos voltar a codar porque a sprint está quase acabando.

Um abraço e até o próximo direto ao ponto.

Thiago Luna - Linkedin

PHP - Uma das Linguagens de Programação mais Populares

Thiago Luna — Fri, 10 Apr 2020 16:03:07 +0000

Na área da tecnologia, os softwares são os grandes responsáveis pela interação do usuário com esse mundo hi-tech. Se alguém quiser consultar seu saldo, usa um software pelo computador ou celular para acessar o banco.

Se quiser comprar algum eletrodoméstico, faz o mesmo. Se quiser comprar uma passagem aérea ou fazer a reserva em um hotel, também faz o mesmo. Alugar um carro, comprar comida, escrever um artigo para o LinkedIn, faz tudo isso através de um software.

E todos esses softwares são desenvolvidos através de alguma linguagem de programação, onde o desenvolvedor escreve linhas de código que serão compiladas/interpretadas pelo computador para gerar o software.

Linguagens de Programação

E nessa área de desenvolvimento de software existem várias linguagens de programação para todos os gostos e necessidades e neste artigo falo um pouco sobre quais as mais populares e, segundo uma pesquisa, qual a número 1 em popularidade.

Olhando o site w3techs.com, que provê informações sobre o uso de vários tipos de tecnologia na internet, encontraremos a pesquisa sobre as linguagens de programação server-side (que rodam do lado do servidor) mais populares.

As mais Populares

W3Techs

Segundo o site W3Techs w3techs.com, os dados são coletados dos 10 milhões de sites classificados no serviço de monitoramento do Alexa (uma empresa da Amazon que fornece dados de tráfego na internet e análise de dados) através de um mecanismo de busca e posteriormente analisados, gerando os relatórios. Além disso, eles utilizam informações públicas divulgadas por empresas como Google, Microsoft e ipinfo.io.

Eles procuram por padrões específicos nas páginas dos sites que identificam qual tecnologia está sendo utilizada.

PHP

Como podemos ver no resultado acima, o PHP é a linguagem mais popular, alcançando 79% dos sites pesquisados que a usam. E é fácil de entender o porquê desse resultado.

É uma linguagem de fácil aprendizagem, ótima performance, código aberto, com uma comunidade bastante atuante, documentação vasta na web e diversos tutoriais que ajudam os desenvolvedores.

Além disso, existem vários frameworks que utilizam PHP, como o CodeIgniter, o Zend e o Laravel, que são bastante conhecidos e usados pela comunidade e que facilitam e agilizam o desenvolvimento.

Um exemplo disso é usar, por exemplo, o Eloquent, um ORM (Object Relational Mapping) nativo do framework Laravel que facilita toda manipulação do banco de dados, sem falar do WordPress, um CMS (Content Management System) que também utiliza o PHP. Ou seja, se você precisa desenvolver um software simples ou complexo, em uma linguagem com documentação abundante e uma comunidade muito participativa e solícita em ajudar, o PHP é uma ótima opção.

Em minha trajetória como desenvolvedor usando o PHP, desenvolvi desde sistemas simples com CRUD até sistemas mais complexos, interoperando com outros sistemas, criei e consumi APIs, realizei manutenção em sistemas com paradigma procedural e orientado a objetos, utilizei CMS como Drupal, WordPress e Joomla e posso dizer que é possível atender a qualquer necessidade, qualquer requisito com o PHP.

Nem Tudo São Flores

Neste resultado, podemos observar que praticamente 60% dos websites que usam PHP, estão usando a versão 5. E isso não é legal. A versão estável até o momento é a 7.4.

Da versão 5 até a 7 houve muitas correções de bugs, novos recursos de linguagem foram implementados e teve um ganho considerável de desempenho. Além disso, uma nova biblioteca chegou para facilitar a utilização de criptografia, hash de senha e etc.

Permanecer com uma versão desatualizada é elevar o risco de problemas ao máximo.

Exemplos de Sites com PHP

Facebook.com
Wikipedia.org
Vk.com
Babytree.com
Wordpress.com
Pinterest.com
Ettoday.net

Outros Números do W3Techs

Mas... E agora?

São muitas as opções de linguagem de programação, mas, qual delas escolher?

Bem, essa é uma pergunta que muitos devem fazer, seja quem está começando a desenvolver, seja quem já desenvolve e até fábricas de software ou empresas que não tem TI como área fim, mas que precisam manter/desenvolver seus sistemas.

Só que a resposta para esta pergunta é um assunto para outro artigo...

E você, o que achou dessa pesquisa? Qual sua experiência com PHP ou outra linguagem de programação e qual sua visão para o futuro da programação web?

Compartilhe conosco sua opinião.

Comunidade PHPRio

E se quiser conhecer mais um pouco sobre PHP e fazer parte de uma comunidade, indico a PHP Rio. Sou membro, acompanho pelo grupo no Telegram que é muito ativo e 1 vez por mês tem Meetup com palestras muito boas e um super bate-papo com a galera.

Há braços e até o próximo artigo.

Thiago Luna - Linkedin