2 puan yazan GN⁺ 2023-10-08 | 1 yorum | WhatsApp'ta paylaş
  • config.load_defaults 7.1 kullanıldığında ActiveSupport::MessageVerifier ve ActiveSupport::MessageEncryptor için varsayılan serileştirme Marshal’dan ActiveSupport::JSON’a değişir; mevcut Marshal mesajları okunmaya devam edebilir
  • ActiveRecord::Base.serialize varsayılan olarak YAML kullanmayacak şekilde değiştirildi; önceki varsayılan değer config.active_record.default_column_serializer = YAML ile geri getirilebilir
  • Yeni 7.1 önbellek formatı eklendi ve yeni uygulamalarda varsayılan olarak kullanılır; mevcut uygulamalarda config.load_defaults 7.1 veya config.active_support.cache_format_version = 7.1 ile etkinleştirilebilir
    • 6.1 veya 7.0 önbellek formatıyla yazılmış öğeler 7.1 formatında okunabilir
    • Rails 7.1 rolling deployment sırasında ilk dağıtımda önbellek formatı korunmalı, sonraki dağıtımda 7.1 önbellek formatı etkinleştirilmelidir
  • :message_pack ve :message_pack_allow_marshal serileştirmeleri MessageEncryptor, MessageVerifier ve config.active_support.message_serializer için eklendi; msgpack gem’i >= 1.7.0 gerekir
  • ActiveSupport::KeyGenerator, MessageEncryptor, EncryptedConfiguration ve Active Record şifreleme nesnelerinin inspect çıktısında gizli değerlerin sızmasını engeller; ActionView::Helpers ve ERB::Util içindeki XSS koruması güçlendirildi
  • has_secure_password için password_challenge doğrulaması ve #{attribute}_salt metodu eklendi; authenticate_by, hesabın var olup olmadığına bağlı zamanlama temelli enumerasyon saldırılarını azaltacak şekilde eklendi
  • Active Record’da bileşik birincil anahtar ve bileşik yabancı anahtar desteği genişletildi; tuple sözdizimiyle where, bileşik anahtarlı batch sıralaması ve şemadan bileşik birincil anahtar çıkarımı desteklenir
  • PostgreSQL desteğine enum adını değiştirme, değer ekleme ve değer değiştirme migration komutları; exclusion constraint, unique constraint, INCLUDE indeks seçeneği ve NULLS [NOT] DISTINCT indeks desteği eklendi
  • SQLite3 adaptöründe Write-Ahead-Log normal syncing mode, capped journal size, shared memory buffer ve shared cache ayarlarıyla ortalama performans artışı belirtildi; çift tırnaklı string literal’ları devre dışı bırakan strict strings mode varsayılan olarak etkinleştirildi
  • Active Record’da tüm tablo üzerinde batch yineleme varsayılan olarak range iteration kullanarak performansı iyileştirir; PostgreSQL’de 10 milyon kayıt testinde querying 253s30s, updating 288s124s, deleting 268s83s sonuçları sunuldu
  • MemCacheStore ve RedisCacheStore için connection pooling varsayılan olarak etkinleştirildi; devre dışı bırakmak için cache store ayarında pool: false belirtilmelidir
  • Trilogy veritabanı istemcisi için adaptör eklendi; adapter: trilogy veya trilogy:// biçiminde DATABASE_URL kullanılabilir
  • ActiveRecord::QueryLogs için varsayılan etiket formatı SQLCommenter formatına değiştirildi; config.active_record.query_log_tags_format = :legacy ile eski format kullanılabilir
  • Kullanımdan kaldırılan ve kaldırılan öğeler arasında ActiveSupport::Deprecation singleton kullanımı, SafeBuffer#clone_empty, #merge içindeki rewhere argümanı, add_foreign_key için deferrable: true, TestFixtures#fixture_path ile çeşitli deprecated Active Record ayarları ve API temizliği yer alır
  • Action View testlerine ActionView::TestCase.register_parser eklendi; render sonuçları için parser kaydedilebilir ve varsayılan parser’lar olarak :html ile :json sağlanır

