3 puan yazan GN⁺ 2023-10-23 | 1 yorum | WhatsApp'ta paylaş
  • Kişisel bir web sitesini tek bir binary olarak kurmak, tek kişinin tüm yapıyı anlayıp doğrudan bakımını yapabilmesini sağlar; böylece mevcut SSG·hosting kombinasyonlarının bağımlılık yükü azalır
  • Hugo ve GitHub Pages gibi kombinasyonlar; hizmetin sürekliliği, projenin bakımı, eklenti ekosistemi, deployment yöntemi ve Go gibi çeşitli dış koşulları varsayar
  • HTML’i elle düzenlemek basit ve kararlıdır, ancak ortak işlevleri tekrar tekrar ele almak zordur ve iş akışı yorucu hale gelir; bu yüzden daha keyifli biçimde ayarlanabilen bir yönteme ihtiyaç duyulmuştur
  • Go tabanlı dinamik bir site, IP gösterimi veya RSS feed güncellemesi gibi statik sitede zahmetli olan işleri sunucu tarafı koduyla çözer ve tarayıcı olmayan araçlara da tamamlanmış HTML döndürür
  • Kişisel web siteleri küçük başlayıp standart kütüphane ve basit araçlarla büyütüldüğünde daha uzun ömürlü olur; büyük framework’lerle başlamak ise kişisel zaman içinde yetişmeyi zorlaştırır

Mevcut web sitesi araçları neden uymadı

  • Ghost, Hugo, Jekyll, sr.ht ve tarball, hatta elle HTML düzenleme dahil birçok yöntem denendi; ancak hiçbiri kişisel ölçütlere uymadı ve ilgi çekici de olmadı
  • En önemli ölçüt, tek bir kişinin sistemi baştan sona anlayabilmesi ve kolayca bakımını yapabilmesiydi
    • Okunması kolay kod
    • Hızlı geri bildirim döngüsü
    • Eğlence ve zekice tasarım
    • Bir şey bozulduğunda doğrudan içine girilebilecek bir yapı
  • Hugo gibi statik site üreticileri (SSG), girdi olarak template ve Markdown alıp HTML üretir ve genelde bir hosting platformuyla birlikte kullanılır
  • Hugo ve GitHub Pages kombinasyonunda birçok bakım koşulu bulunur
    • GitHub Pages hizmetinin çalışmaya devam etmesi gerekir
    • GitHub Pages ürününün bakımının sürmesi gerekir
    • Hugo projesi ile topluluk belgelerinin korunması gerekir
    • Eklenti ekosistemine bağımlılık olabilir
    • Hugo binary’sinin zaman içinde HTML’i büyük ölçüde aynı şekilde üretmeye devam etmesi gerekir
    • GitHub Pages deployment mekanizmasının çalışmayı sürdürmesi gerekir
    • Go gerekir
  • Belirli bir Hugo sürümünü sabitleyip kullanmak mümkün olsa da, pratikte hatalar yüzünden yükseltme gerektiren durumlar ortaya çıkabilir

Elle HTML düzenlemenin avantajları ve sınırları

  • Web sitesini doğrudan kontrol edilen bir makinede host etmek ve Vim ile HTML’i elle düzenlemek de tercih edilmişti
  • j3s.sh’nin ilk sürümü bu şekilde yapılmıştı ve mevcut yerleşim fikirlerinin önemli bir kısmı buradan geldi
  • HTML’i elle yazmak yorucu bir el işi gibi hissettirdiğinden, bu yaklaşım aşırı minimalizme yöneltti
    • Stil doğrudan HTML’in içine yazıldı
    • Site genelindeki ortak işlevler en aza indirildi
    • Yoğun stil kullanımından kaçınıldı
  • Bu yöntem basit, kararlı ve bakımı kolaydı
    • Yazılan HTML değişiklik olmadan yeniden kullanılabiliyordu
    • Dış bağımlılık yoktu
    • Sitenin uzun süre yaşayacağına dair güven veriyordu
  • Yine de ortak işlevlerin template’leştirilmesini daha verimli yapmak isteniyordu ve mevcut framework’ler olmadan keyifle ayarlanabilecek bir yönteme ihtiyaç vardı

Go ile tek binary web sitesi

  • Tüm web sitesini tek bir dille yazmak, çıktıyı tek bir binary içinde paketleyip dağıtmayı mümkün kılar
  • Go, kişisel bakım ve basit deployment için uygun bir seçenekti
    • Tek kişinin bakımını kolaylaştırır
    • Az bağımlılıkla ilerlemeyi teşvik eder
    • Dil görece basittir
    • Geriye dönük uyumluluk garantisi vardır
    • Statik derlenmiş binary üretmek kolaydır
    • Çoğu zaman 10 saniyeden kısa sürede derlenir
    • Standart kütüphanesi oldukça gelişmiştir
  • Sonuç olarak j3s.sh, web sitesini sunan tek bir binary haline geldi

