YAML çok fazla

 (noyaml.com)
2 puan yazan GN⁺ 2023-09-29 | 1 yorum | WhatsApp'ta paylaş
  • DevOps ve CI yapılandırmalarında YAML standartmış gibi kullanılsa da, örtük tür dönüşümü ve ayrıştırıcı farkları nedeniyle aynı yapılandırma bile beklenenden farklı yorumlanabilir
  • YAML 1.1'de NO, 07, 08, 04:30, 0666 gibi değerler boolean·sayı·zaman·sekizlik biçimine dönüşebilir; bu yüzden niyetin string ise bunu açıkça belirtmek gerekir
  • GitHub Actions, Kubernetes, CloudFormation ve çeşitli CI hizmetlerinden örnekler, YAML söz dizimi ile hizmete özgü yapıların tekrarlanan commit'lere, iç içe escape'lere ve birbirinden farklı job ifadelerine yol açabildiğini gösterir
  • Referans bağlantıları, çalıştırılabilir YAML, ayrıştırıcıya göre davranış farkları, çok satırlı string gösterimi, 1.70 sürümünün 1.7 olarak parse edilmesi sorunu ve StrictYAML'in tasarım gerekçelerini birlikte topluyor
  • Nickel, Dhall, CUE, Jsonnet gibi alternatifler de sunuluyor; ancak sayfanın kendisi de devasa, düzenlenebilir bir metin alanı gibi görünerek YAML kullanılabilirliğine dair hicvi sürdürüyor

DevOps yapılandırma dili olarak YAML hicvi

  • YAML, DevOps yapılandırmalarında yaygın kullanılıyor; ancak bu sayfa “kimse YAML kullanmak istemiyor” tarzı ifadelerle YAML yorgunluğunu öne çıkarıyor
  • Neden YAML'ın DevOps teknolojisi olarak kullanıldığını tersine bir ironiyle sıralıyor
    • Her zaman derlenip deploy edilebiliyormuş gibi bir dille alay ediyor
    • Geliştirme sırasında zorunlu hata yakalama olmamasını ve sorunların production çalışma anında patlamasını tiye alıyor
    • Satır numaralı stack trace yerine “bir şey bozuldu” mesajının daha iyi olduğu ima ediliyor
    • Yeni bir CI pipeline'ı kurarken zaman yakmak zorunda kalmaktan şikâyet ediliyor
    • Kubernetes kullanıyor diye bunun güvenli bir tercih sayılmasını hicvediyor
    • JSON'dan farklı olarak yorum satırlarını desteklemesi de artı olarak anılıyor

Örtük tür dönüşümünün yarattığı tuzaklar

  • YAML 1.1'de NO, boolean türü olarak parse edilebilir
    • NO: Norway, ülke kodu değil boolean yorumlama sorunu doğurabilir
    • Amaç string ise "NO" gibi tırnak içine alınmalıdır
    • YAML 1.1 spesifikasyonunda true veya false yazmanın 22 farklı yolu olduğu belirtiliyor
  • Sayı gibi görünen değerler de ayrıştırıcıya göre farklı ele alınabilir
    • 07 ve 08 örneği, sonucun [ 7, "08" ] gibi farklılaşabileceğini gösteriyor
    • Bu durum, Kubernetes kümesinin yedinciye kadar deploy olup sekizincide patlaması üzerinden hicvediliyor
  • Zaman gibi görünen string'ler de otomatik dönüşüm hedefi olabilir
    • 04:30, kullanıcının yazdığı saat string'i yerine gece yarısından sonraki saniye sayısı olan 16200 değerine dönüşebilir
    • Amaç string ise !!str 04:30 gibi açıkça belirtilmelidir
  • YAML'ın sekizlik gösterim farkı da kafa karıştırıyor
    • YAML 1.1, 0666 gösterimini kullanır
    • YAML 1.2, 0o666 gösterimini kullanır
    • Kubernetes'in YAML 1.1 kullanması, “DevOps geçiş ritüeli” gibi sunuluyor

