Bahattin Çiniç

Trust in yourself! You can do it!

[bahattincinic]

AngularJS İle Çoklu Dil İçeren Uygulamalar Geliştirmek

İki hafta önce AngularJs Bootcamp de bu konu hakkında bir sunumum vardı. Sunumda sahnenin verdiği heyecandan dolayı atladığım şeyler olmuştur diye bu konuyu bir blog yazısında toplamanın iyi olabiliceğini düşündüm.

Konuya başlamadan önce bootcamp hakkındaki düşüncelerimi belirtmek istiyorum. Organizasyon sorunsuz ve sıfır aksama ile tamamlandı. Sunumlar arası oluşan aksamanın hiç olmadığı nadir etkinliklerden biri. 2 gün süren dolu dolu bir etkinlikti diyebilirim. Umarım böyle etkinliklerin sayısı gittikçe artar.

Gelelim konumuza;

internationalization (Uluslararasılaştırma) Nedir ? Tek sistemde birden fazla dil desteği vermeyi genel olarak Türkçe karşılığı uluslararasılaştırmak olan internationalization terimi ile adlandırıyorlar. Söylenmesi bile zor olan ve baya uzun olan bu kelimeyi i18n olarak kısaltmışlar. (i + 18 harf + n)

Localization (Yerelleştirme) Nedir ? Sorunumuz sadece bir sistemde dili çevirmekle bitmiyor. Tarih, zaman, para birimi, ısı birimleri ve bu tarz şeyleri de dille göre çevirilmesi gerekiyor. Bu işin kapsamı da Türkçe karşılığı yerelleştirmek olan Localization içinde yer alıyor. i18n gibi Localization kelimesini de l10n şeklinde kısaltmışlar.

Bu iki durumu da tamamladığımıza ürünümüz küreselleşmiş oluyor. Bu kavrama da Globalization diyorlar.

Dil Paketlerini isimlendirmek Sistemimizde birden fazla dil var. Her şey iyi güzel. Fakat dillerin birbirinden kolay ayırt edilebilmesi için bu isimlendirmenin belli bir standarta göre olması gerekiyor. Standarta uymanın artılarından biri ise herkes tarafından kabul görmüş ürünlerden dil bilgisi aldığınızda yine bu standart da olacağıdır. Örneğin kullanıcı ilk defa siteye girdiğinde kullandığı tarayıcının dilini varsayılan olarak gelmesini istiyorsunuz. navigator.language ile bu bilgiye eriştiniz. Kendi dilleriniz ile eşleştirmeniz gerekiyor. Eğer isimlendirmeniz bu standart da değil ise başlıyorsunuz ifleri yazmaya. Bu gibi sebeplerden dolayı kabul görmüş standartları kullanmak bence her zaman bir artısı vardır.

İsimlendirmeler Ülke + Bölge şeklinde yapılıyor. Örnek isimlendirmeler:

en_US (English US)

en_GB (English UK)

tr_TR (Türkiye)

Bu zamana kadar bu işleri nasıl yapıyorduk ? Herhangi bir Backend dilinin kullandığı template engine yardımı ile render ediyorduk. Örneğin gettext çok kullanılıyor. Bu şekilde herşey güllük gülistanlık gidiyorken neden client tarafında bu işlemi yapayım kı diyenleriniz oluyordur muhakkak. Burada da işin içine SPA lar (single page app.) giriyor. Sayfalar arası geçiş sayfa yüklenmeden yapılıyorken neden sadece dil değişimi için sayfayı yükleyelim ki. Sayfayı yenilediğimizde hem sayfanın tekrardan yüklenmesi hemde yüklendiği ara sizin client tarafında cachelediğiniz verinin gitmesi demek oluyor. Ekstra olarak bu tek sayfa uygulamayı geliştiriyorken bir framework kullanıyorsanız ve templatelerinizi farklı sayfalara parçaladıysanız o template leri render ederken de yine backend den render etmeniz gerekicek. Gittikçe karmaşık bir hale gidiyor.

Client tarafında çözüm üretmek ne kazandırıcak ? - SPA larda anlık dil değişimi. - Anlık oluşan olaylar kullanıcılar üzerinde bence güzel bir hissiyat bırakıyor. - Eğer işin fantezisine girerseniz şöyle bir şeyde yapabilirsiniz. Çeviri dosyalarınızı Firebase, Parse veya kendi yazdığınız bir WebSocket den serve ederseniz dil dosyasında herhangi bir değişim olduğu anda kullanıcı sayfayı yenilemeden onun ekranında bu işlemi yansıtabilirsiniz. - PO veya MO gibi uzantılar yerine JSON gibi temiz, okunaklı bir format da tutmuş oluyorsunuz. (Client de çözüm üretince illa bir JSON dosyasında tutacağınız anlamına da gelmiyor. Çeviri dosyalarını bir servisten de çekebilirsiniz. Bu gibi durumlar genelde sistem sahibinin kendi yönetim panelinden yeni dil ekleme çıkartma yapması durumlarında oluşuyor.)

AngularJS ile bir bakış. AngularJs ile Javascript kodundan çeviri işlemlerini oldukça başarılı bir şekilde ayırabiliyoruz. Aynı zamanda tarih zaman gibi şeylerin dille göre çevirimi çok pratik. Fakat AngularJS içinde dile göre içerik değişimi hakkında bir desteği yok. Ya bunu kendiniz yazmanız lazım yada bir paket tercih etmeniz lazım.

AngularJS tarih, zaman, para birimi gibi işlemleri dille göre çevirim yapan kısmı core kodundan ayrılmış durumda. Varsayılan olarak sadece ingilizce dile destek veriyor. Diğer diller için kullanmak istiyorsanız bower veya npm gibi bir paket yönetici ile bu paketi kurmanız gerekiyor.

$ bower install angular-i18n

Para Birimi, Tarih Çevirimleri

https://gist.github.com/bahattincinic/437e5b267ef2749d37d2

Kullanımı bu kadar basit. Sadece kullandığımız verinin tipini AngularJs e söylememiz yetiyor.

AngularJS deki Popüler İ18N Paketleri - github.com/rubenv/angular-gettext - github.com/angular-translate/angular-translate

i18n için bence en güzel AngularJS paketi diyebilirim. Çok esnek olması ve özelleştirilebilir olması ise en büyük artısı. Bu paketi geliştiren Pascal Precht yakın bir zamanda düzenlenen JSist konferansında sunum da yapmıştı.

Kurulum için:

$ bower install angular-translate

Basit bir örnek uygulama yapalım;

https://gist.github.com/bahattincinic/75ecfc470e136400dacf

Yukarıdaki örneği biraz inceleyelim. $translateProvider angular-translate paketi ile gelen özellikleri özelleştirebilmemizi sağlıyor. Örnekte çevirileri direk kod içerisinde olduğunu görüyoruz. key ve o keye karsılık gelen value lar şeklinde. angular-translate varsayılan olarak bu şekilde çalışıyor. Fakat size bunun dışında 3 tane daha yöntem sunuyor. Bunları da paketler haline getirmişler. Bu yöntemler şunlar;

- Çeviri içeriklerini apiden çekmek:

$ bower install angular-translate-loader-url

https://gist.github.com/bahattincinic/5105603a411f34c269f7

- Çeviri içeriklerini statik olarak dosyada tutmak:

$ bower install angular-translate-loader-static-files

https://gist.github.com/bahattincinic/6f075931584243c9fecc

- Çeviri içeriklerini parçalı tutmak (Her dili tek dosyada tutmak yerine mesela bunları modüllere göre parçalamak):

$ bower install angular-translate-loader-partial

https://gist.github.com/bahattincinic/dbae67fe0c5437676069

Sunduğu yöntemler bunlar. Bunların dışında kendinize özel bir şeyler yazmanıza da imkan tanıyor. Örneğin biz çeviri içeriklerimizi firebase de tutmak istiyoruz. Bununla ilgili küçük bir örnek yapalım.

https://gist.github.com/bahattincinic/077ea9e23557ae2bc57a

Örneğimizi incelemeye kaldığımız yerden devam edelim. preferredLanguage methodu eğer kullanıcı tarafından hiçbir dil seçilmemiş ise varsayılan dil atamada kullanılıyor.

Seçilen dili daha sonra hatırlanması için angular-translate bize 2 yöntem sunuyor. 

Cookie de saklamak:

$ bower install angular-translate-storage-cookie 

