Como atualizar o PHP no macOS?

Se tu usas Mac para desenvolver teus sítios WordPress, deves ter notado que felizmente o macOS já vem com o PHP instalado. A questão é que nem sempre a versão instalada é a mais nova, principalmente se estás rodando uma versão antiga do macOS, como eu, que uso o El Capitan no meu Mac Pro 2009.

Ter a última versão PHP é um pré-requisito para poderes desenvolver teus projetos e uma versão antiga pode ficar atrapalhando tua vida, principalmente se queres usar ferramentas auxiliares como a extensão PHP Intellisense dentro do VSCode.

O macOS Catalina já vem com a versão 7.3 do PHP, e o Mojave e o High Sierra até vêm com o PHP 7.1 pré-instalado, mas a versão instalada no macOS Sierra é a 5.6 e o El Capitan vem com o PHP 5.5. Péssimo.

Felizmente o pessoal do grupo php-osx mantém pacotes dos últimos “builds” das versões do PHP desde a 5.3 até 7.3, que podem ser instalados desde o Snow Leopard (OS X 10.6) até o High Sierra (macOS 10.13). Como os programas são instalados na pasta /usr/local/php5, eles não afetam em nada tua instalação padrão do macOS.

Instalando o PHP no macOS

Mais fácil que correr cancha com tropeiro de lesma. Escolhe a versão, abre o Terminal e digita a linha correspondente, abaixo:

PHP 7.3

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 7.3

PHP 7.2

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 7.2

PHP 7.1

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 7.1

PHP 5.6

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 5.6

Infelizmente o pessoal do php-osx não montou um pacote para a versão 7.4 e ainda não descobri uma maneira mais fácil de instalar esta versão sem ter que instalar utilitários extras, como o Homebrew. Quando descobrir, atualizo o artigo.

Verificando se a nova versão do PHP está funcionando

Agora que tudo está instalado, precisamos adicionar a pasta do pacote ao PATH do sistema:

$ export PATH=/usr/local/php5/bin:$PATH  

Depois, é só verificar se a nova versão é a padrão:

Mac-Pro:~ marcoandrei$ php -v

PHP 7.3.8 (cli) (built: Aug 11 2019 20:50:16) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.8, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.8, Copyright (c) 1999-2018, by Zend Technologies
with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans

Feito!

“Tá, mas o VS Code continua dando erro…”

Pois é, em alguns casos, quando o VS Code continua dando erro, é porque a extensão PHP Intellisense não identificou corretamente a versão do PHP, mesmo que o sistema aponte a versão nova. A solução é preencher o parâmetro “executablePath” nas configurações da extensão.

Dentro do VS Code, vai em Extensions e encontra a extensão “PHP Intellisense”. Clica na engrenagem e seleciona Extension Settings. Adiciona (ou edita) esta linha no arquivo settings.json:

"php.executablePath": "/usr/local/php5/bin/php"

Agora sim!

Bueno, este tutorial te ajudou? Tens alguma dúvida? Deixa teu comentário aí embaixo e a gente troca uma ideia!

SSH: Como forçar o uso de senha para autenticação?

Para desenvolvedores que têm conhecimento de infraestrutura e gostam de manter seu próprio servidor, usar o SSH para acessá-lo e fazer manutenções no WordPress e outras pastas é uma tarefa cotidiana. Normalmente o acesso se dá com a dupla usuário/senha, mas há casos, entretanto, em que a plataforma obriga ou já deixa o servidor pré-configurado para fazer o acesso somente por uma chave pública SSH.

Quando o acesso SSH por chave pública atrapalha

O acesso por chave pública é uma opção segura, mas pode ser um problema se tu não tens conhecimento dessa chave ou não estavas preparado para este tipo de acesso.

Nestes casos, ao se tentar acessar o servidor com o comando ssh usuario@servidor, recebemos aquele erro chato e sem muita explicação:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)

Isso normalmente ocorre porque o SSH está tentando fazer a combinação de autenticação e a chave não está armazenada em tua máquina, simplesmente porque não existe.

