Uzun süredir değinmek istediğim bir konu, belki de Türkiye’den çıkmış tüm zamanların en harika web girişimlerinden biri put.io. Tanıtımı ve ne iş yaptığıyla ilgili pek çok yazı başka bloglarda mevcut. Fakat put.io sıradan bir web girişiminden öte, bir çok mühendislik problemine güzel çözümler getirmesiyle dikkat çekiyor. Bugün put.io’nun kurucularından Cem Başpınar (aftermath) ile put.io’daki teknik konular üzerine bir söyleşi yaptık. Umarım put.io ile ilgili efsanelere ve aklınızdaki sorulara yanıt olur. :)

**Dışarıdan bakıldığında put.io’da hangi teknolojilerin kullandığını bilmiyoruz. Kısaca, put.io hangi dillerde kodlandı, hangi veritabanı sistemini kullanıyor?

** put.io’nun büyük kısmında PHP üzerinde çalışan bir web çatısı olan Symfony‘i kullanıyoruz. Sistemin altyapıdaki işleyişini sağlayan job‘ların çoğu yine PHP, bazıları ise Python‘da kodlanmış durumda. İlk başlarda PHP’yi seçme sebebimiz bu dilde geçmişte edindiğimiz iyi tecrübeler, know-how ve ekibimizin bilgisi ön plandaydı. İlerleyen zamanlarda PHP’nin memory management’ı iyi yapamadığını gözlemledik. Zaman zaman job’larda gereksiz şişmeler oluyordu. Python’da ise bu sorun olmuyor ve performansı çok daha iyi.

Sitenin arka tarafında çalışan ve veritabanı ile iletişimde olan Private API var. Tornado Server ile de Public API’nin Private API ile konuşmasını sağlıyoruz. Şu anda kullandığımız veri tabanı MySQL. Bu seçimin nedeni daha önceki pillinetwork projelerinde ve Sosyomat‘tan edindiğimiz geniş know-how’a güvenmemiz. MySQL’in klasik sorunu olduğu üzere tablolar büyüdüğünde biz de sorunlar yaşıyoruz. Veritabanında milyonlarca satır var. Proje daha başlarda olmasına rağmen veritabanı şimdiden toplam 35 GB büyüklüğüne ulaştı. Sistemde ise aktif 1,500 kullanıcı mevcut.

Projenin ilk günlerinde bottleneck (dar boğaz) veritabanı oldu. MySQL kullandığımız için kolay biçimde sunucu sayısını artıramıyoruz ve yatay ölçekleme yapamıyoruz. Replication, sharding, database cluster kurma, master-slave yapıları gibi alternatifleri düşündük, fakat hepsinin kendine göre bottleneck’leri oluyor. Tek veritabanı sunucusu ile sistemi çalıştırabilecek kadar optimize ettik. Kompleks sorgulardan, join’lerden kaçınıyoruz. Mümkün oldukça veriyi denormalize ediyoruz. Maliyetli sorgular background job olarak çalışıyor, böylece kullanıcı deneyimine olumsuz etki etmiyor.

NoSQL güzel ilerleyen bir trend. Doğrusu şimdilik ihtiyacımız yok gibi duruyor ama biz de kullanmak ve bir yerinden aşina olmak istiyoruz. Önümüzdeki MongoDB, Cassandra, CouchDB gibi seçeneklere baktığımızda MongoDB en kompakt ve kullanışlı çözüm gibi duruyor. Test ettik, memnun kaldık ancak Put.io production (yapım) ortamında kullanmadan önce farklı bir projede denemeyi istiyoruz.

Dosyaları saklamak için nasıl bir sistem kullanıyorsunuz? put.io’daki dosyaların toplam büyüklüğü ne kadar?

** **