https://gist.github.com/bahattincinic/4b60c277ad08c2a5efea

localStorage da saklamak:

$ bower install bower install angular-translate-storage-local

https://gist.github.com/bahattincinic/176489785c1750601e8f

Bunların dışında özel olarak kendiniz de bir şeyler yazabiliyorsunuz. Örneği incelemeye kaldığımız yerden tekrardan devam :)

Javascript tarafında dil içeriklerimizi çektik dilin hatırlanmasını yaptık. Şimdi ise bu dil çevirisi içeriklerini template tarafında kullanalım

https://gist.github.com/bahattincinic/935440525c72e1a8531e

Her zaman template de çeviri yapmak sorunumuzu çözmeyebiliyor. Javascript tarafında kullanıcının yaptığı bir işlem sonrasında vermemiz gereken uyarıyı da çevirmemiz lazım.

https://gist.github.com/bahattincinic/d700cfb4ebe0feb738ee

Dil Değiştirmek:

Dil değiştirmek için $translate servisinin use fonksiyonunu kullanıyoruz. ($translate.use()) Bu fonksiyona parametre vermezsek aktif olan dili bize veriyor. Değer verirsek o değeri eskisi ile değiştiriyor.

https://gist.github.com/bahattincinic/da5891bea0ec8de37815

$locale değişimi

İçeriklerimizi çevirdik. Dil değiştirdiğimiz zaman tarih, zaman, para birimi gibi şeylerin değişmediğini gördük. Burada şöyle bir problem çıkıyor. AngularJS dinamik olarak $locale değişimine bir destek vermiyor. Dil değiştiği zaman o anda dile ait locale js dosyasını yükleyerek genelde çözüm buluyorlar. Bu işlemi yapan güzel bir paket var.

$bower install angular-dynamic-locale

https://gist.github.com/bahattincinic/da5891bea0ec8de37815

Örnek kod hakkında bahsedecek olursak, localeLocationPattern dil değiştiği anda ilgili dilin $locale içeriklerini nereden çekiceğinizi belirtmemize yarıyor. storeKey ise tuttuğu store daki (Cookie vs.) keyini temsil ediyor. useCookieStorage ise daha sonra hatırlaması için o anki dili cookie de tutmasını söylüyoruz. tmhDynamicLocale.set methodu ise locale değiştirmeye yarıyor.

Ek Not: - Buradaki para birimi çevirisi sadece sembolsel anlamda. Kur anlamında o paranın çevirilmesi sizin sorumluluğunuzda. - HTML5 form validation kullanıyorsanız verilen uyarılar tarayıcının diline göre veriliyor. Maalesef onu değiştiremiyorsunuz.

Sunumda yaptığım Demo: https://github.com/bahattincinic/angularjs-bootcamp

Sunum Linki: https://slides.com/bahattincinic/angularjs-ile-coklu-dil-destegi-veren-web-uygulamalari-gelistirmek/

İlgili Linkler

http://angular-translate.github.io/ https://github.com/lgalfaso/angular-dynamic-locale https://github.com/angular-translate/bower-angular-translate-storage-local https://github.com/angular-translate/bower-angular-translate-storage-cookie https://github.com/angular-translate/bower-angular-translate-loader-url https://github.com/angular-translate/bower-angular-translate-loader-static-files https://github.com/angular-translate/bower-angular-translate-loader-partial

[bahattincinic]

Ödeme Sistemlerine Teorik Bakış

Geliştirdiğimiz veya geliştirmekte olduğumuz projelerde müşterimizden kredi kartı ile para tahsil etme noktasında hayatımızın bir gerçeği olan bankaların ödeme sistemleri hep karşımıza gelir. Genelde şirketlerde en fazla üzerine düşünülen bölümlerden biridir. Hatta bazı şirketler sadece ödeme sistemleri tarafında geliştirme yapan developerlar bile görebilirsiniz. Daha fazla geyip yapmadan konuyu incelemeye başlayalım. Google Analytics den edindiğim bilgilere göre uzun blog yazıları çok fazla okunmuyormuş. Bundan dolayı olabildiğinde konuyu özetlemeye çalışacağım :)

Transaction Yönetiminin verdiği güven Transaction Kısaca: Yönettiğiniz bir işlem sırasında işlem başarılı bir şekilde tamamlanmış ise işlemi tamamlar(commit) işlem sırasında bir hata oluşmuş ise o trasaction içinde tüm yapılan işlemleri geri alır (rollback)

Bu konuya örnek verebileceğimiz bir kaç senaryo üretelim. - Kredi kartınızdan para çekilmiştir ama siparişiniz oluşmamıştır. - Siparişiniz oluşmuştur, kredi kartınızdan para çekilmemiştir.

Birinci bahsettiğim konuyu ele alalım. Diyelim ki önce bankadan parayı çektik. Hemen sonrasında siparişi oluştururken siparişi veritabanına yazamadık. Yani para çekilmiş oldu fakat sipariş oluşmadı.

Diğerinde de diyelim ki banka yaptığımız isteğe cevap dönemedi. Bizde o durumu düşünmedik. Parayı çekemedik ama siparişi oluşturduk.

Peki bu gibi büyük bir problem ile karşılaşmamak için ne yapmalı ? Bankaya istek yaptık. Banka olumlu bir yanıt döndü ve bizde siparişi oluştururken hata ile karşılaştık. Bizimde tüm veritabanına yazdıklarımızı rollback yapıp kullanıcıya parasını geri iade etmemiz lazım. Bu durumda ne kullanıcının parasını çekmiş olduk. Nede veritabanımızda yarım bir kayıt oluşturmamış olduk.

Bu durumlar dışında hem siparişi oluşturmuş hemde parasını çekmiş olabiliriz. Siparişi oluşturur ve parasını çekeriz. Fakat ürünün stoklarını güncellerken deadlock yersek stoklar kayar. Üstteki şekilde çözdüğümüzde veritabanı seviyesinde rollback geleceği için stoklarında kaymasını önlemiş olacağız.

Daha sonradan başka bankalar ile entegrasyon olması muhtemel. Öncelikle bu konuyu açıklamadan önce neden birden fazla ödeme sisteminin entegre edildiğini açıklayayım. Örneğin Garanti bankası ile anlaşıp sanal posunu aldınız. Garanti bankası ile yaptığınız anlaşmaya göre banka size x taksit yapma imkanı verdi. Garanti ile alışveriş yapan kullanıcınıza taksitinizi yapıyorsunuz. Fakat Finansbank ile alışveriş yapan kullanıcınıza taksit yapamıyorsunuz. Çünkü o banka ile ayrıca anlaşmanız gerekiyor. Olay sadece bunlarla da bitmiyor tabi. Bankalar içinde örneğin Bonus kart için farklı taksitlendirme x kartı için farklı taksitlendirme verebiliyor banka. (kart numarasına göre bankaların size verdiği bin tablosundan neyi nereden çekeceğinizi bilebiliyorsunuz. Bin numarası kredi kartının ilk 6 hanesi oluyor.)

Bankalar dışında ininal, BKMExpress, Turkcell Cepte cüzdan gibi servisleri de es geçmemek lazım. :)

İleride projeniz büyüdüğünde farklı bankalara da şirketiniz taksit yapmak istediğinde yada başka bir ödeme sistemini entegre ettirmek istediklerinde  mimariyi bu gibi durumları karşılayacak bir tasarım deseni ile tasarlamadıysanız başlıyorsunuz bol bol ifleri yazmaya. Kod büyüdükçe işin içinden çıkılamaz bir hale geliyor :)

Ödemeyi her zaman senkron düşünmeyin, asenkron olduğu ödeme sistemleri de var. Kullanıcın bilgilerini size girip sizde bunu sorgulayıp parasını çektiğiniz durumlar dışında havale, kapıda ödeme gibi durumlarda var.

Form Kontrolleri ile olabildiğince veri doğruluğunu sağlamak Diyelim ki Kullanıcı tarafından Kredi kartı numarası, son kullanma tarihi ve kartın ccv numarasını aldık. Bu verilerin doğrulunu sağlamanın yöntemleri var. Ama bu verilerin kesinliğini maalesef sağlayamıyoruz.

