Os donos dos encanamentos

Antigamente os ricos tinham terras e o que definia o status e o poder era a quantidade de terras que se tinha. Quanto mais terra, mais vassalos. Quanto mais vassalos, mais mão de obra trabalhando e maior a sua riqueza e poder. As leis, até muito pouco tempo atrás, trabalhavam para que pouquíssimos pudessem, efetivamente, ser donos das terras.

Até muito recentemente tinha-se apenas a posse (e muita área rural ainda é assim) e na troca da posse, os donos da terra ganhavam um pouquinho – isso praticamente virou o ITBI – mas agora você é o dono e quem recolhe este imposto é o governo.

Passaram-se algumas centenas de anos e vivemos a revolução industrial – agora além das terras os ricos tinham outros meios de produzir riqueza e explorar o trabalho alheio: máquinas, fábricas, projetos industriais. Criou-se uma nova classe dos detentores do poder econômico e social: os burgueses, que se estabeleceram com as indústrias de petróleo, transportes e os mercados de capitais para iniciar o processo de empresas centenárias, perpetuando o histórico de concentração de renda.

Chegamos na era da mídia, rádio e TV agora traziam informação, entretenimento e uma nova oportunidade de exibir anúncios e vender produtos para milhares de desavisados.

Enquanto a TV se popularizava a concessão de transmissão era barata e as empresas compraram concessões e tinham lá o seu canal de TV. Eram poucos canais pois era o que era possível transmitir com a tecnologia da época – e conseguir conteúdo não era uma tarefa tão simples. Era uma transmissão direta do canal para o usuário: os canais de TV eram os donos do meio de transmissão, os encanamentos do negócio eram Canal -> usuário.

Eis que vem uma revolução no meio da mídia: a TV a cabo com uma nova maneira de levar canais para centenas de milhares de telespectadores – criou-se um novo sistema de “encanamento” para distribuição de um produto e agora os canais tinham que pagar para uma operadora para conseguirem chegar aos seus usuários – a TV a cabo passou a valer mais do que os canais de TV.

Mais alguns anos chegamos nos meios digitais, o nascimento da internet comercial e logo em seguida a efusão de esperança na democratização do conteúdo com a promessa da “web 2.0”.  O discurso agora era de que muito valor poderia ser criado mesmo se você não tivesse muito capital: uma promessa de que com uma boa ideia de produto ou serviço você poderia criar um excelente negócio.

Agora a burguesia e os donos dos “meios de produção” não tinham como impedir um programador de desenvolver e lançar um produto, ou um escritor ou jornalista de criar o seu blog e gerar e distribuir seu próprio conteúdo para um número infinito de usuários. Surgiu o RSS que fazia essa ligação direta entre público e público. O público tinha controle do que consumir e o produtor tinha finalmente um número virtualmente infinito de audiência, sem intermediários.

Os encanamentos chegaram finalmente na mão da ralé, do peão, dos trabalhadores.

E isso parecia estar funcionando: nasceram Apple, Microsoft, IBM e dezenas de empresas de jogos e software que revolucionaram o mercado computacional e de entretenimento.

Parecia, mas o que não se considerava – mas agora é óbvio em retrospecto – é a astúcia do capitalismo em cooptar inovações, gerar lucro e criar empecilhos para novos entrantes. O capitalista é um especialista em criar estes novos encanamentos, vender como se fosse algo bom para todos – ele vai chamar isso de eficiência e dizer que aumentará a disponibilização de um bem, barateará custos, ou qualquer outro discurso que fique bom em uma notícia paga. E quando o mundo aderir ao seu novo sistema de distribuição logo em breve será pego nem tão de surpresa com a instalação de um relógio medidor, que virá com uma cobrança para que qualquer um que queira utilizar aquele sistema.

Passamos pela nobreza do feudalismo, os burgueses da era industrial e me parece que carecemos de um novo termo para definir os donos dos encanamentos do mundo digital. Minha sugestão é titãs digitais, e estes trabalham incansavelmente para que tudo transite dentro do seu sistema de encanamentos: Google, Facebook, Amazon, Apple.