Dağıtık bir dosya sistemi olan açık kaynaklı MogileFS‘i kullanıyoruz. MogileFS’de çok sayıda 1 TBlık diskler tutan sunucularımız var. Raid6 ile 400 mb/s gibi dosya yazma hızlarına ulaşabiliyoruz, MogileFS içinde ise 50 mb/s gibi bir performans yakalayabiliyoruz. Aslında sunucuları yapılandırırkenki planımız “her sunucu her işi yapabilsin” şeklindeydi. Örneğin joblar, veritabanı, depolama işlemlerini her sunucuya bölmeyi düşündük. Fakat bundan iyi bir performans alamadık. Daha sonralarda kabaca sunucuları şöyle gruplandırdık:

  • Torrent sunucuları: 2 sunucuda 10’ar tane torrent client’ı, aynı zamanda indirilen zip-rar’ları açıyor.

  • Web fetch (Rapidshare vb.) sunucuları

  • Video Encoding sunucuları: 8’er çekirdekli işlemciye sahip 2 sunucuda aynı anda 6 video’yu encode edebiliyor.

  • Veritabanı sunucusu: MySQL

  • Application (uygulama sunucusu): 2 tane web sorgularını idare eden sunucu.

  • Background job (arkaplan işi yapan) sunucuları

  • Memcached sunucusu: 1 adet in-memory caching (önbellekleme) yapabilen sunucu.

  • Arama sunucusu: 1 tane sistem genelindeki arama işlerini karşılıyor.

  • Depolama sunucuları: 4 tane mogilefs kurulu dağıtık depolama sunucusu. Fakat çoğu sunucuların çalıştırdığı ortak job’lar olabiliyor. Örneğin zipleme-unzipleme gibi işler sistem kaynakları açısından oldukça maliyetli olabiliyor. Aynı zamanda 700mb ve daha büyük dosyaları bir sunucudan diğerine aktarmak veri trafiği yaratıyor. Örneğin torrent protokolünden 1-2 GB bir dosyayı çekmek çok hızlı bir şekilde tamamlanabiliyor, fakat bunu depolama sunucularına dağıtmak dakikalar  sürebiliyor. Buna ek olarak dağıtık bir dosya sistemine sahip olduğumuzdan dosyaları silmek bile maliyet yaratıyor. Yani kullanıcı kendi hesabından sahip olduğu dosyayı silse bile biz onu sunucularımızdan anında temizlemiyoruz. Zeminde çalışan job’lar temizlik işlerini gecikmeli olarak yapıyor.

Projeyi açmadan önce ölçeklenebilirlik kriteriniz neydi? Kaç kullanıcı bekliyordunuz? Bugün ölçeklendirilebilirlik problemleri yaşıyor musunuz?

İlk başlarda birkaç ay fizibilite (uygulanabilirlik) çalışmaları yaptık. Bu projenin hayalini kuruyorduk, ufak bir prototip geliştirdik ve denemeye başladık. Aslında işin teknik gerçeklenebilirliği kısmı dışında iş modeli yönünde olan bu hizmeti “kaç paraya satacağım”, “bana ne kadar kazandıracak” gibi hesapları yaptık.

Projenin adının duyulduğu ilk günlerde proje grubuyla beraber yakın arkadaşlarımızdan oluşan 10-15 kişi sistemi kullandı, biz de buna göre 1,000 kişinin sisteme getireceği yükü tahmin etmeye çalıştık. Ardından yavaş yavaş sayıyı artırdık. 40 kişi olduğumuzda Almanya’daki sunucularımızda beta düzeyinde sistem çalışıyordu. Takiben ISP’mizi Amsterdam’a taşıdık ve testlere devam ettik. Hız bizim için en önemli kriterlerden biri.

Ardından sevgili Arda Kutsal (Webrazzi) projeyle tanıştı ve oldukça beğendi. Daha sonra ufak bir teaser olarak bunu Webrazzi’de yazdı. Takip eden süre içinde 100 kişilik davetiye dağıtmayı düşündük. Sistemin sorun yaşamadan kaç kişiyi mutlu edebileceğinden emin değildik. Bu nedenle davetiye sistemi ile azar azar üye alıp, ölçeklendirme üzerinde çalışma yoluna gittik. Sancılı ama çok öğretici bir süreç oldu.