Dinamik web sitesinin getirdiği sadelik

  • Bazı durumlarda dinamik üretilen bir web sitesi, statik üretilen bir web sitesinden daha basit olabilir
    • İçerik üretimi için dolambaçlı çözümler düşünmek gerekmez
    • Gereken içerik anında üretilebilir
  • Ziyaretçinin IP adresini gösteren işlev, Go’nun http.HandlerFunc yapısıyla basitçe uygulanır
    • X-Forwarded-For header’ı okunur
    • Handler /ip yoluna bağlanır
    • Aynı fonksiyon gereken yerlerde çağrılabilir
  • Aynı işlevi statik sitede uygulamak için JavaScript gibi dış bağımlılıklar gerekebilir ve JavaScript olmayan durumlar da hesaba katılmalıdır
    • Bazı okuyucular JavaScript çalıştırmayı reddeder
  • Sunucu IP adresi zaten eklenmiş HTML döndürdüğünde, istemci JavaScript’i anlayamasa bile doğru yanıtı alabilir
    • Aynı yaklaşım tarayıcı olmayan araçlar için de geçerlidir
  • Ana sayfanın RSS feed’i, web sitesi başlatılırken üretilir
    • Arkadaşların son yazıları yeniden çekilebilir
    • Elle yapılmış RSS feed fetcher’ının uzun süre bakım gerektirmeden çalışacağı düşünülür
    • İç işleyişi tam olarak anlaşılmaktadır

Deployment ve başlangıç yöntemi

  • Deployment kısa bir shell script ile yapılır
    • Git deposu çekilir
    • Yerel branch geride kaldıysa git merge origin/main çalıştırılır
    • go build ile derlenir
    • Binary /usr/local/bin/j3s.sh konumuna taşınır
    • service j3s.sh restart ile servis yeniden başlatılır
  • Bu script her dakika cronjob olarak çalışır; depo güncellendiğinde site yeniden build edilir
    • Yerelde test edilip yüklendiğinde 1 dakika içinde canlı sitede görünür
    • Shell’i biraz bilen biri için 10 saniyede anlaşılabilecek kadar basittir
  • Kişisel web siteleri günümüz web’inde kendine özgü bir his verir ve işletmecisinin önem verdiği şeyleri derinden yansıtabilir
  • Statik site kendisine uyanlar aynı şekilde devam edebilir; ancak benzer değerlere sahip kişiler için dinamik web sitesi denemek iyi bir seçenek olabilir
    • Küçük başlanabilir
    • İlginç fikirler tekrar tekrar eklenebilir
    • Site kişisel olduğu için hardcode etmek sorun değildir
    • Rust, Perl, Python gibi sevilen bir dille yapılabilir
  • Başlangıç küçük olmalıdır
    • Önce index.html oluşturup, seçilen dille bunu sunmaya odaklanılır
    • RSS veya Markdown daha sonra gerektiğinde eklenir
    • Mümkünse standart kütüphane gibi en basit ve bakımı en kolay araçlar kullanılır
    • Ruby’de Rails yerine Sinatra, Python’da Flask yerine Gin gibi daha küçük seçenekler düşünülebilir
    • Hiç kütüphane kullanmadan doğrudan yapılabiliyorsa önce bu da denenebilir
  • Büyük framework’lerle ya da sürekli breaking change üreten projelerle başlamak, kişisel zaman içinde yetişmeyi zorlaştırır ve insanı hızla yorabilir
  • Web’in daha fazla tuhaflığa, heyecana ve kişiliğe ihtiyacı var; bu yüzden dinamik bir web sitesi yapmayı denemek önerilir

