iToverDose/Yazılım· 13 HAZIRAN 2026 · 16:06

GSoC 2026: LTI 1.3 Entegrasyonunda Kod Kabulünün Zorlukları

Açık kaynak projelerde kod göndermek ne kadar basit görünse de, gerçek zorluklar kabul sürecinde gizlidir. GSoC 2026'da CircuitVerse ile Canvas LMS entegrasyonu üzerinde çalışırken, reddedilen pull requestler, karmaşık hata ayıklama ve en küçük kod değişikliklerinin bile projeyi nasıl etkilediğini öğrendik.

DEV Community4 dk okuma0 Yorumlar

GSoC 2026 programının ikinci haftası, kod yazmanın yalnızca işin yarısı olduğunu acı bir şekilde gösterdi. Projeye katkıda bulunmak, kodun yalnızca çalışır olmasını değil, aynı zamanda proje sahipleri tarafından da kabul edilmesini gerektiriyor. CircuitVerse'deki LTI 1.3 entegrasyonu için yürüttüğümüz bu hafta, birçok engelle karşılaştık: reddedilen pull requestler, sert yorumlar ve en basit görünen değişikliklerin bile nasıl karmaşık sonuçlara yol açtığını deneyimledik. Ancak sonunda, projenin geleceğini şekillendirecek temiz bir kod parçası sunduk.

LTI 1.3 Nedir ve Neden Önemlidir?

CircuitVerse, öğrencilerin dijital devreleri tarayıcı üzerinden tasarlayıp simüle edebildikleri popüler bir açık kaynak platformudur. Üniversitelerde yaygın olarak kullanılan Canvas LMS ile entegre olmak ise bu projenin temel hedefidir. Bu entegrasyonu mümkün kılan teknoloji ise Learning Tools Interoperability (LTI) adı verilen bir standarttır.

LTI, farklı eğitim araçlarının (örneğin CircuitVerse) herhangi bir Öğrenme Yönetim Sistemine (LMS) (örneğin Canvas) sorunsuzca entegre olmasını sağlayan bir protokoldür. Öğrenciler tek bir giriş yaparak ödevlere erişebilir, çalışmalarını gönderebilir ve notlarını otomatik olarak sistemde görebilirler — tüm bunları kurs sayfasından ayrılmadan gerçekleştirebilirler.

İki ana LTI versiyonu bulunuyor:

  • LTI 1.1: Eski ve güvenlik açıkları bulunan OAuth 1.0 protokolünü kullanır.
  • LTI 1.3: Daha güvenli, modern ve Canvas tarafından önerilen versiyondur.

Projemizin amacı, CircuitVerse'in LTI 1.1'den LTI 1.3'e tamamen geçmesini sağlamaktır.

Pazartesi–Salı: Diff Okumanın Önemi

Haftaya, Canvas'tan gelen notları CircuitVerse'e geri gönderen mevcut LTI 1.1 özelliğindeki bir hatayı düzelten bir pull request göndererek başladım. İlk başta basit bir hata düzeltmesi gibi görünen bu iş, bana diff dosyalarını ne kadar dikkatli okumam gerektiğini öğretti.

Pull requestim incelendiğinde, iki önemli sorun tespit edildi:

  • Database şemasındaki gereksiz değişiklikler: schema.rb dosyasını lokalde yeniden oluştururken, Rails framework'ünün yeni bir versiyonu tüm veritabanı sütunlarını alfabetik sıraya sokmuştu. Bu da yüzlerce satırlık ve alakasız bir diff oluşturdu. Değişikliklerimin asıl amacıyla hiçbir ilgisi yoktu.
  • Güvenlik açıklarına yol açan versiyon düşüşü: jwt (JSON Web Token) kütüphanesi, kimlik doğrulama için kullanılan ve yakın zamanda 2.x'den 3.x'e yükseltilen bir kütüphaneydi. Ancak benim pull requestimde, başka bir bağımlılık zinciri nedeniyle (webpush kütüphanesi) bu versiyon 2.x'e geri düşürülmüştü. Bu da güvenlik açıklarına yol açabilirdi.

Çözüm: Dosyaları orijinal haline geri döndürmek, jwt versiyonunu 3.2.0'a yükseltmek ve webpush'i uyumlu olduğu eski versiyona geri almak gerekti. Üç farklı dosyada dikkatlice değişiklik yapmak ve her adımı kontrol etmek zorunda kaldım. Bu deneyim, pull request göndermeden önce diff dosyasını mutlaka incelemem gerektiğini bana öğretti.

Çarşamba: Kapanmak Zorunda Kaldığım Pull Request

Yaptığım düzeltmelerden sonra, pull requestimi yeniden güncelledim ve geri bildirimler aldım. Ancak projenin diğer kısımlarındaki bağımlılıklar nedeniyle, bu değişikliklerin daha geniş bir alana yayıldığını gördüm. Özellikle ims-lti kütüphanesi, hem LTI 1.1 hem de LTI 1.3 özelliklerini desteklemediğinden, bu kütüphanenin tamamen değiştirilmesi gerekiyordu. Mevcut haliyle, grade passback (notların geri gönderilmesi) özelliğim çalışsa bile, diğer sistemler bozulacaktı. Bu yüzden pull requestimi kapatmak zorunda kaldım.