O Google matou o Google Reader, um leitor de Feed RSS que fazia essa ligação entre criador de conteúdo e público. Recentemente também matou o Google Podcast, que fazia esta mesma conexão com podcasts – agora você tem que usar o Youtube para isso e tanto o criador quanto o público ficam a mercê do obscuro algoritmo que define o que você vai consumir, ou para quem seu conteúdo será entregue.

Se você não utiliza os encanamentos de distribuição deles, você não está fazendo buscas e gerando impressão de anúncio, e acaba não clicando no primeiro resultado patrocinado – da loja que você já conhece mas agora reparte uma considerável do lucro com o Google via adwords.

E os donos dos encanamentos farão de tudo para que nenhum novo sistema de encanamento apareça – e vão gastar recursos com lobby, tecnologia e manipulação de opinião para fechar qualquer gotinha que esteja vazando para fora.

Como testar localmente uma Google Cloud Function com trigger de tópico PubSub

Estou trabalhando em um projeto de monitoramento de dados com Google Cloud Functions e, para agilizar e evitar custos desnecessários, queria testar a ativação de uma GCF com um gatilho de evento (tópico no PubSub)

O primeiro passo é iniciar o emulador de PubSub, nesse caso ele vai rodar na porta 8043, para o projeto odesenvolvedor

Criando um emulador do PubSub

gcloud beta emulators pubsub start \
    --project=odesenvolvedor \
    --host-port='localhost:8043'Code language: JavaScript (javascript)

É esperado que você veja no terminal o log do emulador, com alguns detalhes da exeução e indicando que ele está rodando e em qual porta:

[pubsub] INFO: Server started, listening on 8043Code language: CSS (css)

Você vai precisar criar um tópico, em outro terminal execute:

curl -s -X PUT 'http://localhost:8043/v1/projects/odesenvolvedor/topics/mytopic'Code language: JavaScript (javascript)

Agora vamos especificar o endpoint de assinatura do push

curl -s -X PUT 'http://localhost:8043/v1/projects/odesenvolvedor/subscriptions/mysub' \
    -H 'Content-Type: application/json' \
    --data '{"topic":"projects/odesenvolvedor/topics/mytopic","pushConfig":{"pushEndpoint":"http://localhost:8080/projects/odesenvolvedor/topics/mytopic"}}'Code language: JavaScript (javascript)

Enviando uma mensagem para o PubSub

Com o emulador rodando você pode disparar novas mensagens fazendo um post para o emulador (no nosso exmeplo, localhost:8043) indicando o projeto, tópico e ação.

Para publicar uma mensagem no terminal, você pode usar o comando abaixo, lembrando que o data da mensagem deve estar codificado em base64.

curl -s -X POST 'http://localhost:8043/v1/projects/odesenvolvedor/topics/mytopic:publish' \
    -H 'Content-Type: application/json' \
    --data '{"messages":[{"data":"eyJmb28iOiJiYXIifQ=="}]}'Code language: JavaScript (javascript)

Você também pode usar uma ferramenta como Postman para fazer os envios, configurando método como POST, a url como http://localhost:8043/v1/projects/odesenvolvedor/topics/mytopic:publish e o tipo de conteúdo como application/json, enviando a mensagem no corpo do post.

Rodando uma Cloud Function local que escute o evento

Antes de criar a função, você precisa definir as variáveis de ambiente para que sua função utilize o PubSub do emulador e não tente se conectar ao PubSub da Google Cloud, para isso execute o comando abaixo, trocando o id do projeto:

gcloud beta emulators pubsub env-init
export PUBSUB_EMULATOR_HOST=[::1]:8432
export PUBSUB_PROJECT_ID=odesenvolvedorCode language: JavaScript (javascript)

Com o emulador rodando e sabendo como enviar uma mensagem para um tópico, falta apenas criarmos uma função que ouça o tópico.

Crie a função na sua linguagem favorita, no exemplo abaixo uma função em Python:

import json
import base64