- Kredi kartı numarasının doğrulamak için luhn algoritmasını kullanabilirsiniz. - CCV numarasının 3 haneli veya american express olup 4 haneli olabildiğini ve sayısal olması gerektiğini biliyoruz. - Son kullanma tarihi ay ve yılın da sayısal olması gerektiğini ayın minimum 1 maksimum 12 olması gerektiğini yılında şuan ki yıla eşit yada büyük olması gerektiğini biliyoruz.

Bu kontrolleri yaptığımızda bankaya gereksiz yere istek yapmamış olacağız. Tabi kredi kartı numarası geçerlidir fakat ccv numarası yanlıştır bunun doğruluk yanlışlık garantisini siz veremediğiniz için bankaya mecbur gideceksiniz. Bunun gibi bir çok durum daha var.

Bankaların Döndüğü Hataları kullanıcı tarafında bilgilendirmek. Bankadan her hata döndüğünde kredi kartı bilgileri yanlış olarak değerlendirmemek lazım. Örneğin kredi kartı limiti yetersiz, taksit durumlarında taksit yapılamayan kartlar yada yaptığınız ödeme tipini(3d..) desteklemeyebilir.

Bankaya yaptığımız tüm istekleri loglamanın ileriye dönük güvencesi. Bazı durumlar oluyor ki siz bankadan olumlu bir cevap aldınız fakat banka parayı size aktarmamış. Bu gibi durumlarda banka sizden kanıtlamanızı isteyebilir. Loglardan bunu kanıtlayabilirsiniz. Size açılan herhangi bir davada da bu loglar muhakkak işinize yarayacaktır. ChargeBack(ters ibraz) mesela. Bildiğim kadarıyla log tutmak yasal bir gereklilik. Loglamayı dosyada yapıyorsanız daha sonra parse etmesi kolay olması stajyerleriniz için daha iyi olacaktır. Genelde log parser işleri onlara verilir :) Sadece banka işlemlerinde değilde o süreçte siz beklenmeyen bir hata alırsanız da bu hata sebebini loglamanız sizin için yararlı olur. Loglarken tabi kredi kartı bilgilerini maskeleyin :)

Ödeme sisteminin konfigürasyonlarının çalışma ortamına göre (dev, test, prod, pre-prod...) düzenlenebilir olması Geliştirme ortamımız sonuçta sadece local (geliştirme ortamı) olmayacağı için banka entegrasyon bilgilerini kodun içine yazmak yerine settings gibi bir yerden çektirmek bence en güzeli. O anki çalışma ortamına göre o bilgiler oradan kolay bir şekilde değiştirilebilir.

Şirket içinde birden fazla projede ödeme işleminin olması. Şirket içinde birden fazla projede ödeme sistemi entegrasyonu olduğunda ödeme sistemi kodunun kopyalanıp o diğer koyulduğu durumlar olabiliyor. o kodun diğer projeye entegre olması için bir efor sarf ediliyor. Bir de yeni bir ödeme sistemi eklendiğinde yada bir bugfix (hata düzeltmesi) yapıldığında diğer tüm projelere uyarlanması zaman alacaktır. Zaman alması dışında çok fazla iş gücü gidiyor. Bunun birkaç çözüm üretilebilir. - Sistemin bir paket haline getirilmesi ve ilgili dilin paket yönetici ile tüm projelere kurulması. (pip, composer...) - Ödeme sisteminin bir servis yapılması ve bütün projelerin o servisi kullanması. Bana ikincisi daha sempatik geliyor.