Altyapıda gerçekleştirdiğimiz her optimizasyondan sonra daha çok kullanıcıyı sisteme davet edip ölçümlemeler yapıyorduk. Bir noktada 400 kullanıcıyı kaldırabilecek bir sisteme ulaşabileceğimizi düşündük. Hemen Webrazzi aracılığıyla 100 adet ücretsiz deneme davetiyesini kullanıcılara sunduk. Birkaç dakika içinde bütün davetiyeler tükendi. Doğrusu biz altyapıyı çok rahat bu kadar yükü kaldırabilir diye düşünüyorduk.

Gelenlerle birlikte sistemde toplam 140 kullanıcıya ulaştık. O gece sunuculardaki yükler uykularımızı kaçıracak kadar tavan yaptı. Çünkü proje ne kadar güzel bir fikir olursa olsun teknik kısmını uygulayamadığınız zaman çok bir anlam ifade etmiyor. Bu bizim için büyük bir sürpriz oldu. O gece oturduk dar boğazları tek tek tespit edip düzelttik.

Put.io’daki en önemli kriterlerden biri hız. Hız olmadan ne yazık ki böyle bir ürünün değeri olmayabiliyor. Denemelerimizin ardından 500 kişiyi daha kabul etmeyi düşündük ama asıl sorun davetiyelerin dağıtılmasıyla beraber herkesin aynı anda sisteme yüklenmesi ve gün boyu sonuna kadar sistemi denemeye çalışmaları oluyordu. Haliyle bu da çok büyük bir yük yapıyor. Takip eden günlerde 100 davetiye daha dağıttık, 8 dakikada tükendi.

Bu şekilde sistemdeki kullanıcı sayısını yüzer yüzer artırdık. 500 kullanıcıya ulaşınca diğer sitelerden davetiyeler dağıtmaya başladık. Amaç kullanıcı sayısını artırmak ve geliştirme safhasında kullanıcıların sistemimizi deneyerek bug’ları, darboğazları görmemizi sağlamalarıydı.

Ürünün hızlı olması ve düzgün çalışması bizi için önemliydi. Nihayetinde paralı bir ürün satacaksınız ve sistem olması gerektiği gibi çalışmazsa mutsuz kullanıcılar yaratmış olursunuz. Torrent, RapidShare gibi farklı protokollere beraber çalışan bir servis üretiyorsunuz ve bunun sürekliliğini sağlamak çok önemli olduğu gibi bir o kadar da zor.

Bu nedenle projeyi geliştirirken başlarda çekirdek özelliklere (core functionality) odaklandık. Örneğin torrent’ten indirme, streaming (online izleme) vb. Geliştirme aşamalarında sistemin 1.000 kullanıcıyı kaldırmasına “hayal” diyorduk, evet. Ama optimize ederek sonunda 1.000 kullanıcıya ulaşabildik ve zamanla 1.500′e kadar çıktık. Geliştirme sürecinde sistemi 6 ay içinde 1.000 kişiye kadar ölçekleyebilecek duruma geldi.

Örneğin payment (ödeme) sistemini çok geç yaptık, ama vakit kaybetmemek istiyorduk. Ürünü piyasaya sunmadan önce çok hızlı bir biçimde ödeme sistemimizi de geliştirdik. Yayına girdiğinde ödeme yaptığınız aydan sonraki ay otomatik olarak ücreti çekemiyordu. Kullanıcının birinci ödemesiyle ikinci ödemesi arasındaki 30 günlük sürede otomatik ödeme bölümünü tamamlamayı planladık. O sıralar sıkı bir programla çalışıyorduk ve zamanında her şey yetişmiş oldu.

