İnsanların Hakkında Konuşabilmesi İçin Link Verecekleri Bir Hedef Sunmak

 (simonwillison.net)
1 puan yazan GN⁺ 2024-07-14 | 1 yorum | WhatsApp'ta paylaş
  • İnsanların bir projeyi veya ürün özelliğini anlayıp paylaşmasını istiyorsanız, tekrar tekrar açıklamadan önce özel bir web sayfasına ihtiyacınız var
  • ChatGPT Code Interpreter güçlü bir özellik olmasına rağmen resmi belgelerdeki adı ve keşfedilebilirliği tutarsız olduğu için, başkalarının hazırladığı açıklamalar daha kullanışlı linkler hâline geliyor
  • Claude Artifacts ve GitHub Codespaces·Copilot örnekleri, bir özellik link verilebilir bir hedef hâline geldiğinde paylaşmanın ve açıklamanın kolaylaştığını gösteriyor
  • Dan McKinley’nin Boring Technology kavramında olduğu gibi, bir kavram ayrı bir sayfada düzenlendiğinde, onu ilk kez duyan biri bile tek bir linkle bağlamı hızla yakalayabilir
  • Özel bir sayfanın değeri yalnızca arama görünürlüğüyle sınırlı değildir; web üzerindeki sohbetlerde aynı açıklamayı tekrar tekrar yapmayı da önler

Link verilebilir bir sayfa neden gerekli?

  • Proje, fikir, ürün özelliği gibi başkalarının anlayıp hakkında konuşmasını istediğiniz şeyler için link verilebilir bir sayfa gerekir
  • Hiperlinkler web’de konuşmaları genişletmenin temel aracıdır; böylece her seferinde açıklamayı yeniden yazmak yerine belirleyici bir açıklamaya yönlendirebilirsiniz
  • Özel bir sayfa yoksa ilgi ve arama trafiği, başkalarının hazırladığı açıklamalara veya arama terimlerini sahiplenen sayfalara akabilir

ChatGPT Code Interpreter’ın keşfedilebilirlik sorunu

  • ChatGPT Code Interpreter, ChatGPT’nin yanıt sürecinde Python kodu yazıp çalıştırmasını sağlayan bir özelliktir
  • Özelliğin kendisi güçlü olsa da, prompt ile nasıl etkinleştirileceğini bilmiyorsanız varlığını fark etmek zordur
  • OpenAI sitesinde Code Interpreter arandığında API özelliğine ilişkin teknik belgeler veya eski bir forum başlığı çıkıyor ve bu kafa karışıklığı yaratıyor
  • Bu özelliği tanıtırken OpenAI’nin resmi sayfasından çok code-interpreter etiket sayfası daha kullanışlı bir link olarak kullanılıyor
  • Daha sonra gerçek doküman doğrulandı, ancak başlığı Data analysis with ChatGPT idi ve sayfada “Code Interpreter” terimi bulunmadığı için bulması zordu
  • OpenAI bu özelliğin adını sürekli Code Interpreter, Advanced Data Analysis ve Data analysis with ChatGPT olarak değiştirdi

Özellik sayfasının iyi yapıldığı örnekler

  • Claude’un Artifacts özelliği için en azından kolayca bulunabilen bir yardım sayfası var
  • Ancak Artifacts duyuru yazısı, Claude 3.5 Sonnet duyurusuyla birlikte paylaşıldığı için yalnızca Artifacts’a ait net bir link hedefi gibi görünmesi zor
  • GitHub, özellik bazında ayrı landing page’ler sunuyor
  • Bir özellik için ayrı bir özel sayfa olduğunda, link verirken ve paylaşırken açıklamanın referans noktası oluşur

Boring Technology: bir kavramın web sitesine dönüşmesi

  • Dan McKinley, 2015’teki Choose Boring Technology makalesinde Boring Technology terimini ortaya attı
  • Temel fikir, geliştirme ekiplerinin yeni sorunları çözme kapasitesinin sınırlı olduğu; bu kapasitenin ürünü benzersiz kılan alanlara harcanması gerektiğidir
  • Geri kalan alanlarda ise hataları ve sınırlamaları uzun süredir çevrimiçi ortamda anlaşılmış ve tartışılmış, en sıkıcı ve en iyi bilinen teknolojiler seçilmelidir
  • Bu fikir ayrıca boringtechnology.club adlı bir web sitesinde de derlenmiştir
  • Birisi bu terimi bilmiyorsa tek bir link paylaşmak, birkaç dakika içinde bağlamı yakalamasını sağlayabilir