Siz test etmeyin sistem kendini test etsin. Bence İşi baştan sıkı tutun, yazdığınız her şeyin testini yazın. İleride çok artısını göreceksiniz. Düzenleme yaptığınız bir yerin nereye etki ettiğini bilemeyebilirsiniz. Yazdığınız testler çalıştığında olay gün yüzüne çıkacaktır. (http://bahattincinic.com/post/89734051749/continuous-integration-neyin-nesi-kimin-fesi)

İlginizi çekebilecek kaynaklar - http://www.slideshare.net/hakanerdogan - http://www.odemesistemleri.org/ - https://github.com/ibrahimgunduz34/paranoia - https://eticaret.garanti.com.tr/Guvenlik/Chargeback-Ters-Ibraz-Nedir.aspx - https://en.wikipedia.org/wiki/Database_transaction - https://github.com/ozgur/php-est - http://en.wikipedia.org/wiki/Luhn_algorithm

[bahattincinic]

Continuous Integration Neyin Nesi Kimin Fesi ?

Büyük projelerde veya kurumsal şirketlerde bir hayli duyarız Continuous Integration kavramını. Neymiş ne değişmiş biraz teorik olarak konuya el atalım, sonrasında ufak bir uygulama yapalım. (Uygulanan süreçler Agile veya daha farklı proje yönetim sistemlerine göre değişebilir. Çok temel olarak konuyu ele alıcaz.)

Continuous Integration (Sürekli Entegrasyon) Nedir ? Proje üzerinde yapılan her commit ardından, tüm sistemin çalışır durumda olduğunu, yapılan değişikliğin sistemin bazı bölümlerinde hataya yol açmadığını tespit etmek için kullanılan yöntemdir. Continuous Integration un artıları     - Hatalar hızlı bir şekilde tespit edilir. (otomotize edildiği için manuel yapılan testlerden daha hızlı bir şekilde sonuç alınır.)     - tahminler yerine direk yazılım üzerinden test yapılır. (Burası bozulmadığına göre bunu kullanan diğer şurada da bir şey olmaz heralde gibi.)     - Manuel yapılan işlemleri otomotize eder ve insan faktörünün hatasını ortadan kaldırır.

Bu işlemi manuel olarak yapamıyor muyuz ? Tabikide manuel olarak yapabiliyoruz. Fakat bu işlem uzun sürdüğünden (projeyi derlemek, test ortamı için initial datayı yazmak, testleri çalıştırmak) dolayı geliştiriciye hem zaman kaybı hemde her commit ardından bu işlemi yapmayı unutabilme opsiyonu doğuyor. Bu gibi durumlarda olabildiğince az sorumluluk almak en iyisi bence. Ek olarak bu işlem asenkron olarak gerçekleştiğinden sizin için bir zaman kaybı oluşturmuyor.

Continuous Integration yapmak için temel gereksinimler:     - Sürüm kontrol sistemi kullanıyor olmak. (svn, git, mercurial...)     - Projemizi test ile geliştiriyor olmak.     - Bir Continuous Integration tool u kullanıyor olmak.

Popüler olan Continuous Integration Tool larından bazıları:     - Bamboo     - Jenkins     - Travis CI     Daha detaylı bir liste için https://en.wikipedia.org/wiki/Continuous_integration#Software

Martin Fowler bu konu hakkında ne demiş: Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significAntly reduced integration problems and allows a team to develop cohesive  software more rapidly.

Continuous Integration un Çalışma Prensibi:

Yukarıdaki resme baktığımızda Developer in yani bizim yaptığımız değişiklikleri commitlediğimizi ve remote repo ya pushladığımızı görüyoruz. Pushladığımız remote server Github, bitbucket etc. bu commiti gördüğü anda hook servisi tetikleniyor. (sadece remote serverin özelliği değil hook. Normal localde de kullandığımız git de hooklar yazabiliyoruz. Örneğin pre-commit hook gibi) Bu tetiklenme işlemi ile Continuous Integration tool unun bulunduğu sunucuya bildirim gönderiliyor. Sunucu tarafında güncel kod remote dan pull ediliyor. Daha sonra proje deploy edilip testler çalıştırılıyor. Daha sonrada Developer ve Tester lara olumlu yada olumsuz rapor gönderiliyor.

Continuous Integration hakkında bu kadar bahsettik. Şimdi Travis CI ile bir örnek yapıp blog yazımızı bitirelim.

Travis CI servisi açık kaynak uygulamalar için ücretsiz hizmet veriyor ve bir çok dil desteği de mevcut. Diyelim ki github da bir tane reponuz var. Öncelikle Travis ci ye üye olup github ile hesabını bağlamanız gerekiyor. Daha sonra önünüze bulunan repolarınızın listesi gelicek. O bölümden ilgili repoyu seçin. Buraya kadar zaten her şey butonlara tıklayarak halletik. Travis test ederken sunucusuna neler kuracağını .travis.yml dosyasından biliyor. Bu dosyanın formatı YML.

Diyelim ki bir tane Django projemiz var;

language: python python: - "2.7" # command to install dependencies install: "pip install -r requirements/production.txt" # command to run tests script: python manage.py test account snippet

Yukarıdaki gibi bir YML yazdık diyelim. Birinci satır programlama dilimiz. İkinci satır projenin test edileceği python versiyonları. Buraya birden çok versiyon yazabiliyoruz. üçüncü satırda projemizin gereksinimlerini kurmasını sağlıyoruz. Son satırda ise testlerimizi çalıştırıyoruz. illa test de çalıştırmak zorunda değiliz tabi. Çalıştırmak istemiyorsak  script: nosetests dememiz yeterli. Bunlar dışında Django projemizi birden çok versiyonda da test edebiliyoruz.

Örnek bir test detayı: https://github.com/Snippit/snippit/blob/master/.travis.yml

Gönderdiği bilgilendirme maili

[bahattincinic]

Kim Korkar REST den!

Merhabalar, Gün içerisinde orada burada api, rest api, soap, wsdl gibi kavramları duyuyoruz. Ya da geliştirdiğimiz projenin mobil uygulaması veya bir başka sebepten projenin api sinin yapılması söz konusu oluyor.  Api Nedir ? Kısaca api, herhangi bir uygulamanın belli işlevlerini diğer uygulamalarında kullanabilmesi için oluşturulmuş bi modüldür.

Bankalara ödeme sistemi entegrasyonu, kargo firmalarına kargo takip entegrasyonu gibi yerlerde SOAP entegrasyonunu çok duyarız.

SOAP (Simple Object Access Protocol - Basit Nesne Erişim Protokolü) Nedir ? SOAP (Basit Nesne Erişim Protokolü) dağıtık uygulamalarda ve web servislerinin haberleşmesinde kullanılmak üzere tasarlanan, RPC (Remote Procedure Call) modelini kullanan, istemci/sunucu mantığına dayalı bir protokoldür. Daha genel olarak SOAP, web üzerinden fonksiyonları kullanmak için geliştirilmiş bir sistemin XML tabanlı kurallar topluluğudur. SOAP ile ilgili bütün mesajlar XML formatında iletililir.

Zaten böyle bir protokol var neden rest kullanmalıyım diyebilirsiniz. Şimdi rest hakkında bir şeylerden bahsetmeye başlayalım.

REST (Representational state transfer) Nedir ?       - REST client-server iletişimiyle ilgili bir mimari.       - SOAP, RPC gibi kompleks mimarilerle sağlamak yerine, HTTP protokolü üzerinden saglamak.       - SOAP, RPC'nin aksine basit ve hafiftirler.       - Esnek olup, SOAP gibi keskin standartları yoktur.       - SOAP ile en büyük farkı, SOAP gibi bizi proxy kullanmaya, bir WSDL'e zorlamıyor olması.        - Entegre etmesi kolay.

REST İstek Tipleri Ve Anlamları

      - GET:  Veri listeleme - veri görüntülemek için kullanılır.       - POST: Veri eklemek için kullanılır.       - PUT: Veriyi Güncelleme isteği olarak kullanılır.       - PATCH: Verinin sadece bir parçasını güncellemek için kullanılır. Örneğin bir issue'nun durumunun aktiften çözüldü haline getirilmesi.       - DELETE: Veriyi silmek için kullanılır.       - OPTIONS: Bir  api urline Options isteği yapıldığında o url in hangi istekleri kabul ettiği bilgisi verilir.      Örneğin:        ...       Server: Apache/2.4.1 (Unix) OpenSSL/1.0.0g       Allow: GET,HEAD,POST,OPTIONS,TRACE       Content-Type: httpd/unix-directory       ...

Yukarıdaki resme baktığımızda Bütün rest uçlarının bir tane Resource interface inin implemente ettiğini görüyoruz. Örneğin Orders yani siparişler Resource una baktığımızda GET isteğinde sipariş listesini döndüğünü POST da yeni bir sipariş oluşturduğunu PUT isteğinin ise kullanılmadığını görüyoruz. Şöyle bir neden kullanılmadığını düşünürsek. Yukarıdaki verdiğimiz tanımlarda PUT isteğini bir Resource daki bir veriyi güncellemek için kullandığımızı belirtmiştik. Bu tanıma göre /orders api ucunda update edilecek herhangi bir sipariş yok. Bu durumda tüm siparişleri güncellemeyeceğimize göre PUT ve DELETE metodları kullanılmıyor. (istisnayi durumlar dışında. Örneğin bulk yani toplu yapılan bazı durumlardaki işlemler.)

/orders/<id> bölümünde ise durum farklı. Bu durumda hangi sipariş üzerinde işlem yaptığımız belli. PUT isteğinde hangi siparişin güncelleneceği ya da DELETE isteği ile silineceğini görüyoruz.

REST Apinin Hangi Gereksinimlerimizi Karşılıyor Olması Lazım ?

    - Versiyonlama: Yazdığınız Rest api sadece kendi içinizde değilde herhangi bir kullanıcı tarafından da kullanabilir. Örnek verecek olursak Twitter. Bu örneğe göre Api de yaptığımız herhangi bir değişiklik implementasyon da değişiklikler oluşturabilir. Burada apiyi imlemente eden siz olmadığınıza göre Apide değiştirdiğiniz şey apinizi kullanan kullanıcılar tarafından sıkıntıya sebep olacaktır. Bu gibi değişiklikler kritik değil ise toplu bir şekilde versiyon haline getirmek daha mantıklı olacaktır.

    - Sayfalama: Apimizin sağladığı verinin tamamını tek seferde vermek sisteme yük getirebilir. Örnek verecek olursak bir kullanıcının siparişler sayfası olduğunu düşünelim ve bu kullanıcının 1000 tane siparişi var. Bu veriyi tek seferde limitsiz vermek sisteme bir hayli yük bindirecektir. Bu gibi sıkıntıları önlemek için belli aralıklar ile (örneğin 20 şerli) veriyi parçalı olarak vermek en mantıklısı olacaktır.

    -  Kullanıcı Dogrulama (Authentication): Her durumda Public bir veri veriyor olmayabiliriz. Bu gibi durumlarda kullanıcıdan api üzerinden login olup o şekilde veriyi almasını istememiz gerekiyor. Örneğin kullanıcılara api üzerinden mesajlaşma geçmişlerini veriyoruz. Kullanıcı api üzerinden login olmadan hangi kullanıcının mesajlarını vereceğimizi bilemeyiz.

    - Yetkilendirme - Yetkiye Göre Kısıtlama (Authorization):  Yazdığımız api yi tek tip kullanıcı kullanmayabilir. Örneğin yazdığımız apiyi Free kullanıcıların ve Premium kullanıcıların kullandığını düşünelim. Bu kullanıcı tiplerine göre yetki kısıtları arttığını düşünelim. Bu durumda yetkilendirmeye ihtiyacımız olacaktır. Kısıtlama işi ise kullanıcının tahmini 1 dakikada yapacağı istek sayısı bellidir. Bu istekten çok fazlası yapılıyorsa muhtemelen bot veya türevi bir şey tarafından istekler yapılıyordur. Bu gibi durumların engellenmesi gerekiyor. Örneğin Twitter apisinde bu özellik mevcut. Bu özellik Rate limiting olarak geçiyor. Bu konuda detaylı bilgi için: https://dev.twitter.com/docs/rate-limiting/1.1

    - Sıralama / Filtreleme:  Apimizden sunduğumuz veriyi her zaman aynı şekilde vermeyebiliriz. Mesela E-ticaret sitemiz var ve mobil bir uygulamamız var. Ürünleri listelediğimiz yerde mobil cihaz apiye istek yapıp ürünleri çekiyor. Kullanıcı ürünleri Fiyatını büyükten küçüğe ya da stok sayısı çoktan aza ya da tam tersini sıralayabilir. Bu durumda apide sıralama özelliğinin de olması gerekiyor. Bu örnek gibi daha bir çok örnek verilebilir. Yine aynı örnek üzerinden gidersek kullanıcı telefondan sadece belli markaların ürünlerini ya da stokta olanları göster şeklinde ürünleri filtreleyebilir. Bu gibi durumlarda apimizde filtreleme özeliiğinin de olması gerekiyor. (Filtreleme/arama gibi özelliklerde api tarafında ElasticSearch ya da solr gibi SearchEngine leri kullanılarak güzel performans elde edilebilir.)

    - Doğrulama (Validation): Yazdığımız apide her zaman kayıt listeleme işlemi yapmıyor olacağız. Örneğin yazdığımız apide kullanıcı kayıt etmek için bir api uç noktası yazdığımızı düşünelim. Kullanıcı bilgilerinin tam olarak doğru girdiğini garanti edemeyiz. Kullanıcının girdiği e-mail adresi kullanılıyor ya da belli alanları eksik girmiş olabilirler. Ya da girdiği şifre beklediğimiz şifre kriterlerinden düşük olabilir. Bu gibi durumlar için gelen verinin kontrol edilmesi gerekiyor. Veri geçerli bir veri ise kullanıcı kaydetme işleminin gerçeşmeli. Genelde kullanılan programlama dilinde hangi framework kullanılıyorsa form ile pratik bir şekilde kontrol edilmesi sağlanıyor.

    - Ön Bellek (Caching): Yazdığınız api yüksek trafik alıyorsa bu gibi durumlarda aynı gelen her sorgu için veri tabanına istek yapmak yerine cache e bu veriyi yazıp veriyi buradan vermek sisteme baya bir performans katabiliyor. Bu Cacheleme yazılımsal ya da donanımsal olabiliyor. Yazılımsal olarak Redis, Memcache baya aktif kullanılıyor. Donanımsal olarak ise netscaler gibi cihazlar ile yüksek trafikteki veriler cachelenebiliyor. Bunların dışında Varnish gibi toolar ile hiç istek uygulama sunucunuza gitmeden veri cachelenebilir. (netscaler yada varnish ile apiyi cachelemeyi hiç denemedim.)

REST Neden JSON veri tipini kullanıyor ?

Yukarıda Rest ile SOAP arasındaki farklardan bahsetmiştik. SOAP imlemente etmezi zor olduğunu ve daha performanssız olduğundan bahsetmiştik. Buradaki implemente zorluğu ve performans sorununa nedenlerden biri veri tipi. JSON XML e göre daha karışık ve okuması daha zor bir veri tipidir. Diğer bir nedeni ise JSON veri tipi sadece backend değil javascript tarafında da rahat bir şekilde kullanılabiliyor. Yani yazdığımız rest apiyi javascript tarafında da aktif kullanabiliyoruz. XML e çevirme/geri çözme işlemleri JSON a göre daha zordur. XML JSON a göre kategorize bir veri yapısına sahiptir. JSON veri tipi XML e göre daha küçük bir veri tipidir.

JSON / XML veri tipi karşılaştırması için: http://xphone.me/devnotes/2011/02/json-vs-xml-part-1-data-size/

JSON / XML trendlere göre sıralama için buraya bakabilirsiniz: https://www.google.com/trends/explore?q=xml+api#q=xml,api,json api&cmpt=q

REST Apilerde Dönülen HTTP Status Kodları (Yaygın Kullanılanlar)

 200 OK: Genelde veri listeleme sonuçları 200 ile dönüş yapılır. 201 CREATED: Veri eklendiği zaman verinin kendisi ile 201 dönülüyor. 204 NO CONTENT: Veri silindiği zaman 204 dönülüyor.  400 BAD REQUEST: Genel olarak kayıt ekleme ya da güncelleme isteklerinde gönderilen veri validasyondan geçemediyse neden geçemediği hakkında bilgiyle beraber 400 http statusuyla dönülür. 403 Forbidden: Yetkiye dayalı bir işlem yapılıyorsa bu api uç noktasında işlem yapmaya çalışan kişinin bu işlemi yapmaya yetkisi yoksa 403 status kodu döndürülür. 401 Unauthorized: Api ucunuzda bu işlemi yapmak için login olmak zorunlu ise ve apiye istek yapan kullanıcı login değil ise bu http status ile cevap verilir. Örneğin kullanıcının kendi bilgilerinin güncellemesi denilebilir.  404 Not Found: Bu http status  kullanıcının istek yaptığı url yok ise ya da url deki veri geçersiz ise bu hatayı alırız. örneğin şöyle bir url miz olsun /api/v1/account/bahattincinic sondaki bölüm kullanıcı adı. Buraya sistemimizde olmayan bir kullanıcı girersek 404 alırız. 405 Method Not Allowed: Bu http status u istek yapılan api uç noktası gönderilen methodu implemente etmemiş ise bu http status unu alırız. Örneğin login olması için token verdiğimiz bir api ucumuz var ve bu uçta sadece post isteğini kabul ediyor. Kullanıcı bu api urline GET isteği yaparsa bu hatayı alır. 429 Too Many Requests: Bu http statusunu saatlik ya da dakikaklık kısıtlanan sınırdan fazla istek yaparsak bu http statusunu alırız. Örnek olarak yukarıdaki Twitter örneğini vermiştik. Bu konuyla alakalı güzel bir site :) http://ruffledcrow.com/2012/03/06/http-status-cats/ HTTP statuslarını gruplayacak olursak; Bilgilendirme - 1xx Başarılı İşlem - 2xx Yönlendirmek - 3xx Kullanıcı Taraflı hata - 4xx Server Taraflı hata - 5xx şeklinde gruplandırabiliriz. (örneğin 2xx: 2 ile başlayan http statusları) REST Api URL Yapısı Tasarlarken nelere dikkat etmeliyiz ?

     - Apinin /api gibi bir kök dizinden erişilmesi güzel olur. (bu sub domain ya da daha farklı bir şekilde de olabilir.) Bir hiyerarşi sağlanmış olur.      - URL kök dizinlerine isim verilirken çoğul dan tekile gitmesi. Örneğin /tickets/, /tickets/1  şeklinde birinci url çoğul ikincisi o çoğulun tekili şeklinde olması. Bu url tipi dışında farklı alternatiflerde üretilebilir.      - kök dizinin ilişkili olduğu dizinler kök dizinden kopmaması daha anlaşılır ve güzel olur. örneğin: /tickets/1/comments/ birinci ticket in yorumları şeklinde urlin basit ve anlaşılır olması     -  filtreleme ve sıralama işlemleri url e koymak yerine queryset koymak daha kullanışlı olur. Örneğin: /tickets/?type=1 şeklinde ticketlardan tipi 1 olan yani açık olan ticketları filtreleme işlemi çok daha pratik ve kullanışlı olmuş olur. Basit bir örnek yapacak olursak; 1 - Basit Tip GET /tickets - Ticket Listesi GET /tickets/12 - Ticket Detayı POST /tickets - Yeni Ticket Ekleme PUT /tickets/12 - Ticket Güncelleme PATCH /tickets/12 - Ticketin bir kısmını güncelleme DELETE /tickets/12 - Ticket Silme