Şu anki kapasitesiyle sistem 2500 kullanıcı karşılayabilir diye düşünüyoruz. Aynı zamanda artık ürün olarak çıktığı ve dünya çapında kullanıldığı için kullanıcıların zaman dilimi homojen olarak dağılmış durumda. Beta testler yaptığımızda tamamen Türkiye’den kullanıcılar giriyordu ve tahmin edersiniz ki akşamları yoğun yüklerle karşı karşıya kalıyorduk. Bazı işlemler sunucu tarafında çok geç tamamlanıyordu, uzun kuyruklar oluşuyodu. Homojen dağılım sayesinde sistemde tek bir “prime-time” yok ve bu yüzden aşırı yük olmuyor.

Kullanım istatistiklerine gelecek olursak en çok kullanan ülkeler şu şekilde:

  1. ABD

  2. Fransa

  3. Türkiye

  4. Almanya

  5. İngiltere En çok kullanıcının ABD’den olması Avrupa’daki prime-time’da oluşan yükü dengeliyor diyebiliriz.

**Sunucularınız nerelerde bulunuyor?

** Şu an Amsterdam’da bir ISP’de bulunuyor. Amsterdam’a taşıdıktan bir süre sonra Webrazzi’den beta davetiyelerini dağıttık. Fakat birkaç ay sonra bütün hepimizin put.io’ları birdenbire yavaşladı. Sunucu tarafına baktığımızda gördük ki sorun bizde değil. Sonradan öğrendik ki sorun TTNET ile bizim ISP’miz arasındaymış.

Bu durum Türk kullanıcıların deneyimini olumsuz etkiledi. Buna çözüm olarak tunneling yapma fikrini düşündük. Bu şekilde asıl ISP’mize bağlantı yapmak yerine araya bir tünel ekleyerek TTNET’in yetersiz Amsterdam çıkışlarından kurtulduk. İlk tünelimizde her sunucuda 100 mbit bağlantı vardı ve bu elbette put.io gibi bir servis için yeterli değildi. Bu nedenle birden fazla tünel sunucu yapmaya ihtiyaç duyduk. Şu an Almanya’da 3, ABD’de 1 tünel var ve yakında Kanada’da da açılıyor olacak. Şimdiki bağlantımız tüneller hariç 1 gbit.

**Zamanında karşılaştığınız veya hala yaşadığınız önemli dar boğazlar (bottleneck) neler? Nasıl çözdünüz? **Queue (kuyruk) ve threading yapınız kısaca nasıl çalışıyor? Load balancing (yük dengeleme) mekanizmalarınız neler?

Sistem kullanılmaya başladıkça gördük ki diske yazma (disk I/O) konusunda bottleneck’ler oluşturuyor. Bunun üstesinden gelmek için yaygın harddisk’ler yerine Solid State Disk‘lere (SSD) geçmeyi düşündük. Fakat daha önceden deneyen birinin tecrübelerinden öğrendik ki bizim yaptığımız işlem türü için sadece %20 performans artışı sağlıyormuş. Bu nedenle bu kısmı erteledik.

Kuyruk mekanizmasında ve görevleri bölüştürme kısmında yine danga’nın geliştirdiği açık kaynaklı bir çözüm olan Gearman‘i kullanıyoruz. Bunu kendi ihtiyaçlarımız doğrultusunda modifiye ettik, örneğin job kayıtlarını persistent hâle getirdik ve her job’ı sonucuyla beraber veritabanında saklıyoruz. Bundan önce bazı job’lar çalışmış gibi görünüyordu fakat işlerini yapmıyorlardı, bazıları da kaybolup gidiyordu ve bunu takip edemiyorduk.

Yük dengeleme tarafında 2 tane application server var, bunlar nginx arkasında çalışıyor. Nginx tüm projelerimizde varlığına minnettar olduğumuz bir yazılım. Round-robin mekanizması ile istekleri Apache sunuculara dağıtıyor.