Kişisel fikirler de paylaşılabilir sayfalara ihtiyaç duyar

  • baked data, git scraping, prompt injection gibi fikirler de sıkça paylaşılabilecek sayfalar olarak düzenlenmiştir
  • Ancak ayrı bir alan adı alınmadığında, “link verilmesi gereken asıl sayfa burası” mesajı zayıflayabilir
  • Net bir link hedefi, fikirlerin paylaşılabilirliğini ve üzerine konuşulabilirliğini artırır

SEO’dan çok, sohbetlerde daha büyük değer üretir

  • Özel bir sayfanın açık amaçlarından biri SEO’dur
    • Kullanıcılar ürün özelliğini aradığında başkalarının hazırladığı sayfalara değil, sizin sitenize gelmelidir
  • Daha büyük değer ise sohbetlerde ortaya çıkar
    • Bir kavramı açıklarken bir paragrafı yeniden yazmak yerine, belirleyici açıklamayı içeren bir link paylaşabilirsiniz
  • İnsanların bir fikri, projeyi veya özelliği anlayıp tartışmasını istiyorsanız, buna uygun bir web sayfası oluşturmalısınız

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-14
Hacker News yorumları

  • rsync.net bu işi iyi yapan bir hizmet. Örneğin başka bir hizmette CEO sayfası gibi bir şey gördüğümü hatırlamıyorum.
    Gerçekten faydalı mı bilmiyorum, CEO'ya bir şey iletmem gerektiği de hiç olmadı ama müşteri bile değilken bu yazıyı okur okumaz aklıma ilk bu sayfa geldi.
    [1]: https://www.rsync.net/products/ceopage.html

    • Bazı konferanslarda “Çalışanınız neden KimchiBurgerConf'a katılmalı” sayfası oluyor.
      Katılımcıların makul bir iş gerekçesini kendilerinin uydurmasına gerek kalmadan, doğrudan yöneticilerine gönderebilmeleri için tasarlanmış bir sayfa.

  • OpenAI seviyesine gelince artık teknik dokümantasyon yazarları işe almış olacağını düşünürdüm, ama LinkedIn'e göre öyle görünmüyor. Bu yüzden dokümantasyonun bu kadar kötü durumda olması da çok şaşırtıcı değil.
    Neden dokümantasyona özel bir rol için işe alım yapmadıklarını anlamıyorum. Ya bunu önemli görmüyorlar ya da büyümeyi dokümantasyonun önüne acımasızca koyuyorlar; nedeni ne olursa olsun sonunda kendi zararlarına çalışıyorlar.

    • OpenAI dokümantasyonu son zamanlarda biraz iyileşiyor ama şu anda Anthropic'in epey gerisinde. Anthropic'in prompt rehberi gerçekten şimdiye kadar gördüklerimin en iyisi: https://docs.anthropic.com/en/docs/build-with-claude/prompt-...
    • Teknik dokümantasyon yazarı işe almak, teknik dokümantasyon alanında insan üstünlüğünü kabul etmek anlamına gelir. Mühendisler ve kullanıcılar üzerindeki etkisinden bağımsız olarak, GPT tarafından üretilmiş dokümantasyon kullanmak dışarıdan daha iyi görünüyormuş gibi bir durum.

  • Yazıda https://boringtechnology.club/ referans veriliyor; yenilikçilik çabasını yalnızca size özgü çözümlere saklamayı anlatan harika bir slayt destesi.
    Geri kalan her şeyde mümkün olduğunca sıkıcı teknoloji tercih edilmeli. Geliştirme ekiplerinin en alt katmana kadar her şeyi yenilemeye çalışırken, aslında hangi değeri sunduklarına dair odağı kaybettiklerini çok sık gördüm. Bu slayt destesini dünya görüşüme kazımak istiyorum.

  • Simon'dan yine iyi bir yazı. Dün gece yeni bir projeye bu kavramı aynen ekledim. Google Gemini App'in yt-dlp'yi sansürlediğini ama Gemini API'nin sansürlemediğini gösteren bir kanıt sunmak istedim; aynı zamanda projeye trafik getirecek yolları ve Simon'ın bahsettiği iş tarafındaki gerekçeleri de oluşturmak istedim.
    https://topicalsource.dev/chat/84a0d6dd-f66f-4f12-af17-5e99c...
    Ayrıca localStorage kullanarak ziyaret edilen herkese açık sohbetlerin listesini kaydettirdim. Geri döndüğünüzde okuduğunuz diğer sohbetleri görebiliyorsunuz; ilk bağlantıyı nereden aldığınızı bulmak için mesaj geçmişini kurcalamaktan da daha kolay.

    • Not: Örnek YouTube bağlantısını açmasanız iyi olur. Gemini yaygın bir troll mem çekip getirmiş.

  • Ölü bağlantılar en kötüsü. Biri GPT ile ölü bağlantıdaki web sitesini halüsinasyonla yeniden oluşturan bir tarayıcı eklentisi yapamaz mı?

    • Şimdiden birkaç nesil, bağlantı çürümesinin yalnızca Discord görsel bağlantıları gibi “iç” URL'lerde değil, tüm bağlantılarda yaşandığını bilmiyor olabilir.
      Sanatçılar yalnızca sosyal medya sitelerine bağlantı veriyor; oysa hesaplar askıya alınabilir ve kullanıcı adları değişebilir. Geliştiriciler de bağımlılıkları “bağlarken” deponun kaybolabileceğini, kimse yedeklemediyse o sürümün kaynak kodunun da birlikte yok olabileceğini, paket sürümünün registry'den kaldırılabileceğini veya bağımlılığın çevrimiçi dokümantasyonunun kaybolabileceğini hesaba katmıyor.
      [1]: Manifest dosyasına sadece ad+sürüm ekleyip sonsuza kadar unutmak. Önbellek ekleseniz bile bu düzgün bir mirror değil; felaket durumunda bağımlılıkları kendi başınıza derleyebileceğiniz bir yöntem hiç değil.
    • https://websim.ai/
    • Sabitlenmiş bir LLM sürümünün yazarın amacını karşılayan bir sayfa oluşturmasına yetecek kadar bilgiyi sağlayan bir sıkıştırma yöntemi de ilginç olabilir.
      İnsanların o sayfanın eskiden nasıl göründüğünü tek tek tarif etmesi ya da ipuçları bulmak için web'i taraması epey ilginç bir fikir. “Yapım aşamasında” banner'larını da geri getirebiliriz.
    • Eskiden buna hayal gücü denirdi. Dijital çağda kaybetmişiz gibi :3
    • Tarayıcı eklentisini bilmem ama websim AI adlı bir site, LLM ile gerçek zamanlı sahte sayfalar oluşturuyor. Açıkçası şaşırtıcı derecede iyi çalışıyor.

  • Simonw blogunu seviyorum. Geçen yıl eylülden beri blogunu Python yorumlayıcısını kullanarak okuyorum. Kendisinin bunu, anında tam uygulamalar yapmak için tek başına kullanmaya başladığını söylemişti.
    Ancak hâlâ bunun nasıl yapıldığı bana net değil. Kolay bir seçenek ya da düğme vardır sanmıştım ama bulamadım. Daha çok uğraşıp öğrenebilirdim, ama pratik bir bağlantı ya da eğitim olsaydı GPT'yi büyük ölçüde görmezden gelmek yerine kullanmayı sürdürürdüm.

  • Bu bağlamda Square'in kesinti müdahale mem'i https://outage.party/ adresinde yaşamaya devam ediyor.

    • O zaman orada olmayanlar için bağlamı açıklayabilir misiniz?

  • Microsoft ürünlerinin önemli bir kısmından tam da bu yüzden gerçekten nefret ediyordum. VSTS/VSO/Dev Ops gibi adı sürekli değişen ürünler ya da Sharepoint özellikle berbattı. Tek bir deep link 700 karakterdi; onlarca base64 sorgu dizesi ve saçma sapan bir yol eklenmiş oluyordu. “Sorun ne? URL kısaltma servisi kullanırsınız olur biter, değil mi? URL’ler zaten uzundur, yapacak bir şey yok” tarzı yaklaşımları insanı çıldırtıyordu.
    2014’te ekip içi bir araç sistem kaynaklarının durumunu gösteriyordu ve tüm kaynaklar ile durumları bir SQL veritabanındaydı. Ama web uygulaması, router gibi şeyler ortaya çıkmadan önceki bir SPA’ydı; URL’yi güncellemiyor, deep link desteklemiyordu. Belirli bir kaynak sorununu e-posta ya da mesajlaşma uygulamasıyla göndermek için “X aracına git, Y’yi ara, sonra Z -> W -> M -> O -> K’ye bas, orada görürsün” diye açıklamak gerekiyordu. Derinlemesine iç içe geçmiş bir durumu neden basitçe https://X.com/Y/Z/W/M/O/K bağlantısıyla paylaşamadığımıza çok sinir oluyordum. Defalarca söyledim ama aldığım yanıt hep “öncelik değil ve o kadar da büyük bir mesele değil” oldu.
    Bir keresinde düzeltmek istediğim bir şey üzerinde 2 hafta çalışma fırsatım oldu ve deep link destekleyen bir alternatif yapmaya karar verdim. Ayrıca tüm deep link’lerin başına /api/ öneki eklenirse içeriği JSON olarak döndürmesini sağladım. Ekipte ve şirkette büyük ses getirdi; aracım çok daha basit ve daha az özellikli olmasına rağmen X aracının kullanımı neredeyse bir gecede düştü. Sonuçta çoğu insanın istediği şey “derinlemesine kazıp araştırma yapmaya yarayan güçlü bir SPA”dan çok, bağlantıları kolayca paylaşmanın bir yoluydu.
    Bir ay sonra X aracı ekibi, şirket geneline attığı e-postayla deep link desteğini büyük bir duyuruyla açıkladı. Ama /api/ önekiyle JSON verisi döndüren basit özelliği önemli görmediler. 5 yıl sonra aracımın UI’ı eskimişti, fakat gerçek servis; birçok ekip otomasyonlarını /api/ önekli URL’ler etrafında kurduğu için kritik bir iç servis statüsüne yükseldi ve sonunda o ekibin kodu devralıp bakımını yapması gerekti.

    • Ofis ortamlarında insanların araçları ve belirlenmiş prosedürleri aynen kullanmaktan memnun olduklarını, daha iyi olabileceğini pek düşünmediklerini sıkça gördüm. Sorsanız da böyledir; daha iyisini gösterene kadar fark etmezler.
    • React Server Components’ın rahatsız edici gelmesinin nedenlerinden biri, API ile sunum katmanını karıştırmaya teşvik etmesi. Avantajları var, ama hepimiz biliyoruz ki sunum katmanı, henüz öngörülmemiş kullanıcılar ya da kullanım senaryoları için tasarlama konusunda her zaman başarısız olur.
    • SPA nedir?

  • Bir Simonw hayranı olarak, henüz kimsenin değinmediği bir noktayı söyleyeyim: Simon’ın insanların bağlantı verebileceği şeyler sunmasının diğer örnekleri HN’de de çok etkili: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
    Simon, yapay zeka tarafında yakın çevredekilerin zaten bildiği ama daha geniş kitlenin henüz bilmediği gelişmeleri çoğu zaman çok hızlı özetliyor. İlgili gerçekleri hızla bağlantılanabilir ve erişilebilir hale getirerek, konudan uzakta olan insanların da tartışmaya katılmasını sağlıyor.

  • “Hiperlinkler web’in en iyi yanı” sözüne katılıyorum. Daha doğrusu hiperlinkler ve URL’ler.
    URL, web’in temel taşıdır. Yazıları ve diğer kaynakları doğru, evrensel olmasını umduğumuz ve uzun ömürlü olmasını istediğimiz bir biçimde referans göstermemizi sağlar. İnsanların bunun ne kadar harika olduğunu fark etmemesini görmek beni hep sinirlendiriyor. Örneğin bir mesaja link yapıştırmak yerine “Bunu YouTube’da ara” demeleri gibi. Bir yazıya web üzerinde kalıcı bir yuva vermek görünürlüğünü de artırır, yazarın aynı düşünceyi tekrar tekrar yazma ihtiyacını da azaltır.
    İlgili klasik deneme: Cool URIs don't change. [0][1]
    [0] https://www.w3.org/Provider/Style/URI
    [1] https://news.ycombinator.com/item?id=23865484

    • URL’lerin yeterince kullanılmayan iki özelliği neredeyse sınırsız sayıda üretilebilmeleri ve beyanlarının öne çekilebilmesidir.
      Pratikte etkisi şöyle olur: Biriyle konuşurken ya da bir sunumun soru-cevap bölümünde “Evet, bunu biz de düşündük ve ilgili bilgi acmeinitiative.example.com/skub adresinde” demek isteyebilirsiniz; henüz /skub yazısını yazmamış olsanız bile, o anda /skubu o yazının belirlenmiş tanıtıcısı olarak hemen seçebilirsiniz. Yazıyı daha sonra yazdığınızda orada görünür; ilgilenenler de istedikleri zaman o URL’den bulabilir. Başkasının yazdığı bir yazı ya da dış kaynak için de aynı şey geçerli: kendi ad alanınızda anında bir URL oluşturup sonra vaktiniz olduğunda asıl linke yönlendirebilirsiniz.
      Kendi alan adına açıkça sahip olan zeki teknoloji insanlarının yer aldığı kayıtlarda, podcast’lerde vb. bu yöntemi kullanmadıklarını çok fazla duydum. Genelde belki bulunabilecek bir tarif mırıldanıyorlar ya da başlığı hatırlamaya çalışıp yarısını yanlış söylüyorlar. Sonra ilgilenen tüm dinleyicilerin her biri bunu bulmak için kendi zamanını ve dikkatini harcamak zorunda kalıyor; kolektif olarak muazzam bir enerji boşa akıyor.
    • Duvarlarla çevrili bahçeler URL’leri giderek daha fazla engelliyor.
      FB, telifli içerik paylaşımı gerekçesiyle rastgele bloglar dahil birçok siteyi engelliyor; reddit tüm .ru alanlarını, çeşitli arşiv sitelerini, Telegram linklerini vb. engelliyor. Twitter bazı blog platformlarını engelledi; daha küçük siteler de çoğu zaman Discord’u engelliyor. Discord engellemesi haklı görülebilir, ama bu eğilimin insanların oradan ayrılmasına vesile olmasını isterim.
    • “Ara” ifadesinden hoşlanmıyorum.
      Birincisi, hemen AOL Keyword benzeri rahatsız edici bir hissi tetikliyor. İkincisi, arama balonu kavramını tamamen yok sayıyor. Aynı arama terimini girsek bile senin ve benim aldığımız sonuçlar epey farklı olabilir. Üçüncüsü, URL ve hiperlink zaten varken bana fazladan iş çıkarmana gerek yok. Doğrudan link verirsen, sayısız tepki videosu arasında dolaşmadan tam olarak neye atıf yaptığını görebilirim.
    • https://youtu.be/dQw4w9WgXcQ adresine tıklamamı söylemek kolay, ama telefon ya da podcast gibi yalnızca sesli mecralarda bu URL’yi nasıl ileteceksiniz? Aynı şekilde ezberlemesi zor URL kısaltma servislerine bel bağlamadan bu kolay değil.
    • Yazarın aynı düşünceyi tekrar yazmak zorunda kalmaması kısmının gerçekten öyle olmasını isterdim.
      Ama birçok site ve servis bundan hoşlanmıyor. Çünkü bunu kendi dikkat alanlarına bir müdahale olarak görüyorlar. Bir yazar olarak, bir blog yazısında ya da kitapta zaten özenle ifade ettiğim bir fikre link verdiğimde, yorum “tanıtım” gerekçesiyle kaldırılıyor ya da sansürleniyor. Bugünlerde HN’de ceza almamak için, okurun daha derine inebileceği bir link vermek yerine, yazdığım özgün metni doğrudan kopyalayıp yapıştırdığım daha sık oluyor. Bilgiyi yaymanın iyi bir “akademik” yolu diye savunduğumuz şey ile ifadeyi kontrol eden sistemlerin gerçekliği arasında bariz bir uçurum var.