Já faz um tempo que eu venho querendo apagar tudo o que postei no Twitter, ou X, Xwitter. Não só pelo fato da empresa ter entrado com tudo na era da merdificação, mas porque gosto de pensar que ajudei alguém a virar um milionário. Ainda mais se esse alguém era antes um bilionário.
Buscando no GitHub, encontrei algumas soluções. Uma que pareceu dar mais certa foi a tweetXer, que você abre o console no Twitter e cola código pra fazer a coisa acontecer. O risco é ser banido pelo Twitter, mas acho que nesse ponto é até lucro.
Antes de começar é preciso solicitar a criação de um backup de sua conta. Um dos arquivos js que virão é o que alimentará o script pra ir apagando. Depois é sentar e esperar.
Como é possível ver na imagem acima, o treco mandou bala em 59.723 tweets meus. Haja tweets!
O resultado final foi esse aqui:
Tive de fazer o scroll em duas página pra mostrar que não sobrou nada. Nada. Foi bem eficiente. Mas...
como pode ser visto aqui, meus replies ficaram pra trás.
Mesmo assim é uma ótima ferramenta pra quem quer apagar o que postou ao longo do tempo no Twitter e migrar pro Mastodon.
https://github.com/lucahammer/tweetXer
Eu entrei numa thread com a pergunta sobre o que fazer pra apagar tudo que sobrou. Até o momento segue sem reposta.
Hoje mandaram essa dica legal na firma. Você pode puxar a previsão do tempo no shell usando curl e apontando pra wttr.in/<cidade>.
Bem legal a ideia e prática.
E o código fonte está no github: https://github.com/chubin/wttr.in
Eu estou no momento trabalhando num troubleshooting de uma rede 5G. Qual a novidade? Seria o 5G? Bom... não. A diferença é que pra acessar o ambiente cloud eu preciso fazer login numa máquina e depois fazer login em outra máquina.
Nada muito glamouroso, mas não é algo que eu possa escolher não fazer. Então a forma pra ajudar a ter isso feito da forma mais rápida possível foi através dos uso de expect.
Primeiramente uma visão da rede:
Um diagrama feito no libreoffice draw. Também nada glamouroso, mas deve dar conta do recado. Eu rodo o script, que pede somente minha senha de rede uma vez que é o mesmo usuário no server-gw1. E conecta via ssh. No server-gw2 é o mesmo usuário e senha, o que facilita as coisa. Dali pra rede k8s não tem mais nada porque eu acesso com um kube.conf e comand kubectl.
O script é esse aqui:
#! /usr/bin/expect
stty -echo
send_user -- "Entre a senha: "
expect_user -re "(.*)\n"
send_user "\n"
stty echo
set PASS $expect_out(1,string)
spawn ssh server-gw1
while {1} {
expect {
"ssword:" { send "$PASS\n" }
"(yes/no)?" { send "yes\n" }
"\$ " {break}
}
}
send "ssh server-gw2; exit\n"
while {1} {
expect {
"ssword:" { send "$PASS\n" }
"(yes/no)?" { send "yes\n" }
"\$ " {break}
}
}
interact
Note que é possível trocar pra receber o username como input ou como argumento do script. Na chamada pro segundo servidor existe um 'send "ssh server-gw2; exit\n"'. O motivo disso é pra quando eu digitar "exit" do servidor server-gw2 não precisar digitar novamente no server-gw1. Então ele faz o ssh pro server-gw2 e o próximo comando esperando já é um exit.
Espero que ajude e happy coding!
Nota: esse foi um artigo que escrevi pra Revista Espírito Livre, mas a edição nunca saiu. Mantive no mesmo formato e estilo que sairia na revista.
Algumas pessoas podem não acreditar ou até mesmo pensar que é loucura mas o software livre trata sobre... software! Nesse momento imagino já algumas pessoas revoltadas jogando cadeiras e ameaçando colocar fogo nas lixeiras mas infelizmente o software livre é sobre software. O software livre nos dá as diretivas pra termos um software que seja livre, mas não diz nada sobre como escrever esse software. Nenhuma direção, nada. Apenas sobre sua licença.
E software, apesar de ser uma forma de comunicação com um computador que interpretará as diretivas como uma linguagem de máquina e mandará sua CPU executar os passos descritos, pode e deve ser legível por seres humanos. Sim! Software é uma forma de escrita e como tal é imperativo para que seja lido e entendido tanto por CPUs quanto por humanos.
Existe então um movimento chamado "software craftmanship". A tradução remonta aos forjadores de armadura da idade média (não que o termo venha dessa época, é apenas a referencia feita). Uma tradução mais próxima seria algo como "forjadores de programação". Esse movimento tem seu manifesto explicitado em:
https://manifesto.softwarecraftsmanship.org/#/pt-br
Descrevendo o mesmo literalmente aqui:
Como aspirantes a verdadeiros Artesãos de Software, estamos ampliando as fronteiras da qualidade no desenvolvimento profissional de programas de computadores através da prática e ensinando outros a aprender nossa arte. Graças a esse trabalho, valorizamos:
Não apenas software em funcionamento,
mas software de excelente qualidade
Não apenas responder a mudanças,
mas agregar valor de forma constante e crescente
Não apenas indivíduos e suas interações,
mas uma comunidade de profissionais
Não apenas a colaboração do cliente,
mas parcerias produtivas.
Sendo assim descobrimos, que para atingir os objetivos à esquerda, os que estão à direita são indispensáveis.
A tradução existente no site usa o termo "artesãos de software" mas eu prefiro como "forjadores de software". Preciosidades linguísticas à parte, é possível ver que o foco é que todo código seja lido e interpretado por pessoas.
Um dos pais desse movimento é Robert C. Martin, ou como é mais conhecido, uncle Bob. Além de ter escrito os livros que são referências para clean code, Clean Code: A handbook of Agile Software Craftsmanship[1] e The Clean Coder: A Code of Conduct for Professional Porgrammers[2], ele também tem uma série de vídeos a respeito que ajudam a entender e aplicar os conceitos de clean code. O primeiro episódio[3] está disponível gratuitamente.
Clean code é uma prática ativa de software e um artigo somente não é o suficiente pra cobrir todo o assunto. Então descreverei apenas uma pequena parte referente sobre como escrever código de uma forma prática. Usarei shell script como exemplo por ser uma das primeiras linguagens de programação pra quem inicia no mundo Unix e ter uma curva de aprendizado mais baixa se comparada com linguagens como C.
Em clean code a ideia é escrever o código próximo da linguagem falada. Então algumas dicas são usar variáveis com nome significativo e lembrando substantivos. Então um loop for como esse:
for f in *txt
do
...
done
A variável "f" é claramente um padrão não desejado. O que significa "f"? De acordo com os fundamentos o melhor seria:
for fileName in *txt
do
...
done
Eu escolhi manter o padrão em inglês, mas claro que ali poderia ser "nomeArquivo". Eu usei a notação chamada "camelCase". Poderia ter usado for formato "file_name", snake case, mas esse tipo de detalhismo não é relevante pra clean code. O melhor seria seguir o padrão que o time usa no código em geral. No meu time trabalhamos muito com a linguagem go, que usa a forma "camelCase" e por isso acabo adotando no meu código.
Outra regra pras variáveis é tentar decidir se o nome é longo ou curto baseado em seu escopo de uso. Se a variável é muito usado, o melhor é ter um nome longo e bem descritivo. Se seu uso é curto, seu nome também pode ser curto. Então se dentro de um programa existir uma pequena função que apenas faça um sleep:
for i in $(seq 1 10)
do
echo $i
done
Esse não é lá um código muito útil, mas ilustra que pra um pequeno loop uma variável "i" pode ser aceita. Sempre lembando que depende do escopo de uso da variável.
Já as funções em clean code seguem a recomendação inversa. Se for muito usada no escopo do programa, o melhor é usar um nome mais curto. Se for pouco usada, um nome mais longo. E sempre usar um verbo pra funções. Ampliando o código do exemplo anterior, é possível criar uma função que retorne os nomes de todos os arquivos passados em seu argumento como padrão, algo como "*.txt". Como o exemplo é em shell script, não é possível usar return, mas um "echo" diretamente pra ler a resposta.
O código então poderia ser:
getFileNames() {
pattern=$1
for fileName in *$pattern
do
echo $fileName
done
}
allTXTFiles=$(getFileNames txt)
Então a função vira um "pegar os nomes de arquivos". O substantivo "allTXTFiles" tem o verbo "pegar os nomes de arquivos txt", ou ficando mais próximo da língua falada: "todos os arquivos TXT" é "pegar os nomes dos arquivos txt".
Booleanos são variáveis com valores sim ou não, verdadeiro ou falso. Seu uso em clean code pode ser traduzido como pergunta. Então parâmetros booleanos podem ser valores como "temperatura é alta", "isTemperatureHigh".
Um pequeno exemplo com um script pra verificar se é fim de semana.
getWeekend() {
weekDay=$(date +%a)
echo $weekDay | egrep -q "Sun|Sat"
echo $?
}
isWeekend=$(getWeekend)
if [ $isWeekend ]; then
echo "This is weekend."
else
echo "This is a working day."
fi
Os comentários em código significam que ou seu código está tão mal escrito que precisa ter explicação. Então em clean code deve-se evitar o uso de comentários, mas se forem necessários, que sejam extremamente descritivos.
Então um exemplo de comentário pro meu código acima.
# it returns 0 for Sundays or Saturdays, 1 for every other day.
getWeekend() {
weekDay=$(date +%a)
echo $weekDay | egrep -q "Sun|Sat"
echo $?
}
Meu comentário não descreve a função, que o nome já faz isso. Apenas melhora o entendimento do que voltará como parâmetro.
Eu pedi um exemplo pra aplicar os princípios de clean code às pessoas do grupo de shell script no telegram[4]. Agradeço então ao usuário @fonini por ter fornecido seu código. O código em questão é esse (apenas uma parte do código):
ts="$(date +%Y%m%d.%H%M%S.%N)" # timestamp
if [[ ! -v DEBUGFILE ]]; then
printf "Set DEBUGFILE first.\n" 1>&2
exit 1
fi
if (( $# < 1 )); then
printf '%s\n%s\n' \
"usage: DEBUGFILE=filename debug format [args]" \
" e.g.: export DEBUGFILE=log.txt"
exit 2
fi
O que pode ser melhorado nesse código? Segue o que seria uma aplicação dos princípios de clean code no sell script.
checkForDebug(){
if [[ ! -v DEBUGFILE ]]; then
printf "Set DEBUGFILE first.\n" 1>&2
exit 1
fi
}
printUsage() {
printf '%s\n%s\n' \
"usage: DEBUGFILE=filename debug format [args]" \
" e.g.: export DEBUGFILE=log.txt"
}
validateNumberArguments() {
totalArguments=$1
if (( $totalArguments < 1 )); then
printUsage
exit 2
fi
}
timestamp="$(date +%Y%m%d.%H%M%S.%N)"
checkForDebug
numberOfArguments=$#
validateNumberArguments $numberOfArguments
Não mentirei que clean code é fácil. É uma disciplina: é preciso praticar o tempo todo pra conseguir aplicar. No começo não é fácil, mas com o tempo seu código vai melhorando a legibilidade. E isso é apenas uma pequena parte de clean code. Tentarei descrever mais nas próximas edições.
|
Sobre o autor:
|
|
Referências:
[1] Clean Code: A Handbook of Agile Software Craftsmanship - http://hl.eng.br/6cX
[2] The Clean Coder: A Code of Conduct for Professional Programmers - http://hl.eng.br/6cW
[3] Clean Code: Fundamentals, Episode 1 - https://cleancoders.com/video-details/clean-code-episode-1
[4] Shell Script (#!/bin/bash) - https://t.me/shellbr
Tenho feito muitos testes para utilizar TLS e mTLS. TLS é uma camada de criptografia assimétrica para garantir a comunicação segura entre dois pontos.
Em geral temos o model parecido com os sites web onde o servidor tem uma conexão segura assinada por uma autoridade certificadora e nos conectamos a ele. No caso de mTLS, mutual TLS, é preciso validar quem conecta também.
Pra gerar os testes que venho fazendo, gero um certificado de 1 dia usando openssl da seguinte forma:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 1 -nodes \
-subj "/C=SE/ST=Stockholm/L=STHLM/O=Company/OU=ADP/CN=localhost
Esse comando gera para mim a chave do servidor (key.pem) e a chave da autoridade certificadora, que assina a chave.
Em geral carrego isso no meu programa que utiliza TLS.
Pra testar (assumindo que seu serviço seja http e esteja usando a porta 9091):
curl --cacert cert.pem --key key.pem --cert cert.pem "https://localhost:9091/
Eu poderia gerar um chave pro client, que no caso é o comando curl, mas como é pra ambiente de testes, re-uso o mesmo.
Boa diversão!
