Geçen zaman içerisinde Neo4j büyük bir gelişme gösterdi ve yaygınlaştı. Ben de bu popüler veritabanını tekrar kurcalamak istedim. Örnek uygulamamda kendi Twitter takipçilerimden başlayarak bir takipçi grafı oluşturmaya karar verdim. Uygulama benim takipçilerimi çekecek ve ve aramızda FOLLOWS ilişkisi ile Neo4j veritabanına kaydedecek. Daha sonra takipçilerimin takipçilerini çekecek ve aynı işlemi veritabanında olmayan kişi kalmayana dek devam ettirecek.

İşe önce Neo4j’i indirerek başladım. Konsol aracılığıyla sunucuyu herhangi bir sorunla karşılaşmadan başlattım. neo4j-shell ile sunucuya bağlanıp komutları biraz kurcaladım. Daha sonra dokümantasyonda gezerken Neo4j’in bir REST API sağladığını fark ettim. Benzer bir REST API‘yi Twitter da sağladığı için uygulamayı bu API’leri kullanarak JavaScript ile geliştirmeye karar verdim.

Twitter, istenilen kullanıcının takipçilerinin ID listesini döndüren bir API sunuyor.

http://api.twitter.com/1/followers/ids.json?user_id=...

Belki tek sıkıntı saatte 150 sorgu sınırının olması. Yazdığım kod bu API aracılığıyla her bir kullanıcının takipçilerini çekiyor ve createNode fonksiyonu ile Neo4j içinde her bir kullanıcı için bir düğüm oluşturuyor. Kullanıcıların tekrarlanmasını engellemek için Neo4j’in unique indexlerinden faydalandım. İndexlenmek istenen veri ilk kez indexleniyorsa API’nin kendisi otomatik olarak bir düğüm oluşturuyor. Aksi halde yeni düğüm oluşturulmuyor. 7474. portta çalışan bir Neo4j sunucusu olduğunu varsayan kodu aşağıda paylaşıyorum.

Mevcut kod kullanıcıların yalnızca ID’lerini çekiyor. Tüm graf oluştuktan sonra ayrı bir kodun bu ID’lere ait ayrıntıları çekip düğümleri güncellemesini planlıyorum. Böylece aynı anda en çok 100 kullanıcının ayrıntılarını döndürebilen Twitter API’sini de etkin kullanmış olacağım.

Elde bu graf olduktan sonra iki düğüm arasındaki en kısa yolu hesaplamak Neo4j ile oldukça kolay. Ayrıca graf, centrality açısından da kolayca incelenebilecektir diye tahmin ediyorum.

Tabloyu şöyle özetleyebiliriz. HashSet ve LinkedHashSet performansı birbirine oldukça yakın. Fazladan yönetilmesi gereken LinkedList sebebiyle LinkedHashSet add, remove ve contains işlevlerinde HashSet’e göre çok az da olsa kötü performans sergiliyor. Buna karşılık LinkedHashSet’in iterator performansı HashSet’e göre %30 kadar daha iyi. TreeSet ise gerçekten Set elemanlarının sıralanması istenmiyorsa yanına yaklaşılmaması gereken bir gerçekleme olarak kendini gösteriyor.

Bu sonuçlara bakarak ben varsayılan gerçekleme olarak LinkedHashSet ile yoluma devam etmeye karar verdim. Başka bir Pazar günü de senkronize olan gerçeklemelere bulaşmaya çalışacağım.

Bu arada http://implement.asyonturkcedegil.com/

Güncelleme
Ahmet A. Akın ve Mehmet D. Akın’ın önerileriyle test kodunu ve sonuç analizini güncelledim. Testleri art arda 3 kez çalıştırıp sonuçları add, remove ve contains için ayrı tablolarda gösterdim. Süreler ms cinsindendir. Denemek isterseniz Ahmet A. Akın’ın biraz daha geliştirdiği test kodu burada.

Ahmet A. Akın:

Eğer ciddi bir bellek ve performans kaygım yoksa,
- Ekleme sırası önemsiz ise HashSet
- Ekleme sırası önemli ise LinkedHashSet
- Nesnelerin doğal sıralanışı önemli ise TreeSet
gönül rahatlığı ile kullanıyorum. Yani bu durumda hızdan çok işe göre yapıyı seçmek daha makul. Özel durumlar için ise özel kütüphaneleri tercih edilebilir. Guava, muhtelif primitive collections vs.

