YAML demais

 (noyaml.com)
2 pontos por GN⁺ 2023-09-29 | 1 comentários | Compartilhar no WhatsApp
  • YAML é usado quase como padrão em configurações de DevOps e CI, mas, por causa de conversões implícitas de tipo e diferenças entre parsers, a mesma configuração pode ser interpretada de forma diferente do esperado
  • No YAML 1.1, valores como NO, 07, 08, 04:30 e 0666 podem virar booleanos, números, horários ou octais, então é preciso deixar clara a intenção de usar strings
  • Casos envolvendo GitHub Actions, Kubernetes, CloudFormation e vários serviços de CI mostram que a sintaxe do YAML e as estruturas específicas de cada serviço podem levar a commits repetidos, camadas de escape e representações inconsistentes de jobs
  • Os links de referência reúnem YAML executável, diferenças de comportamento entre parsers, notações para strings multilinha, o problema de a versão 1.70 ser parseada como 1.7 e a justificativa de design do StrictYAML
  • Alternativas como Nickel, Dhall, CUE e Jsonnet também são apresentadas, mas a própria página parece um campo de texto editável gigante, mantendo a sátira sobre a usabilidade do YAML

Sátira do YAML como linguagem de configuração para DevOps

  • YAML é usado com frequência em configurações de DevOps, mas esta página expressa o cansaço com YAML com frases do tipo “ninguém quer usar YAML”
  • Ela lista, de forma irônica, os motivos para usar YAML como tecnologia de DevOps
    • Satiriza dizendo que ele sempre compila e pode ser implantado
    • Ironiza a falta de tratamento obrigatório de erros durante o desenvolvimento e o fato de os problemas estourarem em runtime de produção
    • Diz que uma mensagem como “algo quebrou” é melhor do que um stack trace com números de linha
    • Expressa a reclamação de que é preciso gastar tempo ao criar uma nova pipeline de CI
    • Satiriza a situação em que ele é tratado como uma escolha segura só porque o Kubernetes usa
    • Também menciona a vantagem de oferecer suporte a comentários, ao contrário do JSON

Armadilhas criadas por conversões implícitas de tipo

  • No YAML 1.1, NO pode ser parseado como tipo booleano
    • NO: Norway pode causar um problema de interpretação booleana, em vez de ser um código de país
    • Se a intenção for uma string, é preciso colocá-la entre aspas, como "NO"
    • O texto aponta que a especificação YAML 1.1 tem 22 formas de escrever true ou false
  • Valores que parecem números também podem ser interpretados de formas diferentes pelo parser
    • Os exemplos 07 e 08 mostram que o resultado pode divergir, como [ 7, "08" ]
    • A página satiriza uma situação em que um cluster Kubernetes é implantado até o sétimo e falha no oitavo
  • Strings que parecem horários também viram alvo de conversão automática
    • 04:30 pode ser convertido para 16200, o valor em segundos desde a meia-noite, em vez da string de horário escrita pelo usuário
    • Se a intenção for uma string, é preciso explicitar, como em !!str 04:30
  • Diferenças na notação octal do YAML também geram confusão
    • YAML 1.1 usa a notação 0666
    • YAML 1.2 usa a notação 0o666
    • O fato de o Kubernetes usar YAML 1.1 é tratado como um “rito de passagem” de DevOps

Problemas no tratamento de versões, SHAs e strings

  • Versões de pacotes podem ser parseadas como números de ponto flutuante
    • foo: 1.7 e bar: 1.70 podem ser interpretadas como a mesma versão
    • fizz: 1.7.0 e buzz: 1.70.0 podem ser tratadas como strings de versão diferentes
  • SHAs curtos do Git usados em CI também podem não ser seguros
    • Um SHA de 8 caracteres pode ser composto só por números
    • my.flaky_version com ${GIT_SHORT_SHA} sem aspas pode não ser uma string
    • O texto diz que esse valor é string em cerca de 98% dos casos, e 100% string se for envolvido como "${GIT_SHORT_SHA}"
  • Um caso envolvendo a toolchain do Rust também é incluído como link de referência