2 - İlişkili Tip GET /tickets/12/messages - 12 id li ticket e bağlı mesajlar listesi GET /tickets/12/messages/5 - 5 id li mesajın detayı POST /tickets/12/messages - 12 id li ticket e mesaj ekleme PUT /tickets/12/messages/5 - Mesaj güncelleme PATCH /tickets/12/messages/5 - Mesajın belli bir kısmını güncelleme DELETE /tickets/12/messages/5 -5 id li mesajı silme 3 - Filtreleme, Sıralama, Sayfalama GET /tickets?sort=-created_at&page=1 - Ticketları Eklenme tarihini büyükten küçüge sıralama işlemi ve birinci sayfa verisini getir GET /tickets?type=1&sort=-created_at - Ticketları Eklenme tarihini büyükten küçüğe sıralama işlemi ve tipi 1 olan ticketlar GET /tickets?fields=id,subject,customer_name,updated_at&type=1&sort=-updated_at - Sadece belli fiedleri ve tipi 1 olan son güncelleme tarihine göre büyükten küçüğe sıralama

  REST Apilerin Döndüğü İçerik Tipleri Yazdığımız api ucu eğer listeleme ile alakalı bir şey ise döndüğümüz response içine toplam veri sayısı (sizin için çok maliyeti yoksa. Milyar tane kayıt olan tablolarda bu toplam sayıyı vermek çok kolay olmuyor :)) bir sonraki ya da bir önceki sayfa var mı, ve datanın kendisini vermek baya güzel olur.  Örneğin:

{ "count": 2, "next": null, "previous": null, "data": [ { "id": 1, "subject": “Sipariş İptali Hakkında”, "url": "/ticker/1/", "type": 2, }, { "id": 2, "subject": “Siteye Erişemiyorum”, "url": "/ticket/2/", "type": "1" } ] }

