1 puan yazan GN⁺ 2024-11-19 | 1 yorum | WhatsApp'ta paylaş
  • Tarayıcının çalıştırdığı tek bir HTML dosyası ile veri keşfi, analiz, görselleştirme, dizgi ve dağıtımı tek bir belgede birleştirerek mevcut not defteri → yayıncılık aracı → PDF akışını azaltmak mümkün
  • Temel uygulama, style ve script öğelerini ekranda gösteren echo hücreleri, contenteditable ve Observable Runtime'ı birleştirerek düzenlenebilir reaktif hücreler oluşturma yaklaşımına dayanıyor
  • cell(name, inputs, definition) Observable'ın bağımlılık modelini izleyerek counter, FizzBuzz render'ı, gizli hücreler ve çıktısı olmayan ara değer hücreleri gibi birbirine bağlı yürütme birimlerini kuruyor
  • Aynı HTML belgesi içinde Observable Plot, TeX, Markdown, Graphviz, WASM tabanlı SQLite, Pyodide tabanlı Python, WebR tabanlı R, Observable Inputs ve Mutable durum da gösteriliyor
  • Ortaya çıkan çıktı, ayrı bir platform olmadan tarayıcıda çalışan bilimsel ve teknik belgeler oluyor; uygulama daha sonra @celine/celine kütüphanesi olarak yayımlanıyor

Tek bir HTML dosyasıyla not defteri-yayın ayrımını azaltmak

  • HTML dizgi için yaygın olarak kullanılsa da, veri keşfi, analiz ve görselleştirme platformu olarak görece daha az kullanıldı
  • Tipik iş akışı birden çok araçtan geçiyor
    • Jupyter, RStudio, Pluto.jl, Observable gibi etkileşimli not defterlerinde keşif, analiz ve görselleştirme yapılıyor
    • Typst, Overleaf, LaTeX, WYSIWYG düzenleyiciler gibi yayın platformlarına taşınıp dizgi yapılıyor
    • Dağıtım için .pdf olarak dışa aktarılıyor
  • Tek bir HTML dosyası bu üç adımı üstlenirse manuel prosedürleri, CLI araçlarını, CI aşamalarını ve üçüncü taraf platform bağımlılığını azaltabilir
  • Uygulama, Anton Zhiyanov'un In-browser code playgrounds, Cristóbal Sciutto'nun Self-modifying HTML notes, Quarto ve Observable Framework çalışmalarından güçlü biçimde etkileniyor

Düzenlenebilir hücreler oluşturmak

  • İlk adım, echo CSS sınıfıyla style ve script öğelerini belgenin içinde olduğu gibi görünür hale getirmek
  • Yerleşik sözdizimi vurgulamalı yazı tipi ve contenteditable özniteliği eklenince bu yapı temel bir kod düzenleyici gibi kullanılabiliyor
  • contenteditable uygulanmış script, odağı kaybettiğinde yeniden değerlendirilir
    • Mevcut script kopyalanarak yeni bir script öğesi oluşturulur ve orijinali kaldırılır
    • eval, import ifadesi içeren kodda çalışmadığı için bu yöntem gerekir
  • Observable tabanlı yürütme için iki kütüphane yüklenir
  • Global alanda yalnızca library ve cell adlı iki sembol açığa çıkarılır

Observable Runtime tabanlı reaktif veri akışı

  • cell(name, inputs, definition, observerVisibility) işlevi, hücre tanımlamak için Observable Runtime'ın modül kapsamını kullanır
  • Aynı isimli değişken zaten varsa mevcut değişken alınır, yoksa yeni bir değişken oluşturulup tanımlanır
    • Bu yapı sayesinde contenteditable hücre yeniden değerlendirildiğinde yeni tanım bağlı hücrelere yayılır
  • Observable Inspector, hücre çıktısını script bloğunun üzerinde göstermek için kullanılır
  • counter hücresi, her 1 saniyede bir sayı üreten asenkron bir generator olarak kurulur
    • scriptin id özniteliği ile cellin name argümanı aynıdır
    • Başlangıç değeri i değiştirilip odak kaldırıldığında yeni değer uygulanır
  • countera bağımlı hücreler de oluşturulabilir
    • Hypertext Literal yüklenerek counter değeri FizzBuzz biçiminde render edilir
    • htl, HTML5 ayrıştırıcısını uygular ve otomatik escape, event listener, stil nesnesi ve DOM düğümü gibi serileştirilemeyen değerlerin enterpolasyonunu işler

