Ancak en yeni teknolojileri(?) devreye almak istediğinizde JUnit4 sık sık ayak bağı olabiliyor; bu yüzden kişisel olarak JUnit5'e geçilmiş olmasını dileyen küçük bir temennim var. https://docs.gradle.com/develocity/test-distribution/
junit-vintage-engine kullanılırsa büyük değişiklikler yapmadan junit4 testlerini junit5 üzerinde çalıştırmak mümkün, ancak ek yük oldukça fazla. (yaklaşık %20 kadar yavaşlıyor)
Bir şekilde Android uygulama build mühendisi olarak yerleşmiş biri olarak fikrimi bırakacak olursam..
Build: gradle
Çok büyük ya da karmaşık olsa bile gradle kullanmak gerekiyor... (uzaklara dalan bakış)
Çok büyük ya da karmaşık projelerde gradle’ın build performansını iyileştirmek için aşağıdaki projeler yürütülüyor; bu yüzden büyük projelerde gradle kullanıyorsanız, migration hazırlıklarını şimdiden yapmakta fayda var.
Kişisel olarak, mimari katmanları özellikle build sistemine görünür kılmak için bir neden olmadığını düşünüyorum.
Benim yönettiğim uygulamada modülleri feature-api / feature-impl olarak build sistemine görünür olacak şekilde düzenliyoruz.
feature-app:
Veri modeli veya başka modüllerle entegre olan interface
feature-impl:
feature’ın gerçek implementasyonu
Bu şekilde yapılandırınca, feature-impl içindeki kod değişiklikleri feature-api’yi referans alan diğer modülleri etkilemediği için (dependency isolation), incremental build ya da build cache hit rate artışı açısından çok faydalı oluyor.
Birim testi - junit 4
Burada Google’ın kararının büyük rol oynadığını düşünüyorum.
Bu aralar kullanım sayısını ya da süresini sınırlayan servisler yeniden moda oluyor gibi; ama bir süre önce popüler olan, adını tam hatırlamadığım, yayın benzeri şekilde konuşulan uygulama gibi bir anda parlayıp sonra sönümlenmez mi diye düşünüyorum.
Hmm... Bu arada son birkaç yılda startup'ların çoğunun Flutter'ı tercih ettiği, META ve OpenAI gibi büyük şirketlerin ise native'e yöneldiği garip bir olgu gözlemleniyor..
Sevindirici bir haber! İlginç bir şekilde, MS'in TypeScript dili beklentilerin aksine gerçekten de oldukça beklenmedik(?) seçimler yapıyor gibi görünüyor. MS açısından bakınca bu neredeyse ilk açık kaynak projesi sayılır; ayrıca JS'yi değiştirmeye çalışan Google'ın Dart'ından farklı olarak JS'yi tamamlamayı seçmesi de gerçekten akıllıca hissettirmişti. Bu kez yerel porta çevrilen dil için de kendi dilleri epey fazla olmasına rağmen Google'ın Go'sunu seçmiş olması şaşırtıcı.
Özyinelemeli generik tipler kullanırken yavaşlama yüzünden alternatif bir yol seçmek zorunda kaldığım oldu. 10 kat ise bu tür noktaların da iyileşebileceğini umuyorum.
Ancak en yeni teknolojileri(?) devreye almak istediğinizde JUnit4 sık sık ayak bağı olabiliyor; bu yüzden kişisel olarak JUnit5'e geçilmiş olmasını dileyen küçük bir temennim var.
https://docs.gradle.com/develocity/test-distribution/
junit-vintage-enginekullanılırsa büyük değişiklikler yapmadan junit4 testlerini junit5 üzerinde çalıştırmak mümkün, ancak ek yük oldukça fazla. (yaklaşık %20 kadar yavaşlıyor)Bir şekilde Android uygulama build mühendisi olarak yerleşmiş biri olarak fikrimi bırakacak olursam..
Çok büyük ya da karmaşık olsa bile gradle kullanmak gerekiyor... (uzaklara dalan bakış)
Çok büyük ya da karmaşık projelerde gradle’ın build performansını iyileştirmek için aşağıdaki projeler yürütülüyor; bu yüzden büyük projelerde gradle kullanıyorsanız, migration hazırlıklarını şimdiden yapmakta fayda var.
Kişisel olarak, mimari katmanları özellikle build sistemine görünür kılmak için bir neden olmadığını düşünüyorum.
Benim yönettiğim uygulamada modülleri feature-api / feature-impl olarak build sistemine görünür olacak şekilde düzenliyoruz.
Bu şekilde yapılandırınca, feature-impl içindeki kod değişiklikleri feature-api’yi referans alan diğer modülleri etkilemediği için (dependency isolation), incremental build ya da build cache hit rate artışı açısından çok faydalı oluyor.
Burada Google’ın kararının büyük rol oynadığını düşünüyorum.
Ama yakın zamanda yayınlanan screenshot testing plugin ise JUnit5 tabanlı.
Clubhouse gibi görünüyor, benim de tam olarak aklıma gelen buydu.
Bu aralar kullanım sayısını ya da süresini sınırlayan servisler yeniden moda oluyor gibi; ama bir süre önce popüler olan, adını tam hatırlamadığım, yayın benzeri şekilde konuşulan uygulama gibi bir anda parlayıp sonra sönümlenmez mi diye düşünüyorum.
Vay canına, aileniz adına ne büyük bir onur.
Trafik yalnızca o saatlerde aşırı yoğunlaşacağı için verimli bir işleme ihtiyaç olacak gibi görünüyor.
İleride mevcut TypeScript kod tabanının bakımının ihmal edilmesinden endişe ediyorum
C# diline yönelik geliştirme durmuş değil ama C# kullanan framework'lerin ihmal edildiği hissini çok sık alıyorum.
Test ediyorum; biraz her şeyden bir parça sunan kapsamlı bir paket gibi hissettiriyor.
Benzer yazılar tekrar tekrar gündeme geliyor ama insanın hırsının sonu yok, aynı hataları da durmadan tekrarlıyoruz
Bir bilgisayarın CPU yükünün %100 olması normal değil,
ama konu insanların iş yükü olunca %100'ün daha çok çalışmaları gerektiği sonucuna varılıyor..
Hmm... Bu arada son birkaç yılda startup'ların çoğunun Flutter'ı tercih ettiği, META ve OpenAI gibi büyük şirketlerin ise native'e yöneldiği garip bir olgu gözlemleniyor..
Öyle yani, ama .NET geliştiricilerinin ne hissettiğini de anlayabiliyorum...
Sevindirici bir haber! İlginç bir şekilde, MS'in TypeScript dili beklentilerin aksine gerçekten de oldukça beklenmedik(?) seçimler yapıyor gibi görünüyor. MS açısından bakınca bu neredeyse ilk açık kaynak projesi sayılır; ayrıca JS'yi değiştirmeye çalışan Google'ın Dart'ından farklı olarak JS'yi tamamlamayı seçmesi de gerçekten akıllıca hissettirmişti. Bu kez yerel porta çevrilen dil için de kendi dilleri epey fazla olmasına rağmen Google'ın Go'sunu seçmiş olması şaşırtıcı.
Dotnet ve Rust geliştiricileri epey öfkelenmiş görünüyor.
Brother, üçüncü taraf yazıcı mürekkep kartuşlarının kullanımını engelleyen zorunlu firmware güncellemesi
Ha? Deno tarafında zaten Rust tabanlı bir toolchain yapan bir şey vardı sanki... birdenbire Go mu oldu?
Özyinelemeli generik tipler kullanırken yavaşlama yüzünden alternatif bir yol seçmek zorunda kaldığım oldu. 10 kat ise bu tür noktaların da iyileşebileceğini umuyorum.
"Neden Go?" tartışma başlığı oldukça ilginç.
https://github.com/microsoft/typescript-go/discussions/411
Düşünülmesi gereken şeyler de çok...
Birçok kişinin 4. seçeneğe kaydığını görüyorum ve bu gerçekten çok üzücü.
Go ile yazın~