1 yorum

 
GN⁺ 2023-10-08
Hacker News yorumları
  • Rails harika ve şu an her zamankinden daha iyi
    Kariyerimin başlarında çoğunlukla Django ve Laravel kullandım, sonra günümüzde yaygın olan frontend işlerine geçtim; bu yıl da yeniden bir Rails + Hotwire projesi aldım
    Ne kadar basitleştiğine gerçekten şaşırdım ve bunun bu kadar kolay olabileceğini çoğumuzun unutmuş olması üzücü. Sektöre bugün giren insanların bu sadeliği hiç deneyimleyemeyebilecek olması da korkutucu
    Rails’i hiç denemediyseniz ya da “PHP çirkin / Rails öldü / JavaScript dağınık” gibi şeyler duyup vazgeçtiyseniz, bir süre başkalarının söylediklerini yok sayıp açık fikirle denemenizi öneririm
    Aynı depoda 1.000 mühendisin çalıştığı bir ortam için en iyi seçenek olmayabilir ama küçük ekipler için rakipsiz ve diğer her şeyin çok ilerisinde. Dürüst olmak gerekirse Laravel de benzer derecede iyi olabilir

    • Buraya Phoenix LiveView’ı da eklemek isterim
      İlk geliştirme hızında Rails’in her zaman kazandığını düşünüyorum. Convention’ları o kadar sıkı ve iyi tasarlanmış ki benzer şekilde yaklaşabilen neredeyse hiçbir şey yok. Laravel yetişiyor ama bence henüz orada değil
      Ancak LiveView her anlamda daha iyi ölçekleniyor. Kimlik doğrulama, veritabanı erişimi, iş kuyruğu, mailer, eksiksiz test araçları gibi varsayılan olarak gelen çok şey var; neredeyse hiç doğrudan JavaScript yazmanız gerekmiyor ve harika bir sanal makine olan BEAM de var
      En azından bu projelerin hepsinin “bir adım geri atalım” mücadelesini vermesi güzel. İşte React ve Relay kullanıyoruz; uzun süredir frontend JavaScript yazıyor ve bir ölçüde iyi olduğumu düşünüyor olsam bile aşılması gereken o kadar çok engel var ki insanı yoruyor
    • Django ile karşılaştırınca, en azından şu anda ikisini aynı seviyede görmemen ilginç. Rails’i Django’ya tercih etmek için somut nedenlerin olup olmadığını merak ediyorum
    • Rails’i seviyorum ama benim ülkemde neredeyse kimse kullanmıyor; kullanan şirketler de neredeyse büyücü seviyesinde geliştiriciler arıyor
      İş bulamadığım için yeterince deneyim de biriktiremiyorum ve sonunda o büyücülerin gerisinde kalıyorum. O iş ilanı 12 aydan uzun süre açık kalabiliyor
      Bunun yerine talebin olduğu yer orası diye dünyaya daha fazla JavaScript yayıyorum
    • Tanıdığım Rails geliştiricilerinin önemli bir kısmı ember.js’ye geçti. Çünkü ember.js de sürekli kırılan sayısız üçüncü taraf eklentiye dayanan bir şey değil, convention tabanlı bir framework
      Yapısal olarak ember-data yaklaşımını seviyorum. Veri kümelerinde left join/right join gibi işlemlerde otomatikleştirilebilecek çok şey var ve entegre bir mock sunucusu da bulunuyor
      Ancak sanırım fazla iyi çalıştığı için diğerleri kadar havalı görünmüyor
      https://emberjs.com/
  • 13.000 satırlık Rails 7.0 uygulamasını 7.1’e yükselttim; 7.0 ile 7.1 arasındaki fark[0] dışında test yapılandırma kodunda yalnızca 1 satır değiştirdim ve her şey çalıştı
    Kolay bir yükseltme yolu açısından bunu başarılı görüyorum. Şimdi eğlenceli kısım, kodun bir bölümünü 7.1’in yeni özelliklerini kullanacak şekilde refactor etmek
    İlgilenirseniz Rails / Docker örnek uygulamasını da 7.1’e yükselttim https://github.com/nickjj/docker-rails-example
    Rails 7.1’e Dockerfile dahil edilmiş olsa da Docker Compose kullanarak geliştirme ve production’da doğrudan çalışan bir deneyim oluşturmak, Postgres, Redis, Action Cable, Sidekiq vb. eklemek gibi hâlâ yapılabilecek pek çok seçenek var
    [0]: https://railsdiff.org/7.0.8/7.1.0

  • Oldukça büyük bir Rails 6 kod tabanına bolca React eklenmiş durumdayken, Hotwire kullanan yeni “JavaScript’siz” yaklaşıma yükseltmeye çalışıyorum. Bana şans dileyin
    Rails, varsayılanlara bağlı kaldığınızda harika; ama o varsayılanların dışına çıktığınız anda acılar diyarına dönüşüyor

    • Görece yeni bir Rails 7 kod tabanında çalışıyorum. Başta Stimulus kullanmaya başladık ama birkaç nedenle React’e geçmeyi düşünüyoruz
      Frontend mühendisi işe almak söz konusu olduğunda React aday havuzu birkaç basamak daha büyük. Genel işler için kullanılacak vanilla JavaScript paketleri bulup bunları Stimulus controller’larıyla sarmalamak da React paketi bulmaktan giderek daha zor hale geliyor
      Stimulus, controller birim testleri yazmak için de pek bir yol sunmuyor. React’te her zamanki gibi jest ve react-test-renderer kullanabiliyoruz
      Üstelik Turbo TypeScript etrafındaki son tartışma, Hotwire ekosisteminin uzun vadeli işletimi konusunda güven vermedi
      Henüz karar vermedik. Stimulus’un frontend kodu yazmanın çok Rails’e özgü bir yolu gibi hissettirmesi kesinlikle bir artı; özellikle de Rails’e zaten aşina küçük ekipler için
    • “Rails varsayılanlara bağlı kalınca iyidir, dışına çıkınca acı verir” sözü tüm framework’ler için geçerli
      Uygulama oldukça basitse ve framework’ün yaklaşımıyla iyi örtüşüyorsa framework harikadır. Daha karmaşık ve esnek bir yapı gerekiyorsa kütüphanelere bakmak gerekir
    • Rails’in JavaScript entegrasyonuna olan inancımı kaybettim
      Artık slim ile sunucu tarafı render yapıyorum ya da API-only kurup frontend’i ayırıyorum
      Rails, JavaScript yapmaya çalışırken CoffeeScript, asset precompile, webpack gibi çok fazla yön değiştirdi
    • Mevcut React frontend’ini Hotwire’a taşıma işini Rails’in kendisini yükseltmekle aynı anda yapmayı önermem. Önce bağımsız olarak Rails 7.1’e kadar çıkmanın daha iyi olduğunu düşünüyorum
      Bu arada Rails 7+’da tek sayfa uygulama JavaScript’iyle uğraşma biçimi de eskisine göre çok daha makul. Esasen istediğiniz build aracını Rails uygulamasından ayrı kullanmanız yeterli
      Geliştirme sırasında rails s ile birlikte yarn build --watch gibi bir şey de çalıştırmanız gerekiyor, ama kişisel olarak bunun kötü olmadığını ve çok daha basitleştiğini düşünüyorum
      Şirketimiz Rails yükseltmelerini otomatikleştiren yazılım geliştiriyor ve Rails yükseltmesini sizin yerinize yapan uçtan uca bir hizmet de sunuyor. İlgilenirseniz steve (at) infield.ai adresinden ulaşabilir veya https://app.infield.ai/users/sign_up üzerinden ücretsiz bir Rails yükseltme planı oluşturabilirsiniz. Kredi kartı gerekmiyor
      Ayrıntılar için bkz. https://docs.infield.ai/docs/creating-an-upgrade-path
    • https://vite-ruby.netlify.app/guide/rails.html denemenizi öneririm
      Benim durumumda neredeyse doğrudan bir webpack alternatifi gibi oturdu
  • Rails’i seviyorum ve Rails 2’den beri ara ara kullandım
    Çok iyi bir framework ve arada bir web sitesi ayağa kaldırması gereken benim gibi biri için gerçekten en az dirençli yol
    Ancak yeni bir dizüstünde Rails çalışacak şekilde kurulum yapmak eziyetli. node gerekiyor, o zaman npm de gerekiyor. Backend geliştiricisiyim; node’u nasıl kuracağımı, hangi sırayla yapmam gerektiğini pek bilmiyorum
    Sık yaptığım bir iş olmadığı için her seferinde kavga gibi geliyor. Sonunda hallediyorum ama en sonunda neden her şeyin yerine oturduğundan hiçbir zaman emin olamıyorum
    Gerekli şeyleri tek seferde ayarlayıp rails’in sadece çalışmasını sağlayan bir kurulum programı olsa keşke. rvm kurucusu ruby’nin üstüne rails’i kuruyor ama onun altındaki node sistemini kurmuyor

    • asdf adlı sürüm yöneticisi nodejs yönetimi için iyi. Ruby tarafını hiç denemedim
      https://asdf-vm.com/
    • “Backend geliştiricisiyim, node kurulumunu bilmiyorum” demeni anlıyorum
      Node çoğunlukla frontend aracı olarak biliniyor ve Rails de onu bu amaçla kullanıyor, ama hatırladığım kadarıyla Node en azından başlangıçta JavaScript runtime’ını backend’e taşımak için yapılmıştı
      Paket yöneticisi olmadan bile Windows’ta bildiğin node.exe; npm’i indirip açarak node ve npm’i PATH ortam değişkenine koymak yeterli diye biliyorum
    • Rails 7’nin temel önermesi zaten node bağımlılığını kaldırmak
    • Rails’i hiç kullanmadığım için merak ediyorum: “Ruby on Rails” neden nodejs’e ihtiyaç duyuyor, bilmek isterim
      Ayrıca node kurulumu oldukça kolay. Hatta fazla kolay. Keşke çok daha zor olsa ve diploma gerektirseydi
    • Ruby/Rails topluluğu gördüklerim arasında en iyi ve en nazik olanlardan. Ama içlerindeki en kötü şey kesinlikle JavaScript nefreti
      JavaScript de diğerleri gibi sadece bir araç. Beğenin ya da beğenmeyin çok önemli bir araç ve beğenin ya da beğenmeyin uzun süre burada kalacak
      Biraz açık fikirli olup en azından temellerini öğrenirseniz işleriniz kolaylaşır
  • Rails + HTMX ve yalnızca çok etkileşimli sayfalara biraz JavaScript serpiştirme yaklaşımının yeniden yükselişe geçmesini umuyorum
    Rails’i Slim/HAML ile kullanmak gerçekten keyifli. İsterseniz ViewComponents gibi bir kütüphaneyle partial rendering’i daha da kolaylaştırabilirsiniz. Buna web component’leri ekleyince epey etkileşimli sayfalar yapılabiliyor; belirli bir sayfada gerçekten gerekirse React de kullanılabilir
    HATEOAS, uygulama karmaşıklığını ciddi ölçüde azaltıyor. Yine de API gerekiyorsa farklı MIME type’lara yanıt vermek de çok kolay; isterseniz aynı endpoint’i paylaşmak da mümkün
    Deneyimlerime göre React kullanan uygulamaların çoğunun aslında React’e hiç ihtiyacı yok. Birkaç açılır menü için React kullanılıyor
    Bu yüzden React’siz ya da çok az React kullanan büyük uygulamalar ortaya çıkmaya başlarsa, bugün uygulamalarımızın ne kadar gereksiz karmaşık olduğunu fark eden insanlar olmasını umuyorum
    Ama şimdiden “herkes React kullanıyor, o yüzden React’e geçmeliyiz” denildiğini görüyorum. İç çektiriyor
    Hayal kurmak serbest

  • Resmî duyuru burada: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
    Üst düzeyde biraz daha ayrıntı var; yeni değişikliklerden bazılarını denemeyi heyecanla bekliyorum. Özellikle yeni asenkron sorgu metotları hızlı performans iyileştirmeleri için epey faydalı olacak gibi görünüyor

  • Backend tarafında Rails hak ettiği değeri yeterince görmüyor
    Ancak frontend tarafı çok uzun süre berbat durumdaydı

    • “Frontend tarafı uzun süre berbat durumdaydı” ifadesine karşı çıkmıyorum ama frontend'in kendisi de uzun süre berbat durumdaydı
      Şimdi Rails 7.1 + Hotwired + Importmaps kombinasyonuyla çalışmak keyifli
      Ama tarayıcılarda en azından ES6 ve Import Maps desteğinin iyileşmesini beklemek gerekti
      Bu yazının tarihine bakarsanız https://web.dev/import-maps-in-all-modern-browsers/ 28 Mart 2023'te importmaps'in tüm modern tarayıcılarda kullanılabildiği duyurulmuş
      Yani şimdiye kadar Webpack, Yarn ve diğer JavaScript yardımcı araçlarından kaçınmanın bir yolu yoktu
      Artık importmaps var ve tarayıcıların ES6 desteği de yeterince iyi olduğundan https://caniuse.com/?search=es6, neredeyse hiç ek araca ihtiyaç duymadan modern JavaScript yazılabiliyor
    • Katılıyorum. Burada seçenekler neler olabilir? Rails'in yalnızca API modu mu?
    • Yeni Hotwire özelliklerini seviyorum. Frontend'de neyin hoşuna gitmediğini merak ediyorum
  • Birkaç hafta önce bir arkadaşım “Bir Rails sürümü duyurulduysa ve sen yükseltme PR'ı açmadıysan, gerçekten olmuş sayılır mı?” diye şaka yaptı
    Pekâlâ, şimdi PR açma zamanı. Aylardır bekleyen 7.0 PR'ının arkasına eklemek zorunda kalsam bile

  • Deneyimlerime göre birçok ekip ActiveRecord ile temiz bir codebase oluşturmakta zorlanıyor

  • Umarım beni taşlamazsınız ama hâlâ Rails 4.2 kullanıyorum ve memnunum
    Kendi yaptığım ya da B2B şirketleri için yaptığım JavaScript'siz veya az JavaScript'li backend SaaS işleri için gereken her şeyi sağlıyor ve düşük özellikli VPS'lerde de çalışıyor
    Yanıtlamaya vaktiniz varsa, neden yükseltmem gerektiğini merak ediyorum

    • Ben de eski bir sürüm kullanıyorum. Öncelikle en güncel patch/minor sürüme kadar çıkıp çıkamayacağını kontrol etmek gerekir
      Eski sürümlerdeki temel sorun, bağlı gem'lerdeki güvenlik açıklarıdır. Örneğin nokogiri, Rails major yükseltmesi olmadan yükseltilemeyebilir
      Ancak çoğu uygulama örneğin karmaşık XML ayrıştırma yapmadığı için, güvenlik açıklarının önemli bir kısmı geçerli olmayabilir. Bu yüzden güvenli olup olmadığını kontrol etmeye yönelik biraz bakım gerekir. Hataları önlemek için monkey patch eklemek de sık görülür
      Yükseltme, güvenliği artırır ve bakım süresini azaltır. Ama sürekli yükseltme maliyetini de hesaba katmak gerekir. Bir başka etken de yeni sürümlerde daha hızlı Ruby desteği alabilmektir
      Genelde Rails uygulaması geliştirirken en güncel sürümü kullanırım; ama çok popüler değilse veya uygulama çok eski olup yeni sistemlerde bir şeyler çalışmıyorsa, sonrasında Rails sürümünü yükseltmem
    • Güvenlik nedeniyle yükseltmelisin