def minha_gcf(event, _context = None):
    payload = base64.b64decode(event['data']).decode('utf-8')
    payload = json.loads(payload)
    print(payload)
    return "OK"Code language: JavaScript (javascript)

Agora é só rodar esta função localmente, avisando que ela deve ouvir os eventos do PubSub:

functions_framework --debug --port 8080 --target=minha_gcf --signature-type=event

O importante aí é o –signature-type=event, mesmo sendo uma função local rodando na porta 8080 ela irá escutar os eventos do PubSub

Ao enviar novas mensagens para seu emulador do PubSub, sua função será executada.

ISPConfig 3.2 e jailkit – problemas para login com ssh

Depois de atualizar o ISPConfig para a versão 3.2 tive problemas com alguns acessos ssh para usuários com jailkit ativo.

Aqui, alguns usuários logo após tentar fazer o login com chave, eram desconectados do ssh.

Como a maioria dos processos de deploy que utilizo neste servidor utilizam rsync, isso travou o deploy das aplicações com este problema.

Baseado neste link e em algumas outras leituras, acompanhei o /var/log/auth.log enquanto autenticava com os usuários e parecia ser um erro de permissão, o resultado era muito parecido com o da thread linkada:

Oct 15 18:46:43 server1 jk_chrootsh[16809]: ERROR: failed to execute shell /bin/bash for user username (5007), check the permissions and libraries of /var/www/clients/client1/web78//bin/bashCode language: JavaScript (javascript)

Logo após isso, o logout do usuário. A barra dupla não é um problema (foi a primeira coisa que achei que poderia ser).

No fim, depois de muitas horas e testes, eu não consegui identificar a causa do problema. As configurações do jailkit estava idênticas as ispconfig.

Tentei fazer o resync dos usuários shell, não retornava erro mas não alterava em nada.

Solução encontrada

O que resolveu aqui, foi bem parecido com o sugerido no final da thread no fórum:

  • Removi todos os usuários shell da conta em questão
  • Na configuração de site, marque na aba options a opção Delete unused jailkit chroot
  • Aguarde a sincronização do ISPConfig ou execute manualmente o update via .sh no server
  • Recrie o usuário shell – isso irá recriar a estrutura de arquivos para o chroot e recriar o usuário

Estes passos resolveram e o acesso voltou a funcionar com o jailkit, mas não consegui identificar a causa (não ocorreu com todos os usuários com jailkit).

Mantendo o WordPress seguro – permissões corretas de arquivos e diretórios

Seguindo as recomendações de segurança do WordPress, as permissões de arquivos devem ser: 755 para diretórios e 644 para arquivos.

Isso pode ser configurado com o comando abaixo (unix):

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;Code language: CSS (css)

Para os uploads funcionarem (via wp-admin) é necessário que o usuário do seu servidor (no meu caso, o Apache usa o www-data) tenha acesso a pasta de uploads.

chown www-data:www-data wp-content/uploads

O acesso ao www-data também é necessário no restante dos arquivos se você quiser habilitar o update via painel, instalação de temas e plugins.

Parêntesis e chaves coloridas: um plugin que vai mudar sua vida

A rima não intencional no título é para falar do Bracket Pair Colorizer – ou de qualquer outro plugin que auxilie a identificar o que está fechando o que no seu código (parêntesis, chaves, colchetes).

Esta semana eu terminei de fazer um curso de NodeJS e estou colocando em prática duas das metas para 2019: trabalhando em um produto próprio e produzindo algo que vai para produção com NodeJS no back-end.

No javascript – mesmo evitando uma cadeia de callback hell – você ainda pode acabar se deparando com algo com uma estrutura parecida com isso:

({({({})})})

Descobri o plugin no tweet abaixo e ele faz exatamente o que parece:

Se você utiliza o VSCode, instalar é fácil:

ext install CoenraadS.bracket-pair-colorizer

Confira a página do Bracket Pair Colorizer. Se você utiliza outro editor recomendo procurar algo parecido – comecei a usar hoje e é muito prático.