Buna ek olarak real-time ziplerken stream etme gibi ilginç konularda da araştırmalarımız ve çözümlerimiz oldu. Bug’lardan iyice arındırdıktan sonra açık kaynaklı lisanslarla herkesin kullanımına paylaştırmayı düşünüyoruz. Dropbox’un da geliştirdiği real-time zipping çözümü var fakat bu gibi çözümler indirmeyi kaldığı yerden devam ettirememe gibi kötü özelliklere sahip. Geliştirdiğimiz çözümü herkese sunarak bunun gelişiminden biz de fayda görmeyi umut ediyoruz.

**put.io’yu geliştirirken hangi açık kaynaklı çözümleri kullanıyorsunuz?

** Munin ile sistem kaynaklarını ve ağ trafiğini inceliyoruz, Monit ile sistemlerde çalışan job’ları ve process’leri inceliyoruz. Web kısmında Symfony ve Tornado kullanıyoruz. Bunlar dışında bir çok irili ufaklı Unix tool’u ve kütüphanesi sisteme dahil çalışıyor. Arama için Solr kullanıyoruz.

put.io’nun RapidShare, Torrent vb. üzerindeki bu hızını neye borçlusunuz?

Sunucu tarafında 1 Gbit kadar bir hat var. Aslında takıldığımız hız limiti Disk I/O’dan kaynaklanıyor. Dosyaları önce memory’e yazıp bir süre oradan sunup lazy (geç) olarak diske yazmayı düşünürsek birden fazla indirmenin aynı anda ilerlemesi çok ciddi bir memory kapasitesi gerektiriyor olacaktır. Aynı zamanda concurrency de bu tip büyük sistemlerde önemli rol oynuyor. Concurrency’i sağlarken aynı anda birden fazla iş yapma imkanınız düşebiliyor. Dosyayı çekerken yazmaya çalıştığımız zaman 400mb/s gibi bir hıza ulaşıyoruz. Depolama kısmında RAID 6 kullanıyoruz.

Bu yüzden bazen servisimizin hızı, karşı taraftaki storage servisinin hızı kadar oluyor. Örneği Hotfile bağlantı hızı olarak çok yavaş bir servis, RapidShare de son karar değişiklikleri nedeniyle artık kan kaybediyor. Buna karşıt olarak, Fileserve çok hızlı. Sahip olduğumuz bu 1 gigabit hattın ortalama bir zamanda 100mbit’i dolmuyor. Örneğin, şu an ben konuşurken (TSİ 22.30) ağ trafiğinin %50′si dolu, çünkü prime-time’dayız. Bu network trafiğinde upstream ile downstream yarı yarıya bağlantıyı harcıyorlar. Bu hattı kolaylıkla artırabiliyoruz. Fakat ek maliyetlere girmek sistemin getirdiği kârı düşürüyor. Bu şekilde ucuz bir çözüm sağlayabilmemiz kullanıcıya da ucuz fiyat olarak yansıyor.

**Projede düzenli yazılım testleri yapıyor musunuz? Bunlar ne tür testler oluyor?

** Build ve deployment işlemlerinde Hudson CI kullanıyoruz. Hudson sayesine sürekli bir entegrasyon test ortamımız oluyor. Çok sayıda PHPUnit testimiz de mevcut. Aynı zamanda production ortamında projede önemli failure’lar (aksaklıklar) yaşanırsa bize mail ve SMS geliyor. Diğer ufak hatalar sisteme kaydediliyor ve daha sonra loglardan inceliyoruz.

Sistemin payment (ödeme) kısmında çok sayıda test düzeneği var. Neticede para ile ilgili işlemlerde hata yapmak istemeyiz. Sistemin metriklerini ölçtüğümüz bir background job karşı sitelerin (rapidshare, megaupload vb.) sağlığını kontrol ediyor. Bu sitelerden biri çökerse yine bize SMS atıyor.

Hangi sistem metriklerini ölçümlüyorsunuz ve bunları nasıl kullanıyorsunuz?