Görünen hücreler, gizli hücreler ve çıktısız hücreler

  • echo sınıfı eklenmezse hücre tanımı gizlenirken çıktı yine gözlemlenebilir
    • Bu tür hücreler render primitive'i olarak kullanılabilir
  • Çıktının kendisini göstermeyen hücre tipleri de yapılabilir
    • silent(name, inputs, definition), observerVisibility değerini gizli ayarlayarak ara değerleri veya veri yapılarını saklamak için kullanılabilir
  • Hücreler, bildirim sırasından bağımsız çalışabilir
    • Örnekte reallyNegative hücresi, daha sonra bildirilen negative hücresine bağımlıdır
  • Aynı hücre değeri daha karmaşık çıktılarda da kullanılabilir
    • Observable Plot yüklenerek sayı dizisi bir çizgi grafiği olarak çizilir ve counter % 40 konumunda dikey bir kural çizgisi gösterilir

Belge ve görselleştirme çıktısını genişletmek

  • Hücreler herhangi bir DOM öğesini döndürebilir
  • TeX, Markdown ve Graphviz demoları sırasıyla farklı türde öğeler döndürür
    • tex hücresi bir span öğesi döndürür
    • md hücresi bir table öğesi döndürür
    • dot hücresi bir svg öğesi döndürür
  • Hücreler Promise döndürebilir veya Error fırlatabilir
    • Observable Inspector, çalışmakta olan hücrenin dışındaki dive observablehq--running sınıfını uygular
    • Hata hücresine observablehq--error sınıfını uygular
    • Belge bu durumlara uygun stiller tanımlar

Tarayıcı içinde SQLite, Python ve R

Girdi ve değiştirilebilir durum

  • viewof hücre tipi, Observable Inputs ile birlikte kullanılmak üzere oluşturuluyor
  • viewof, iki reaktif hücre bildirir
    • NAME: girdinin değeri
    • viewof NAME: DOM öğesinin kendisi
  • Girdiyi hücrenin üzerinde göstermek için hücre idsi viewof NAME olarak ayarlanır
  • Örnekte Inputs.range([0, 100], { step: 1 }) ile bir aralık girdisi oluşturulur ve rangePlot hücresi buna göre güncellenir
  • Observable Inputs'in çalışma şekli biraz kafa karıştırıcıdır; Synchronized Inputs demosu yardımcı olabilir
  • Yalnızca saf fonksiyonel veri akışının yetmediği durumlar için mutable yardımcı işlevi de oluşturulur
    • mutable, değer değiştiğinde yeni değeri yayan bir Mutable nesnesi kaydeder

Kütüphanenin yayımlanması ve sunum slaytları

  • Bu uygulama için ilk başta incel adı düşünülse de daha sonra celine adı tercih ediliyor
  • Kütüphane @celine/celine olarak yayımlanıyor
  • Bu belge SydJS etkinliğinde demo olarak gösteriliyor
  • Belgeyi slayt gösterisine dönüştürmek için kod da içeriyor
    • Shift+N: slayt gösterisini başlat veya sonraki slayta geç
    • Shift+B: önceki slayta geç
    • Shift+E: slayt gösterisini bitir
  • Uygulamanın kaynak kodu source code olarak yayımlanmış durumda