Um exemplo comum são servidores criados nos serviços Lightsail ou EC2 da Amazon. Nestes serviços, os servidores não tem um usuário “root” e o acesso por padrão é via chave pública. Para melhorar, a documentação não é clara sobre este aspecto da configuração (até porque é quase toda em Inglês).

No caso da Umbler, é um pouco diferente. A documentação é melhor e o suporte é amistoso, o que já melhora 100%. Entretanto, para se fazer o acesso SSH é obrigatório fazer o envio da chave pública antes, não há a opção de acessar por senha.

Já na DigitalOcean, Vultr e outras, em geral é possível ter o acesso via chave pública, mas a autenticação padrão é por senha, o que pode ser menos seguro, mas é mais prático logo que se cria o servidor.

O que fazer?

O que fazer nestes casos? Na verdade é simples. Basta usar os parâmetros PreferredAuthentications (Autenticação Preferida) e PubkeyAuthentication (Autenticação por Chave Pública) para forçar o acesso por senha e dispensar a chave pública.

O comando ficaria assim:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no usuario@servidor

Ou seja, “Autenticação Preferida = senha” e “Autenticação por Chave Pública = não”.

Com esse comando, o SSH vai responder com:

usuario@servidor's password:

Daí é só entrar com a senha e pronto.

Tenha configurações SSH diferentes para cada servidor

Outra possibilidade interessante é guardar as configurações usadas para cada servidor que precisares fazer acesso.

Isso é feito por meio de um arquivo “config” que é gravado na pasta .ssh, a mesma onde ficam as chaves de acesso.

Criando um arquivo de configurações para o SSH

1) Acessa a pasta .ssh na tua pasta de usuário e cria um documento com o nome config e ajusta as permissões do arquivo para 600.

2) Edita o arquivo e cria seções iniciando sempre com este modelo

host <servidor ou padrão>

Por exemplo:

host *.gauderio.com
user gaudencio
port 9191
PubkeyAuthentication=no

Daí é só usar ssh indio-veio.gauderio.com que o SSH vai consultar o arquivo de configurações e aplicar as opções listadas acima.

Ainda há a chance de haver um arquivo de configuração padrão para todo o sistema. Neste caso, será necessário “enganar” o SSH, especificando uma configuração de mentirinha:

ssh -F /dev/null usuario@servidor

O parâmetro -F permite especificar um arquivo de configuração alternativo e a configuração padrão de sistema é ignorada.

Este artigo te ajudou? Ficaste com alguma dúvida sobre o SSH? Seguiste os passos e não funcionou? Deixa teu comentário aí embaixo para a gente ver juntos!

O PHP morreu. Viva o PHP!

Apesar de estar em mais de 80% dos sítios na Web, incluindo Facebook e Wikipédia, os detratores continuam dizendo que o PHP morreu. Será mesmo?

Estes tempos estava conversando com um grupo de colegas de um curso e alguém me declara: “mas o PHP está morrendo, né?”.

Acho engraçado isso. Mais do que isso, acho engraçado aquele pessoal vive na busca sôfrega por duas coisas: “qual/quem é o melhor?” e “qual/quem é o moribundo?”. Toda a vez que surge uma nova tecnologia, a galera fica desesperada para que ela seja a “ferramenta definitiva”, matando tudo que tem em volta. Pois a bola da vez parece ser o PHP.

Eu trabalho com o PHP desde um pouco antes de começar com o WordPress. O WordPress é feito em PHP e pretende continuar usando a linguagem em longo prazo, o que me faz pensar rapidamente que: NÃO, O PHP NÃO MORREU.

E antes de alguém dizer “mas…” vou apelar para as estatísticas da W3Techs:

OITENTA E TRÊS POR CENTO de presença na Internet. Parece pouco?

“Ah, mas porque tem um monte de CMS feito em PHP e a estatística fica distorcida!” Muito bem, Mike Oram em seu artigo “Is PHP relevant” nos conta que mesmo sem os CMSs, o PHP continua com 54% da Web. Adicione-se a isso o fato de sítios como Facebook, Ali Express, Wikipedia e outros terem escolhido o PHP como ferramenta de desenvolvimento. Parece irrelevante?