Metrikler konuusnda detaya inecek olursak çok sayıda ölçümleme ve raporlama yapıyoruz. Birkaç örnek. “kaç tane .mp4 encode edilirken hata vermiş”, “kaç torrent çekilmiş, boyutları neler”, “giden trafiğiğin yüzde kaçı ZIP dosyaları”, “webden ne kadar download yapılıyor, mobile’den ne kadar yapılıyor”… Bu alanlarda elde ettiğimiz verilerle tahminler yapıyoruz. Aynı zamanda bu tip metrikler yatırımcılar tarafından sıkça sorulan şeyler oluyor. İşin teknik tarafına geldiğimizde bu ölçümlemeler sistem sağlığı ile ilgili bize büyük bilgiler veriyor. Örneğin, “bir torrentin ortalama downloaddan sonra hazır edilme süresi ne kadar” (cevabı, yaklaşık 10 sn), “dosyanın network içindeki transfer süresi”, “torrent job’ının baştaki bekleme süresi ne kadar”, “hangi siteden download hızı ortalama ne kadar” vb. günlük ortalama rakamlar ile takip ediliyor.

Bu tip ölçümlemeler yaparak sistemde iyileştirmelere gidebiliyorsun. Örneğin torrent hızlarını izlerken fark ettik ki bazı ayarlamalar ve güncellemeler yaparak bunu artırabiliyoruz. Bu şekilde geçtiğimiz hafta Torrent’te tam iki kat hız artışı sağladık.

Kullanım alışkanlıklarını inceleme kısmına gelince beta davetiyeler süresince kullanıcıların kullanım alışkanlıklarını inceledik ve ona göre paketlerin boyutlarını ve fiyatlarını belirledik. Aslında doğrudan kullanıcıları takip etmiyoruz veya etraflı istatistik çalışmaları yapmıyoruz. Google Analytics sayesinde arayüzle ve sitenin kullanışlılığıyla ilgili bazı değerleri izliyoruz. Şimdilik sadece sistem sağlığına yönelik incelemelerimiz var.

Marketing bölümü için Kissmetrics.com kullanmaya başladık ve çok memnun kaldık. Google Website Optimizer ile marketing bölümünde küçük denemeler ve ölçümler yapıyoruz Aslında geliştirmeyi düşündüğümüz bir “happiness score” sistemi var. Bu sistemle kullanıcı mutluluğunu ölçmeye çalışıyoruz. Bunun içinde Torrent kullanımı, Paysite kullanımı, Podcast (RSS) servisi kullanımı gibi verileri inceleyerek kullanıcının sistemi daha iyi tanıması ve sistemden mutlu kalması için öneriler sunmayı sağlamayı düşünüyoruz. Bu tip bir projede elbette kullanıcıya destek kısmı önemli. Gelen her şikayet/sorun ile tek tek ilgileniyoruz ve büyük oranla çözüyoruz.

**Ne tip gözlemleme (monitoring) sistemleri kullanıyorsunuz?

**

put.io’da Munin’e pluginler (eklentiler) yazıyoruz. Bahsettiğim bu metrikleri birer plug-in’e dönüştürüp Munin’den takip ediyoruz. Bu şekilde istatistiklerin grafik halinde sunumlarını alıyoruz ve gerektiği zaman inceliyoruz. Bu açıdan Munin’i tavsiye ediyorum. Tüm projelerimizde sıkça kullanıyoruz. Munin isterseniz günlük limit aşımlarını SMS atabiliyor. Hata veren background job’ları (örneğin arka arkaya 5 .mp4 dönüştürme işlemi başarısız olursa) SMS atıyor, biz de hemen hatayı düzeltmeye çalışıyoruz. Bizim açımızdan bu oldukça büyük rahatlık sağlıyor. Kullanıcılar farketmeden sistemin herhangi bir yerindeki hatalardan haberdar oluyorsun. Paysite’lar (rapidshare vb.) kapandığında haber gelmesi de bizim için önemli.

