Se você está começando agora nesse tal Kubernetes e já está naquele ponto em que seu navegador tem +200 abas abertas em materiais diversos, desde o site oficial até artigos diversos por aí, bem-vindo! A meu ver, você já pode deixar isso tudo de lado e ficar tranquilo, porque por meio da leitura deste artigo, você conseguirá ainda nesse dia de hoje (a não ser que você esteja lendo-o próximo da meia-noite, claro) adquirir conhecimento suficiente para tornar-se um profissional muito decentemente capacitado a trabalhar com essa tecnologia bacana que é o Kubernetes.
Então, por favor, leve numa boa os parágrafos um tanto mais “filosóficos” do início, porque ainda teremos uma abordagem bastante prática para deixá-lo a par e, se possível, acostumado com o instrumental todo (que nem é muito, mesmo).
Uma das grandes influências de Now foi Tcl. Tcl é uma linguagem magnífica! Com relação a sintaxe, concorre fácil com qualquer outra para ser a que mais gosto.
Como concluímos, eu e um colega: “Tcl é um diálogo, não uma fórmula matemática”.
É, pois é, a ideia é ser uma ferramenta auxiliar em projetos de software, mas no fim do dia o formato é tão legal que eu acabo usando para anotar algumas coisas que ficam bem como “dados estruturados”, inclusive quando misturados com anotações desestruturadas.
Situação comum durante o desenvolvimento de software é entrar no Dilema Makefile/Shell Script. Afinal, existe sempre um conjunto de operações básicas que os desenvolvedores querem efetuar no projeto, seja rodar o projeto localmente, os testes unitários, compilar algo, análise estática, popular o banco com dados mockados, rodar migrations, pingar alguns serviços ou mesmo engatilhar um deploy. E a melhor opção para entregar isso geralmente é fazer uso do bom e velho make, que permite usar “subcomandos” (os targets do Makefile) e chamar comandos, tudo de maneira muito simples.
/etc/udev/rules.d/50-bluetooth.rules
ACTION=="add", SUBSYSTEM=="input", ATTRS{uniq}=="<keyboard-mac-address>", RUN+="/home/cleber/bin/on-bt-keyboard-connected.sh"
Preste atenção ao <keyboard-mac-address>. Você pode vê-lo usando o comando bluetoothctl:
$ bluetoothctl
[prompt] devices
Device F4:73:xx:xx:xx:xx Keyboard K380
Device 2E:D6:xx:xx:xx:xx Philips TAT1215
bin/on-bt-keyboard-connected.sh
#!/bin/bash
export DISPLAY=:0.0
(
sleep 2.5
su -c 'xmodmap /home/cleber/.Xmodmap' cleber
# su -c 'command' user
) &
O sleep é necessário (pelo que entendi) porque o Xorg demora um pouco para “carregar” o teclado depois que o mesmo é detectado pelo udev.
~/.Xmodmap
No meu caso, eu mapeio o CTRL para a tecla Caps Lock, enquanto o Caps Lock mesmo vai parar na right-CTRL.
$ cat ~/.Xmodmap
remove Lock = Caps_Lock
keysym Caps_Lock = Control_L
add Control = Control_L
remove Control = Control_R
add Lock = Control_R
Ou seria “golang”?
golang golang golang golang golang golang golang golang golang golang golang golang golang golang
Pronto. Talvez assim esse artigo seja encontrado quando alguém buscar algo sobre “Go” no Google.
Briguinhas
Durante uma década inteira ficamos contentes com nossas pequenas brigas entre diversos feudos. Python (ou, “os programadores que usavam linguagem Python”) fazia graça com Java e sua sintaxe ridícula, Java gabava-se de ser “Enterprise” enquanto temia a vinda da .Net que, por sua vez, tentava ser um pouco de tudo, mas focava mesmo em C#, que por sua vez era desprezada pelo C++ por ser “muito pesada” ou “pouco portável” enquanto o velho C assistia a tudo, sentindo-se superior, e dava risada enquanto seus usuários dançavam num salão recém-encerado carregando navalhas.
Pode parecer um erro idiota (e talvez seja mesmo), mas acredito ser bem comum, especialmente quando você está começando com Erlang: chamar self/0 logo depois do spawn, pensando que está referindo-se ao processo pai.
Exemplo:
funcao_pai() -ᐳ faz_algo(),
spawn(
fun() -ᐳ
funcao_filha(self())
end
).
É fácil de você se confundir e começar a pensar no processo novo a partir da execução de funcao_filha/1, isto é, a partir da entrada em seu escopo. Engano! O escopo do novo processo é a fun/0 que foi chamada pela spawn/1.
Consequentemente, aquela chamada a self/0 não retorna o PID do processo pai (execução em funcao_pai/0), mas o PID do processo filho (execução já na fun/0).
Quando você está no meio de um “ímpeto programadorístico”, essa coisa óbvia pode passar desapercebida. Fica a dica. :)
Este artigo foi escrito originalmente em 14/12/2014.
A ideia do kerl é facilitar o building e a instalação de instâncias de Erlang/OTP ([https://github.com/yrashk/kerl]). Ele permite que você instale, por exemplo, várias versões da VM e até facilita que você tenha várias instâncias da mesma versão, mas compiladas com opções diferentes (habilitar o HiPE apenas em uma, por exemplo).
E o melhor é que trata-se apenas de um pequeno script shell. Vamos começar a usá-lo?
Chegou a hora de vermos uma das features mais alardeadas pelo povo do Erlang: concorrência.
Primeiramente, vamos definir o que é concorrência e o que é paralelismo.
Na visão dos criadores de Erlang, concorrência é, meramente, você ter mais de um processo trabalhando na mesma máquina. Eles não precisam ser executados ao mesmo tempo. Se você tem uma CPU com um núcleo só e um sistema operacional multi-tasking, você deve ter vários programas sendo executados em condição de concorrência nesse exato momento. Mas cada um tem seu próprio “espacinho” na fila da CPU.
É, pois é. A gente costuma começar com o “Hello World” e eu simplesmente esqueci. Se bem que não faz diferença, mesmo, já que há anos eu não faço “Hello Worlds” para começar a aprender linguagens de programação…
O que vamos ver hoje são os caracteres de formatação de io:format/2.
~n
Imprime o caracter de “nova linha”.