Sürüm, SHA ve string işleme sorunları

  • Paket sürümleri kayan noktalı sayı gibi parse edilebilir
    • foo: 1.7 ve bar: 1.70, aynı sürümmüş gibi yorumlanabilir
    • fizz: 1.7.0 ve buzz: 1.70.0, farklı sürüm string'leri olarak ele alınabilir
  • CI'da kullanılan kısa Git SHA'ları da güvenli olmayabilir
    • 8 karakterlik SHA tamamen rakamlardan oluşabilir
    • ${GIT_SHORT_SHA} ifadesini tırnaksız kullanan my.flaky_version, string olmayabilir
    • Bunun yaklaşık %98 oranında string olduğu, "${GIT_SHORT_SHA}" gibi sarılırsa %100 string olacağı söyleniyor
  • Rust toolchain örneği de referans bağlantıları arasında yer alıyor

CI ve altyapı yapılandırmalarında ortaya çıkan maliyet

  • GitHub Actions öğrenirken bir saatte 8 kez commit/push yapıldığı ve son commit mesajının “I don't really like yml” olduğu bir örnek veriliyor
  • SQL'i YAML ile yazsaydınız nasıl görünürdü sorusuna dair bir örnek de bulunuyor
    • SELECT, FROM, WHERE EXISTS, AND, EQUALS, LT gibi SQL yapıları YAML iç içe yapısına dönüşüyor
    • Kısa SQL ifadesinin uzun ve lafı uzatan bir YAML biçimine dönüşmesi hicvediliyor
  • Her CI hizmetinin job ve step ifade etme biçimi de farklı
    • Azure DevOps, jobs altında job, steps, script biçimini kullanıyor
    • CircleCI, jobs, job1, steps, checkout, run biçimini kullanıyor
    • “Geleceğin CI sistemi” örneği, aynı işin başka bir iç içe yapıyla ifade edilebileceğini gösteriyor
  • CloudFormation'da CloudWatch DashboardBody içine SEARCH fonksiyonu konulduğunda, zaten escape edilmiş içeriğin tekrar escape edilmesi ve tüm JSON'un çift tırnakla kapatılması gereken bir örnek de yer alıyor

Çalıştırılabilir YAML ve ayrıştırıcı farkları

İlgili kaynaklar ve alternatifler

Sayfanın kendisine yönelik tepkiler

  • Reddit tepkileri, sayfa tasarımını da eleştiri konusu yapıyor
    • Web sitesinin devasa düzenlenebilir bir metin alanı olduğu yönünde yorumlar var
    • Köprülerin tıklanamadığı söyleniyor
    • Sayfadaki tüm metnin seçilip silinebilmesiyle sorunun çözüldüğüne dair bir şaka yapılıyor
    • YAML'dan hoşlanmama fikrine katılındığı, ancak web sitesi tasarım tercihinin sorgulandığı belirtiliyor
  • Son ifade, sayfanın bilerek “YAML kadar kullanılabilir” hale getirildiğini söylüyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-29
