2000’lerin sonlarında araç navigasyon yazılımı şirketinde çalışırken rota arama modülü geliştirdiğim günlerin anısı(?) aklıma geliyor. Dijkstra, navigasyon rota aramasında kullanılmayacak kadar yavaş olduğu için tercih edilmiyor; bunun yerine sezgisel olarak iyileştirilmiş sürümü olan A* (A Star) araması kullanılıyor. Araştırınca A*’ın SSSP değil, SPSP (Single-Pair Shortest Path) algoritması olduğunu gördüm.

 

Bunu yapmış biri olarak söylüyorum; kişiselleştirme için çoksa 2 GB'tan fazla bilgi miktarı gerekiyor

 

markitdown formatlar arası dönüşümde kullanışlı ama PDF için asla kullanılmamalı bence

Belge çıkarma tarafında Gemini gibi multimodal LLM kullanan yöntemler zaten epey var ve benchmark sonuçlarında da oldukça iyi görünüyorlar. Ancak maliyet sorun oluyor.

docling gibi şeyler de iyi.

 

İşlev veya yaklaşım olarak Atlas'a benziyor: https://atlasgo.io/

 

Üç temel tuzağa da gerçekten çok katılıyorum. Sadece tek bir gatekeeper bile olsa, ortaya bir dizi olumsuz durum çıkabiliyor.

 

Düşük seviye... demek için de... formu uygulamak için sadece HTML input etiketi kullanınca olacak bir iş için state'i, jsx'i, kontrolsüz/kontrollü bileşeni gereksiz yere bilmek zorunda kalmak, ayrıca çok fazla kod üretmek zorunda kalmak gibi şeyler metnin motivasyonu olmadı mı diye düşünüyorum

 

Sigara içmediğim için ne denmek istendiğini önce anlamamıştım ama tek kullanımlık olmasına rağmen fazlasıyla çok kaynak kullanıldığını söylüyormuşsunuz.

 

karma -47'nin görkemi haha

 

Başka bir yöntemin yeni eklenmiş olması, mevcut yöntemin öldüğünü söylemek gibi geliyor.
Gerçekten mevcut yöntemi artık kullanamıyor muyuz ve mutlaka yeni yöntemi mi kullanmamız gerekiyor?

 

Bu konsepte oldukça katıldığım için hafta sonu yeni bir projede biraz test ettim, ama düşündüğüm kadar iyi çalışmıyor. Hâlâ çok fazla iyileştirmeye ihtiyaç var gibi görünüyor. Öncelikle kabaca çalışma şekli, daha önce birçok kez tanıtıldığı gibi, şöyle: spesifikasyon yazımı → spec yazımı → görev yazımı → uygulama

Sorun ise şu:

  • constitution.md dosyası "nasıl geliştireceğiz" konusundaki temel rehber ama "bu uygulama sonunda ne olacak" bilgisini içermiyor
  • spec.md, tek bir özelliği açıklayan bir doküman
  • "bu uygulama nedir" sorusuna cevap veren bir ana doküman yok
  • GitHub'da yürüyen tartışmaları okuyunca, spec zincirinin eninde sonunda source of truth olacağı söyleniyor gibi görünüyor. Biraz kuşkulandırıyor ama kabaca anlayabildim.
  • /specify ve /tasaks komutlarıyla çok sayıda doküman çıktı olarak üretiliyor (istediğim sonuç buydu), ama bu yüzden sanırım context çok hızlı tüketiliyor (Claude Code kullanıyorum)
  • Bir kez implementasyona girince, bir süre Spec Kit'ten uzaklaşılıyor ve her zamanki gibi Claude Code ile sohbet ederek implementasyon tamamlanıyor
  • Tüm context tüketilip compaction yapıldığında ya da yeni bir oturum başlatıldığında, Spec Kit'in oluşturduğu dokümanların varlığı unutuluyor
  • tasks.md içinde tanımlı işleri ilerletirken, başta düzgün yapılmış şeylerin üzerine yazılabildiği ve bug düzeltme sürecinde yeni özellikler de yapılabildiği için tasks.md ile giderek bağ kopuyor. tasks.md'yi kalıcı olarak saklamanın anlamını bilmiyorum.

Şimdilik vardığım sonuçlar şöyle:

  • İlk düşünülen şeyden farklı bir sonuç çıksa bile, önce spec'i tamamlayıp ardından yeni bir spec oluşturarak yavaş yavaş düzeltmek gerekiyor
  • İlk spec kaçınılmaz olarak büyüyecek, bu yüzden uygulamanın işlevlerini hiç açıklamadan sadece boilerplate oluşturmak daha iyi olabilir
  • PoC seviyesinde bir şey yaparken Spec Kit kullanmamak daha iyi olabilir
 

Hahahahahahahaha

 

Kesinlikle katılıyorum. Ne kadar iyi yapılırsa yapılsın, araya girmesi rahatsız edici oluyor. Sanki yokmuş gibi durup ihtiyaç duyulduğunda ortaya çıkıp yardımcı olması ideal; burada kritik nokta bununla ilgili durum değerlendirmesini ne kadar isabetli yaptığı gibi görünüyor. İnsanlarda da bunu iyi yapanlar var, yapamayanlar var; yapay zeka bunu aşabilirse bir devrim yaşanacak gibi görünüyor.

 

Vulkan ile ilgili olarak, tam ifade etmek gerekirse doğru olan şu: Pi 5'in iGPU'sunun desteklediği Vulkan API, llama.cpp tarafından henüz desteklenmiyor. Bu desteklenmiş olsaydı performansın ne kadar olacağını ben de merak ediyorum.

 
joyfui 2025-09-21 | üst yorum | konuda: Ultrasonik Şef Bıçağı (seattleultrasonics.com)

Vay canına! Ultrasonik kesici!

 

markitdown, PDF ayrıştırma için https://github.com/pdfminer/pdfminer.six bunu kullanıyor ve metin ya da gömülü görselleri dosyadan olduğu gibi çıkarıyor. OCR demek bile baş döndürücü...

 
kuber 2025-09-21 | üst yorum | konuda: Grok 4 Fast (x.ai)

gpt-oss'tan daha pahalı ve daha yavaş görünüyor; insanların bunu neden bu kadar çok kullandığını merak ediyorum..

 

Korece promptlara ihtiyaç duyanlar için burada Koreceye çevrilmiş promptlar var. Sadece tıklayın, doğrudan ChatGPT ve Claude'a giriliyor.

https://gongbuhow.com/posts/chatgpt-students-100-use-cases/

 

5 saniyelik bir iki reklam gösterildiğinde karşılıklı bir denge var diye düşünüp reklamların hepsini izliyordum ama sonu gelmeyen ardışık reklamlar ve videonun ortasına rastgele reklam koyma işinde iyice çizgiyi aşınca anında ad blocker kurdum, haha

 

Geçenlerde civit.ai'da bounty özelliği olduğunu görünce bunu bir bug bounty sanmıştım, ama meğer işlev geliştirmelerini ödülle birlikte herkese açık şekilde yayınlayabiliyorlarmış. Biraz ilginç bir konseptti. Para var ama şirket içi yetkinlik yetersizse fena bir seçenek olmayabilir.