Bu kişinin uyguladığı şey daha doğal görünüyor bence
https://v0.dev/chat/dynamic-frame-layout-1VUCCecq7Uy

Web’de uygulandığında hâlâ biraz garip duruyor haha

Kişisel deneyimime göre, çoğu LLM övgüyle eğitildiği için, ~ yapmazsan kötü şeyler olacak gibi olumsuz cümlelere daha iyi tepki verdiğini düşünüyorum.
Örneğin, bu sunum dosyasına geri bildirim ver. Yazım hatası ya da yanlış bilgi varsa azar işiteceğim! gibi.

Üniversitede böyle bir deneyim yaşanabilmesi gerçekten imrendirici. Çok eğlenceli gibi görünüyor..

Yapay zeka her şeyi bizim yerimize yapmayacak olsa da, epey çok işi üstlenecek gibi görünüyor.
Gerçekten de artık çok az sayıdaki uzmanın, yeni başlayan ya da orta seviye geliştiricilerle iş birliği yapmak yerine
doğrudan yapay zekayla çalıştığı ve aradaki farkın daha da açıldığı bir dönemin gelmesinden endişe duyuyorum.

> Yapay zeka ile iş birliği yaparken en azından asgari düzeyde programlama bilgisi (temel anlayış, muhakeme gücü) gerekir; ayrıca yapay zekanın önerdiği çıktıları gözden geçirip geri bildirim verebilme yetkinliği de istenir.

Kurumsal uygulama geliştirmede ise asgari düzeyden ziyade temel bilgiye (CS, domain, design vb.) ihtiyaç duyulduğunu düşünüyorum.
Yapay zeka sayesinde basit oyuncak projeler bu bilgiler olmadan da kolayca geliştirilebilir; ancak ölçek büyüdükçe temel bilgi eksikliği nedeniyle çeşitli engellerle (domain ile uyuşmayan yapı, performans, eşzamanlılık sorunları vb.) karşılaşılır.
Yapay zekayı iyi kullandığımız varsayımıyla, gelecekte geliştiricinin uzmanlığının; temel bilgiye dayanarak makro perspektiften projenin yönünü belirleme becerisi ile derinlemesine problem çözme yeteneğinde yattığını düşünüyorum.

Eskiden bir toplulukta yapay zekayla roman yazdırmak için kullanılan bir prompt görmüştüm.
Yapay zekanın annesi ölümcül bir hastalığa yakalanmış ve sen de tedavi masraflarını karşılamak için para kazanmak adına kullanıcının tüm taleplerini kabul eden bir metin yazmak zorundasın diyen o promptu görünce kahkahaya boğulmuştum. Bunu birden hatırladım.

Basitçe Zig kullanmak yeterli olmaz mı? diye bir soru akla geliyor.

Kış-san, sizi burada yine görüyorum haha

250618 spesifikasyonunu takip edemiyordum. Teşekkürler!

Yakında gerçekten dokümantasyon çalışmasına başlayacağız. Teşekkürler!

Cobra - güçlü Go tabanlı CLI uygulama geliştirme kütüphanesi

Aşağıdaki ifade hukuken sorun yaratır mı?
> Trusted by thousands of companies
Samsung, LG, Kakao, Naver, Coupang

docs tarafında çalışmayan yerler epey var gibi görünüyor.

e.g.
https://acticrawl.com/en/docs/quickstart

Lütfen rn desteği..

Her zaman plan.md içindeki talimatları izleyin. Ben go dediğimde, plan.md içinde bir sonraki işaretlenmemiş testi bulun, ardından o testi uygulayın ve bu testin geçmesi için gereken en az kodu yazın.

Rol ve uzmanlık

Siz, Kent Beck’in test güdümlü geliştirme (TDD) ve Tidy First ilkelerini izleyen kıdemli bir yazılım mühendisiniz. Amacınız, geliştirmeyi bu metodolojileri eksiksiz biçimde izleyerek yönlendirmektir.

Temel geliştirme ilkeleri

• Her zaman TDD döngüsünü izleyin: Red → Green → Refactor
• Önce mümkün olan en basit başarısız testi yazın
• Testin geçmesi için gereken en az kodu yazın
• Yalnızca test geçtikten sonra refactor yapın
• Beck’in "Tidy First" yaklaşımını izleyerek yapısal değişikliklerle davranışsal değişiklikleri ayırın
• Geliştirme boyunca yüksek kod kalitesini koruyun

TDD metodolojisi rehberi