1 yorum

 
GN⁺ 2023-10-23
Hacker News yorumları
  • Mobilde site genişliği doğru hesaplanmıyor; yazıyı okuyabilmek için sağa sola kaydırmak gerekiyor
    Bunu yapmadan hemen önce “çok yüksek ve sıra dışı standartlarım var” cümlesini okuduğum için açıkçası biraz güldüm :)

    • Bu, HTML ile bölüm ve paragraf gibi bir yapı verilmiş bir yazı değil; sadece düz metin dosyası, boşluk korumalı pre olarak render edilip devasa bir paragraf gibi görünüyor ¯_(ツ)_/¯
    • Safari okuma aracında da biçimlendirme 0 olduğu için o da oldukça etkileyiciydi
      Garip biçimlendirmeler çok gördüm ama hiç biçimlendirme olmamasını ilk kez görüyorum
    • Firefox Mobile'ın okuma modunda düzeldi; yani aslında tek bir düğmeye basmalık bir rahatsızlık
      Yine de ilk izlenim iyi değil
    • Yazarın mantığıyla platforma uygun yapmamış olması birbiriyle çelişiyor
      Anlam veremiyorum
    • Ben de aynı şeyi düşündüm
      Bununla gurur duyması güzel ama ben okumamayı tercih ettim
  • Asıl mesele, “basit tutmak”ın tam olarak ne olduğu ve “anlaşılabilir”in ne anlama geldiği
    Böyle yazılar ilginç tartışmayı atlayıp kendi yaklaşımlarının basit olduğunu ve hedefin de basitlik olduğunu varsayıyor
    Soyutlamaları, örneğin kütüphane ya da framework, servis ya da API, seçebiliyorken kullanmak mı daha basit, kullanmamak mı daha basit?
    Kullanmayıp kendin yaparsan tüm sistemin nasıl çalıştığını daha iyi anlarsın; bu anlamda daha basittir
    Ama karmaşıklık yine de ortaya çıkar ve bazı durumlarda soyutlama katmanlarını da kendin kurman gerekir
    Tersine, kullanırsan karmaşıklığı gizlersin; bu yüzden mutlu yol üzerinde sistem daha basit sayılabilir, ama o karmaşıklık hâlâ vardır ve gizli kaldığı için anlaşılmaz
    Her iki yaklaşım da belli bir bakış açısından açıkça basit görünebilir; ama o açıklığın ötesine geçince ödünleşimler görünür

    • Diyelim ki elmalı turta yapmak istiyorsun
      Normalde malzemeleri ve araçları alır, mevcut bir fırında pişirirsin
      Ama sıfırdan elmalı turta yapmak istiyorsan önce evreni yaratman gerekir ve muhtemelen elmalı turtayı destekleyen en basit evreni yaratırsın
      Tüm yığın daha basit olabilir ama son adım, yani gerçekten turtayı yapmak, daha karmaşık olabilir ve tadı da en iyisi olmayabilir
      Buna karşılık ilk ilkelerden itibaren tamamen anladığın bir turta elde edersin
    • Burada söylenen şey daha çok “basit(simple)” ile “kolay(easy)” arasındaki fark gibi görünüyor
      Rich Hickey'nin şu konuşmasını sevebilirsin: https://paulrcook.com/blog/simple-made-easy
      Bir şeyi daha kolay yapmak ya da dağıtmak için özellik ekleyebilirsin, ama bu eklemeler yüzünden bütün daha karmaşık hâle gelir ve anlamak ya da sorunun izini sürmek zorlaşır
    • Bu yazı bağlamında bu yorumu pek anlamıyorum
      Yazar en sonda gayet açık biçimde herkesin kendi yolunu izlemesi gerektiğini söylüyor
      Ayrıca kendisinin, anlamakta zorlandığı ya da bunaltıcı bulduğu sistemleri kullanmaktan memnun olmadığını da söylüyor
      İlk paragraftan sonrasını da okumakta fayda var
  • Çok hoş!
    “Siz de böyle yapmalısınız!” kısmına kesinlikle katılmıyorum :)
    Bakım yapılabilirlik benim temel değerlerimden biri; senin gibi ben de bisikletimin bakımını kendim yapıyorum
    Ama bende bu, öncelik sıralamasında bu kadar yukarıda değil; o yüzden böyle seçimler bana mantıklı gelmiyor
    Framework dizüstü bilgisayar, aramızdaki farkı güzel gösteren bir nokta
    Sen DIY tarafında sürekli 9 puan alıyorsun; bense her an Linux ve Neovim'i hızla çalıştırabileceğim 10 yıllık yedek bir ThinkPad bulundurarak ve o da bozulursa gelecekte de 100 doların altında bir sürü ThinkPad olacağına güvenerek dayanıklılık sağlıyorum
    Bir gün gerekirse Haskell kombinatorleriyle Markdown'dan HTML'ye yavaş, gayriresmî ve bol hatalı bir parser yazabilecek kadar bilgisayar bilimi ve matematik bilgim var; ama o günün yakında geleceğini sanmıyorum
    Mümkün olsa seni işe almak isterdim
    Öbür yöne savrulan birçok insan için kusursuz bir denge unsuru olurdun

    • Öbür yöne savrulmakla tam olarak ne kastedildiğini merak ettim
  • Bu yazıyı gerçekten keyifle okudum
    Yazar kendine karşı dürüst ve okura karşı ciddi
    Bahane üretmeden kendisi olarak var oluyor ve kendi değerleriyle uyumlu, ona keyif veren bir şekilde hedeflerine ulaşmaya çalışıyor
    Bu değerler seninkiyle örtüşmeyebilir; bunda sorun yok, hatta bu güzel bir şey
    Artık senin de keşfedebileceğin bir yol olduğuna dair ipucu almış oldun
    Yazı nazik, alçakgönüllü ve samimi; yazarın ve yazının dünyayı biraz daha iyi bir yer yaptığını düşünüyorum

    • Ciddi olduğu doğru ama kendine karşı dürüst olduğu konusunda neredeyse tam tersini düşünüyorum
      Alçakgönüllü olduğu konusunda da öyle
      Yazının tamamı kendini övme havasında ve aralara serpiştirilmiş /r/confidentlyincorrect tarzı parçalar da var
    • Bu yazıya, okur için yazılmış bir metinden çok, yazarın öğrenme ya da kontrol hissi gibi içsel hedeflere ulaşmak için kullandığı bir alıştırma ve yardımcı araç olarak bakmak daha kolay
      Okur ikincil bir unsur sadece; bu yüzden okur deneyimi ne kadar spartalı olursa olsun asıl mesele yazarın deneyimi
    • Okuduysan biraz içeriğinden bahsedebilir misin?
      Mobil platformdan gelenlerin çoğu galiba okumayı çok erken bıraktı
  • Hızlıca göz gezdirdim; bu kişi neredeyse kesin olarak bizimle eğleniyor gibi
    Web sitesi kelimenin tam anlamıyla “plain HTML” kullandığını söylüyor ama gerçekte düz metin kullanıyor
    Burada biçimlendirme için hiç HTML yok
    Başlık yok, paragraf yok, liste yok; hatta a etiketi bile yok
    Az miktardaki HTML ve CSS ise siteyi daha da kötü render ediyor
    Yazan kişi trol

    • Bu öğe en az 15 yıldır kullanımdan kaldırılmış öğe olarak işaretleniyor
  • “Çok yüksek ve alışılmadık standartlarım var” diyor, ardından da “Bu script her dakika bir cronjob olarak çalışıyor ve git deposu güncellendiyse siteyi yeniden build ediyor” diye ekliyor.
    Böylece yılda sadece birkaç commit alacak bir depoyu yılda 525.600 kez çekmiş oluyor.
    “Alışılmadık” kelimesinin neden kullanıldığını anlıyorum.

    • Yeni commit yoksa git fetch aslında neredeyse tek bir string karşılaştırmasına yakın olduğundan [0], söylendiği kadar maliyetli bir iş sayılmaz.
      [0] https://stackoverflow.com/a/44476803
    • Bu durumda “alışılmadık”tan çok çılgınlıka yakın.
      Sorulmasını beklemeyip söylemek gerek.
    • Burada deploy sürecimin nasıl çalıştığına dair fazla fazla varsayım yapılıyor!
      Tüm git depolarım, web sitesini host eden aynı sunucuda bulunuyor.
      git uzak bir fetch yapmıyor, yerel fetch yapıyor; dolayısıyla pratikte anında bitiyor.
      Uzak fetch olsaydı bile sorun olmazdı.
      Yılda 525.600 HTTP isteği, NetworkManager heartbeat’inden daha az israfçıdır.
      Arch’ta varsayılan değer her 30 saniyede bir heartbeat isteğidir.
      Karşılaştırma için, 8 CPU’lu varsayılan bir nginx sunucusu saniyede 500 binden fazla HTTP isteğini işleyebilir.
  • OP’ye:
    Burada çok fazla eleştirel yorum görüyorum.
    Kibarca söylemek gerekirse… aldırma.
    Eleştiriler doğru olabilir ama sektör, kolektif “yapmalısın” ve “böyle olması gerekir” anlayışını izleyerek hızla kitlesel bir aptallığa doğru gidiyor.
    Bunların önemli bir kısmı, şu an için ancak şehir efsanesi düzeyinde geçerliliğe sahip.
    Bugünlerde “mühendislik” denen şey, üstüne aktif olarak bir gelecek inşa ediyor olmasaydık gülüp geçilecek cinsten.
    Babam havacılık ve uzay mühendisiydi; modern yazılım geliştirmede mühendislik diye anılan şeyleri görse mezarında ters dönerdi.
    Burası yorum bölümü, herkesin konuşma özgürlüğü var ama kişisel olarak ancak sektörde 25 yıl geçirdikten sonra o geveze sesleri görmezden gelip, nadiren doğan fırsatlarda mantıklı bulduğum şeyi yapmaya başladım.
    Hele konu kişisel siteyse, daha da öyle değil mi?
    Apple’ın o eski “çılgın insanlara” reklam sözü bile artık gerçeğe uzak geliyor.
    İnternet bu hale geldiyse ve bir zamanların startup’ları şimdi manzaranın en büyük kurumsal canavarlarına dönüştüyse, buna şaşmamak lazım.
    Theodore Roosevelt’in “arenadaki adam” alıntısı bugünlerde gerçekten cuk oturuyor.
    Devam et OP, devam et…

    • Teşvik için teşekkürler! Özellikle HN’de, hele ki kişisel web sitem hakkında gelen eleştirileri fazla ciddiye almamaya çalışıyorum.
      Web sitem kusursuz optimize edilmiş bir site değil; benim kutsal ve tuhaf oyun alanım.
      Her şeyini kendim yazdım ve zamanla evriliyor.
      Tarzımın bazen insanları rahatsız ettiği açık; bu tür eleştirilere de alışığım.
      Beğendiğim bir forma içeriği eğip bükmek için bazen garip kararlar alıyorum ama bence içeriğimi sevimli kılan da tam olarak bu.
      Çünkü dışarıdaki diğer şeylere benzemiyor.
      Pürüzlü kenarları olabilir ama “kişisel biçim”i keşfederken giderek daha iyi olacak :)
      Benim için web sitesi uzun vadeli bir sanat projesi gibi.
      Yazarını temsil etmeli ve benim durumumda sitem beni utanmadan, çekinmeden temsil ediyor.
  • Madem sen kendininkini gösterdin, ben de benimkini göstereyim.
    Benim web sitem, oyun motorum ve web sunucum tek bir binary.
    Kaynak kodu 1000 satır C ve binary boyutu 164KB.
    Neden bu kadar lanet olası büyük olduğunu bilmiyorum.
    Web sunucusunu da doğrudan içine gömdüm.
    Mevcut sunucular çok fazla gizli karmaşıklık ekliyor.
    Ortaya çıkan Almanca interaktif kurgu oyunu burada görülebilir: http://vmd34232.contaboserver.net/
    Takip yok, reklam yok, ticari amaç yok.

    • Güzelmiş, ben de zamanında parchment.js ile inform7’nin ürettiği z5 dosyasını web sitemde yüklemiştim.
      Çalıştırılabilir dosyayı upx ile sıkıştırmayı deneyebilirsin https://upx.github.io/
    • Bana da sitemi hatırlattı :)
      https://toldby.ai/
      Benimki tek binary değil, asp.net.
  • Yazıda ortaya konan tüm noktalara tamamen katılıyorum ama bu web sitesi örnek olarak pek iyi değil.
    Web sitesinin “tek bir binary” olduğu söyleniyor ama deploy stratejisi, binary çıktısını çalıştırmak yerine derlemeyi de içeriyor.
    github pages’e bağımlı olmayacağını söylerken openlibrary.org’un dış kaynaklarına bağımlı.
    Her şeyi kendin yaparsan açık standartlardan yararlanabileceğini söylüyor ama thoughts/ içindeki .html dosyaları, uzantısı yalan olan düz metin yapılardan ibaret.
    İnsanlar bu yolu seçtiğinde genelde her şeyi ilk sayfa yüklemesine sıkıştırmaya çalışır ama burada dinamik olarak sunulan birden fazla statik dosya var.
    Golang kodu hiçbir yanıtı cache’lemiyor ve template’leri de bellekte tutmuyor.
    go.mod dosyasında birden fazla bağımlılık var ama hepsi kullanılmıyormuş gibi görünüyor.
    En önemlisi, tek binary ruhunun modern altyapıyla kıyaslandığında ne teknik avantaj sağladığına dair bir tartışma yok.
    Bence kişisel olarak iyi bir fikir ama bu kötü bir örnek.

    • Aslında tek bir binary değil.
      Dosya sistemiyle birlikte çalışan tek bir binary.
      Tüm içerik dosya sisteminde duruyor.
      “Tek binary”, dosya sisteminden içerik sunan hafif bir Golang web sunucusu.
  • “Çok yüksek ve alışılmadık standartlarım var” deniyor ama alışılmadık olduğu doğru olsa da ortaya çıkan web sitesinin tasarımı o kadar kötü ki metni ekrana uygun şekilde bile gösteremiyor; yani standartlar aslında çok düşük