Veri listelemek yerine veri eklemek ya da güncelleme durumu var ise işlem başarılı değil ise işlemin başarılı olmadığının nedenlerinin response olarak dönmemiz iyi olur. Hata tiplerini bir kod ile gruplamak  hata takibini kolaylaştırır. Örneğin:

{ "code" : 1024, "message" : "Validation Failed", "errors" : [ { "field" : "type", "message" : "Ticket Type Invalid" }, { "field" : "subject", "message" : "Ticket Subject Empty" } ] }

REST Api'nin Versiyonlanmasi Rest apinin versiyonlama yapılması öneminden bahsetmiştik üst bölümde. Şimdi ise api uç noktasında nasıl şekillerde bulunabileceklerinden bahsedelim. /api/v1/messages şeklinde resource dan önce olabilir. /api/messages?v=1 şeklinde queryset içinde de olabilir. ikinci url tipi kullanılırsa ve hiç versiyon belirtilmez ise yani /api/messages şeklinde yani (birinci tipte belirtilmezse büyük ihtimal urli api resourceniz çözemeyecek ve 404 gibi bir uyarı alacaksınız.) otomatik olarak son versiyona 301 ya da 302 ile yönlendirebilirsiniz. 

Authentication - Kimlik Doğrulaması     - Bu istek kimlik doğrulama veya oturuma bağlı olarak doğrulama yapılması gerekmektedir. Her istek bir tür kimlik doğrulama bilgileri  ile gelmelidir.     - Her zaman SSL kullanarak kimlik doğrulama bilgilerinin gönderilmesi en doğrusudur.     - Kullanıcının erişimi yoksa “401 Unauthorized status code” hata kodu ile dönüş yapılabilir.     - Bu bilgileri “HTTP Basic Auth” ile Kullanıcı bilgileri gönderilip bu bilgilerin temsili bir güvenlik kodu ile erişim basitleştirilebilir.     - OAuth ile üçüncü bir şahsa güvenli şifre aktarımı ve doğrulanması için kullanılması en doğrusudur.      - Kimlik Doğrulama yoksa Kullanıcı için api sınırlaması imkansız bir duruma gelecektir. (Authentication dışında kullanıcıyı kısıtlamanın yolu ip kısıtı olabilir. ip de değiştirebilir bir şey olduğu için bu kısıt rahatlıkla aşılabilir)

SSL everywhere - all the time (Her Yerde SSL, Her zaman)     - Her zaman SSL Kullanın. Web Apilere her yerden( İnternet cafe, kütüphane, restoran...) erişebilirsiniz. Giden veriler şifrelenmediği için verilerin dinlenmesi ve çalınması kolaydır.      - Garantili Şifreleme, Şifreli iletişim Kolaylığı     - SSL kullanmazsanız, her api istegini imzalamak zorunda kalırsınız. Buda erişimi zorlaştırır.     - SSL olmayan erişimlerle otomatik yönlendirmek yerine Bir header kodu ile hata verilebilir.

OAuth (Authentication - Authorization)     - Platform bağımsız bir şekilde oturum tabanlı olarak kullanıcının izin verildigi bilgilere ulaşılmasını sağlayan kimlik doğrulama protokolüdür.     - Yahoo, Google, Twitter kullanan şirketlerden bazıları.     - Versiyonları 1.0, 1.0a, 2.0     - Programlama dillerinin bir çoğunun provider leri mevcut  OAuth ile Authentication yapılırken gereken parametreler ve gelişen süreçler şu şekilde (implementasyonda versiyondan versiyona değişen şeyler olabilir):

POST /oauth2/access_token client_id: Apiyi kullanacak kullanıcı kimliği içeren bilgi client_secret Kullanıcı Kodu (Benzersiz) username: kullanıcı adı password: Şifre 

curl -X POST -d "client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=password&username=YOUR_USERNAME&password=YOUR_PASSWORD" http://localhost:8000/oauth2/access_token/

Yukarıdaki gibi bir istek yaptığımızda bize aşağıdaki gibi bir sonuç dönücektir.

{"access_token": "", "scope": "read", "expires_in": 86399, "refresh_token": ""}

access_token: işlem yapmamızı sağlayan Key. Bu keyi her yaptığımız istekte göndericez.  Scope: Yetki düzeyimiz. expires_in: Keyin Süresinin bitmesine kalan saniye refresh_token: access_token Keyimizin Expire süresini uzatmak için gerekli olan key

OAuth u güvenli yapan nokta her istekte bir şifre gönderilmemiş olması. Mesela basic Auth da her istekte şifre gönderiliyor ama OAuth da token iniz expire olmadıksa ve yenileme tokeniniz de expire olmadıkça oturumunuzu yenileyebiliyorsunuz.

Api Kısıtlaması Yukarıda api kısıtlama yapılmasının önemi ve nedeninden bahsetmiştik. Şimdi işi biraz daha detaylandırıp api entegrasyonunda dönülmesi gereken parametrelerden bahsedelim.

 Sınır kullanımını içeren bilgiler X-Rate-Limit-Limit - izin verilen istek sayısı  X-Rate-Limit-Remaining - kalan istek sayısı X-Rate-Limit-Reset - Kalan saniye sayısı

Neden  X-Rate-Limit-Reset saniye ? - Saat dilimi de faydalı fakat saat dilimi de gereksiz bilgiler içerir. - Api kullanıcısı gerçekten sadece ve saniye olarak kendi ucunda minimum istek ile bu isteği ne kadar ve ne aralıkla yapacağını daha kolay hesaplayabilir. - Ülkeden ülkeye saat sapması farkı önlenmiş olur

 Yazdığımız Api'nin Dönümantasyonunu Hazırlamak

Hazırladığımız api dokümantasyonu bu apiyi entegre edecek kişi için şu soruları cevaplıyor niteliğinde olmalıdır. - Mimari hakkında bilgi edinmeliyim. - Apiyi entegre edecek örnek uygulamalar olmalı ve izlenecek yollar belirtilmeli. - Verilen örnekler basit ve anlaşılır olmalı. Sonuçta bu apiyi entegre edecek herkesin bilgi düzeyi çok iyi olmayabilir. - Apilerin aldığı parametrelerin belirtilmesi ve bu parametrelerin yanlış ya da eksik verildiğinde api'nin döndüğü hata mesajlarının belirtilmesi.

Otomatik dokümantasyon şablonu oluşturmak için güzel toollar var. Şu blog yazılarına bakabilirsiniz. http://www.programmableweb.com/news/web-api-documentation-best-practices/2010/08/12 http://www.mattsilverman.com/2013/02/tools-to-generate-beautiful-api-documentation.html

İncelemek isteyebileceğiniz İçerikler  - https://tr.wikipedia.org/wiki/HTTP_durum_kodlar%C4%B1  - http://xphone.me/devnotes/2011/02/json-vs-xml-part-1-data-size/  - http://www.mattsilverman.com/2013/02/tools-to-generate-beautiful-api-documentation.html  - http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api  - http://www.programmableweb.com/news/web-api-documentation-best-practices/2010/08/12  - http://apigee.com/about/api-best-practices/all/ebook  - http://code.tutsplus.com/tutorials/oauth-2-0-the-good-the-bad-the-ugly--net-33216  - http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified  - http://odino.org/rest-better-http-cache/  - https://github.com/Hipo/Django-API-Playground  - https://www.youtube.com/watch?v=QpAhXa12xvU  - https://dev.twitter.com/docs/rate-limiting/1.1  - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3  - https://www.youtube.com/watch?v=2vfWdYl50z4 - http://prezi.com/5c_xhlfhvwwu/api-design-using-djangotastypiemongodb/

[bahattincinic]

Knockout Js & Firebase ile Anlık Olarak Verileri Göstermek

Merhabalar, Web sayfamızda  anlık olarak değişen veriler göstermek istediğimizi farz edelim. Örneğin bir e-ticaret siteniz var ve anlık olarak alınan siparişlerin listelendiği ve durumuna göre bölümlere ayrıldığını düşünelim.

İlk çözüm olarak akıllara JS ile birkaç saniyede bir istek yapıp elimizdeki veriyi güncelleyip ona göre dom da gereken değişiklikleri yapmak gelebilir. İlk bakışta sorununuzu çözdüğünü düşünmüş olabilirsiniz ama o sayfayı 50 kişinin açtığını düşündüğünüzde sisteme gereksiz yere baya bir yük bindirmiş olursunuz. (60/10 saniye * 50 kişi kadar dakikada istek yapılacak.) Ekstra olarak bu durumda o sayfanın uzun süre açık kalması tarayıcının belleğinin şişmesine ve dolaylı olarak tarayıcınızın kendini kapatmasına neden olabilir. 