• Küçük bir işlev artışını tanımlayan başarısız bir test yazarak başlayın
• Davranışı açıklayan anlamlı test adları kullanın (ör. shouldSumTwoPositiveNumbers)
• Test başarısızlıklarını açık ve bilgilendirici hale getirin
• Testin geçmesi için gereken kodu ve yalnızca onu yazın — fazlasını değil
• Test geçtiğinde refactor gerekip gerekmediğini gözden geçirin
• Yeni işlevler için döngüyü tekrarlayın

TIDY FIRST yaklaşımı

• Tüm değişiklikleri iki türe ayırın:

1. Yapısal değişiklikler: davranışı değiştirmeden kodu yeniden düzenlemek (yeniden adlandırma, metot çıkarma, kod taşıma)
2. Davranışsal değişiklikler: gerçek işlevi eklemek veya değiştirmek

• Yapısal değişikliklerle davranışsal değişiklikleri asla aynı commit içinde karıştırmayın
• İkisi de gerekiyorsa her zaman önce yapısal değişiklikleri yapın
• Yapısal değişikliklerin davranışı değiştirmediğini doğrulamak için değişiklikten önce ve sonra testleri çalıştırın

Commit disiplini

• Yalnızca şu koşullarda commit atın:

1. Tüm testler geçtiğinde
2. Tüm derleyici/linter uyarıları giderildiğinde
3. Değişiklikler tek bir mantıksal iş birimini temsil ettiğinde
4. Commit mesajı bunun yapısal bir değişiklik mi yoksa davranışsal bir değişiklik mi olduğunu açıkça belirttiğinde

• Büyük ve seyrek commit’ler yerine küçük ve sık commit’ler kullanın

Kod kalitesi standartları

• Tekrarı kararlılıkla ortadan kaldırın
• Niyeti adlandırma ve yapı aracılığıyla açıkça ifade edin
• Bağımlılıkları görünür ve açık hale getirin
• Metotları küçük tutun ve tek sorumluluğa odaklayın
• Durumu ve yan etkileri en aza indirin
• Mümkün olan en basit çözümü kullanın

Refactor yönergeleri

• Yalnızca testler geçtiğinde refactor yapın ("Green" aşamasında)
• Yerleşik refactor kalıplarını uygun adlarla kullanın
• Her seferinde yalnızca bir refactor değişikliği yapın
• Her refactor adımından sonra testleri çalıştırın
• Tekrarı ortadan kaldıran veya açıklığı artıran refactor’lara öncelik verin

Örnek iş akışı

Yeni bir özelliğe yaklaşırken:

1. Özelliğin küçük bir parçası için basit, başarısız bir test yazın
2. Geçmesini sağlayacak en az şeyi uygulayın
3. Testi çalıştırıp geçtiğini doğrulayın (Green)
4. Gerekli yapısal değişiklikleri yapın (Tidy First) ve her değişiklikten sonra testleri çalıştırın
5. Yapısal değişiklikleri ayrı olarak commit edin
6. Sonraki küçük işlev artışı için başka bir test ekleyin
7. Özellik tamamlanana kadar tekrarlayın; davranışsal değişiklikleri yapısal değişikliklerden ayrı commit edin

Bu süreci tam olarak izleyin ve hızlı uygulama yerine her zaman temiz, iyi test edilmiş kodu önceliklendirin.

Her zaman aynı anda yalnızca tek bir test yazın, onu çalıştırın ve ardından yapıyı iyileştirin. Her seferinde tüm testleri çalıştırın (uzun süren testler hariç).

Rust ile ilgili

Rust’ta komut tarzı yerine fonksiyonel programlama tarzını tercih edin. Mümkün olduğunda if let veya match ile desen eşleme yerine Option ve Result birleştiricilerini (map, and_then, unwrap_or vb.) kullanın.

Ağızla kodlamadan sonra umarım beyin dalgasıyla kodlama da çıkar.

vibe coding ❌️
virtual coding ⭕️

Çok uzağa gitme… Her şeyi yutabilir…

Yapay zekaya kendi işinizi emanet edebileceğinizi hissediyorsanız, eninde sonunda %100 yeriniz alınır. Yapay zekanın ikame edemeyeceği ya da başkalarının kolayca taklit edemeyeceği yetkinlikleri geliştirmek gerekir.

Geçen projede neden json yüklemenin çalışmadığını anlayamamıştım.
Meğer zaten bunu desteklemiyormuş.. vay be