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.

Mozilla'ya Bulaşma Hikayem

Dün gece IRC'den yeni bir gönüllü özel mesaj gönderip "sanırım bu bug için danışmanım(mentor) sensin" dediğinde uzun süredir içinde olduğum "Mozilla macerası" ile ilgili bir yazı yazma zamanımın geldiğini anladım.

Mozilla, bir çoğunuzun Firefox'tan bildiği ancak aslında çok da yakından tanımadığı, gelir amacı gütmeyen bir kuruluş. Yegane amacı "özgür internet" ve bu sayede insanların kendilerini ve fikirlerini serbestçe ifade edip, paylaşıp kendilerine ve çevrelerine faydalı olmalarını sağlamak. Firefox bu yolda uzun yıllar önce Microsoft ve Internet Explorer tekeline karşı atılmış bir adım ancak kendisi Mozilla'nın bu yoldaki tek projesi değil.

Özellikle son yıllarda Firefox'un tarayıcı pazarında %20 gibi oldukça iyi bir kullanım oranına ulaşması, ve bu sırada Google gibi büyük bir oyuncunun tarayıcı pazarına girip ortalığı iyice hareketlendirmesi, Opera'nın ise bu gelişmeleri yakından takip etmesi ve hatta bazılarına ön ayak olması ile Firefox'un en azından temel amacını gerçekleştirdiğini söyleyebiliriz. İşin güzel yanı Google Chrome’un çekirdeğini oluşturan WebKit’in geliştiricileri, Opera’nın ve hatta yeni Internet Explorer’ın geliştiricilerinin bir kısmı eski Firefox katkıcılarıydı. Bu yüzden amacını layıkıyla yerine getirdiğini söylersek sanırım daha doğru olur.

Mozilla da aynı fikirde olacak ki özellikle son 2-3 yıldır odağını tarayıcısından biraz uzaklaştırıp tekrar kullanıcılara ve geliştiricilere yöneldi. Benim Mozilla ile tanışmam çoğunuz gibi uzun yıllar önce Firefox kullanmama dayansa da gerçek ideallerini kavramam ve katkıda bulunmam da bir kaç yıl önceye ve bu odak değişimine dayanıyor.

Nispeten uzun ancak gerekli bir girişten sonra Mozilla'ya nasıl katkıda bulunmaya başladığımdan ve bu katkıların bana ve diğer insanlara nasıl yol su elektrik olarak geri döndüğünden bahsetmeye başlayabiliriz. 2011 Şubat ayı civarı, tam da askerlik hizmetine başladığım zamanlara denk gelen "Wiki Wednesdays" hareketi sayesinde uzun süredir hayranlıkla yararlandığım Mozilla Developer Network'teki belgelerin gerçekte ben dahil herkesin katkıda bulunup geliştirebileceği "wiki"ler olduğunu fark ettim. Bu hareketin temeli her çarşamba katkıya ihtiyaç duyulan belirli wiki sayfalarının Mozilla Hacks blogunda duyurulması ve katkıcılardan yardım istenmesiydi. O hafta katkıda bulunanlara bir sonraki Wiki Wednesdays blog yazısında teşekkür ediliyor bu sayede insanlar motive oluyordu. Sonuçta resmi Mozilla bloglarından bir tanesinde size teşekkür edilmesi hem gurur verici hem de özgeçmişinize koyduğunuzda sizi bir kaç basamak üste taşıyan bir şey.

Bu farkındalık içerisinde ve askerliği yedek subay olarak yapmanın avantajlarını da kullanarak(akşamları eve gidip internete girebilmek ve hatta iş yerinden rahatça internete girebilmek gibi) düzenli olarak MDN'e katkıda bulunmaya başladım. Yaklaşık 6 ay kadar sonra Janet Swisher’dan beni o yıl Almanya'da yapılacak olan JSConf EU konferansına ve burada gerçekleştirilecek olan "Doc Sprint"e (dokümantasyon maratonu diyebiliriz) davet eden bir e-posta aldım. "İyi güzel diyorsunuz da nasıl geleyim ben oralara, uçak bileti var otel rezervasyonu var askerliği var" diyip e-postayı silerken gözüme "konferans bileti dahil tüm masraflarınızı karşılayacağız" benzeri bir cümle çarptı. Üstünkörü okuduğum e-postayı tekrar okuduğumda MDN'e yaptığım katkılardan dolayı tüm masrafları Mozilla tarafından karşılanmak üzere oldukça prestijli bir konferans olan JSConf EU 2011'e davet edildiğimi öğrendim ve muhtemelen hayatımın şu anki noktaya gelmesine sebep olacak olayların başlangıç noktası olacak bu etkinliğe katılmak için gerekli hazırlıklara hemen başladım.