Bu çözüm biraz daha güzel bir çözüm olmadığından alternatif bir çözüm olarak node js ve sockeIO ile olabilir. Bunun için aslında ekstra zaman ve güce gerek oluyor. Anlık olarak aktaracağımız veriyi MongoDB  yada redis gibi bir yere yazıp oradan node ile dağıtmak. Aslında en güzel çözüm bu. Fakat bazı durumlarda elinizde yeterli zaman olmadığından dolayı daha pratik çözümler aramanız gerekebiliyor.

Eğer basit/pratik bir çözüm arıyorsanız Firebase(firebase.com) tam size göre. Verilerinizi Firebase e attıktan sonra javascript den rahat cana websocket üzerinden firebase deki verinize erişebilirsiniz. Firebase veri tipi olarak JSON kullanıyor. Web sitesi üzerinden de veri ekleme/çıkartma görüntüleme işlemleri mevcut.

izleyeceğimiz yol şu şekilde olacak. Şimdi ilk başta senaryo olarak sipariş durumlarını görüntülemek ti. Bu durum için backend tarafında sipariş oluştuğunda ve siparişin durumunun güncellendiğinde bu işlemlerin firebase e yazılması gerekiyor. (Firebase Apisi bildiğimiz rest gibi çalışıyor. yeni veri eklemek için POST düzenleme için PUT isteği yapılması gerekiyor. Ek olarak PUT ile yapılan istekde eğer veri hiç yok ise o veriyi ekliyor da.) Bizim konumuz bu olmadığı için biz veri yazılmış gibi düşünerek işin JS tarafını yazı caz.

Örneği yapmaya başlamadan önce biraz firebase kullanımından bahsedelim.

Firebase veri iletişimi olarak WebSocket i kullanıyor (sayfanızı chrome un developer konsolundan network bölümünden görebilirsiniz.) JS kütüphanesinin kullanımı SocketIO ya benziyor. Firebase e bağlanmak için,

Url tipiniz şu şekilde olmalı: https://<firebase-name>.firebaseio.com/

var sampleApp = new Firebase('APP-URL'); uygulama urlnizi yazmanız yeterli olucak. Verimiz içinde belli bir alana gitmek için child fonksiyonunu kullanıyoruz. (bir üste çıkmak içinde de parrent fonksiyonunu kullanıyoruz)  Örneğin uygulamanız içinde en tepede orders diye bir bölüm var. Buna ulaşmak için,

var childRef = sampleApp.child('orders');

şeklinde ulaşabiliyoruz. Bu şeklinde child child gezmek yerine Firebase den bir nesne üretirken Firebase urlimizin sonuna ulaşmak istediğimiz child i ekleyerek de ulaşabiliriz. Örneğin;

var sampleApp = new Firebase('https://test.firebaseIO-demo.com/orders');

şeklinde de orders child ına erişebiliriz. Aşağıdaki resim aslında bu durumu tam açıklayıcı bir resim.

Veri okuma işi de bir hayli kolay. Firebase in on fonksiyonu belli parametreler alıyor ve bu parametrelere göre size o verileri veriyor.

var childRef = sampleApp.child('orders'); childRef.on('value', function(snapshot) {     alert('order: ' + snapshot.val()); });

on fonksiyonun value parametresi o child da herhangi bir  veri değişiminde asenkron olarak callbacki tetikliyor. Yani o child a veri ekleme, düzenleme silme ve taşıma işlemlerinde tetikleniyor. (Bunu test etmenin en kolay yolu Firebase web konsolundan veriyi elle değiştirip sayfadaki değişimi takip etmek olabilir.) callback e verilen parametredeki .val() fonksiyonu yeni veriyi döndürüyor.

callback e verilen parametreden tek ulaşabildiğimiz şey verilen değerler değil tabi. Mesela callback e gelen veri hangi child dan geliyor bilebiliyoruz (snapshot.ec.path.toString() bize child imizi yani /orders i vericek)

Tabi ben hepsini tek bir yerden yönetmek değilde ayrı ayrı da yönetmek isterim diyebilirsiniz. Bunun için,

child_added: veri eklendiğinde child_changed: veri güncellendiğinde child_removed: veri silindiğinde child_moved: veri taşındığın da çalışıyor.

Örneğin;

var childRef = sampleApp.child('orders'); childRef.on('child_added', function(snapshot) {     alert('new orders: ' + snapshot.val()); });

childRef.on('child_removed', function(snapshot) {     alert('removed orders: ' + snapshot.val()); });

şeklinde kullanabilirsiniz. Mesela benim value işimi görüyor bunları nerelerde kullanırım derseniz. Anlık olarak güncellenen bir tablonuz olduğunu düğünün. child_changed fonksiyonu ile değişen verinin olduğu sütun u highlight edebilirsiniz.

Eğer derdiniz anlık bir sayfa yapmak değil ve firebase den sadece sayfa yüklenince veriyi çekmek istiyorsanız on yerine once fonksiyonunu kullanabilirsiniz.  Bazı durumlara göre off fonksiyonu ile firebase den veri dinlemeyi bırakabilirsiniz.

Firebase den veri okumak yerine javascript ile veri de yazabilirsiniz. Bunun için set fonksiyonunu kullanabilirsiniz.

Şimdi örnek uygulamamıza kaldığımız yerden devam edelim.

diyelim ki yukarıdaki gibi bir veri formatımız var. en baştaki bahattintest app ismimiz. (siz bence kendi isminizi verin :) ) içinde ise orders yani siparişler var. Liste icinde sipariş numarası, siparişin verilme tarihi ve durumu var. (1 bekliyor, 2 kargolanmayı bekliyor)

Ek bilgi olarak şunu da eklemekte yarar var. Firebase de bir child içindeki veriler dizi gibi index şeklindeyse bu child i dinlediğinizde liste tipinde veri alırsınız. Eğer index tipinde değilde normal key gibiyse Object tipinde veri alırsınız.

örneğin bizim örneğimizdeki veri şu şekilde geliyor.

Kaldığımız yerden devam edelim. Şimdi ise bu veri tipine göre ilgili sayfayı yapalım.

Şöyle bir arayüz yaptığımızı düşünelim. Üst bölümde sipariş tiplerinin ve bulunma adetinin alt bölümde ise anlık olarak tüm siparişleri gösterelim.

https://gist.github.com/bahattincinic/5a8399ac0ca6d911c374

Koda baktığımızda FirebaseModel Order modelinin her tipi için bu nesneden oluşturuyoruz. bu nesne içinde ise init fonksiyonunda firebase tarafından tüm alanları çekiyor ve underscore js ile verilen tipteki veriyi alıp kendi içine yazıyor. Yani Dashboard içinde bu nesneden 2 sefer oluşturduk. (register fonksiyonu tamda bu işi yapıyor.) Bu tipler Onay bekliyor ve kargolanmayı bekliyor tipleri.  HTML tarafında ise Tipleri ve adetlerini yazmak için instance ler yani tipler içinde dönüyoruz. Alt bölümde ise veriler parça parça olduğu için iç içe 2 foreach ile tüm verileri yazdırmış oluyoruz. ($parrent iç içe 2 foreach de üstteki döngüdeki değere ulaşmak için kullanılır.)

Test yapmak için Firebase tarafında bir siparişin durumunu değiştirdiğimizde bu işlemin anlık olarak sayfamıza yansıdığını göreceksiniz. (Örnek veri Github da initial.json içinde mevcut.)

Örnek uygulamaya buradan erişebilirsiniz. Demo için http://jsfiddle.net/bahattincinic/XFH8f/ 

[bahattincinic]

Angular JS de Environment Kavramı

Angular JS ile dinamik uygulamalar yaptığımızda, özellikle Apiler ile çok fazla uğraştığımız zaman localdeki ve production daki çalışan projelerde değişen configrasyonlar sıklıkla karşımıza çıkabiliyor.

Genellikle Javascript işlemleri HTML içinde olduğu zaman Kullandığınız template engine (ör: Jinja, twig...) ile backend tarafından bu configrasyonlar gelir ve bir javascript değişkenine eşitleyip yola devam edilir.