E a tendência do uso de PHP não é de baixa, ao contrário, a linguagem chegou a AUMENTAR levemente sua presença no último ano, como podemos ver neste gráfico também da W3Techs.

Acho que isso é o suficiente para provar que apesar dos seus detratores e “haters”, o PHP continua firme e forte há mais de 20 anos (foi lançada em 1995).

Claro que a linguagem tem suas “falhas” ou “problemas”, como alguém pode dizer, dizendo que tem erros ou indicando que é fracamente tipada, por exemplo. Pois para o primeiro argumento, sugiro se atualizar, pois ainda em 2009 a versão 5.3 resolveu a maioria dos “bugs tradicionais” encerrando de vez o assunto. E para o segundo, bem, eu considero uma VANTAGEM, que um bom programador saberá usar a seu favor!

Já estamos na versão 7.2 e posso dizer que a linguagem só melhora, com um salto incrível de velocidade a partir da versão 7 (tanto que se pulou da versão 5.6 para a 7.0 direto!).

Ainda não te convenceste? Te dou uma dica: lê o artigo “7 linguagens de programação que todo o desenvolvedor deveria aprender em 2018” da TechRepublic. O PHP está lá, só para constar.

Pagamos caro por uma Internet ruim; e querem piorar

Transmissões pela Internet é um caminho sem volta e os “datilógrafos” do Brasil querem obrigar os seus clientes a continuar consumindo seus produtos obsoletos.

Para quem ainda não entendeu a extensão do “golpe” dos provedores de Internet, saibam que mesmo que não se use o Netflix, ainda temos muitos serviços que consomem um volume de dados considerável.

Tanto que os próprios programas têm a opção de fazer transferências só quando conectado no WiFi para “não consumir franquia de dados 3G”.

Alguns exemplos de serviços que serão afetados:

– armazenamento em nuvem: Dropbox, Microsoft OneDrive, Apple iCloud, Google Drive, etc.
– portais de vídeo: YouTube, Vimeo, G1, R7, Terra, UOL, etc.
– vídeo por demanda: Netflix, NET now, etc.
– transmissões em linha: todos os canais que têm aplicativos, etc.

Para quem ainda não entendeu o porquê, saibam que o Netflix é um dos principais concorrentes da TV a cabo, e a ideia, é claro, dar um golpe nos provedores de conteúdo.

Transmissões pela Internet é um caminho sem volta e os “datilógrafos” do Brasil querem obrigar os seus clientes a continuar consumindo seus produtos obsoletos. A venda casada é clara: se comprares a TV junto, a conexão Internet sai mais barato. NÃO COMPRO.

Minha dica de protesto:

– ao contratar uma conexão Internet para ti, NÃO COMPRES a TV e o telefone (ninguém usa, ninguém vê), mesmo que seja mais caro;
– ao comprar um telefone fixo, NÃO COMPRES VoIP, porque se faltar luz, ficarás sem telefone (podes usar qualquer mensageiro como Skype, Hangouts, etc. em vez disso, é um serviço pago inútil);
– opte por provedores que oferecerem uma banda cheia, que não se protejam atrás da regulamentação ridícula da Anatel, que obriga os provedores a entregar 40% da banda nominal (te vendem 10MB e te entregam 4MB, isso quando entregam);
– se teu plano atual não tem franquia de dados NÃO MUDA; os novos já têm isso.

Um detalhe importante: os provedores que tiverem planos por franquia de dados são OBRIGADOS a fornecer uma ferramenta para controle do consumo. Sem ela, NÃO PODEM oferecer planos limitados.

Temos uma das piores infraestruturas de Internet do mundo e ainda temos que pagar caro por ela.

A última dica então é: NÃO CONSUMAS o que não precisas. Gasta teu dinheiro de maneira consciente e não pagues por porcarias.