Hacker News yorumları

  • Benim en sevdiğim baş ağrısı şu:
    07
    08
    Sonuç [ 7, "08" ] oluyor
    Bunun nedeni sekizlik sayı ve string varsayımları
    Bu varsayım, üç seviye aşağıda şablonla üretilmiş bir YAML içinde ortaya çıktı ve bizde tüm k8s cluster'ında kesintiye yol açtı; sadece 08 cluster'ı bozuldu. Önceki 7 tanesi sorunsuz çalıştı

    • Bu web sitesini yapan kişiyim. Bunu pull request olarak gönderirsen harika olur
    • Kahretsin, günümüzde çoğu geliştiricinin sekizlik sayıları ya da 0 önekiyle yazılan sekizlik sayı literallerini bilmediğini düşünüyorum
      Bu yoruma güldüm ama 2023'te config dosyalarında sekizlik sayı kullanan neredeyse kimse olmadığını düşününce, bu davranış ve varsayım mantıklı değil. Onaltılık olsa neyse; ondalık zaten beklenecek şey, ama sekizlik biraz fazla
    • Bunun nasıl doğru davranış olabileceğini anlayamıyorum
    • O varsayımı “keşfettik” demek, spesifikasyonu okumayıp davranışı bildiğinizi varsayarak kullanmaya başladığınız anlamına mı geliyor?
      Bunu üreten taraf kesinlikle veriyi bir kütüphaneyle serialize etmemiş olmalı. Kütüphane kullansaydı tipleri doğru biçime dönüştürürdü

  • YAML'de çok sorun var ama bence asıl temel sorun config içine mantık koymaya çalışmak
    YAML yalnızca veri için kullanılır, mantık için kullanılmazsa insanların okuyup yazması için iyi veri formatlarından biri
    CI/CD'de her zaman bir miktar mantık vardır; saf YAML ile biten durum neredeyse yoktur, üstüne tuhaf şablonlar da karışır. Keşke gerçek bir programlama dili için gerçek bir API sunsalar diyorum

    • Bu YAML sorunu değil, daha çok YAML'in yanlış kullanımı. Kazara Turing-tamlık her yerde sorun
      15 yıl önce XML tabanlı Ant kullanırken de aynı sorun vardı ve bu XML'in suçu değildi
      YAML'in başlıca sorununun tip güvenliği eksikliği olduğunu düşünüyorum. Yanlış girintileme, anahtar adlarında yazım hataları, boolean olarak parse edilen string'ler gibi şeyler
      Bunun dışında kısa ve öz, diğer formatlara göre sözdizimsel gürültüsü çok daha az olduğu için iyi bir format olduğunu düşünüyorum. Bu yüzden insanların tip güvenli YAML kullanması ve bu tür sorunlar hakkında anında, net hata mesajları alması için https://github.com/crdoconnor/strictyaml'i yaptım
    • Deneyimlerime göre bir dil ne kadar çok şey yapabiliyorsa, insanlar onu o kadar karmaşık biçimlerde kullanıyor
      Çünkü gerekli olduğunu düşünüp soyutlamaları işin içine çekiyorlar. Bu yüzden config formatı olarak Turing-tam bir programlama dili kullanmaktan her zaman kaçınırım
      AWS CDK'yı JavaScript debugger'ıyla satır satır izleyerek saatler harcadığım oldu. Basit ve aptal bir yaml/Json/ne olursa dosyası olsaydı böyle bir sorun olmazdı. Küçük bir projeydi ve karmaşıklığa ihtiyaç yoktu
      Bu yüzden JS araçlarının config'inde de JS yerine JSON'u tercih ediyorum. webpack config'inin çorbaya dönmesinin nedeni de burada. Gerçek bir dil kullanma imkânı olunca insanların “DRY sensörü” devreye giriyor ve işleri daha karmaşık hale getiriyorlar
      Deklaratif olursa standart pratikleri takip etmek de daha kolay, araç desteği de daha iyi olur. package.json gerçekten build.gradle gibi olsaydı çok daha kötü olurdu
    • Çalıştırılabilir config büyük avantaj sağlayabilir. Python bariz tercih
      “Script'i sıkı kısıtlı bir cgroup içindeki Python yorumlayıcısında çalıştır ve sonuçta CONFIG adlı bir dict ortaya çıkmalı” diye belirlemek yeterli. Wrapper mantığı da bunu ayarlanacak program için uygun şekilde serialize eder
    • Kötü şema tasarımının neden YAML'in suçu olup şema tasarımcısının suçu olmadığını anlamıyorum
      helm'in karmaşıklığından ya da katılığından şikâyet etmeye benziyor. Helm chart'ları kendi kendine yazılmıyor. Sanırım sorunu anlamak ve uygulamaktansa şikâyet edip görmezden gelmek daha kolay geliyor
    • %100 katılıyorum. İnsanlar YAML'den nefret ettiklerini söylediğinde çoğu zaman asıl kastettikleri şeyin “YAML ile pipeline tanımlamaktan nefret ediyorum”a daha yakın olduğunu düşünüyorum. Ben de o hissi anlıyorum
      Dosya formatı olarak YAML'in artıları ve eksileri var. Ama asıl sorun, koşullar, döngüler, fonksiyonlar, şablonlar üzerinden sınıflar/alt sınıflar gibi şeyleri JSON muadili bir dosya formatıyla ifade etmeye çalışmak
      YAML küçük config'ler için gayet iyi. Ama herhangi bir tür kontrol akışına ihtiyaç duyulduğu an, satıcıya özel spagettiye çok hızlı dönüşüyor

  • YAML içinde Jinja bence açıkça bir antipattern
    Başta yeterli programlanabilirlik düşünülerek tasarlanmamış, sonradan da bu yolu seçip başarılı olan projeleri insanların taklit etmesiyle ortaya çıkmış gibi görünüyor
    Yazıda Dhall ve Jsonnet gibi alternatiflerden söz ediliyor; iki seçenek daha düşünülebilir
    Birincisi, gerçek programlama dilleri için bir yapılandırma kütüphanesi oluşturup bu kütüphanenin JSON yapılandırma dosyası üretmesini sağlamak. Bu JSON, elle düzenlenecek bir hedef olarak değil, yalnızca denetlenebilir bir çıktı olarak ele alınır. Kullanıcı, araç desteği alan kod biçimindeki yapılandırmayı sürüm kontrolüne koyar. Sunucuda doğrudan acil düzeltme yapmayı zorlaştırması hem dezavantaj hem avantajdır
    İkincisi, Starlark. İlk olarak Bazel derleme sistemi için geliştirilmiş, Python türevi ve Turing-complete olmayan bir dil. Birden fazla implementasyonu var; uyumluluğun ne kadar derin olduğunu bilmiyorum ama Python bağlamaları da var: https://github.com/caketop/python-starlark-go, https://github.com/inducer/starlark-pyo3

    • YAML içindeki Jinja’nın antipattern olduğuna katılıyorum; özellikle varsayılan blok/ifade karakterleri olan {% ve {{ ikisi de YAML karakteri olduğu için tüm kullanım noktalarını tırnak içine almak gerekmesi nedeniyle
      GitHub Actions’taki ${{ ya da <%, << gibi yaklaşımların çok daha iyi olduğunu düşünüyorum. Elbette <<:’ın YAML sözdizimi olması gibi bir risk var, ama bu geçerli Jinja değil
      YAML içine çalıştırılabilir herhangi bir şey koyulmamalı demekse, bence o gemi çoktan kalktı. Çünkü insanlar literal kısımları varsayılan bırakıp arada yalnızca çalıştırılan kısımlar eklemenin, ASP/JSP/PHP’de olduğu gibi içerik üretmek için iyi olduğunu fark etti
      Bu iş parçacığında kardeş bir flame war başlatmak isterseniz HCL ve for_each konusunu açabilirsiniz, ama en azından burada yapmamak daha iyi olur
    • Amazon’un CDK’de seçtiği yol bu. Bir ölçüde çalışıyor, ama azıcık karmaşık bir şey yapmak istediğinizde Rube Goldberg makinesi kuruyormuş hissi çok güçlü
      Bunun ne kadarının CDK’den, ne kadarının CloudFormation’ın zaten kötü olmasından kaynaklandığını bilmiyorum
    • Katılıyorum. Şablonlaştırılmış YAML ile çalışmak o kadar zahmetliydi ki sonunda bu yüzden Cels adlı bir araç yaptım: https://github.com/pacha/cels
      Jsonnet ve Starlark’ı seviyorum, ama pratikte çoğu kullanım senaryosunda yeni bir programlama diline ihtiyaç yok. Genelde sadece temel bir belge oluşturup üzerine patch uygulayarak değiştirmek istiyorsunuz. O zaman her şey çok daha basitleşiyor
      Saf YAML kullanma deneyimi başlı başına o kadar kötü değil. Biçimin epey şüpheli birkaç yanı var ama kullanılabilir. Bence sorun, belgeleri birden fazla ortama uyarlamak için eklemek zorunda kaldığınız çözümlerin karmaşıklığında ortaya çıkıyor
    • Bu yüzden Ansible’ı tekrar ele almayı düşünmek bile kâbus gibi
      Eskiden YAML yerine kullanılabilen gerçek bir Python DSL’i olduğunu duymuştum, ama kaldırılmış gibi görünüyor. Bu yüzden artık döngüler ve if-then’ler YAML içinde uzayıp giden korkunç yığınlara dönüşüyor ve Jinja’yı tamamen öngörülemez biçimde yorumluyor
    • jsonnet gibi Starlark kodu çalıştırıp JSON ya da YAML üretebilen bağımsız bir araç olup olmadığını merak ediyorum

  • YAML’in kendisinin harika olduğunu düşünüyorum. Harika olmayan şey, bizim CD’nin dağıtım kısmını fazlasıyla zorlaştırmış olmamız
    Azure DevOps içindeki yapılandırmamızın pek de iyi olmadığını kabul ediyorum; ama birden fazla ekibin ya da 5-6 operatörün bu tür araçlarla uğraşmak zorunda olduğu organizasyonların var olması şaşırtıcı. Google gibi yerleri bilemem, ama en fazla 50 bin eşzamanlı kullanıcısı olan ya da çoğunlukla bundan çok daha azına sahip sıradan bir kurumsal ortam için bu aşırı geliyor
    2000’lerin başında yük dengeleme, ağ işleri vb. her şeyi tam zamanlı 0,25 kişiden bile az birinin hallettiği şirket içi IIS’e kurumsal bir web uygulaması dağıtmak, bugün aynı şeyi “modern” bir düzene dağıtmaktan daha kolaydı
    Elbette modern pipeline’ların avantajları var. “Benim bilgisayarımda çalışıyor” sorununu büyük ölçüde aştı ve daha iyi onay kapılarıyla kalite kontrolünü ciddi biçimde artırdı. Ama gerçek dağıtım 2023’te bile bir kâbus
    Bu, gerçek teknoloji şirketlerindeki ya da iyi bir özel DevOps ekibi olan şirketlerdeki HN programcıları için sorun olmayabilir. Ama teknoloji dışı kurumsal dünyada CI/CD, kariyerimde hiç bu kadar kötü olmamıştı
    YAML’i suçlayabiliriz; bir şey yapmak için çok fazla YAML gerekmesini ve şablonların zor olmasını suçlayabiliriz. Ama bence bu, teknik bir sorundan çok organizasyonel bir sorun. CD araçları, geliştiricilerin altyapıyı kod olarak tanımlaması gereken bir iş olmaktan çıkacak kadar çok daha otomatikleşmeli
    Bunun mümkün olması iyi, ama gerçek şu ki milyonlarca geliştiriciden, neredeyse hiç anlamıyor olabilecekleri altyapıyı dağıtmaları isteniyor. Sadece konteyneri verip ağ işlerinin ve “sunucu tarafı işlerin” kendiliğinden halledilmesini istemeyen bir geliştirici görmedim
    Bunu yapmazsanız, kimsenin nasıl çalıştığını pek bilmediği bir sürü VNET ve alt ağ ortaya çıkıyor; geliştiriciler bunun /x ile yapılabileceğini bilmediği için organizasyon büyük para kaybediyor

    • Bulut, yeni mainframe’dir
      Bir tür “iş tanımını” çevrimdışı yazıp tescilli, paylaşımlı bir sisteme gönderiyorum; kuyrukta bekliyorum; sonra da kontrol etmediğim bir sistemin ürettiği günlük dosyasını alıyorum. Tescilli sistem kodunu iş istasyonumda yerel olarak çalıştıramadığım için iç iterasyon döngüsü en kısa hâliyle onlarca dakika, uzun hâliyle saatler ya da günler sürüyor
      Önizleme ya da “what if” modu, “dry run” da yok. “Test” diye adlandırsanız bile sistem tek olduğu için fiilen prodüksiyonda çalışıyorsunuz
      Asıl sorun YAML değil. Pipeline Tanrı’nın programlama diliyle betiklenmiş olsa da fark etmezdi
      Yazılımı merkezi zaman paylaşımlı mainframe yerine iş istasyonlarında geliştirmenin bu kadar popülerleşmesinin nedeni, iç iterasyonu dramatik biçimde hızlandırması, prodüksiyon ortamından izole etmesi ve kontrolü yeniden geliştiricinin eline vermesiydi
      Mevcut nesil CI/CD pipeline’ları genel olarak bunların hepsini geri alıyor
      Tek makinelik Kubernetes, iş istasyonu tabanlı geliştirmenin avantajlarının çoğunu geri getiriyor; ama hâlâ çok yeni bir sistem olduğu için büyüme sancıları fazla
      İlgili bir sorun da şu: Tek başına tıklayarak bir uygulamayı işleten geliştirici için harika çözümler var; binlerce geliştiriciye yönelik büyük ölçekli otomasyon yapan dev şirketler için de harika çözümler var. Ama ortadaki alan, yani birkaç kurumsal geliştiricinin onlarca uygulamayı yönettiği yer, düpedüz kaos
    • “Benim bilgisayarımda çalışıyor” sorununu tamamen aştığımızdan emin değilim
      Docker imajımda defalarca sorunsuz çalışıp, dağıtılmış imajda bozulduğu epey durum yaşadım
      Bu ancak tüm build ve dağıtım pipeline’ı tamamen şeffafsa, imaj deposuna tam erişiminiz varsa ve build talimatlarını gerçekten kontrol edebiliyorsanız aşılabilecek bir sorun. Bu, yerel işletim sistemini kontrol etmek kadar kısıtlayıcı; kodu başka bir makineye taşırken bozulduğu organizasyon sayısı kadar başarısız olacağını düşünüyorum
    • Dağıtımda neyin sorun olduğunu anlamıyorum. Benim kurduklarımda sadece commit’e tag koyup push ediyordum, o commit dağıtılmış oluyordu
      Herhangi bir CI/CD sisteminde bunu bu şekilde ayarlamak oldukça sezgisel görünüyor

  • Herkes tek bir kurala evrensel olarak saygı gösterirse barışı koruyacak bir çözüm olduğunu düşünüyorum: Python ekosistemi dışında YAML kullanmayalım
    Böylece okunabilirliği doğruluk, dayanıklılık ve bakım yapılabilirliğin önüne koyan anlaşılması güç betik biçimlerini sevenler sekme karakterlerini, gevşek tipleri ve muğlak söz dizimini kullanmaya devam edebilir. Geri kalanların buna ihtiyacı kalmaz. C tarzı söz dizimini tercih edenler akıl sağlığını koruyabilir
    Sanırım sorunun özünü ancak şimdi yakaladım. Bir C söz dizimi geliştiricisi olarak benim için söz dizimsel boşluk saf delilik. Boşluk bilgi ya da komut değil, biçimlendirmedir. İyi biçimlendirme yardımcı ve faydalıdır; iyi bir C söz dizimi geliştiricisi de okunabilir biçimlendirmeye önem verir
    Python ve YAML'de biçimlendirme, yönerge bilgisidir. Çalışan her kodun okunmasının kolaylaşması gibi bir avantajı var. Ama kodun çalışması için neden mutlaka okunması kolay olmak zorunda?
    YAML gibi bir iş arkadaşıyla çalıştığınızı hayal etmek yeterli. Uzun bir mesaj gönderdiniz, o da “Ne? Bunun anlamı yok” diye yanıtladı. Meğerse paragraflar arasına boş satır koymadığınız için anlam bozulmuş. Boş satırları yeniden ekleyip mesajı gönderince ancak o zaman okuyabiliyor. Söz dizimsel olarak doğru biçimlendirme olmadan gönderdiğiniz bilgi anlamsızmış

    • Yazılım olarak kodun, çalıştırılabilir olmanın yanında bir başka amacı da okunabilir olmaktır
      Biçimlendirme yapmanın sayısız yolu var ve ben insanların kod yazarken linter kullanmasını tercih ederim. Mümkünse benim kullandığımla aynı linter olmasını isterim
      Bu tür diller standart söz dizimi yapısını dayatır. Okuması zor kod yazmanın yolları azaldığı için bu iyi bir şeydir
    • Genelde anlamlı boşluk felsefi ya da dini bir mesele olarak görülür. Seveni de vardır, sevmeyeni de; iki taraf da tercihini rasyonelleştirir ama sonuçta mesele güçlü bir zevk meselesiymiş gibi kabul edilir
      Ama artık farkın felsefe değil, araç meselesi olduğunu düşünmeye başladım. Metin düzenleyici ya da e-posta programı gibi bazı araçlar anlamlı boşluğu iyi destekler, bazıları desteklemez
      Kullandığım metin düzenleyicilerin hepsi boşlukları ve sekme karakterlerini gösterecek şekilde ayarlı ve ikisini farklı gösteriyor. Genelde soluk noktalar ve soluk çizgiler gibi. Alıştığım için hiç rahatsız etmiyor
      Benim bakış açıma göre kod rastgele bir metin değildir. Kitapta kullanmayacağınız sabit genişlikli yazı tipi kullanır, söz dizimini renklerle ayırırız. Boşlukları görünür kılmamak için de bir neden yok
      Yine de anlamlı boşluk olmayan dilleri daha çok tercih ediyorum, ama böyle dillerden nefret etmiyorum. Benim için hiç sorun değil
      Fakat sevdiğiniz araç anlamlı boşluğu iyi desteklemiyorsa, boşlukları görünür kılmıyorsa, hatta değişken genişlikli yazı tipiyle kod yazıyorsanız, anlamlı boşluktan hararetle nefret edip onu saf delilik olarak görmeniz kaçınılmaz
    • C geçmişim olduğu için ben de boşluğun bilgi ya da komut olmadığı konusunda aynı şeyi düşünürdüm. Python'ın ilk dönemlerinde bu yüzden onu biraz küçümsediğim de oldu
      Fikrimi değiştiren şey, şaşırtıcı biçimde CoffeeScript kullanmam oldu. JavaScript'i pek sevmem ama CoffeeScript kullanma hissi, Crockford'ın The Good Parts'ının damıtılmış hâli gibiydi. Kötü kısımları yanlışlıkla üretemiyordunuz
      Üstelik girintinin kod hâline gelme biçimi epey rahattı. Tek rahatsızlık, Vi'da açılış ya da kapanış süslü parantezinin üzerinde % tuşuna basıp bloğun öbür ucunu bulamamak. Buna karşılık girinti sayesinde kod garip görünüyorsa çoğu zaman gerçekten garip oluyordu
      Yine de Python'ı hâlâ çok öğrenmiş değilim. Bugünlerde TypeScript kullanıyorum ama bir gün CoffeeTypeScript çıkarsa…
    • TOML'un standart kütüphanede olup YAML'in olmaması biraz tuhaf. Üstelik TOML çirkin
    • Kubernetes topluluğu ilgiyle bakıyor

  • Bu yüzden kendim BCL adında bir biçim geliştirmeye başladım: https://github.com/wkhere/bcl
    Tüm YAML kullanım örneklerine hemen yardımcı olmayacak ama en azından Terraform tarzında kaynak tanımlamanın daha güzel bir yolu olabilir. Aslında bir iç projede HCL'in yerine şimdiden işe yarıyor ve bunu yapmamın son motivasyonu da buydu
    Daha geniş açıdan bakınca, Kubernetes'te YAML'in her yerde olma sorununa nasıl yardımcı olur bilmiyorum. Benim $daily_job sorunumun yarısından fazlası, nihai Helm chart'ını birden çok kaynaktan birleştirme işinin fazla kaba saba olmasından kaynaklanıyor
    Bu, Helm'in özünde kötü bir araç olduğu ya da şirketimizin Helm'i oldukça kötü bir şekilde seçtiği anlamına gelmiyor. Herkesin koşulları dikkate alarak elinden gelenin en iyisini yaptığını düşünüyorum
    Ama anlamlı boşluk içeren metin şablonlarını manipüle etmek fazla hataya açık ve hataların fark edilmesi de çok geç oluyor. Kubernetes, YAML'in ne kadar harika olduğunu kanıtlamaya çalışmak yerine C tarzı söz dizimine dayalı özel bir biçim kullansaydı bence çok daha iyi olurdu. Hele ki YAML hiç de harika değil

  • Bu bir iç platform etkisi. Uygulama büyüdükçe yapılandırma da genişler ve sonunda bir programlama diline dönüşür; ama bol hatalı, yetersiz tanımlı ve kullanılabilirliği berbat bir dile
    Yapılandırma iflası ilan edip yeni bir yapılandırma biçimi seçersiniz. Sonra aynı döngü tekrarlanır
    Elbette biçimin kendisi de tamamen sorumsuz değil. Ne kadar esnekse, kötü bir programlama dili olarak yeniden kullanılması o kadar kolaylaşır
    Bu hatayı defalarca yaptıktan sonra, bugünlerde temel yapılandırma için mümkün olan en basit yapılandırma biçimini seçerdim. .ini bile fazla güçlü olabilir. Daha karmaşık “yapılandırmayı” gerçek bir programlama diline, mümkünse uygulamanın yazıldığı dile devrederdim

  • “YAML pek iyi değil” örneklerinin ezici çoğunluğu, tuhaf literal’ların hepsini tırnak içine alarak çözülüyor
    YAML’in zaman zaman can sıkıcı olduğu doğru. Örneğin map listeleri kısa sürede garipleşiyor ve anlamlı boşluklar neredeyse kesinlikle bir gün ayağınıza dolanıyor. Ama bu tür yazılar, en iyi ihtimalle bile biraz özensiz görünüyor

    • Ama o örneklerin hiçbirinde tırnak kullanılmıyor, araçlar da bunu yapmıyor
      YAML ekosisteminin tamamı değerleri tırnaksız yazmaya teşvik ediyor. Çoğu zaman iyi çalışıyor, sonra üretimde tökezletecek kadar nadiren bozuluyor

  • EDN, Clojure’un bir alt kümesidir: https://github.com/edn-format/edn
    Açık, stream edilebilir, genişletilebilir ve boşluklara duyarlı değildir. Yine de okunabilirlik için biçimlendirme teamülleri vardır

    • Listeleri ve kümeleri açıkça ayıran bir veri biçimini ilk kez gördüm; bu iyi bir şey
      Ama liste ile vektör arasındaki anlamsal farkın ne olduğundan pek emin değilim. Benim kafamda dizi ve bağlı liste, veri biçimi farkı değil, kod içindeki veri yapısı uygulama ayrıntılarıdır
    • Alternatiflerden çok daha iyi. Clojure ekosisteminin dışında da kullanılmaya başlamasını gerçekten isterim
    • Tam olarak boşluktan bağımsız demek zor. Çünkü öğe sınırları veya ayırma için boşluk gerekiyor
      Yine de anlamsal girinti oyunları hiç yok. Virgüllerin boşluk sayılması ve gerekli olmaması güzel

  • Öğrenciler ödevlerini e-öğrenme platformu üzerinden gönderdiğinde, tüm gönderimleri oldukça büyük bir XML dosyası olarak alıyoruz
    Gönderimleri okuyup statik analize ve örnek çalıştırmalara aktardıktan sonra, her ödev için tüm gönderimleri, notlandırma ipuçlarını, yorumları ve puan giriş alanlarını vb. içeren bir YAML dosyası yazıyoruz
    Ardından YAML dosyasından markdown+okuma (Pandoc) üzerinden raporlar, istatistikler ve geri bildirim PDF’leri üretiyoruz
    YAML bizim için çok iyi uyuyor. Çünkü Markdown sözdizimiyle ek geri bildirim eklemek kolay. Örneğin doğru girintilenmiş - you missed a \NOT` here` gibi
    Blok metinler için farklı kaçış yöntemleri sayesinde, öğrenciler çeşitli SQL ayraçları kullansa bile SQL gönderimlerini kaçış karakterleri olmadan okunaklı biçimde çıktılayabiliyoruz
    Her şey düz metin olduğu için sadece metin editörü kullanıyoruz ve notlandırma sorumluluğunu sağlamak için git’te saklıyoruz. Her şeyi makine tarafından okunabilir tutabildiğimizden, geçmiş gönderimler üzerinde yeni statik analiz araçlarını da test edebiliyoruz
    Ama CI pipeline’ları ve ev otomasyonu ayarları da YAML ile yazılmak zorunda kalınca o acıyı anlıyorum

    • Gömülü metinlerde girintiyi kaldırma, muhtemelen YAML’in en iyi özelliğidir
      TOML’de çok satırlı string girintisinden vazgeçip okunabilirliği düşürmeniz ya da her satırın sonuna ters eğik çizgi koymanız gerekir. İkisi de ideal değil
      Bu yüzden Markdown veya başka metin biçimlerini içermesi gereken DSL’ler ya da yapılandırmalar için YAML oldukça iyidir ve TOML gibi seçeneklere göre üstünlük sağlar
      Ama “YAML yorgunluğu”nun tüm sorumluluğunu, DSL’ler için taşıyıcı biçim olarak YAML’i seçen CI ve DevOps araçlarına yüklemem. Orijinal yazının iyi özetlediği gibi, YAML’in kendisinde de büyük sorunlar var
      Meşhur “Norway sorunu” YAML 1.2’de çözüldü ve baştaki 0’ların sekizlik sayı olarak parse edilmesi sorunu da YAML 1.2’de çözüldü. Sayılar, tarihler, saatler vb. için aşırı tip zorlaması kafa karıştırıcı olabilir. Çok satırlı string işleme modları da epey kafa karıştırabilir. Güvensiz serileştirme modern parser’larda bir sorun değildir, ancak Ruby, Python, Java gibi dinamik özellikleri olan eski dillerde YAML kullanırken dikkatli olmak gerekir
      Bunların hepsi YAML spesifikasyonunun kendi sorunlarıdır