Gerçek zamanlı analiz için Chartbeat.com‘un ücretli servisini kullanıyoruz. Response time ve uptime takibi için Pingdom‘un ölçüm servisini kullanıyoruz.

Kullanıcılarınızın çoğu servisinize put.io web arayüzünden girecek olmasına rağmen neden bir API yaratma ihtiyacı duydunuz? Bunun size getirileri neler olacak?

Sistemin ön yüzü de aslında arka taraftaki Private API’larla çalışıyor. İlk etapta tasarlarken birden fazla datacentera bu servisi dağıtabilecek bir yapı yapmayı düşündük. Bunun faydasını sistem büyüdükçe görüyoruz. put.io (frontend’i) sitesi de bizim API’lerimizle konuşarak çalışıyor.

Public Developer API konusunda Private API’daki bilgilerin basit (sadeleştirilmiş) versiyonunu bir API servera kurduk ve oradan sunduk. Oradaki hedefimiz developer-friendly bir API sağlamak oldu. Aynı şekilde o da Private API ile konuşuyor.

Public API yaparkenki motivasyon bizim için çok önemliydi. Sonuçta dosya çekme ve depolama sistemleri ile uğraşıyoruz. Depolama konusu gerçekten ayrıntılı ve geniş bir konu. Put.io API kullanan 3. parti çok ilginç uygulamalar çıkılabilir.

Biz Public API’ı hazırlarken put.io’nun kendi arabiriminden daha entesesan bir aracın çıktığını görmeyi ümit ettik. Belki birileri put.io frontend’inin eksiklerini tamamlayan “betterputio.com” diye bir projeyle çıkagelir diye umduk. Şimdiye kadar Android uygulaması yapıldı. Buna ek olarak Objective-C hariç bütün dillerde resmi olarak desteklediğimiz API’yi rahat kullanmak için tasarlanan kütüphaneler kullanıcılar tarafından kodlandı. API, bu kütüphanelerle JSON notasyonunda konuşuyor.

API’da neleri sunacağımızı düşünürken her şeyi basit tutmaya çalıştık. API’yi kullanarak bir şeyler üretmek işkence olmamalı diye düşündük. Public API’ın tutup tutmayacağını bilmiyorduk. Kimse kalkıp bir uygulama yapar mı, fikrimiz yoktu. Bu yüzden API’da ilkel yetkilendirme sistemleri kullanıyoruz. Kullanıcı bir sayfadan girip API key’ini alıyor ve uygulamaya veriyor.

Bunlar dışında bence Boxee uygulaması süper! Biraz da bu tip dahili ihtiyaçlar için Public API’a gerek vardı.

Not: Benim put.io API ile ilgili yorumuma API Sunan Türk Web Servisleri yazımdan ulaşabilirsiniz.

**put.io’daki yenilikler neler? Yakın zamanda neler göreceğiz?

** Şu an yürütmekte olduğumuz bomba bir proje var doğrusu. put.io’daki depolama alanınızı normal bir harddisk sürücüsü gibi bilgisayarınıza mount ediyor. (Zamanında Gmail’i de depolama alanı olarak kullanmak için benzer bir şeyler çıkmıştı) Bu şekilde kullanıcı put.io’da indirdiği bir dosyayı put.io’yu açıp siteden indirmeden doğrudan file browser’ından istediği programla açabilecek.

Windows ve Mac’te konsepti test edecek kadar ilerledik. Olumlu sonuç verdi. Dosya sistemleriyle uğraşan bir arkadaşımız bu sistemi üzerinde çalışıyor. Bilgisayarındaki bir dosyayı seçer gibi put.io’daki bir dosyayı seçiyorsun, indirmeye başlıyor. Aynı zamanda dosyayı parçalara bölerek çekiyor ve çektiği kadarını önbelleğe alarak oradan, izleme imkanı sunuyor. İyi bir bağlantı hızıyla video izlenebiliyor ve video içinde gezintiler de oldukça rahat. İstediğin player ile video izlemeni sağlıyor. Put.io’yu işletim sisteminin bir parçası yapmayı sağlıyor. Bu şekilde Divx Web Player’ın sorunlarından daha az etkileniyor olacağımızı düşünüyorum.