Çok hızlı bir şekilde gerekli askeri izin belgelerini doldurup ilgili yerlere elden ulaştırdım ve devamında Almanya vizesi için başvuruda bulundum. Ne mutlu ki şansım yaver gitti ve Seylan'ımın da desteği ile gerekli belgeleri hallettim, iznimi ve vizemi alarak yola çıkacağım 30 Eylül 2011 tarihini beklemeye başladım.

Yazı olması gerekenden çok daha uzun olduğu için konferansa gidişim ve devamında olanları bir sonraki yazıya saklamaya karar verdim ancak sizi bu konuda heyecanlandırmak için burada başlayan olayların devamında internet girişimlerinin merkezi diyebileceğimiz San Francisco'da 20 kişilik bir Mozilla ekibiyle harika bir sohbet eşliğinde güzel bir akşam yemeği yediğimi ve bunun yine San Francisco'da bulunan ve şu an taze bir çalışanı olmaktan gurur duyduğum DISQUS adlı internet girişiminde çalışmaya başladığım ilk günlerimde olduğunu söyleyebilirim. =)

Bir sonraki yazıda görüşmek üzere!

GSM Operatörleri için Özel Yazılım Önerileri

Ülkemizde de cep telefonu operatörleri "özelleştirilmiş" yani kendilerine ait yazılım yüklenmiş ya da yazılımı operatöre göre modifiye edilmiş telefonları uygun(!) fiyatlarla satmaya/hediye etmeye başladılar. Ben de bu telefonlarda görüp çok beğendiğim(!) bir takım uygulamaların en güzellerini bir yazıda sizlerle paylaşmaya karar verdim.

Dilerseniz hemen başlayalım:

• Telefonun kullanım kolaylığı sağlayan bir takım özelliklerini kapatın ya da kullanımlarını kısıtlayın. Kullanıcılarınız azla yetinmeyi öğrenmeli değil mi?
• Telefonun içerisine kaldırılması mümkün olmayan ve demo kullanım süresi 1 hafta ila 10 gün içerisinde dolan programlar yükleyin. Programın fiyatı hiç önemli değil, maksat kullanıcının sinirleri ile oynamak.
• Telefonun açılışına, kapanışına, varsayılan zil sesine, duvar kağıdına, ekran koruyucusuna ve daha başka aklınıza neresi geliyorsa oralarına(kapak olur, pil olur, tuş takımı olur) firmanızın reklamlarını, şarkılarını, logolarını koyun. Mümkünse bunların hiçbiri değiştirilemesin.
• Telefonun içerisine doğru düzgün işlevleri olmayan ya da NYStock vs. gibi ülkemizde kullanmanın anlamsız olacağı kaldırılamayan ücretsiz uygulamalar yükleyin.
• Telefonun tarayıcısı içerisine silinemeyen ve en tepeden aşağı kesinlikle indirilemeyen çeşitli lüzumsuz bağlantılar ekleyin. Burada para aldığınız çeşitli firmaların bağlantılarının yanı sıra her gün girmek isteyeceğimiz kendi anasayfanızın bağlantısını da koymak artık bir endüstri haline geldi.
• Bu kadar özelleştirme yaptıktan sonra telefonla ilgili hiçbir sorunda sorumluluk üstlenmeyin. Topu mutlaka üretici ya da ithalatçı firmaya atın. Ne de olsa siz sadece telefonu getirip içini güzelleştirdiniz, kullanıcı desteğinden size ne?
• Telefonu satarkenki sözleşmelerinizi en az 2 yıl, mümkünse de daha uzun yapın ki 6 ay sonra bile teknolojinin eskidiği günümüzde kullanıcılar uzun süre aynı telefonu kullanmak zorunda kalsınlar. Ne de olsa habire yeni telefon almak kötü bir şey değil mi?

Evet şimdilik bu kadar. Eğer atladığımı düşündüğünüz maddeler varsa yorumlar kısmı sizi bekliyor.