GitHub Badge projesinden neler öğrendik?
GitHub Badge başlangıçta kullanıcıların GitHub profilleri ile ilgili birkaç istatistiki bilginin gösterileceği ve geliştiricilerin özgeçmişlerine veya bloglarına koyabilecekleri basit bir bilgi alanından ibaretti. Aslında hala öyle ancak “birkaç istatistiki bilgi” kısmını biraz genişlettik.
İlk sürümü yayınlandıktan sonra,
- Google App Engine’in ücret politikasının değişmesi
- Kullanıcı sayısının hızla artması
- Yeni eklenen özelliklerle uygulamanın kullandığı kaynağın artması
gibi nedenlerle mevcut yapı App Engine’in ücretsiz kullanım limitlerini zorlamaya başladı.
Ölçeklenebilirlik
Memcache
İlk yaptığımız şey üretilen HTML sayfasının belirsiz süreyle Memcache üzerinde önbelleğe alınmasıydı ki bu oldukça etkili bir çözüm oldu. Her ne kadar sunduğumuz bilgiler her zaman en güncel bilgiler olmasa da iletilen bir şikayet olmadı. Kaldı ki çoğu durumda GitHub’ın agresif önbellekleme stratejisinden dolayı GitHub arayüzünden daha güncel veriler sunmamız rastlanmayan bir durum değil(eğer bir projeyi veya kullanıcıyı takip etmediyseniz ya da bir gönderi yapmadıysanız profilinize ait bilgiler GitHub Badge’e göre daha eski olabilir). Ancak gönderi yoğunluğunu gösteren “sparkline” özelliği yayına girdiğinde her öğenin yaşam süresini 24 saatle kısıtlamamız gerektiğine karar verdik.
Bu durumun üzerine “bizi destekleyin” ve “Google Analytics’i kapat” gibi HTML çıktısını değiştiren özelliklerin eklenmesiyle sadece üretilen HTML sayfasının önbelleğe alınması yetmemeye başladı. Bu durumu çözmek için hesaplanan kullanıcı bilgilerinin bulunduğu sözlük nesnesini de JSON biçiminde önbellekte saklamaya başladık.
Google App Engine, Memcache kullanımını ücretlendirmediği için alabildiğimiz tüm bilgileri Memcache ile önbelleğe aldık ya da önbelleğe aldığımız veri miktarını arttırmaya çalıştık. Bu durum, artan günlük ziyaretçi sayımıza ve kullanıcılarımıza rağmen hala ücretsiz kullanım sınırları içerisinde kalabilmemizin iki temel sebebinden bir tanesi.
Ön yüz
Ön yüzde neredeyse ilk sürümden beri HTML ve CSS sıkıştırma kullanıyoruz, Google App Engine de gzip kısmını kendisi hallediyor. Buna ek olarak tüm sayfanın yarım günlüğüne tarayıcı önbelleğine alınması ve kişilerin GitHub’da görünen resimlerinin de sunucu tarafında yeniden boyutlandırılıp sayfaya gömülmesi gibi optimizasyonlar ile bant genişliğimizi oldukça etkin kullanmayı başardık.
API kullanımı ve Pyresto
GitHub Badge’in ilk sürümünde, GitHub API ile ilgili işleri yapmak, takipçi sayısı gibi bilgileri hesaplamak için bir nesne ve buna bağlı birkaç yöntem yeterliydi. Gönderi grafiği, kişinin kendisi dışındaki toplam proje takipçi sayısı gibi veri işleme gerektiren, daha ayrıntılı bilgileri göstermek istediğimizdeyse bu basit sınıfın işimizi görmeyeceğini anlayıp farklı çözümler aramaya karar verdik. Yaptığımız küçük araştırmada GitHub için halihazırda yazılmış olan Python istemcilerinin ya eski ya da istediğimiz gibi olmadığını gördük ve “hepsine hükmedecek tek bir yüzük olmalı” diyerek “adam gibi yazılmış” REST tabanlı her türlü uygulama arayüzü ile çalışacak bir ORM projesi yazmaya karar verdik. İlk kurbanımız elbette ki GitHub olacaktı.
Bu noktada GitHub’ın sunduğu uygulama geliştirme arayüzünün üçüncü sürümünün gerçekten mükemmele çok yakın olduğunu, mükemmel olmayan kısımlarında da GitHub ekibinin yaptığımız hata bildirimleri ve özellik isteklerine olumlu ve hızlı yanıt verdiğini belirtmekte fayda var ki bu da geliştirme sürecinde işimizi oldukça kolaylaştırdı. Pyresto’nun asıl yaptığı şey veri ile uğraşmak isteyen programcıyı arkaplanda dönen karmaşık işlemlere bulaştırmamak, basitçe onun önünden çekilmek ve veriyle rahatça uğraşmasına izin vermek, bunu yaparken de farklı platformların geliştirme arayüzü tanımlamalarını olabildiğince basite indirgemek. Örneğin şu an kullanmakta olduğumuz GitHub modülü sadece 70 satırlık bir dosyadan ibaret. Bu kod elbette tam değil ve herşeyi kapsamıyor ancak yaptığımız ve sıradan olmaktan uzak GitHub uygulaması için fazlasıyla yeterli. İşin güzel yanı bu 70 satırın çoğu aslında veri modelini tanımlıyor, yani gerçek kod değil.
Sözün özü GitHub Badge projesinin kalbinde aslında Pyresto yatıyor ve bir sonraki hedefimiz bu kütüphaneyi hem belgelemesi hem de testleri ile herkesin rahatça kullanabileceği bir hale getirip yaygınlaşmasını sağlamak. Şu anki hali de PyPI üzerinden indirilebilir durumda.
Arayüz
Eklenen yeni özelliklerle beraber, bu özelliklerin son kullanıcıya nasıl sunulacağı da önemli bir soru haline geldi. Bu nedenle arayüz toplamda üç kez değişti. Bu süreç, ürünün özelliklerini kısıtlı bir alanda, kullanıcının kafasını karıştırmadan, mümkün olan en sade ve güzel tasarımla, olabilecek en fazla bilgiyi sunmaya çalışmak gibi hedefler nedeniyle epey öğretici ancak bize göre sunum konusunda hala olması gerekenden uzakta olan bir tasarım deneyimi oldu. Yani bu konuda tavsiyelere açığız.
Açık kaynak topluluğu ile iletişim
GitHub Badge öncesinde başta Mozilla ve Python olmak üzere açık kaynak projelere katkıda bulunuyorduk ancak jGrow haricinde sıfırdan yazdığımız ve topluluktan geribildirim aldığımız bir proje geliştirmemiştik. GitHub Badge ilk katkılarını yayına girdikten birkaç saat sonra aldı. Test sürecinde farketmediğimiz hataları da yine bu sayede düzelttik.
Bir açık kaynak projeye katkıda bulunmanın tek yolu kod yazmak değil. Başlangıçta çok basit olarak düşündüğümüz proje, Emre Sevinç’in katkılarıyla çok daha fazla bilgi sunar hale geldi. Her ne kadar yeni sürümlerde eklediğimiz JSONP ve CORS tabanlı API’ler için beklediğimiz geri bildirimi alamamış olsak da sağlıklı bir açık kaynak proje nasıl olur ve nasıl gelişir konularında bir miktar tecrübe kazandık, mutlu olduk falan.
Bu yazı projenin diğer geliştiricisi olan Berker Peksağ ile birlikte hazırlanmış olup, onun blogunda da yayınlanmıştır.