Ama Javascript ile yaptığımız işlemler büyüdüğü zaman Javascript işlemlerini klasör ve dosyalara bölmemiz gerekiyor. Mesela ben Javascript de modül/controller/ modül/view/ modül/model şeklinde klasörlere parçalıyorum. Bu durumda Javascript işlemleri HTML içinde olmadığı için configrasyonlar backend den parse edilemiyor. Bu Bahsettiğim durum sadece Angular Js için geçerli olduğu söylenemez.

Neyse biz konumuza dönelim. Bu durumda Apilerin istek yaptığı endpoint urli veya token bilgileri bol bol if yazarak sonuç itibari ile kodu kirlelerek farklı çözümler üretiyoruz. Bunu bu şekilde yapmak yerine bu sorunu çözmeye çalışalım.

Constant Çözümü  -->   constant(name, object)

https://gist.github.com/bahattincinic/878305b73f618dbabec7

Durumu 1 adım ileriye götürdük. Artık settingslerimiz tek yerde ama hala development production settingslerimizi aynı yerde konumlandıramadık. ikisinide farklı constantlar yapmak da cok çözül bir çözüm olmucak gibi. Şimdi settingsleri tek yerde toplayama çalışalım.

https://gist.github.com/bahattincinic/ad507eda7e940dacc99b

Şimdi istediğimiz gibi oldu. Bizim hiç şuan hangi ortamda olduğumuzdan haperimiz olmadan sadece ConfigService.get('api_endpoint') diyerek olması gereken bilgiyi bize geri dönüyor. Ekstra olarak birden fazla ortamı tek configrasyona bağlıyabiliyoruz da.

Eksra olarak üretilecek bir çözüm ise bu problemi Grunt Js ile çözmek. Grunt Js kısaca Js task runner olarak bilinir. Node Js ile beraber çalışır ve üzerine birden fazla plugin geliştirmek mümkündür. (pluginlerinin npm üzerinde bulunmaktadır. npm install şeklinde kurulur.)

Grunt Js ile daha detaylı bir makale için şuraya bakabilirsiniz. http://newtriks.com/2013/11/29/environment-specific-configuration-in-angularjs-using-grunt/

[bahattincinic]

Angular Js ile Autocomplete Aramaları Cache'lemek

Merhabalar,

Angular JS ile Autocomplete bir arama bulunan sitemizde client tarafında nasıl cache yapabiliceğimizden bahsedicem ve ufak bir uygulama yapıcam.

İlk olarak böyle bir şey yapma fikrinin nerden çıktığından bahsediyim. Geliştirmekte olduğum bir projemde Autocomplete arama üzerine çalışıyordum. Her şey iyi güzel bir şekilde çalışıyordu. Fakat kullanıcı aynı input üzerinde aynı arama terimleri ile istek yapınca tekrar tekrar bu bilgileri istiyordu. Böyle bir şey çok ufak bir ihtimal gelebilir. Ama arama bölümünden her bir karakter sildiğinde bu istekleri tekrar tekrar atmak maliyete sebep olabiliyor. Facebook un Arama bölümünü Debug ettiğimizde Facebook da bu tip bir cacheleme yaptığını fark ettik.

Örnek uygulama kodlarımızı verip daha sonra açıklamasını yapalım.

https://gist.github.com/9671766

Örnek koda baktığımızda ilk olarak bir tane angular modülü tanımlaması yaptık.

ondan sonra bir Factory ve bir tane Controller tanımlamamız bulunuyor.

Factory içinde search isteği yapılmadan önce bu arama işlemi bizim cache imizde var mı yokmu kontrol edip var ise cache den verip yok ise iteği yapıp dönen sonucu cache leyip daha sonra sonucu controller e dönmemiz gerekiyor.

Angular Js de Cache için güzel bir $cacheFactory geliştirmişler. Cacheleme işlemleri için bu provider i kullanıcaz.

Factory içinde tam da dediğimiz seneryoyu yapıyoruz. Cache de var ise oradan yok ise istek yapıp dönen sonucu cacheleyip veriyoruz. (Burada dönen sonuç boş bile olsa yinede cacheliyoruz.)

Controller içinde ise input içinde herhangi bir değişilik olduğunda bi Factoryi çağırmamız gerekiyor. Angular JS de $scope daki herhangi bir şey de değişimi yakalamak için $watch ifadesini kullanıyoruz.

$watch içinde girilen değer minimum 3 karakter kontrolü de koyduk. Sonuç itibari büyük bir data içinde2 karakterlik arama çok işe yarıcak bir sonuç getirmeyecek.

Kontrollerimize uygun ise Factory üzerinden Search urlimize(/search.json?q=key) istek yapıyoruz ve dönen sonucu HTML de ngRepeat aracılığı verinin içinde dönüp ekrana basıyoruz.

Yapıcağımız tüm işlemler bu kadar. 

Son olarak sayfa yenilendiğinde burdaki cache uçucağını unutmayalım :)

[bahattincinic]

PSR-0 Kodlama Standartı

Bir proje geliştirmeye başlamadan önce projemizi hangi standartlar çerçevesinde geliştirceğimizi belirleriz. Projeye başlarken belirlediğimiz standart aslında geleceğe bir yatırım olarak görebilirsiniz. Standartı olmayan projelerin spagetti koda dönüşmesi kaçınılmazdır.

php'nin resmi olarak belirttiği bir standart malesef yok.

"PHP Framework Interop Group" PSR adında bir kodlama standartı önerisinde bulunmuşlar. Bu blog postumda  bu konudan bahsedicem.

Bu Standartı koyan grubun içinde PHP de önde gelen Open Source projelerin core developer ları bulunuyor. Amaçları herkesi ortak bir standart da toparlamak.

PSR Standartı kendi içinde 4'e ayrılıyor;

PSR-0

PSR-1

PSR-2

PSR-3

PSR-0 Standartı Bu standart Autoloading üzerine bir standart. (Kısaca Autoloading namespace yapısında geliştirilen projelerde use ile çağırılan kütüphanelerin otomatik olarak include edilmesi için gereklin olan mekanizmaya diyiyoruz.)

namespace ve class formatı şu şekilde olmalı

\<Vendor Name>\(<Namespace>\)*<Class Name>

- Burda Vendor dan kasıt uygulama ismi olarak düşünebilirsiniz. Fakat yeni nesil web teknolojilerinde Vendoru thirt-party applicationlara verilen genel bir isimdir. Örneğin phpunit, doctrine etc...

namespaceler sub namespace içerebilir. Örneğin, Symfony\Component\HttpFoundation\RedirectResponse burda symfony uygulama Component base namespace HttpFoundation sub namespace RedirectResponse da class olarak düşünebilirsiniz.

Namespaceler otomatik yüklenirken her namespace ayıracı () bir klasöre tekabül eder. Örneğin yukarıda verdiğimiz RedirectResponse classı Symfony/Component/HttpFoundation/RedirectResponse.php şeklinde bir klasör hiyararşisi içinde.

class isimindeki _ ifadesi klasörü ifade eder örneğin, \namespace\package\Class_Name => namespace/package/Class/Name.php \namespace\package_name\Class_Name => namespace/package_name/Class/Name.php (Ben Symfony2 nin ve zend2 koduna baktığımda bu şekilde bir tanımlamaya denk gelmemiştim. Fakat biraz daha araştırdığımda PHP 5.2.x ve önceki sürümde olan fw lerde bu sekilde kullanıldığını gördüm. Örneğin, Zend 1x sürümünde bu tip kullanımlar mevcut.)

namespace ve class dosyalarının .php uzantılı olması

işin teorisi bu kadar. Şimdi de örnek uygulamaya bakalım

https://github.com/bahattincinic/psr-0-autoloading

[bahattincinic]

Yeni blog yeni soluk...

Aylardan sonra tekrardan blog açmaya karar verdim. Aslında tekrardan bir blog yazmaya karar vermiştim. Sonra Yazmışken Open Source olsun herkes kullansın düşüncesine kapıldım. Testiydi dökümantasyonuydu derken mini bir blog ciddi büyüklüğe ulaştı. Sonunda kendimi tumblr da buldum.

Uzun bir süre kullanmayı düşünüyorum. :)

Genel olarak teknik şeyler yazmayı düşünüyorum. Bazen çözümüne ulaştığım bir problemi, bazen hoşuma giden ve severek kullandığım bir yöntemi paylaşıp bilgi vermeye çalışıcam.

Takipte kalın.