Fiquei numa vibe de montar arvore familiar no site mórmon do FamilySearch.
A origem, apesar que as pessoas pensem que seria no Japão, talvez seja aqui no Brasil mesmo. É difícil ficar fuçando aqueles registros.
Um dos registros acessíveis neste site são os de desembarque de navios vindos do Japão, o registro japonês do navio é parecido com o registro municipal japonês.
Registro municipal
Mesmo com toda tecnologia, o Japão ainda mantém um sistema curioso de registro municipal em papel, um documento essencial usado pelos filhos, netos de japoneses chamado: koseki-tohon, existem umas variações mas não me recordo a diferença.
Nesse papel contém informação do chefe da casa, a esposa e os filhos.
Quando a mulher nasce, ela ganha um nome com ideogramas. Pelo menos nos registros que pesquisei da minha família, depois quando a mulher casa, ela “perde” todos os ideogramas do primeiro nome igual no filme da Viagem de Chihiro. Escrevendo o primeiro nome de forma simples com Katakana, também não se mantém o sobrenome da família. Quando o homem nasce, o nome não se altera quando casa e cria um novo registro para denominar este homem como o novo chefe, este dá o sobrenome a esposa.
Os filhos são numerados, primeiro até o enésimo filho. Se casar ou morrer é marcado um X e o registro escrito, porque aquele membro não pertence mais aquela família.
Outros membros da família não sei como fica neste documento, só vi no registro do navio que aparece: Irmão da esposa, sobrinha etc.
Para solicitar ou atualizar este documento, você envia uma carta para a cidade na qual seus antepassados vieram. Dizem que as pessoas quando vieram para o Brasil, elas tinham uma cópia deste documento, este é valido também.
Dupla nacionalidade
Para dupla nacionalidade era feito um esquema que não sei se isso ainda funciona, mas para uns parentes, mesmo nascidos aqui no Brasil eles tinham sangue japonês (pai japonês), já que a nacionalidade japonesa não se define pelo local de nascimento. Então, o documento era atualizado e enviado uma carta para a cidade da onde eles vieram para fazer o registro oficial. Caso este documento não fosse entregue atualizado para a cidade, a pessoa não é mais reconhecida com a nacionalidade japonesa.
Pensava que isto era um registro histórico comprovante das raízes japonesas, mas é um documento ainda usado.
Considerando o tempo fora de programação com alvo em Windows, algumas coisas não mudam.
Existem regras que voltam a cabeça automagicamente. Assim uma compilação que funciona em alguma máquina do infinito e não precisou reconfigurar já fazem alguns anos, precisa ser feita novamente em outro lugar.
O resultado são símbolos bagunçados, reconfiguração de caminhos de bibliotecas, padronização de saída conflitante, problemas de resolução de assinaturas por conta do tipo de compilação utilizada e afins.
As pessoas entendem o caos delas. Organização de uns, caos de outros. Indiferente a plataforma.
Visual studio
Neste ponto, uma vez com o SDK não é obrigatório usar a IDE, mas já estava instalada por algum projeto feito há anos atrás.
As opções de pasta eram gerais, agora são feitas por projeto. Isto deve já fazer um bom tempo que funciona desta forma.
Quando mexe muito em uma versão específica, você espera que todas as versões funcionem da mesma forma.
O Intellisense demora a indexar, mas funciona razoavelmente bem. Considerando o esforço que é feito para gerar o mínimo de resolução de referências no outro projeto Linux, o Visual Studio é bem amigável neste aspecto.
Gerenciadores de dependências
Esta é a parte onde pode ser complicada no Windows. Era comum fazer os seguintes passos: baixar os fontes, verificar se existia suporte para Windows e torcer para compilar direito (por fim, compilar não significa que funciona).
Utilizando um gerenciador de dependências pode ser mais simples, mas a parte de verificar o suporte para o sistema operacional ainda existe.
Conan
Não sei se já passou pela sua cabeça que poderia ter um gerenciador de dependências por projeto, ficando desacoplado instalador do sistema operacional e nem tão complicado como um toolchain.
Em uma das dependências para resolver, havia um README.md com passos simples utilizando o Conan. Dizia que compilava para Windows e compilou sem erros. Inacreditável.
Nesta hora se imagina que foi feito especificadamente um trabalho árduo para aquele projeto, mas era um código python e um txt listando as dependências daquela biblioteca.
NuGet
Tem alguns pacotes NuGet em C++. Achei curioso, já que usei NuGet somente com C#. Unica coisa que instalei foi a suite de testes para tentar aparecer no Test Explorer. Não tinha nenhuma dependencia complexa no projeto que mexi, apesar de ter visto até Boost para instalar com Nuget.
Vcpkg
Este foi a solução usada, baixa o projeto do GitHub e lá tem as receitas para funcionar no seu SO. Diferente do Conan, você não baixa versões específicas de cada biblioteca. Sempre estamos numa espécie de latest.
A integração é bem limpa com o Visual Studio, uma vez instalado e feito o comando de integração tudo parece funcionar bem.
Mesmo com essas coisas os alguns dos projetos estavam quebrados e foi um tempo pra arrumar os modos de Debug. Coisas a parte do Windows, tem aquele submodule hell do Git que não me agrada muito, mas é o que tem pra hoje.
Compilar e versionar todos na latest assim como é feito com o vcpkg, poderia ser uma opção. Já que por algum motivo os binários novos não conversavam com os antigos em determinadas atualizações. E lá vamos nós.
Este ano por conta da quarentena (COVID-19), não houve a comemoração presencial em muitos lugares, onde há palestras e bolo, afinal é um aniversário. No site comemorativo era possível fazer sete atividades em formato de lab para entender melhor a ferramenta Docker.
A seguir as notas sobre as atividades propostas nos hands-on labs.
Hands-on lab: de forma grosseira quando é oferecido uma ferramenta praticamente configurada sem precisar instalar o software no nosso computador, necessitando apenas do browser com acesso a Internet.
Formatação
Nos comandos do Docker, foi possível passar o parâmetro --format '{{json .}}' | jq para conseguir exibir a saída da informação em formato JSON. O | jq serve para embelezar a saída com novas linhas e tabulações.
Para ter uma noção do que passar para o parâmetro, use o modelo Golang de formatação (em inglês) como referência para montar a saída.
Alguns exemplos de formatação (são as respostas de algumas das atividades propostas no lab de aniversário):
Quando utilizado iteradores, a quantidade de {{end}} não agrada muito, mas funciona.
Criação de contexto
No Docker 18.09 é possível usar a variável de ambiente DOCKER_HOST para conectar em uma instância docker por SSH (conexão tcp ou sock). Novas versões como a 19.03 suporta criação de contexto para poder configurar qual contexto será utilizado de forma simples.
Volume para dentro do container
Para persistir os dados são utilizados os volumes. Quando referimos a Linux, uma referência para arquivo pode ser qualquer coisa, como uma conexão para o Docker.
/var/run/docker.sock:/var/run/docker.sock
Existem outros exemplos que podem compartilhar som e a interface gráfica X11.
O exemplo acima para expor a conexão do Docker para dentro do container está relacionado ao Jenkins para não precisar criar um ambiente Docker on Docker.
Root
Não utilizar portas aleatoriamente, algumas tem regras, como no Linux portas menores que 1024 são reservadas ao sistema e o usuário root.
Para executar o container com o usuário root, após ter mudado o usuário padrão:
docker exec --user root
Rede
Quando iniciamos um container é possível anexar na mesma rede de outro container somente utilizando a referência do que está sendo executado, o comando a seguir inicia um alpine na mesma rede do container container:broken.
docker container run -it --network container:broken alpine
Copy-pasta dos hands-on labs
Segue o modo que foi criado os arquivos Dockerfile, copy-pasta na linha de comando pra não sofrer tentando fechar o vi:
cat >Dockerfile <<EOF
FROM foo
WORKDIR /bar
ENTRYPOINT ['./baz']
EOF