1 yorum

 
GN⁺ 2024-11-19
Hacker News yorumları
  • Yazının öncülüne güçlü biçimde katılıyorum. HTML, hesaplamalı notebook’lar için harika bir temel olabilir
    Ancak buradaki uygulama tercihlerini beğenmiyorum. Dinamik ve reaktif HTML bundan çok daha deklaratif hâle getirilebilir; Observable harika olsa da standart JavaScript’ten sapan yönleri var
    Heximal adında reaktif bir HTML sistemi yapmaya başladım; ileride notebook desteği de eklemeyi planlıyorum. HTML şablonları ve özel öğeler tabanlı deklaratif bir sistem; bunun üzerine TC39 Signals önerisine dayalı bir ifade/reaktivite sistemi oturtuluyor
    https://github.com/elematic/heximal
    HTMX, Tangle, Curvenote ve Polymer karışımı bir şeye daha yakın; HTML baştan beri reaktif olsaydı muhtemelen böyle görünürdü. Grafik düzenleme ve notebook kullanım senaryolarına oldukça iyi uyacağını düşünüyorum

    • “Observable harika ama standart JS’ten sapıyor” ifadesi front-end için doğru, ancak alttaki runtime yalnızca JavaScript çalıştırıyor. Kaynak kod da MIT lisanslı acorn ayrıştırıcısına tamamen sığan, önemsiz bir makro eklenmiş JavaScript’e yakın
      Bu yüzden Observablehq’da normal JavaScript debug ifadeleri düzgün çalışıyor
      https://github.com/observablehq/parser
      Observable runtime’ını sevdiğim için front-end kaynak ile derlenmiş saf JS gösterimi arasında çift yönlü dönüşüm yapabilen bir decompiler da yaptım
      https://observablehq.com/@tomlarkworthy/observablejs-toolcha...
    • Burada Observable Framework’ün de dikkate alınıp alınmadığını merak ediyorum. Mart ayında çıktı ve başlıca özelliklerinden biri, Observable Notebooks’ta yapılan sözdizimi hilelerini değil standart JavaScript’i kullanmasıydı: https://observablehq.com/blog/observable-2-0#a-better-develo...
  • Gerçekten harika. Özellikle Python ve SQLite demosunu beğendim. Web üzerinden düzenleme döngüsünden (TTW) başlayıp buna quine demesi ilginç; geçerli sayılır, ama temel zayıflık kalıcılık
    TiddlyWiki de aslında aynı şeyi yapıyor, ancak çalışmayı kaydetmek baş ağrısı. Çünkü bir şeyi kalıcı kılmak için sonunda ayrı bir headless sunucu sürecine ihtiyaç duyuluyor
    Benzer bir şey yapmak istediğimde[0] şahsen kalıcılıktan başlamıştım; bu da doğal olarak dosya demekti. Programcı editörüyle düzenlenebilen, dosya sistemiyle kaydedilip dağıtılabilen düz metin dosyalarıydı. Böylece tarayıcının içinde programcı editörünü yeniden uygulama sorunundan kaçınabiliyorsunuz; bu hiç kolay değil
    Bunun yerine hızlı bir sunucu yazma sorunu doğuyor, ama bu da oldukça keyifli bir problem[1]. Burada temel contenteditable bölümleri kullanarak o sorundan kaçınmışlar, fakat bu kalıcılıktan sonraki en büyük sorun
    Gömülü script içinde export yapılamaması da aynı duvar gibi görünüyor. Global window nesnesini kirletmemek için böyle bir özellik iyi olurdu; benim kullanım senaryomda kod üretimini de kolaylaştırırdı
    0 - Literate Markdown: https://simpatico.io/lit.md
    1 - Reflector, Markdown’ı dönüştüren, sıkıştıran, önbelleğe alan ve dosya izleme invalidation’ı yapan küçük bir node sunucusu: https://simpatico.io/reflector

  • Harcanan düşünce ve emeğe saygı duyuyorum ama bu yaklaşımın kullanılabilirliği korkunç. Keşifsel veri analizi yapmaya çalışırken neden stil öğeleriyle de uğraşmam gerektiğini bilmiyorum
    Jupyter Notebook gibi araçların iyi tutmasının nedeni tam da bu. Yine de merak edip alternatif fikirleri hayata geçirmiş olmasını çok takdir ediyorum

    • Yazar: Ben de üzülerek bu yöntemin kullanılabilirliğinin korkunç olduğuna katılıyorum; @celine/celine’i yapma motivasyonumun önemli bir kısmı da buydu (https://maxbo.me/celine, yani yazıyı bir kütüphane olarak paketlemek)
      Keşifsel veri analizi platformu olarak henüz yeterli değil. Observable Notebooks gibi tam teşekküllü bir web kod düzenleyicisinin anlık tepkiselliği de yok; dosya izleme tabanlı hot reloading sunan Observable Framework de değil. Deno + VSCode için yeni Jupyter kernel’i de oldukça akıcı bir deneyim sunuyor
      Bu yüzden keşifsel analiz için kullanılabilirliği konusunda, şey… kötü olduğuna katılıyorum; ama dağıtım kullanılabilirliğinin o kadar kötü olmadığını düşünüyorum. Hatta iyi. Çünkü yalnızca tek bir dosya. Birine grafikler ve veri işleme sonuçları göndermek için devasa bir toolchain’i sürdürmeye ya da üçüncü taraf bir servise para ödemeye gerek kalmadan, tek bir HTML dosyasını Slack’e atabilir veya bir yerde barındırabilirsiniz
      Analiz sonuçlarını stillendirebilme esnekliği sayesinde, bloglar veya araştırma makaleleri gibi stilin önemli olduğu ortamlarda da yayımlanabilir
    • İlk bakışta bunu “keşifsel DOM analizi” tarafına konumlandırmaya çalışıyor gibi görünüyor. Tanıtım demosu, yapı ve temel öğeleri oluşturarak çalışması bakımından Scheme/Smalltalk hissi veriyor; ivoryyi rede çevirince sözdizimi vurgulamasının gerçek zamanlı değiştiği sahne de bunu gösteriyor
      Buraya nasıl gelindiğini anlıyorum ama JavaScript framework ve kütüphaneleriyle tarayıcıda daha kolay oynayamamak üzücü. Sonuçta sadece JS; hafif bir ortamda hızlıca deney yapılabilmeli. Bu yaklaşımın güçlü olduğu nokta da bu
      HTML/JS’in oyuncu ve deneysel olanaklarını geri getiren bir yöntem. TS, rollup, webpack gibi şeylerdense böyle denemelerin daha fazla olmasını isterim
      Ek: Biraz daha okuyunca bunun veri analizi için önerildiğini gördüm. O kullanım için pek uygun olduğunu düşünmüyorum
    • “Sadece keşifsel veri analizi yapmak istiyorum” deniyor ama asıl mesele, keşifsel veri analizi yapıp sonuçları kolayca yayımlayabileceğiniz entegre bir platforma sahip olmak değil mi? Atılıp gidecek Jupyter notebook’ları için değil
      Atılıp bitmeyen Jupyter notebook alternatiflerinin büyük değeri olduğunu düşünüyorum. Mevcut kullanıcı deneyiminin gerçekten berbat olması düzeltilebilir. Sorun, bu düzenin Jupyter notebook’un JSON karmaşasından daha iyi olup olmadığı; kişisel olarak ben daha iyi olduğu görüşündeyim
  • Lit’in asıl yazarı yakın zamanda Google’dan ayrıldı ve bildiğim kadarıyla buna çok benzeyen bir şey üzerinde çalışıyor
    https://github.com/elematic/heximal

    • Sonrasında üzerinde çalıştığı şeyi duyurduğunu bilmiyordum. Haber verdiğin için teşekkürler
  • Bu yazının biçimini beğendim. En temelden başlayıp ilginç bir şeye kadar adım adım inşa ediyor. Bir bağımlılık yığını ya da şuradan buradan framework ekleyen abartılı bir akış değil
    Takip etmek için verilen parçaları kopyalayıp yapıştırmak ve adım adım nasıl çalıştığını anlamak yeterli olacak gibi. Ben böyle bir şey yazsaydım, org-mode’un literate programming özelliğiyle yazar, sonra HTML’e aktararak blog yazısına dönüştürürdüm
    Yine de yerleşik sözdizimi vurgulaması olan font hâlâ kafamı kurcalıyor

  • Tepkisel HTML deniyor ama neredeyse tamamı JavaScript değil mi, yoksa bir şeyi yanlış mı anladım?

    • Etkileşim/tepkisellik kısmı JavaScript, ama notebook kendi kendine yeten bir HTML dosyası içinde uygulanmış. Belge yapısından düzenlemeye ve görüntülemeye kadar her şeyi hallediyor
      Tarayıcı dışında üçüncü taraf yazılıma bağımlı değil; HTML’in olduğu gibi uzun ömürlü, taşınabilir ve kullanımı kolay
    • “Neden herkes tarayıcıda notebook çalıştırmak için Colab veya Observable kullanıyor? Neyse, zor kısımlar için Observable kullanan bir alternatif sunacağım” gibi bir his veriyor
  • Yakında bu tür HTML notebook’ları Raku içinde ya da Raku için desteklemeye çalışacağım
    Raku’nun mevcut “notebook çözümü” Jupyter tabanlı ya da Mathematica tabanlı

  • Bu süreci web teknolojileriyle karmaşıklaştırmanın mantığını pek anlayamıyorum. Eklenen karmaşıklık neyi çözüyor? Aksine süreci yavaşlatmaya ve otomatik tamamlama, snippet, eklenti gibi gerekli özellikleri ortadan kaldırmaya daha yakın görünüyor
    Üstelik başkalarının bu kuruluma aşina olmama ihtimali yüksek olduğundan iş birliği de daha zorlaşıyor
    Ortamı bir kez kurup, teknoloji değiştikçe küçük iyileştirmeler ekleyerek kullanmaya devam etmek yeterli
    n/vim kullanıcıları için şunlar yeterli olabilir. 1- Veri keşfi: https://github.com/untitled-ai/jupyter_ascending kullanarak metni Jupyter notebook’a bağlar. jupytext kullandığı için kodu metin düzenleyicide verimli biçimde düzenleyip çalıştırabilirsiniz
    2- Yazı yazma: LaTeX için https://github.com/lervag/vimtex kullanılabilir
    Buna tmux ve tmuxp eklerseniz projeyi anında açabilirsiniz. Emacs’te org mode[1][2] ve/veya Auctex ile akıcı bir süreç oluşturulabilir
    [1] https://sqrtminusone.xyz/posts/2021-05-01-org-python/
    [2] https://martibosch.github.io/jupyter-emacs-universe/

    • Tarayıcıda Jupyter notebook’u açınca hangi teknolojiyi kullanmış oluyorsun? OP’nin web sitesini açınca hangi teknolojiyi kullanmış oluyorsun?
    • Genel olarak iyi bir nokta
      Ancak Python’ı pek sevmediğim için Python merkezli olmayan araçlar kullanmak istiyorum. Bu yüzden Raku ve Mathematica’dan söz ettim
      Bu arada https://github.com/imbue-ai/jupyter_ascending bağlantısını paylaştığın için teşekkürler
    • Katılıyorum. Reaktif notebook isteyenler Emacs’i ciddi biçimde değerlendirmeli. Emacs’i yalnızca birkaç amaç için kullanan çok kişi var; reaktif notebook da çoğu zaman bunlardan biri oluyor
  • Bu yazının öncülüne, yani HTML’nin bilimsel yazıların dağıtım ortamı olarak yeterince kullanılmadığına büyük ölçüde katılıyorum
    Bununla ilgili Will Crichton’ın yakın tarihli çalışmaları var
    https://willcrichton.net/nota/
    https://willcrichton.net/notes/portable-epubs/

  • Bu aralar notebook’lar gerçekten gündemde. Biz de TypeScript notebook sürümünü yayımladık[1], ancak ödünleşimlerde epey farklı bir tarafı seçtik
    Biz backend node kodu çalıştırmak istediğimiz için, bu yazıdaki yöntemden veya Observable’dan farklı olarak tarayıcı ortamında çalıştırmaya çalışmıyoruz. Yine de birçok uygulama için bu fikir daha iyi bir çözüm olabilir
    Yazarı alkışlıyorum
    https://github.com/srcbookdev/srcbook