Mikrobenchmarking’i bu devirde doğru yapmak neredeyse mümkün değil (http://www.parleys.com/#id=2103&st=5 http://wiki.jvmlangsummit.com/images/1/1d/PerformanceAnxiety2010.pdf). O nedenle kafayı küçük farklara takmamak iyidir derim. Sonuçta farklı işletim sistemleri, işlemciler ve JVM sürümleri ile testler yapılıyor.

Mehmet D. Akın:

size() metodunu olcmek cok anlamli degil cunku hepsi de sadece nesnenin icindeki size ismindeki bir integerin degerini donduruyor, rakamlardaki farklilik gürültuden ibaret.

Microbenchmarking cok ince bir is, ozellikle Java gibi JVM userinde calisan ve GC iceren bir ortamda islemci, isletim sistemi, JVM versiyonu ve daha baska bir cok etken sonuclari degistirebiliyor.

Geçenlerde Twitter’da kaynağını tam olarak bilemediğim fakat çok beğendiğim bir tweet dolaştı.

HTTP response codes for dummies. 50x: we fucked up. 40x: you fucked up. 30x: ask that dude over there. 20x: cool.

Kısmen usturuplu Türkçe çevirisi şöyle:

Zor öğrenenler için HTTP durum kodları. 50x: biz sıçtık. 40x: sen sıçtın. 30x: şu karşıdaki elemana sor. 20x: tamamdır.

HTTP durum kodları bundan daha iyi anlatılamazdı sanırım. Bu tweetten bir zaman sonra Karl Seguin‘in şu tweeti geldi. Kısaca söylediği şuydu: web servisiniz hataları neden 200 durum kodu ile döndürüyor?

Bu iki tweet RESTful Web API geliştiricileri için önemli ipuçları veriyor. Ben de kendi tecrübelerim ışığında bir RESTful Web API’nin nasıl tasarlanması gerektiğinden bahsetmeye çalışacağım. Anlatacaklarımın %100 geçerli ya da doğru olmasını beklemek büyük bir yanılgı olur. Bu sebeple bu yazıyı bir tür başlangıç noktası olarak değerlendirmenizi öneririm.

Hangi durumda hangi HTTP metodu kullanılmalı?

HTTP metodlarını kullanırken dikkat edilmesi gereken belki en önemli nokta HEAD ve GET metodlarının salt okunur olması gereğidir. Başka bir deyişle HEAD ve GET metodları ile kaynak bilgilerini güncellememeli ya da yeni kaynak oluşturmamalısınız. Yazma işleri için POST, PUT ve DELETE metodlarını kullanmalısınız. Diğer yandan PUT ve DELETE metodları idempotent metodlardır. Bu sebeple art arda çağrılmaları sorun oluşturmaz/oluşturmamalıdır.

URI’ler nasıl olmalı?

Google’da arama yaparsanız bu konuda pek çok farklı öneriye/gerçeklemeye ulaşabilirsiniz. Ben de kendi önerilerimi sıralayacağım. Wikipedia’da yapılan açıklama oldukça güzel. Benim önerilerim de bu tabloya benzer olacak.

URI’leriniz ID dışında parametre içermemeli.
Parametreleri URI içine yazdığınızda URI’leriniz yönetilemez bir hale gelecektir. Bir örnek vereyim:

GET /api/{TICKET}/{DOMAIN}/users/{ROLE}/

Bu API ile belli bir etki alanında(DOMAIN) belli bir role(ROLE) sahip olan kullanıcıların sorgulandığını varsayalım. TICKET parametresinin ise güvenlik amacılığıyla gönderilen bir anahtar olduğunu kabul edelim. Bu URI’nin istemci tarafında oluşturulması oldukça zordur. Bu sebeple ben ID parametresi dışındaki parametrelerin URI’de bulunmasını pratikte çok uygun bulmuyorum. Buna bir istisna olarak örnekteki TICKET parametresini verebilirim. Eğer TICKET parametresi her URI’de bulunacak ise (bu tür parametrelere statik parametre diyorum) bu URI’lerin istemci tarafında ortak bir kod ile oluşturulması pek zor olmayacaktır. Bunun diğer bir faydası da TICKET içermeyen istekler için doğrudan HTTP 404 döndürülebilmesine imkan sağlamasıdır. Sonuç olarak önerilerim doğrultusunda yukarıdaki URI şu hale gelmelidir.

GET /api/{TICKET}/users?domain=...&role=...

URI’lerde büyük harf kullanılmamalı.
Bu önerimin nesnel bir açıklaması yok ama genel kullanımda /dailySessions yerine /daily_sessions ya da /sessions/daily kullanımı daha düzgün ve kolay görünüyor.

Hangi durumda hangi HTTP durum kodu kullanılmalı?

Yazının başında verdiğim tweet örneği durum kodlarını oldukça iyi açıklıyor. 50x durum kodları servis sağlayıcı tarafında bir hata olduğuna, 40x durum kodları istemci tarafında bir hata olduğuna işaret ediyor. 20x durum kodları ise isteğin başarıyla sonuçladığını ifade ediyor. Bu sebeple hata mesajları asla ve asla 20x durum kodu ile gönderilmemelidir. Hata türüne uygun durum kodu seçilerek hata mesajı bu durum kodu ile istemciye gönderilmelidir. Oldukça fazla sayıda durum kodu olsa da ben 200, 400, 403, 404 ve 500 durum kodlarını yeterli buluyorum. Ama belli durumlarda diğer durum kodlarını kullanma gereği olabileceğini de aklınızdan çıkarmayın derim.

Durum kodu ile birlikte hata mesajı gönderme zorunluluğunuz bulunmasa da hata mesajı vermek API kullanıcılarının işini oldukça kolaylaştıracaktır. Bu sebeple 400, 403, 404 ve 500 durum kodları ile birlikte mutlaka hata mesajı dönmenizi öneririm.

Yanıt hangi formatta olmalı?

Yanıt için yeni bir format keşfetmenize inanın hiç gerek yok. JSON formatı hem güzel, hem parse edilmesi kolay, hem de çok fazla kütüphane desteğine sahiptir. Bu sebeple yanıtlarınızı aksi çok gerekli olmadıkça JSON formatında dönmenizi öneririm.

JSONP ve CORS

Bu iki yöntemin ayrıntılarına burada değinmeyeceğim ama geliştirdiğiniz API Javascript istemciler ile kullanılacaksa iki yönteme de destek vermeniz yerinde olacaktır.

Buraya kadar sabırla okuduğunuz için teşekkür ederim. Umarım faydalı olmuştur.

Önceleri bildirimleri saklamak için Queue kullanmayı düşündüm. Fakat yukarıda belirttiğim ihtiyaçları değerlendirince her kullanıcı için ayrı bir kuyruğa sahip olmam gerektiğini fark ettim. Her kullanıcı için ayrı bir Queue oluşturmak ve bunları yönetmek çok maliyetli olacağından ihtiyacıma en uygun veri yapısının MultiMap olduğuna kanaat getirdim. MultiMap içinde kullanacağım anahtarlar kullanıcı adına(username), değerler de bildirimlere(Notification) karşılık gelecek. Bir kullanıcı için birden fazla bildirim olabilecek.

Sonraki adımda bildirim kuyruğundaki bildirim sayısı belli bir değerin üstünde ve en eski bildirimin oluşturulma tarihi belli bir zamandan önce olan kullanıcıları en performanslı şekilde nasıl elde edebileceğimi düşündüm. Hazelcast, Map içindeki değerleri sorgulayabilmemiz için SQL benzeri bir DSL sağlıyor. Yalnız bu özellik MultiMap için geçerli değil. Bu sebeple veriyi denormalize etmeye ve kullanıcı kuyruklarına ait bilgileri(her bir kullanıcı kuyruğu için eleman sayısı ve en eski bildirim zamanı) ayrı bir Map içinde tutmaya karar verdim.

MultiMap içine yazacağım bildirimler için bir Notification sınıfı oluşturdum.

Her bir kullanıcı için kuyruk bilgilerini saklamak amacıyla oluşturduğum QueueMetaData sınıfı ise şöyle:

Daha sonra, bir ExecutorService kullanarak 6 farklı kullanıcı için 16384 adet rastgele bildirim oluşturan bir kod yazdım. Buradaki belki en önemli problem Map ve MultiMap için senkronizasyonu sağlamak idi. Hazelcast’in sağladığı anahtar bazlı lock mekanizması yaptığım testlerde sorunsuz çalıştı. Yazma işleminin ayrıntısı için aşağıdaki Producer koduna bakabilirsiniz.

Her bir Producer opCount kadar Notification oluşturmakta. Serialization için JSON kullanmaya karar verdim. Bu sebeple google-gson kütüphanesinden faydalandım. Farklı sayıda Producer ile testler yaptım. Sonuçları yazının sonunda paylaşacağım. Producer sınıfının çalışabilmesi için gerekli olan LatchWorker ve HazelcastManager sınıflarının kodları aşağıda.

Son olarak yazma işlemini Akka ile de denemeye karar verdim. Bundaki amacım hem Akka’yı öğrenmek, hem de performansını ExecutorService ile karşılaştırmaktı. Producer sınıfına benzer şekilde bir Producer aktörü yazdım.

Producer aktörlerini yönetmek için yazdığım Master aktörü aşağıda. Bu aktörün görevi belirtilen sayıda Producer oluşturarak bunların opCount kadar Notification oluşturmalarını sağlamak.

16384 adet bildirim için farklı thread/actor sayıları ile Akka ve ExecutorService yöntemlerini karşılaştırdım ve işlem sürelerini ölçtüm. Süreler µs(1/1000ms) cinsindendir. Sonuçlar aşağıdaki tabloda yer almakta.

Eğer bariz bir hata yapmıyorsam Akka yöntemi hem yönetim hem de performans açısından ExecutorService yöntemine göre daha önde. Hata bildirimi/öneri için yorumlarınızı beklemekteyim.

Anlatmaya çalışacağım örnek iki ayrı uygulamadan oluşmakta. İlk uygulama bir REST API sağlayıcı olmakla birlikte kullanıcı oluşturan ve kullanıcı ayrıntılarını döndüren iki API sağlıyor olacak. Diğer uygulama ise ilk uygulamanın sağladığı API’leri kullanacak. İlk uygulamaya “Provider“, ikinci uygulamaya “Client” diyeceğim.

Önce Provider içinde kullanıcıları saklamak üzere User modelini oluşturarak işe başlayalım.

Sonrasında kullanıcı oluşturmaya ve istenilen kullanıcının ayrıntılarını döndürmeye yarayan API fonksiyonlarını yazalım. Bu fonksiyonlar Provider uygulamasında Provider controller’ı içinde yer alsınlar.

routes dosyasını güncelleyerek yazdığımız API’ler için HTTP route’ları belirleyelim.

GET     /api/user                               Provider.getUser
POST    /api/user                               Provider.createUser

Dikkat edeceğiniz üzere iki API için de aynı route’u kullanacağız. Hangi API’ye ulaşmak istendiği ayrımını HTTP metodu(GET ya da POST) ile yapıyoruz.

Provider uygulamasını böylece tamamlamış olduk. Client uygulamasına HTTP metodlarını içeren bir enum ekleyerek devam edelim. Bu enum yapacağımız API isteklerini yönetmemizi kolaylaştıracak. Provider içine eklediğimiz User modelinin bir benzerini Client uygulamasına da eklememiz gerekiyor. Fakat bu kez JPA annotation’larına ihtiyacımız olmayacak çünkü kullanıcıları Client uygulamasında veritabanına kaydetmeyeceğiz.

Sırada Client uygulamasının kalbi ClientJob ve Client sınıfları var.

Provider uygulamasını http://localhost:9001 adresinde çalıştırıyoruz. ClientJob sınıfı Provider uygulamasına HTTP isteğini yaptıktan sonra sonucu Either içerisinde döndürüyor. Böylece dönen cevap ya bir Throwable ya da bir User oluyor. Client uygulamasındaki fonksiyonlar geriye Promise döndürüyorlar. Dönen Promise herhangi bir controller içerisinde await fonksiyonuna verilebilir. Örnek olarak Client uygulamasında Application.index içerisinde bu fonksiyonları kullanalım. Önce bir kullanıcı oluşturalım, sonra bu kullanıcının ayrıntılarını isteyelim.

Çıktıda şu logu göreceğiz.

INFO  ~ Kullanıcı oluşturuldu: name:Foo surname:Bar

Örneği oldukça basit tutmaya çalıştım. Ancak 4Primes bünyesinde geliştirmekte olduğumuz KURAM(*) platformu da çok benzer bir yapı kullanmakta. Bu yapının oldukça karmaşık ve büyük ölçekli ortamlarda sorunsuz çalıştığını da belirtmek isterim. Umarım faydalı olmuştur.

(*): KURAM platformu bir tür Tümleşik Yönetim Bilgi Sistemi Platformu’dur. SSO, Kullanıcı ve Yetki yönetimi, Doküman Yönetimi, Log Yönetimi, Dağıtık Arama, Dağıtık Önbellek gibi özellikler sunmaktadır. KURAM hakkında yakın zamanda güzel yazılar yazabilmeyi umuyorum.

OS:        Mac OS X Lion 10.7.3
İşlemci:   2.4 GHz Intel Core 2 Duo
Bellek:    4 GB 1067 MHz DDR3
Memcached: 1.4.13
Redis:     2.4.8
Hazelcast: 2.0.1

Memcached testi için spymemcached, Redis testi için Jedis, Hazelcast testi için Hazelcast Native Java Client kütüphanelerini kullandım.

Uyguladığım testte üç ürüne de 16 byte uzunluğunda bir String’i 131072 kez yazıp okudum ve geçen süreyi ölçtüm. Aynı testi her ürün için 1, 2, 4, 8, 16, 32, 64 ve 128 thread ile tekrarladım. Ürünleri ayrı bir sunucuda değil yine kendi makinamda çalıştırdım. Başka bir deyişle test uygulaması ve ürünler aynı makinada çalıştılar. Hazelcast için yaptığım testi Memcached istemcisi ve Hazelcast Java istemcisi ile tekrarladım. Aslına bakılırsa sonuçlar üç ürün için de tatmin edici oldu. Yorumlamadan önce sonuçları paylaşayım. Süreler µs(1/1000ms) cinsindendir.

Genel görünümde Redis’in thread sayısından bağımsız olarak aynı performansı sürdürdüğünü görebiliyoruz. Thread sayısı arttıkça Hazelcast performansındaki artışa dikkat etmek gerek. Talip Ozturk ve Fuad Malikov çok iyi iş çıkarmışlar. Native Java Client ile Hazelcast’in 32, 64 ve 128 thread sayısındaki performansının üstüne çıkabilen yalnızca 8, 16 ve 32 thread sayısında Memcached oldu. Testin başlangıcında ürünler arasında en az özelliğe sahip olan Memcached performansının çok daha üstün olmasını bekliyordum. Memcached’in ortalama performansı üstün olsa da yoğun concurrent ortamlarda zirvenin sahibi Hazelcast olarak görünüyor. Redis de güçlü özellikleri, performansı ve kararlılığı ile kendini gösteriyor.

Testi tekrarlamak isteyenler için kodları aşağıda paylaşıyorum. Yaptığım testteki eksikleri/hataları yorum olarak bekliyorum.

1. Okuyucuların sizi daha iyi tanıması adına kendinizi kısaca tanıtır mısınız?

Merhaba. Adım Bora Gönül, 1974 doğumluyum. Yazılımla ilgilenmeye ortaokul yıllarında Commodore-64 ve Amiga oyun introlarını kırıp kendi adımı yazmak niyetiyle başladım. Daha sonra İTÜ Elektronik ve Haberleşme Bölümü’nde okudum. Buna paralel çalışmaya başladım. Yaklaşık 17 senedir İstanbul’da IT sektorundeyim. Pek çok yerli ve yabancı firmada çalıştım. Şu anda da Software & Solutions Architect olarak freelance çalışıyorum.

2. Fonksiyonel programlama dilleri aslında çok uzun zamandır ortalardalar. Siz ne kadar zamandır fonksiyonel programlama dilleri ile ilgileniyorsunuz?

Yazılım benim hem işim, hem hobim. Bu yüzden birçok farklı dilde uygulama geliştirdim. Imperative dil olarak Java, fonksiyonel programlama dilleri olarak Scala, Haskell, Erlang ve Javascript favorilerim. Bu tanışıklığımız da yaklaşık 15 sene önce Haskell ile başladı.

3. Fonksiyonel programlama dillerine olan ilginizin sebebi nedir?

Bu biraz matematiğe olan sevgimle ilgili. Ortaokulda okuduğum ilk kitapta gördüğüm “X=X+1″ beni o kadar rahatsız etmişti ki ( 0=1 ?) kitabı hemen kapatmıştım. Sonra merakım ve arayışım devam etti. Üniversitenin ilk yıllarında Haskell ile tanıştım. Matematiği kullanabileceğim bir yazılım dili bulmak benim için heyecan vericiydi.

4. Fonksiyonel dillerin diğer dillere(nesne yönelimli, mantıksal, prosedürel) kıyasla temel avantajları nelerdir? Bu dillerin günümüzdeki kullanım alanları hakkında bilgi verebilir misiniz?

Oldukça derin bir soru oldu. En temel fark şu:
– Imperative dillerde (C, Java, vs) sonuç odaklıyız; değişkenler tutup onları güncelleyerek sonuca ulaşıyoruz.
– Applicative dillerde (Scala, Haskell vs) olayın kendisini ifade etmek için hesaplamalara (sonuçlara değil!) odaklanıyoruz.

Şimdi sorsanız kimse fonksiyonel bir dil bilmediğini söyleyecek, halbuki her gün kullandığınız fonksiyonel bir dil var: “Javascript” JS’deki “fonksiyon alan fonksiyonlar, fonksiyon dönen fonksiyonlar, closure’lar, callback’ler, vs.” ne kadar güçlüler bir düşünün.

Diğer bir önemli fark FP(Fonksiyonel Programlama) dillerinde State olmaması. “Y=X+1″. İşte bu, benim bildiğim matematik…

Bir başka artısı paralel programlama konusunda. Bir örnek vereyim: Yazdığımız kod kendi makinamızda çalışır ama production ortamında aynı şekilde çalışmaz (Benim makinamda çalışıyor sendromu). Peki bunun sebebi nedir? Determinism = State * Parallelism. Bizse non-deterministik; çalışması ortama bağlı olarak değişmeyen kod istiyoruz.

Nasıl yapacağız?
- Parallelism istenen bir şey olduğuna göre State’i ortadan kaldıracağız. Bu konuyu okurlara bırakıyorum, başka bir sohbette detaylarını anlatırım.

Bir başka önemli katkı olarak applicative dillerde business logic kodun içinde kaybolmaz. Örnek:

Java


Scala


Peki neden şimdi FP? FP esasında yeni bir şey değil. Ama bildiğiniz gibi Moore yasası doyuma ulaştı. Çekirdeklere daha fazla transistor sığdıramıyoruz. Bunun yerine çekirdek sayısını arttırıyoruz. Amacımız da bu çekirdekleri daha iyi kullanmamızı sağlayacak dilleri bulmak. FP dillerde state olmadığı için multicore’dan verim almak daha kolay. Elbette ki sürekli değişken yaratmanın yan etkileri var(bellek açısından) ama kullandığımız makinalarda en az 4GB RAM var. Bu konu dediğim gibi oldukça derin. Umarım cevabım biraz tatmin etmiştir sizi. Özetle FP yeni değil, eski ve değerli. Her alanda kullanılabilir. Web programlamadan, data mining ya da real-time sistemlere kadar…

5. Scala, fonksiyonel programlama dillerinin en popülerlerinden biri olmakla beraber prosedürel ve nesne yönelimli programlama özelliklerini bir arada barındıran C++ diline benzer şekilde nesne yönelimli ve fonksiyonel programlama özelliklerini birlikte sunuyor. C++ oldukça başarılı olsa da hiçbir zaman prosedürel bir dil olan C dilinin önüne geçemedi. Nesne yönelimli diller konusunda zirvenin sahibi ise Java oldu. Sizce Scala bu bilgiler ışığında başarılı olabilecek mi?

Object oriented programlamanın avantajı insan zihninin bir sorun karşısında olayı küçük
parçalara ayırıp; detayları tek tek çözüp, sonrasında bunları birleştirebilme yeteneğini simgeliyor olması. Örnek olarak bir film sahnesinde cam ekran üzerinde aktörün bir treni tutup pek çok küçük parçaya böldüğünü ve sonra birleştirdiğini hayal edin.

FP ise apayrı bir dünya. Bildiğiniz tüm tasarım kalıplarını bir kenara koyun, bir de fonksiyonlar ve recursion(özyineleme) ile yapabileceklerinizi.

Bir soru: bana “while” control structure’ının kendisini OO bir dilde gerçekleyebilir misiniz? Scala’da gayet basit:

Şu kodda bile High-Order Fonksiyonlar, Currying gibi kavramlar var ve bunlar applicative(kendini anlatıyor). Kısaca Scala ya da FP bir rakip değil aksine bir tamamlayıcı.

6. Scala hakkında son zamanlarda, özellikle çok karmaşık olduğuna dair olumsuz yorumlar yayınlanıyor. Hatta bu yorumlar adeta bir karalama kampanyasına dönüşmüş durumda. Sizce yapılan yorumlarda doğruluk payı var mı? Scala gerçekten çok mu karmaşık?

Evet Scala zor bir dil çünkü:

- FP lisedeki biri için kolay, imperative dil bilen (Java, C vs) biri için çok zor.
- Type oriented programming (Varyans, Covariant, Contravariant) karışık.
- Implicit conversionlar ilginç.

Sanki bu yeni bir gezegen bulmak gibi, keşfetmek için biraz zaman gerekiyor. Ama tadını alınca dünyaya geri dönmek istemiyorsunuz. Bir diğer problemse bu dünyada yalnız kalıyorsunuz. Bu açıdan eleştirilere katılıyorum. Düşünsenize ben kime, nasıl Scala anlatacağım, öğreteceğim ve birlikte ortak bir proje yapacağız?

7. Sizce Türkiye’de gerek üniversiteler, gerekse kurumlar ve şirketler açısından fonksiyonel programlama dillerine gereken ilgi gösteriliyor mu?

Kesinlikle hayır Pek çok üniversitede Scala ile ilgili seminerler verdim. Hocalarımızın çoğu dahil FP ne demek Türkiye’de bilinmiyor. Tüm gençlere aynı şeyi söyledim. Yurt dışında çalışmak mı istiyorsunuz? En az bir FP dili öğrenin.

8. Türkiye’de bilişim sektöründe fonksiyonel dillerin payı ne orandadır? Bu konuda kendini geliştiren bir üniversite öğrencisinin sektörde kendine yer bulma şansı nedir?

Şu anda Türkiye’de odaklanılan konu Web + DB programcılığı. Henüz hatırı sayılır real-time yazılımlarımız bile yok.

İki örnek;
- Uçakların inmesini kalkmasını sağlayan, sensor verilerini toplayan merkezi bir real-time sistem. FP ve Message Passing Concurrency (Erlang / Akka) için biçilmiş kaftan.
- Kredi kartı alışverişi real-time data mining. Kim hangi sektörde ne oranda kredi kartı kullanıyor. Yine FP ve Data-Mining/Data-Flow için ideal.

Bu konuda gençler Türkiye’yi değil yurtdışını düşünsün. Orada Haskell, Erlang ve Scala çok aranıyor.

Bir de söyle bir yanlış anlama var. Genişleme daha çok makina demek değil. Aynı makinadan daha iyi verim almak demek. FP’ye bir de bu gözle bakmak lazım.

9. Nesne yönelimli programlama dillerinden birine yeterince hakim bir geliştirici fonksiyonel programlama dillerinden birinde sizce ne kadar zamanda yeterli hale gelebilir?

Hiç gelemeyebilir. İkisi apayrı, iki farklı dünya. Biri makinaların dünyası(Java, C altında assembly), diğeri matematiğin, kümelerin, monad, monoidlerin dünyası.

10. Türkiye’de Scala eğitimi verdiğini bildiğiniz üniversiteler ya da kurslar var mı? Sizin bu konuda çalışmalarınız oluyor mu?

Ben Scala ve FP eğitimi vermeyi çok istiyorum. Ama henüz böyle bir oluşuma ihtiyaç yokmuş gibi görünüyor. Keşke olsa…

11. Play! Framework 2.0 çekirdeği radikal bir şekilde değiştirilerek Scala ile yeniden yazıldı. Bu konuda yorum yapmak ister misiniz?

Evet Play!, Scala ile yeniden yazıldı. Nedenlerini sitesinde bulabilirsiniz. Yukarıda saydığım tüm nedenler orda var. Ayrıca FP ile yazılan kod çok daha basit ve elegant(asil) oluyor. Ne demek istediğimi FP yazınca anlayacaksınız.

Play şu anda TypeSafe’e katıldı. Martin ve ekibi bu konuda çok iyi yoldalar. Özellikle Akka çok doğru bir şekilde Erlang temellerini Scala’da implement etti. 2000′li yıllarda Spring bir gün defakto standard olacak dediğimde kimse inanmamıştı, bugün herkes CV’sine Spring yazıyor. Aynı şekilde Akka(Message Passing Concurrency), concurrent programlama için defakto standart olacak diye düşünüyorum. Lütfen kayıtlara geçin

12. Son olarak eklemek istediğiniz noktalar var mı?

Ne yazık ki FP ya da Scala’yı Türkiye’de kullanırız diyemeyeceğim. Startup olgusu keşke bizde de oluşsa ve düşük maliyetli, cloud üzerinde çalışan Internet tabanlı uygulamaların sayısı artsa. Oyun sunucuları, bankacılık, sigorta sektorü, realtime engine’ler… Bunların hepsi için doğru adres FP, Scala ve Erlang.

Teşekkürler.

Güncelleme (11 Mart 2011)
Play! Framework Türkiye Google Grubu‘nda Ahmet Alp Balkan şöyle bir yorumda bulunmuş. Buraya da not düşmek istedim.

Bir noktada serializable alan metoda kabul ettirmek icin ArrayList olarak degistirmissiniz List olan bir variable’i. Neyin gelmedigini bilmediginiz durumlarda (ornegin JPA cogu metodu List donduruyor ama tipi soylemeyebiliyor, bu yuzden ArrayList yazamayabilirsiniz bu ornekteki gibi), butun list’leri (Serializable)’a guvenle cast edebilirsiniz, tum standard API List implementasyonlari serializable oldugu icin.

Play! Framework Türkiye mail listesinde konuyu tartışırken CacheManager sınıfını daha da iyileştirdik.

Controller içerisinden istatistiklere erişmek için aşağıdaki kod yeterli oluyor.

Dosya boyutlarının oldukça fazla olduğundan bahsetmiştim. Bu durumda kullanıcıların indirme işlemine herhangi bir sebeple oluşan kesintinin ardından kaldıkları yerden devam etmeleri büyük önem kazanıyor. Flashget ya da DownThemAll! gibi indirme yöneticileri kullanıcılarına bu imkanı veriyorlar. Fakat söz konusu süreç yalnızca istemci tarafında bitmiyor. Eğer web sunucu bu desteği vermiyorsa durdur/sürdür(pause/resume) işlemi gerçekleşemiyor. Bu işlem için HTTP protokolünün Range başlığı kullanılıyor. Ayrıca sunucunun istemciye Range başlığını kabul ettiğini belirtmek için Accept-Ranges başlığını göndermesi gerekiyor. Aslında tüm bu süreç hem Apache HTTP server hem de Netty server tarafından destekleniyor. Fakat dosyaları statik sunmadığınız zaman durum ne yazık ki değişiyor.

Play! Framework ile gelen renderBinary() metodu binary dosyaları istemciye gönderebilmeniz için hem yalın hem de çok kullanışlı bir özellik olsa da Range başlığı desteği sunmuyor. Konu üzerinde biraz araştırma yaptığımda kuyrukta bekleyen bir pull isteğine rastladım. Söz konusu yama renderBinary metoduna Range başlığı desteği ekliyor. Ancak yama henüz kuyrukta olduğundan en erken bir sonraki Play! Framework sürümüne dahil edilecek.

Durum böyle olunca kendi başımın çaresine bakmak durumunda kaldım. HTTP protokolüne uygun şekilde bir gerçekleme yaptım ve DownThemAll! ile başarılı sonuç aldım. Böylece kullanıcılarım birden fazla thread ile dosya indirme ve indirmeyi durdurup sürdürme imkanına kavuştular. Gereken kodları içeren bir gist hazırladım. Aşağıda paylaşıyorum.