Sınıflandırma yapısı sayesinde, tasarımımızda hangi stratejinin gerçekten çalıştığını az çok görebiliyoruz.
"Verebiliyor ama vermiyor" tarafını wrapper ile ele almadan önce, önce 149 vakaya bakmak daha doğru görünüyor. Yanıtta bir ID var ama eşleme yapılmadıysa, bunun nedeni büyük olasılıkla alan adı konvansiyonu sorunu (id / _id / resource_id / document_id) ya da iç içe yapı (result.data.id) olabilir. Bu 149 vaka, API'yi değiştirmeden yalnızca mapping katmanını düzelterek yakalanabilecek bir kapsamda.
"Veremeyen" taraf için ise araca göre farklı yaklaşmak gerekecek gibi görünüyor.
write_file için yol + içerik hash'i kombinasyonuysa, "aynı içerik iki kez yazıldı mı" tespit edilebilir.
k8s scale için hedef replica sayısı mevcut değerle zaten aynıysa fiilen idempotent — ön durum sorgusuyla yinelenen çalıştırmanın kendisi engellenebilir.
click farklı. Aksiyonun kendisine ID eklemenin pek anlamı yok; bunun yerine, "bu click'in hedeflediği durum değişikliği zaten gerçekleşti mi" sorusunu öncesi/sonrası snapshot'ları karşılaştırarak ele almak daha gerçekçi görünüyor.
Bizim içeride tartıştığımız şey, araçları "ID döndürebilme durumu × durum değişikliği türü" şeklinde bir matrise oturtup işleme stratejisini dallandırmak. 149 vakanın hangi örüntülerde yoğunlaştığını biraz daha paylaşırsanız, mapping stratejisini belirlemede yardımcı olur.
Evet! Modelleme, yaygın standart daire tipini baz alacak şekilde yapıldı.
Ancak bu standart tipin bulunmadığı apartmanlarda, tahmin çoğunluktaki örnek daire tipleri üzerinden yapılacak şekilde uygulanmıştır.
Annemle babamın oturduğu eski apartmanı girip denedim..
Sadece 33 pyeong çıkıyor.. O eski apartmanda 33 pyeong ve 26 pyeong birlikte var.
Normalde sadece 33 pyeong mu destekleniyor?
Metinde apartman paylaşım özelliğini atlamışım haha. Ünlü büyük site Helio City için bir paylaşım bağlantısını test amacıyla bırakıyorum.
(Tahmin sonuçlarını lütfen yalnızca referans amaçlı değerlendirin; ayrıntılı modelleme için teknik incelemeye bakmanızı rica ederim!)
Giriş yapmadan hemen açılıyor; grafik arayüzüne göz atmak için rahatça tıklayın. https://app.apt-insights.com/s/apt/9NPumhVmCv
Ah, cppreference için Korece bir site olduğunu bu yazıyı görünce ilk kez öğrenip sevinmiştim..
Sanırım her zamanki gibi İngilizce siteyi kullanmak gerekecek.
3.197 vakayı nedene göre ayırınca tablo şöyle oluyor.
Yanıtta ID alanı hiç yok: 2.011 vaka (%62,9)
Çağrı hatayla başarısız oldu: 1.037 vaka (%32,4)
Yanıtta ID var ama bizim eşlememiz yakalayamadı: 149 vaka (%4,7)
Burada bir düzeltme yapmam gerekiyor. Az önce "çoğu mükerrerlik, takibin kendisinin yapılamadığı aralıkta" demiştiniz; ancak %32'si çağrının başarısız olduğu vakalar. Hiçbir şey gerçekleşmediği için takip edilecek bir hedef de yok. Gerçekten "gerçekleştiği hâlde takip edilemeyen" 2.011 vaka var. Bu hâlâ büyük bir sayı, ama 3.197'den küçük.
Yalnızca başarı/başarısızlık döndüren 24 araç vardı. Türlerine göre gruplarsak:
Bu 24 araç iki türe ayrılıyor. Spesifikasyon tasarımında işe yarayabileceğini düşündüğüm için ekliyorum.
ID veremeyenler: Tarayıcı tıklaması veya dosya düzenleme gibi işlemlerde baştan "oluşturulan bir varlık" yoktur. Bir tıklamaya ID ekleyemezsiniz. Dosyada ise yol zaten tanımlayıcıdır.
ID verebildiği hâlde vermeyenler: github-create_repository bunun tipik örneği. Bir depo oluşturduysanız elbette bir ID vardır ama yanıtta yok. emails-send_email için de SMTP seviyesinde message ID vardır ama geri döndürülmüyor. github-fork_repository ve excel-write_data_to_excel de aynı durumda.
Düzeltilebilecek taraf ikincisi. İç araç spesifikasyonuna "oluşturma türündeki işlemlerde yanıt içinde varlık ID'si zorunludur" kuralını koyacaksanız, bu ayrımın nerede uygulanacağını belirlemek için bir ölçüt olabileceğini düşünüyorum.
Son 149 vaka bizim eşleme sorunumuz. notion database-query 102 vaka, pptx open_presentation 28 vaka olarak yoğunlaşmış; ikisi de bizim bilinçli olarak kapsam dışında bıraktığımız araçlar olduğu için yakalanmadı. Bu bir araç tasarımı sorunu değil, bizim kapsama alanı sorunumuz.
Şu anda işlettiğiniz stack'te yazma işlemleri daha çok hangi tarafa yığılıyor? Bizim baktığımız şey bir benchmark olduğu için araç bileşiminin gerçek operasyonlardan farklı olabileceğini düşünüyorum.
Her gün bir adım bile ilerleyebiliyorsak bu yeterlidir.
Üretim kolaylaşırken doğrulama daha incelikli hale geliyor; sonunda “seçim”in kilit olduğu bir çağa giriyoruz. Bu nedenle akışı doğru okuyabilen bir bakış açısı her zamankinden daha önemli.
Günümüzde kodlama ajanları kişinin eksik kaldığı yönleri tamamlayabildiği için, insan kendi güçlü taraflarını net biçimde bilip bunları öne çıkarabilirse eşiğin düşebileceğini düşünüyorum.
Benim için de sorun hep dokümantasyondu; bunu bir ölçüde kodlama ajanına devredince hem yüküm azaldı hem de o dokümante edilmiş materyalleri gözden geçirirken dokümantasyon konusunda bir bakış açısı kazanmaya başladığımı hissediyorum.
Genç... Evimin değerini geri verin...
Şu anda her ay abonelik kullanıyorum... Maliyeti pek küçük değil gibi geldiği için sürdürülebilirliği üzerine düşünüyorum.
Sınıflandırma yapısı sayesinde, tasarımımızda hangi stratejinin gerçekten çalıştığını az çok görebiliyoruz.
"Verebiliyor ama vermiyor" tarafını wrapper ile ele almadan önce, önce 149 vakaya bakmak daha doğru görünüyor. Yanıtta bir ID var ama eşleme yapılmadıysa, bunun nedeni büyük olasılıkla alan adı konvansiyonu sorunu (
id/_id/resource_id/document_id) ya da iç içe yapı (result.data.id) olabilir. Bu 149 vaka, API'yi değiştirmeden yalnızca mapping katmanını düzelterek yakalanabilecek bir kapsamda."Veremeyen" taraf için ise araca göre farklı yaklaşmak gerekecek gibi görünüyor.
write_fileiçin yol + içerik hash'i kombinasyonuysa, "aynı içerik iki kez yazıldı mı" tespit edilebilir.k8s scaleiçin hedef replica sayısı mevcut değerle zaten aynıysa fiilen idempotent — ön durum sorgusuyla yinelenen çalıştırmanın kendisi engellenebilir.clickfarklı. Aksiyonun kendisine ID eklemenin pek anlamı yok; bunun yerine, "bu click'in hedeflediği durum değişikliği zaten gerçekleşti mi" sorusunu öncesi/sonrası snapshot'ları karşılaştırarak ele almak daha gerçekçi görünüyor.Bizim içeride tartıştığımız şey, araçları "ID döndürebilme durumu × durum değişikliği türü" şeklinde bir matrise oturtup işleme stratejisini dallandırmak. 149 vakanın hangi örüntülerde yoğunlaştığını biraz daha paylaşırsanız, mapping stratejisini belirlemede yardımcı olur.
Evet! Modelleme, yaygın standart daire tipini baz alacak şekilde yapıldı.
Ancak bu standart tipin bulunmadığı apartmanlarda, tahmin çoğunluktaki örnek daire tipleri üzerinden yapılacak şekilde uygulanmıştır.
Annemle babamın oturduğu eski apartmanı girip denedim..
Sadece 33 pyeong çıkıyor.. O eski apartmanda 33 pyeong ve 26 pyeong birlikte var.
Normalde sadece 33 pyeong mu destekleniyor?
Vay~ Bu benim de yapmak istediğim bir hizmetti; böyle bir crawling yapıldığında Supabase maliyeti yaklaşık ne kadar oluyor, öğrenebilir miyim?
Video ve kayıtların tamamı sunucuya mı servis ediliyor?
Metinde apartman paylaşım özelliğini atlamışım haha. Ünlü büyük site Helio City için bir paylaşım bağlantısını test amacıyla bırakıyorum.
(Tahmin sonuçlarını lütfen yalnızca referans amaçlı değerlendirin; ayrıntılı modelleme için teknik incelemeye bakmanızı rica ederim!)
Giriş yapmadan hemen açılıyor; grafik arayüzüne göz atmak için rahatça tıklayın.
https://app.apt-insights.com/s/apt/9NPumhVmCv
Ücretsiz uygulama da çok, yapması da kolay; ücretli uygulamaysa hmm...
Bildirim için teşekkürler. Düzelttim!!
Teknik inceleme bağlantısı 404 hatası veriyor!
https://edge.apt-insights.com/v1/public/whitepaper
Ah,
cppreferenceiçin Korece bir site olduğunu bu yazıyı görünce ilk kez öğrenip sevinmiştim..Sanırım her zamanki gibi İngilizce siteyi kullanmak gerekecek.
Ah, uzun zamandır Windows kullanmadığım için pek bilmiyordum. Araştırınca benzer görünüyor.
3.197 vakayı nedene göre ayırınca tablo şöyle oluyor.
Yanıtta ID alanı hiç yok: 2.011 vaka (%62,9)
Çağrı hatayla başarısız oldu: 1.037 vaka (%32,4)
Yanıtta ID var ama bizim eşlememiz yakalayamadı: 149 vaka (%4,7)
Burada bir düzeltme yapmam gerekiyor. Az önce "çoğu mükerrerlik, takibin kendisinin yapılamadığı aralıkta" demiştiniz; ancak %32'si çağrının başarısız olduğu vakalar. Hiçbir şey gerçekleşmediği için takip edilecek bir hedef de yok. Gerçekten "gerçekleştiği hâlde takip edilemeyen" 2.011 vaka var. Bu hâlâ büyük bir sayı, ama 3.197'den küçük.
Yalnızca başarı/başarısızlık döndüren 24 araç vardı. Türlerine göre gruplarsak:
Tarayıcı işlemleri (9 adet) — click, type, navigate vb. Yalnızca click 719 vaka
Dosya sistemi (3 adet) — write_file, edit_file, move_file
Kubernetes (4 adet) — scale, create, apply, delete
Belge düzenleme (3 adet) — add_paragraph, add_heading, format_text
Tekil olanlar — emails-send_email, excel-write_data_to_excel, snowflake-write_query, logging_write_log, github-fork_repository, github-create_repository
Bu 24 araç iki türe ayrılıyor. Spesifikasyon tasarımında işe yarayabileceğini düşündüğüm için ekliyorum.
ID veremeyenler: Tarayıcı tıklaması veya dosya düzenleme gibi işlemlerde baştan "oluşturulan bir varlık" yoktur. Bir tıklamaya ID ekleyemezsiniz. Dosyada ise yol zaten tanımlayıcıdır.
ID verebildiği hâlde vermeyenler: github-create_repository bunun tipik örneği. Bir depo oluşturduysanız elbette bir ID vardır ama yanıtta yok. emails-send_email için de SMTP seviyesinde message ID vardır ama geri döndürülmüyor. github-fork_repository ve excel-write_data_to_excel de aynı durumda.
Düzeltilebilecek taraf ikincisi. İç araç spesifikasyonuna "oluşturma türündeki işlemlerde yanıt içinde varlık ID'si zorunludur" kuralını koyacaksanız, bu ayrımın nerede uygulanacağını belirlemek için bir ölçüt olabileceğini düşünüyorum.
Son 149 vaka bizim eşleme sorunumuz. notion database-query 102 vaka, pptx open_presentation 28 vaka olarak yoğunlaşmış; ikisi de bizim bilinçli olarak kapsam dışında bıraktığımız araçlar olduğu için yakalanmadı. Bu bir araç tasarımı sorunu değil, bizim kapsama alanı sorunumuz.
Şu anda işlettiğiniz stack'te yazma işlemleri daha çok hangi tarafa yığılıyor? Bizim baktığımız şey bir benchmark olduğu için araç bileşiminin gerçek operasyonlardan farklı olabileceğini düşünüyorum.
Korece sürümünün son güncellemesi 2016'da olduğu için özgün metne bakmak daha iyi olabilir
Her gün bir adım bile ilerleyebiliyorsak bu yeterlidir.
Üretim kolaylaşırken doğrulama daha incelikli hale geliyor; sonunda “seçim”in kilit olduğu bir çağa giriyoruz. Bu nedenle akışı doğru okuyabilen bir bakış açısı her zamankinden daha önemli.
Windows'un yerleşik özelliğine benzer bir şey mi? Windows + V
Vay, sadece bununla rol yapma gibi şeyler için endişelenmeye gerek kalmaz herhalde.
Ah, düzelttim.
Günümüzde kodlama ajanları kişinin eksik kaldığı yönleri tamamlayabildiği için, insan kendi güçlü taraflarını net biçimde bilip bunları öne çıkarabilirse eşiğin düşebileceğini düşünüyorum.
Benim için de sorun hep dokümantasyondu; bunu bir ölçüde kodlama ajanına devredince hem yüküm azaldı hem de o dokümante edilmiş materyalleri gözden geçirirken dokümantasyon konusunda bir bakış açısı kazanmaya başladığımı hissediyorum.