Geçtiğimiz günlerde test ederken ilginç bir kullanım senaryosu yaşadık. Ubuntu iso dosyasını Put.io mounter üzerinden VirtualBox’a mount ettik ve Ubuntu’yu internet üzerinden kurmayı başardık.

Ek olarak kendimi medya oynatıcımızı yapmayı düşünüyoruz. Player dosya okuma için mounter’ın teknolojisini kullanıyor olacak. Her iki alt proje de bizim için çok heyecan verici.

Bu mounter sisteminin de, media player’ın da ücretsiz ve açık kaynaklı olarak yayınlanacak. Geliştirilmesine katkıda bulunmak isteyenler bizimle irtibata geçebilir.

Genç altyapı mühendislerine tavsiye olarak, kullanıcılarınızın alt yapıda ne kadar ciddi emek olduğunun farkında olmadan öylece sistemi kullanmaları nasıl bir duygu? Sizce mühendisler sürekli rocket science yapmanın peşinde koşmalı mıdır?

Zaten aslında kullanıcının altta çalışan karmaşık yapıdan haberdar olmaması gerek. En iyi tasarım görünmez olan, kullanıcıya engel olmayan tasarımdır. Bir ürün veya servisin varlık sebebi kullanıcının bir problemini çözmek. Bunu yaparken nasıl yaptığı önemli değil, kullanıcı için işini yapıp yapmadığı önemli.

Sen bir üretici olarak bir vizyonun var ve o ürün için ne gerekiyorsa yapacaksın. O projenin hayata geçmesi gerektiğine inanıyorsan ne kadar zor challenge’lar gerekiyorsa onları yerine getirmekle yükümlüsün. Zorluklar kullanıcıyı ilgilendirmiyor. İster roket bilimi kullan, ister düz html siteler yap.  Kullanıcının sistemin altyapısıyla ilgili senin günlerce kafa paylattığın hiçbir şeyi bilmemesi kötü hissetmeyi gerektirecek bir şey değil diye düşünüyorum.

Put.io’daki kariyer fırsatları neler? Başvurular nasıl gerçekleştirilebilir?

Önümüzdeki hedef, geliştiricilerden oluşan ekibi büyütmek olacak. Gerçekten mühendis zihniyle düşünen, yetenekli, bu konularda araştırmayı seven, henüz erken evrede bize katılıp uzun vadede bizle beraber olmak isteyen geliştiriciler arıyoruz. Bu projede değişik teknolojileri deneme imkanımız var. Video dosyaları, stream, dosya sistemleri, Torrent gibi konularla uğraşıyoruz. Ben oldukça heyecanlı buluyorum. Ayrıca

İlgilenenler info(at)put.io adresinden bizimle iletişime geçebilirler.

–son–

Bir akşamının yaklaşık 1,5 saatini bu muhabbete ayıran Cem’e çok teşekkür ediyorum. Üzerinden yıllar geçse de okunabilecek güzel bir altyapı röportajı olduğunu düşünüyorum. Cem Skype’da epey akıcı konuşurken ben notlar aldım. Bu yüzden bazı kısımları kaçırdığım, bazılarını da elediğim oldu. Umarım yanlış anlaşılmaya mahal verecek bir nokta yoktur. Sürç-i lisan olduysa benim yüzümdendir, şimdiden affola. :)

put.io uzun süredir ağzım açık hayranlıkla izlediğim bir girişim, dahası mühendislik harikası. Bu sadece benim değil, Silikon Vadisi’ndeki projeyi gören insanların da görüşü. Bu uzun röportajla içimdeki ciddi bir ukteyi doldurdum. Türkiye’de her zaman böyle başarılı start-up’lar çıkmıyor, incelemek boynumun borcuydu. ;)