Custos visíveis em configurações de CI e infraestrutura

  • Há um caso de alguém que, enquanto aprendia GitHub Actions, fez commit/push 8 vezes em uma hora, com a última mensagem de commit sendo “I don't really like yml”
  • Também há um exemplo de como seria escrever SQL em YAML
    • Estruturas SQL como SELECT, FROM, WHERE EXISTS, AND, EQUALS e LT viram uma estrutura aninhada em YAML
    • A página satiriza como uma expressão SQL curta se transforma em um formato YAML longo e verboso
  • Cada serviço de CI também expressa jobs e steps de seu próprio jeito
    • Azure DevOps usa o formato job, steps e script sob jobs
    • CircleCI usa o formato jobs, job1, steps, checkout e run
    • O exemplo de um “sistema de CI do futuro” mostra que a mesma tarefa poderia ser expressa por mais uma estrutura aninhada diferente
  • Há um exemplo no CloudFormation em que, ao inserir uma função SEARCH dentro de DashboardBody do CloudWatch, é preciso escapar de novo um conteúdo já escapado e fechar todo o JSON com aspas duplas

YAML executável e diferenças entre parsers

Materiais relacionados e alternativas

Reações à própria página

  • A coletânea de reações no Reddit também toma o design da página como alvo de críticas
    • Há uma reação dizendo que o site é um campo de texto editável gigante
    • Há uma reação dizendo que os hyperlinks não são clicáveis
    • Há uma piada dizendo que foi possível selecionar todo o texto da página e apagá-lo, resolvendo o problema
    • Há uma reação que concorda com a ideia de odiar YAML, mas questiona as decisões de design do site
  • A frase final afirma que a página foi feita intencionalmente para ser “tão usável quanto YAML”

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-29
Opiniões do Hacker News

  • Minha dor de cabeça favorita é esta:
    07
    08
    O resultado vira [ 7, "08" ]
    Por causa de uma suposição sobre octal e strings
    Essa suposição foi encontrada em um YAML gerado por template três níveis abaixo e levou a uma queda total do nosso cluster k8s, mas só o cluster 08 quebrou. Os sete anteriores rodaram bem

    • Sou a pessoa que criou este site. Eu adoraria receber isso como pull request
    • Droga, acho que a maioria dos desenvolvedores hoje em dia nem sabe o que são octais ou literais numéricos octais escritos com prefixo 0
      Eu ri desse comentário, mas, considerando que em 2023 quase ninguém usa octais em arquivos de configuração, esse comportamento e essa suposição não fazem sentido. Hexadecimal até vai, decimal é óbvio, mas octal já é demais
    • Não entendo como isso poderia ser o comportamento correto
    • Quando você diz que “descobriu” essa suposição, isso quer dizer que não leu a especificação e começou a usar assumindo que conhecia o comportamento?
      Quem gerou aquilo com certeza não serializou os dados com uma biblioteca. Se tivesse usado uma biblioteca, ela teria convertido o tipo para o formato correto

  • O YAML tem muitos problemas, mas acho que o problema central de verdade é tentar colocar lógica dentro da configuração
    Se usado apenas para dados, e não para lógica, YAML é um dos formatos de dados mais fáceis para humanos lerem e escreverem
    Em CI/CD sempre existe algum grau de lógica, quase nunca se resolve só com YAML puro, e ainda entram templates estranhos no meio. Às vezes penso que seria melhor oferecer uma API de verdade para uma linguagem de programação de verdade

    • Isso está mais para uso indevido de YAML do que um problema do YAML. Completude de Turing acidental é um problema em qualquer lugar
      Tive exatamente o mesmo problema 15 anos atrás usando o Ant baseado em XML, e a culpa não era do XML
      Para mim, o principal problema do YAML é a falta de segurança de tipos. Coisas como indentação errada, erros de digitação em chaves e strings que são parseadas como booleanos
      Fora isso, acho um bom formato: é conciso e tem muito menos ruído sintático do que outros formatos. Por isso criei https://github.com/crdoconnor/strictyaml, para que as pessoas usem YAML com tipos seguros e recebam mensagens de erro imediatas e claras sobre esses problemas
    • Pela minha experiência, quanto mais coisas uma linguagem consegue fazer, mais as pessoas a usam de formas complexas
      Porque acabam trazendo abstrações por acharem que precisam delas. Por isso sempre evito usar uma linguagem de programação Turing-completa como formato de configuração
      Já passei horas seguindo o AWS CDK linha por linha em um depurador JavaScript. Se fosse um arquivo yaml/Json/seja lá o que for simples e burro, esse problema não teria existido. Era um projeto pequeno e não precisava dessa complexidade
      Por isso, mesmo na configuração de ferramentas JS, prefiro JSON a JS. É também por isso que configurações do webpack viram bagunça. Quando se pode usar uma linguagem de verdade, o “sensor de DRY” das pessoas dispara e elas tornam tudo mais complexo
      Quando é declarativo, fica mais fácil seguir práticas padrão e o suporte de ferramentas também melhora. Se o package.json de fato virasse algo como build.gradle, seria muito pior
    • Configuração executável pode trazer grandes vantagens. Python é uma escolha óbvia
      Basta definir: “execute o script em um interpretador Python dentro de um cgroup bem restrito, e o resultado deve ser um dicionário chamado CONFIG”. A lógica de wrapper serializa isso de uma forma conveniente para o programa que será configurado
    • Não entendo por que um projeto de schema ruim seria culpa do YAML, e não de quem projetou o schema
      É parecido com reclamar da complexidade ou rigidez do helm. Charts do Helm não se escrevem sozinhos. Acho que é porque é mais fácil reclamar e ignorar o problema do que entendê-lo e implementá-lo
    • Concordo 100%. Quando as pessoas dizem que odeiam YAML, em muitos casos acho que o que elas querem dizer de verdade é “odeio descrever pipelines em YAML”. Eu também entendo essa sensação
      Como formato de arquivo, YAML tem prós e contras. Mas o problema real está em tentar expressar condicionais, loops, funções e coisas como classes/subclasses por meio de templates em um formato de arquivo equivalente a JSON
      YAML é ok para configurações pequenas. Mas, no momento em que você precisa de algum tipo de fluxo de controle, ele cresce muito rapidamente e vira um espaguete específico de fornecedor

  • Jinja dentro de YAML é claramente um antipadrão, na minha visão
    Parece algo que surgiu porque não se projetou programabilidade suficiente desde o início e, depois, as pessoas passaram a imitar projetos que tiveram sucesso ao seguir esse caminho
    O texto menciona alternativas como Dhall e Jsonnet, mas dá para pensar em mais duas
    A primeira é criar uma biblioteca de configuração para uma linguagem de programação de verdade e fazer essa biblioteca gerar arquivos de configuração JSON. Esse JSON não seria algo editado manualmente, mas apenas um artefato verificável. O usuário passaria a versionar a configuração em forma de código, com suporte de ferramentas. Ficar mais difícil fazer correções emergenciais diretamente no servidor é uma desvantagem e também uma vantagem
    A segunda é Starlark. É uma linguagem derivada de Python, não Turing-completa, desenvolvida inicialmente para o sistema de build Bazel. Há várias implementações, e não sei até que ponto a compatibilidade é profunda, mas também existem bindings para Python: https://github.com/caketop/python-starlark-go, https://github.com/inducer/starlark-pyo3

    • Concordo que Jinja dentro de YAML é um antipadrão, mas especialmente porque os caracteres padrão de bloco/expressão, {% e {{, são ambos caracteres de YAML, então é preciso colocar aspas em todos os pontos de uso
      Acho abordagens como ${{ do GitHub Actions, ou <%, <<, muito melhores. Claro que existe o risco de <<: ser sintaxe de YAML, mas isso não é Jinja válido
      Se a ideia é dizer que não se deve colocar nada executável dentro de YAML, acho que esse barco já zarpou. As pessoas perceberam que deixar as partes literais como padrão e inserir trechos executáveis de vez em quando é uma boa forma de criar conteúdo, como em ASP/JSP/PHP
      Se quiser começar uma flamewar irmã nesta thread, basta falar de HCL e for_each, mas pelo menos aqui é melhor não fazer isso
    • Esse é o caminho que a Amazon escolheu com o CDK. Funciona até certo ponto, mas, para fazer algo que não seja trivial, dá muito a sensação de estar construindo um dispositivo de Rube Goldberg
      Não sei quanto disso é culpa do CDK e quanto é porque o CloudFormation já era ruim por natureza
    • Concordo. Trabalhar com YAML em templates era tão trabalhoso que acabei criando uma ferramenta chamada Cels por causa disso: https://github.com/pacha/cels
      Gosto de Jsonnet e Starlark, mas, na prática, a maioria dos casos de uso não precisa de uma nova linguagem de programação. Normalmente você só quer criar um documento-base e modificá-lo aplicando patches. Isso deixa tudo muito mais simples
      A experiência de usar YAML puro em si não é tão ruim. O formato tem algumas partes bem questionáveis, mas é utilizável. Acho que o problema aparece na complexidade das soluções que é preciso adicionar para adaptar documentos a vários ambientes
    • Só de pensar em voltar a mexer com Ansible por causa disso já é um pesadelo
      Ouvi dizer que antes havia uma DSL Python de verdade que podia ser usada em vez de YAML, mas parece ter sido descontinuada. Então agora loops e if-then viram blocos horríveis e extensos em YAML, e o Jinja é interpretado de forma completamente imprevisível
    • Fico me perguntando se existe uma ferramenta independente capaz de executar código Starlark, como jsonnet, para gerar JSON ou YAML

  • Acho que o YAML em si é excelente. O que não é excelente é que tornamos a parte de deploy do CD difícil demais
    Admito que nossa configuração dentro do Azure DevOps não é lá essas coisas, mas é surpreendente que existam organizações em que várias equipes ou 5 a 6 operadores precisam lidar com esse tipo de ferramenta. Não sei em lugares como o Google, mas para uma empresa comum, com no máximo 50 mil usuários simultâneos, ou geralmente muito menos que isso, parece exagerado
    No início dos anos 2000, era mais fácil fazer deploy de uma aplicação web enterprise em um IIS on-premises, onde menos de 0,25 funcionário em tempo integral cuidava de todo tipo de coisa como balanceamento de carga, rede etc., do que fazer deploy da mesma coisa em uma configuração “moderna” de hoje
    Claro que pipelines modernos têm vantagens. Superamos muitos problemas do tipo “na minha máquina funciona” e elevamos bastante o controle de qualidade com gates de aprovação melhores. Mas o deploy em si ainda é um pesadelo em 2023
    Isso talvez não seja um problema para programadores do HN em empresas de tecnologia de verdade ou em empresas com boas equipes dedicadas de DevOps. Mas, no mundo enterprise não tecnológico, CI/CD nunca esteve tão ruim na minha carreira
    Dá para culpar o YAML, ou culpar o fato de que é preciso YAML demais para fazer qualquer coisa e de que templates são difíceis. Mas, na minha opinião, o problema organizacional é muito maior que o problema técnico. As ferramentas de CD precisam ser muito mais automatizadas para que o trabalho do desenvolvedor não vire descrever infraestrutura como código
    É bom que isso seja possível, mas a realidade é que se pede a milhões de desenvolvedores que façam deploy de uma infraestrutura que talvez mal entendam. Nunca vi um desenvolvedor que não quisesse simplesmente entregar um contêiner e esperar que a rede e as “coisas do lado do servidor” fossem resolvidas automaticamente
    Se não fizer isso, você acaba com um monte de VNETs e sub-redes cujo funcionamento ninguém conhece bem, e a organização perde muito dinheiro porque os desenvolvedores não sabem que dá para fazer com /x

    • A nuvem é o novo mainframe
      Você escreve algum tipo de “definição de job” offline, envia para um sistema compartilhado proprietário, espera na fila e então recebe arquivos de log gerados por um sistema que você não controla. Como não dá para executar localmente o código do sistema proprietário na workstation, o ciclo de iteração interna leva, no mínimo, dezenas de minutos; no pior caso, horas ou dias
      Não há modo de pré-visualização, “what if” nem “dry run”. Mesmo que chamem de “teste”, como só existe um sistema, na prática você está trabalhando em produção
      O problema real não é o YAML. Não importaria se o pipeline fosse scriptado na linguagem de programação de Deus
      O motivo pelo qual desenvolver software em workstations, em vez de em mainframes centrais de timesharing, ganhou tanta popularidade foi que isso tornou a iteração interna dramaticamente mais rápida, isolou o ambiente de produção e devolveu o controle às mãos dos desenvolvedores
      A geração atual de pipelines de CI/CD, em geral, desfaz tudo isso
      Kubernetes em uma única máquina recupera a maior parte das vantagens do desenvolvimento baseado em workstation, mas ainda é um sistema muito novo e tem muitas dores de crescimento
      Como problema relacionado, há ótimas soluções para o desenvolvedor que opera sozinho uma aplicação por meio de cliques, e também há ótimas soluções para megaempresas que fazem automação em larga escala para milhares de desenvolvedores. Mas o meio-termo, em que alguns desenvolvedores enterprise gerenciam dezenas de aplicações, é simplesmente caos
    • Não sei se realmente superamos por completo o “na minha máquina funciona”
      Já aconteceu várias vezes de funcionar bem na minha imagem Docker, mas quebrar na imagem implantada
      É um tipo de problema que só dá para superar se todo o pipeline de build e deploy for totalmente transparente, se você tiver acesso completo ao repositório de imagens e se puder de fato controlar as instruções de build. Isso é tão restritivo quanto controlar o sistema operacional local, e acho que vai falhar em tantas organizações quanto aquelas em que o código quebrava ao ser movido para outra máquina
    • Não sei qual é o problema com deploy. Nas coisas que configurei, era só marcar o commit com uma tag e dar push, e aquele commit era implantado
      Em qualquer sistema de CI/CD, configurar isso parece bastante intuitivo

  • Acho que há uma solução para manter a paz se todo mundo respeitar universalmente uma única regra: não use YAML fora do ecossistema Python
    Assim, quem gosta de formatos de scripting obscuros que priorizam legibilidade acima de correção, durabilidade e manutenibilidade pode continuar usando tabs, tipagem frouxa e sintaxe obscura. O resto de nós não precisa. Quem prefere sintaxe estilo C consegue manter a sanidade
    Acho que agora cheguei ao cerne do problema. Para mim, um desenvolvedor de sintaxe C, espaço em branco sintático é pura loucura. Espaço em branco é formatação, não informação nem comando. Boa formatação ajuda e é útil, e um bom desenvolvedor de sintaxe C também se preocupa com uma formatação legível
    Em Python e YAML, a formatação é informação diretiva. Há a vantagem de que todo código funcional fica legível. Mas por que o código precisa necessariamente ser legível para funcionar?
    Basta imaginar trabalhar com um colega tipo YAML. Você manda uma mensagem longa e ele responde: “O quê? Isso não faz sentido”. Aí você descobre que o significado quebrou porque não colocou linhas em branco entre os parágrafos. Você recoloca as linhas em branco, envia a mensagem, e só então ele consegue ler. Sem formatação sintaticamente correta, a informação enviada não tinha sentido

    • Outro propósito do código como software, além de ser executável, é ser legível
      Há inúmeras formas de formatar, e eu prefiro que as pessoas usem linters ao escrever código. De preferência o mesmo linter que eu uso, se possível
      Essas linguagens impõem estruturas sintáticas padrão. Isso é bom, porque reduz as formas de escrever código difícil de ler
    • Normalmente, espaço em branco significativo é tratado como uma questão filosófica ou religiosa. Há quem goste e quem deteste; os dois lados racionalizam suas preferências, mas no fim seria uma questão de gosto forte
      Só que agora passei a achar que a diferença não é filosofia, e sim ferramenta. Algumas ferramentas, como editores de texto ou clientes de e-mail, dão bom suporte a espaço em branco significativo, e outras não
      Todos os editores de texto que uso estão configurados para mostrar espaços e tabs, e os exibem de forma diferente. Normalmente algo como pontos discretos e traços discretos. Estou acostumado e isso não me incomoda em nada
      Do meu ponto de vista, código não é texto arbitrário. Usa fonte monoespaçada, que eu não usaria em um livro, e diferencia a sintaxe por cores. Não há motivo para não tornar os espaços visíveis também
      Ainda prefiro linguagens sem espaço em branco significativo, mas não desgosto dessas linguagens. Para mim, não é problema algum
      Mas, se a ferramenta de que você gosta não dá bom suporte a espaço em branco significativo, não mostra os espaços ou você até programa com fonte proporcional, então é inevitável odiar intensamente espaço em branco significativo e vê-lo como pura loucura
    • Vindo de C, eu também pensava que espaço em branco não era informação nem comando. No começo do Python, por isso, eu até o via com certo desdém
      O que me fez mudar de ideia foi, curiosamente, usar CoffeeScript. Eu não gosto muito de JavaScript, e usar CoffeeScript parecia uma versão refinada de The Good Parts, de Crockford. Não dava para criar acidentalmente as partes ruins
      Além disso, o jeito como a indentação vira código era bem agradável. O único inconveniente era não poder apertar % no Vi em uma chave de abertura ou fechamento para encontrar a outra ponta do bloco. Por outro lado, graças à indentação, quando o código parecia estranho, muitas vezes ele estava estranho de fato
      Mesmo assim, ainda não aprendi muito Python. Hoje em dia uso TypeScript, mas se um dia surgir CoffeeTypeScript…
    • É meio estranho que TOML esteja na biblioteca padrão e YAML não. E TOML é feio
    • A comunidade Kubernetes está olhando com um brilho interessante nos olhos

  • Por isso comecei a criar meu próprio formato, chamado BCL: https://github.com/wkhere/bcl
    Ele não vai ajudar imediatamente em todos os casos de uso de YAML, mas pelo menos pode ser uma forma mais elegante de definir recursos no estilo do Terraform. Na prática, já está ajudando como substituto do HCL em um projeto interno, e essa foi a motivação final para criá-lo
    Em uma visão mais ampla, não sei como ajudar no problema de o YAML estar em toda parte no Kubernetes. Mais da metade do meu problema com $daily_job está no fato de que juntar o chart Helm final a partir de várias fontes é algo muito tosco
    Não quero dizer que o Helm seja uma ferramenta intrinsecamente ruim, nem que minha empresa tenha escolhido o Helm de uma forma bem ruim. Acho que todos estão fazendo o melhor possível considerando a situação
    Mas manipular templates de texto com espaço em branco significativo é propenso demais a erros, e os erros são descobertos tarde demais. Acho que o Kubernetes teria sido muito melhor se tivesse usado um formato próprio baseado em sintaxe estilo C, em vez de tentar provar como YAML é incrível. Ainda mais porque YAML nem é incrível

  • Isso é o efeito de plataforma interna. Conforme a aplicação cresce, a configuração também se expande até acabar virando uma linguagem de programação — só que uma linguagem cheia de bugs, mal especificada e com uma usabilidade terrível
    Você declara falência da configuração e escolhe um novo formato de configuração. E o ciclo se repete
    Claro que o formato em si também não é isento de culpa. Quanto mais flexível ele for, mais fácil é ser reaproveitado como uma linguagem de programação ruim
    Depois de cometer esse erro repetidamente, hoje eu escolheria o formato de configuração mais simples possível para configurações básicas. Até .ini pode ser poderoso demais. “Configurações” mais complexas eu delegaria a uma linguagem de programação de verdade, de preferência a linguagem em que a aplicação foi escrita

  • A esmagadora maioria dos exemplos de “YAML é ruim” se resolve colocando todos aqueles literais estranhos entre aspas
    É verdade que YAML às vezes irrita. Por exemplo, listas de mapas ficam esquisitas rapidinho, e espaços em branco significativos quase certamente vão te passar uma rasteira em algum momento. Mas esses textos parecem, sendo generoso, meio desleixados

    • Só que, nesses exemplos, ninguém usa aspas, e as ferramentas também não fazem isso por você
      O ecossistema inteiro de YAML incentiva escrever valores sem aspas. Na maior parte do tempo funciona bem, até quebrar só de vez em quando o suficiente para te derrubar em produção

  • EDN é um subconjunto de Clojure: https://github.com/edn-format/edn
    É claro, permite streaming, é extensível e não é sensível a espaços em branco. Ainda assim, há convenções de formatação para legibilidade

    • É a primeira vez que vejo um formato de dados que distingue explicitamente listas e conjuntos, e isso é bom
      Mas não entendo bem qual é a diferença semântica entre lista e vetor. Na minha cabeça, arrays e listas encadeadas são detalhes de implementação de estruturas de dados no código, não diferenças de formato de dados
    • É muito melhor do que as alternativas. Eu realmente espero que comece a ser usado também fora do ecossistema Clojure
    • Para ser preciso, é difícil dizer que ele seja independente de espaços em branco, porque espaços são necessários para separar ou delimitar elementos
      Ainda assim, não há nenhuma brincadeira de indentação semântica. É bonito o fato de vírgulas serem consideradas espaços em branco e não serem necessárias

  • Quando os alunos enviam trabalhos pela plataforma de e-learning, recebemos todos os envios em um arquivo XML bem grande
    Lemos os envios, passamos por análise estática e execução de exemplos e então escrevemos, para cada trabalho, um arquivo YAML com todos os envios, dicas de correção, comentários e campos para inserir notas
    Depois, a partir do arquivo YAML, geramos relatórios, estatísticas e PDFs de feedback passando por markdown+leitura (Pandoc)
    Para nós, YAML funciona muito bem. Porque é fácil inserir feedback adicional em sintaxe Markdown. Por exemplo, algo como - you missed a \NOT` here` devidamente indentado
    Graças às várias formas de escape de texto em bloco, conseguimos exibir envios de SQL de forma legível, sem caracteres de escape, mesmo quando os alunos usam diversos delimitadores de SQL
    Como tudo é texto simples, usamos apenas um editor de texto e armazenamos no git para garantir responsabilidade na correção. Como mantemos tudo legível por máquina, também podemos testar novas ferramentas de análise estática em envios antigos
    Mas, como pipelines de CI e configurações de automação residencial também precisam ser escritos em YAML, entendo a dor

    • A remoção de indentação de texto embutido talvez seja o melhor recurso do YAML
      Em TOML, é preciso abrir mão da indentação em strings de várias linhas, reduzindo a legibilidade, ou colocar uma barra invertida no fim de cada linha. Nenhuma das opções é ideal
      Por isso, para DSLs ou configurações que precisam incluir Markdown ou outros formatos de texto, YAML é bem bom e tem vantagem sobre coisas como TOML
      Mas eu não atribuiria toda a responsabilidade pela “fadiga de YAML” apenas às ferramentas de CI e DevOps que escolheram YAML como formato de transporte para DSLs. Como o texto original resumiu bem, o próprio YAML também tem problemas grandes
      O famoso “problema da Noruega” foi resolvido no YAML 1.2, e o problema de analisar zeros à esquerda como octal também foi resolvido no YAML 1.2. Conversões de tipo excessivamente agressivas para números, datas, horários etc. podem ser confusas. Os modos de tratamento de strings de várias linhas também podem ser bastante confusos. Serialização insegura não é um problema em parsers modernos, mas é preciso cuidado ao usar YAML em linguagens mais antigas com recursos dinâmicos, como Ruby, Python e Java
      Tudo isso é problema da própria especificação do YAML