Mentörüm bana doğru yolu gösterdi: grade passback özelliğini düzeltmeden önce, önce temel olan LTI kütüphanesini LTI 1.3'e uygun hale getirmem gerekiyordu.

Çarşamba–Perşembe: Başkasının Kodunu İncelemek

Bu arada, başka bir geliştiricinin gönderdiği bir pull requesti incelemem istendi. Bu, Dependabot tarafından önerilen otomatik bir kütüphane güncellemesiydi: ims-lti 1.2.9'dan 2.3.7'ye yükseltme.

Bu inceleme sırasında dikkatimi çeken önemli noktalar:

  • 2.x versiyonunda OAuth desteğinin tamamen kaldırıldığını fark ettim. Bu da LtiScoreSubmission (notların geri gönderilmesi) kodunun çalışmamasına neden olacaktı.
  • `IMS::LTI::ToolProvider` sınıfının 2.x versiyonunda bulunmadığını gördüm. Bu sınıf, öğrencilerin Canvas'tan CircuitVerse'e giriş yaptıklarında kimlik doğrulamasını gerçekleştiren temel bir bileşendi.

Eğer bu pull request kabul edilseydi, LTI üzerinden yapılan tüm girişler ve not gönderimleri çalışmaz hale gelecekti. Bu yüzden, LTI 1.3'e tam geçiş yapılmadan bu değişikliğin yapılmaması gerektiğini açıklayan bir yorum yazdım ve pull requestin ertelenmesini önerdim. Sonuç olarak, pull request kabul edilmedi.

Başkalarının kodunu eleştirel bir şekilde incelemek, kendi kodumu geliştirmenin yanı sıra, projenin genel sağlığı için de kritik bir beceridir. Bu deneyim, bana kod inceleme sürecinin ne kadar önemli olduğunu bir kez daha gösterdi.

Perşembe: Ana Koda Senkronize Olmak — Tahmin Edilenden Zor

Yeni kod yazmaya başlamadan önce, CircuitVerse'in ana kod deposundaki en son değişiklikleri lokal bilgisayarıma çekmem gerekiyordu. Bu işlem "upstream fetch" olarak adlandırılıyor ve genellikle basit bir komut dizisiyle halledilir. Ancak bu sefer işler tahmin ettiğimden çok daha karmaşık hale geldi.

Git komutları çalıştırırken, lokal repomda birden fazla çatallanmış (fork) dal olduğu ortaya çıktı. Bu çatallar, yapılan değişiklikleri takip etmek için oluşturulmuş geçici dallardı, ancak ben bunları temizlemeyi unutmuştum. Her bir dalın değişikliklerini manuel olarak incelemek ve gereksiz olanları silmek zorunda kaldım. Ayrıca, bazı dosyaların yerel değişiklikleriyle ana kod arasında uyumsuzluklar vardı ve bunları da çözmek gerekti.

Sonunda, ana kodla tamamen senkronize olan temiz bir lokal kopya elde ettim. Bu süreç, Git'in dal yönetimi ve çatallanma konularında ne kadar dikkatli olmam gerektiğini bir kez daha bana hatırlattı. Kod tabanının güncel ve temiz olması, yeni özellikler eklemek için hayati önem taşıyor.

Haftanın Öğrettikleri ve Önümüzdeki Adımlar

Bu hafta, açık kaynak projelerde kod göndermek ve kabul edilmek için gereken disiplin ve dikkati öğrendik. En küçük değişikliklerin bile nasıl büyük sonuçlara yol açabileceğini, diff dosyalarını dikkatlice incelemenin önemini ve başkalarının kodunu nasıl eleştirel bir şekilde inceleyeceğimizi anladık. Tüm bu zorlukların ardından, CircuitVerse'in LTI 1.3 entegrasyonu için sağlam bir temel oluşturduk ve projenin gelecekteki sürümlerinde kullanılacak kod parçalarını sunduk.

Önümüzdeki hafta, LTI 1.3 protokolünü tamamen entegre etmek için gerekli olan temel kütüphanelerin güncellenmesine odaklanacağız. Ayrıca, öğrencilerin Canvas'tan CircuitVerse'e giriş yaparken karşılaşabilecekleri sorunları çözmek için gerekli iyileştirmeleri yapacağız. Bu süreçte, hem mentorlerimizin rehberliğinden faydalanacağız hem de benzer projelerde çalışan diğer GSoC katılımcılarıyla fikir alışverişinde bulunacağız. Her yeni özellik ve hata düzeltmesi, projelerin daha güvenilir ve kullanıcı dostu hale gelmesini sağlayacaktır.

Yapay zeka özeti

Açık kaynak projelerde pull request göndermek ve kabul edilmek için gereken ipuçlarını GSoC 2026 CircuitVerse ve Canvas LMS LTI 1.3 entegrasyonunda öğrendiklerimizle keşfedin.

Yorumlar

00
YORUM BIRAK
ID #L67DAL

0 / 1200 KARAKTER

İnsan doğrulaması

5 + 6 = ?

Editör onayı sonrası yayına girer

Moderasyon · Spam koruması aktif

Henüz onaylı yorum yok. İlk yorumu sen bırak.