ben
Gloria Jean's de uzun çekim americano kahve içmeyi çok severim.
çok severim
şuan da
Sammy çekirdeği üzerine javascript ile plugin yapısı.
yapıyorum
en son
turkcell - gncplay, kartaca çatısı altında çalışmak yorucu ve zevkliydi.
yaptım

Keskin kavşaklardan dönerken türkiye, soramadı medya; doğru ne yanlış ne ? ve bunu soranlara ne olacak ? http://bit.ly/12btD3c

Two way binding for marionette with marionette.behavior like angularjs directives approach

Emrah TOY

Tarih : 29-09-2014
Kategori : Yazılım

0

Yorum

I always like angularjs’s approach by using directives and never able to find a direct way to implement for marionettejs. There was another backbone library which is pretty good. It is also supporting evaluation. To be honest i always hate evaluation.

A couple weeks ago i decided to read whole marionettejs documentation. There was ‘Marionette.Behavour‘ layer to make all the interaction with view basic and able to inheritable by the Marionette.View layer.

Marionette.Behavior is important because it is also supporting MarionetteJS’s garbage collector. You do not have to worry about memory usage.

I tried to implement angularjs’s directive approach by using Marionette.Behavior. Here is the gist page of it or you can clone directly.

Most easier way to get Latest tweet from an account via PHP

Emrah TOY

Tarih : 13-09-2011
Kategori : Yazılım

0

Yorum

I used this code for my wordpress theme.
You may like to change default $username property and if you change rpp value you can get more tweet, its all up to you.
This code returns HTML ready tweet that you dont have to render. Only you may like to set css rule for sub tags.

function getLatestTweet($username=’kalimor’){

$format=’atom’; // set format

$buffer = file_get_contents(“http://search.twitter.com/search.{$format}?q=from:{$username}&rpp=1”);
$xml = new SimpleXMLElement($buffer);

$tweet = $xml->entry->content;
return $tweet; // show latest tweet

}
echo getLatestTweet(‘kalimor’);

PS : This code may not work with private accounts.

Etiketler : , ,

Nginx, apache, lighttpd hangisini seçmeli ?

Emrah TOY

Tarih : 10-01-2011
Kategori : Güncel Yazılar, Ubuntu, Yazılım

1

Yorum

Geçenlerde performans ve sürdürülebilirlilik ile ilgili kafama takılan soruları cevaplamak için bazı soruları not aldığımı farkettim ancak çok uzun süredir geri dönüp inceleme ve fırsatı bulamamışım, hazır vaktim varken notlarımı blog’umda irdeleyeyim istedim.

Soruların sayısı arttıkça cevaplamak da problem oluyor.

  1. Sürekli artan isteklerle başa çıkmakta hangi http sunucusu başarılı ve sürdürülebilirliliği sağlamak adına ihtiyaç duydukları minimum konfigürsayon nedir ?
  2. Nginx (engine-x, njinx), apache ve Lighttpd (lighty) daha çok hangi amaçlara hizmet ediyor ?
  3. Temel farkları nedir ?

Sorularıma cevap ararken detaydan ve teknik veriden ziyade aklımda kalabilecek ve yerine geldiğinde şu sunucu şu işi diğerinden daha iyi yapar diyebilmek benim için yeterlidir diye düşünerek yaptım, zira elimde bu farklardan herhangi birine ihtiyaç duyabilecek bir proje yoktu ve daha önceki tüm projelerimde network ve sistem uzmanı arkadaşlara ihtiyaç duyulan doneleri verdikden sonra seçim konusunu onlara bırakmıştım. Ancak son dönemlerde kendi çabamla not aldığım tüm projelerde gördümki artık LAMP dörtlüsünün daha işin başında yetersiz kalmaya başladı daha doğrusu ben performans ile ilgili ve ürettiğim çözümlerin getireceği yük konusunda endişelere kapıldım. Daha önceki projelerime dayanarak incelemeye değer gördüğüm tüm bu sunucu yazılımları kullandığım halde yakından incelemediğimi farkettim.

Daha projenin başında LAMP ( linux, apache, mysql, php ) dörtlüsünün bazı problemlerin çözümünde yetersiz kaldığını gördüm.

Çalışma mantığı ve yaklaşım farkları :

  • Apache Multithread çalışıyor. ( Her bir domain ve/veya projeniz için ayrı bir apache process’i yaratıldığını düşünün. )
  • Nginx Singlethread ve yanısıra Worker desteği ile çalışıyor. ( Her bir isteğin tek bir thread karşılandığını ancak duruma göre farklı bir Worker üzerine aktarıldığını düşünebilirsiniz. )
  • Lighttpd Singlethread çalışıyor. ( Tüm istekleri tek bir thread üzerinden alıp aynı thread ile işleyip yine geriye aynı yol üzerinden cevap veriyor. )

Çalışma mantığı ihtiyaç duydukları donanımı ve sürekliliği doğrudan etkiliyor.

İhtiyaç duydukları donanım türüne göre performans sıralaması :

Ram : Lighttpd >Nginx > Apache

Cpu : Nginx > Lighttpd > Apache

  • Apache PHP’yi fastCgi  olarak kullanmadığı her durumda çok zarar ediyor hem işlemciyi hemde rami aşırı tüketiyor. Nginx ve Lighttpd fastCgi dışında bir destek sunmuyor. Nginx’in fastCgi ile PHP processlerini handle etmekde zorlandığı yazılıyor pek çok blogda ve çözüm olarak PhpFPM ( Php fastCgi Process Management ) öneriliyor.
  • Tüm sunucular APC ile uyumlu çalışıyor ancak Nginx için özellikle Nginx+PhpFPM+APC için geleceğin alternatifi gözüyle bakılıyor.
  • Nginx Ruslar tarafından geliştiriliyor. Lighttpd ise daha çok Amerikalı yazılımcılar tarafından tutuluyor.
  • Apache Modülleri açısından daha başarılı, Nginx hemen arkasından geliyor ancak Lighttpd bu konuda çok zayıftır demek yanlış olur, çok uçlarda istekleriniz yoksa hemen hemen hepsi başarılı.

Netice itibariyle benim düşüncelerim şu şekilde netleşti denebilir.

Sunucuya göre;

  • Eğer sunucumda cpu ve ram problemim yoksa her an herşeye çözüm üretmem gerekecekse ve geniş destek içeriğine ihtiyacım varsa tercihim Apache.
  • Eğer sunucum bir VPS ise özellikle cpu kullanım oranı benim için problem olacaksa tercihim Nginx‘den yana.
  • Eğer sunucum bir  VPS ise özellikle ram kullanımı benim için sıkıntı oluyorsa tercihim Lighttpd‘den yana.

Proje çözümüne göre;

  • Projemde çok fazla istek yapılmıyor ( çok fazla ziyaretçim yoksa, ajax, rpc gibi diğer isteklerin cevapları önemli miktarda değil ise )  ancak çok fazla yazılımsal iş yükü varsa tercihim Apache.
  • Projemde istek ve sayfa gösterim oranları çok yüksek yazılımsal iş yükü ağır ve projelerimde bol dinamik içerik varsa tercihim Nginx.
  • Projemde yazılımsal iş yükü fazla yoksa, dinamik içerikden ziyade statik içeriği aşırı yoğun ziyaretçi yüküne karşı hatasız sunmam gerekiyorsa tercihim Lighttpd.

İş çözümüne göre;

  • Django ile aşırı derecede haşır neşir isem, isteklerin cevaplarını python ile işleyerek elde ediyorsam tercihim Apache.
  • Content Deliver Server ( İçerik ulaştırma sunucusu ) tarzı bir yapıda tercihim Önce Lighttpd sonra Nginx.
  • VPS sunucularda tercihim Nginx, Nginx için Cpanel çözümünün geliştirildiğide not düşeyim buraya.

Pek çok kişi apache’nin ihtiyaçlar doğrultusunda yeniden compile edildiğinde sonuçların çok farklı olacağını söyleyeceğini biliyorum ancak bunu araştırmak şimdilik beni aşıyor. Eğer bir gün yoluma apache ile devam etmem gereken bir projede performans ile ilgili kaygılar duyarsam elbette onunla ilgili de bir blog yazmayı düşünürüm. Ancak söz konusu sunucuların en sık kullanılış türüne ve paket halinde sundukları çözümlere bakınca benim bakış açımdan durum budur, çünkü ben sistem ve/veya network uzmanı değilim ve bu işin hakkını verenlere danışılmadan yazılımcılardan bu tür bekletilere girenlere pek hoş bakamıyorum. Umuyorum şu projede ne kullansak rahat ederiz diyen her meraklı insan için faydalı olmuştur.

Cnetturkiye.com yeni yayın döneminde APC ve Memcache üzerine

Emrah TOY

Tarih : 22-03-2010
Kategori : Güncel Yazılar, Yaptığım işlere dair, Yazılım

0

Yorum

Çalıştığım firma çatısı altında cnetturkiye.com‘un teknoloji ve haber sitesinin yenileme çalışmalarını tamamladım ve yeni hali ile sanıyorum 2 haftadır yayında.

Kimi bölümleri açıldı ( Editör yorumları ve Download ) kimi bölümlerinin içerik hazırlıkları ise devam etmekde.

Site kodlarının tamamı ( Server Side ) Php ancak elbette ( Client Side ) kullanıcı tarafında Javascript kullanıldı.

Farklı olarak server üzerinde Memcache ve APC aynı anda farklı işler için kullanıldı. Genellikle bu durumla çok sık karşılaşılmaz ancak ufak performans kayıplarını bile göz önüne aldığınızda bu özel durumun önemi daha fazla ortaya çıkıyor. Aşağıdaki tablo size bu farka ve gerekliliğe dair bir fikir verecektir.

Memcache APC
Sabit değişken hızı
Eğer yoksa bağlantı beklemesi ve network üzerinde güncel hali araması dezavantaj oluyor.
Hızlı
Bağlantı gerekliliği
ve
Load Balancing
Var
Network olarak dağıldıkça tepki hızı düşebiliyor ve dezavantaj olabiliyor
Yok
Array ve Obje desteği Array’ler de hızlı
Ancak objeler bilhassa her çağırıldığında yeniden yaratılıyor ve APC tarafından tekrar işleniyor.
Objeler de hızlı
Opcode cache gücünü gösteriyor. Ancak On the fly yaratılan Array’ler söz konusu olunca Memcache daha hızlı.

Cnettürkiye.com için çalışırken APC’yi özellikle sabit değişkenlerde objelerde ve Cache süresi çok uzun sürecek Array’lerde kullandık. Memcache’i ise geçiçi olarak yada gerçek zamanlı yaratılan Array’lerin kısa süreli cache ihtiyacı doğduğunda kullandık.

Sonuç bizim için verimli oldu henüz tam gücünü göremesekde ilerleyen zamanlarda yoğunluk hallerinde bize sağlayacağı faydaları şimdiden öngörebilmek mümkün.

Sizlerde benzer bir durumda kalır ve benzer niteliklerde bir setup ile çalışırsanız umarım tecrübelerinizi paylaşırsınız.

Facebook yazılımcılarından Hyper-PHP yada Hiphop PHP

Emrah TOY

Tarih : 03-02-2010
Kategori : Yazılım

2

Yorum

Geçtiğimiz günlerde bir kaç blog yazısında haberini okuduğum Hyper-PHP yada HPHP adıyla anılan ve tam olarak ne olduğu anlaşılamayan bir PHP versiyonundan bahsediliyordu.

Bir çeşit OpCode Cache mi yoksa Java vâri bir Virtual Machine mi söz konusu olan netleşmemişti. Bugün ise okuduğum başka bir blogda  yayınlanan girdiyi görünce durumun netleştiğini gördüm.

Üretilen şey bir PHP compiler’ı ancak tek başına bir compiler değil. Daha çok bir kod yorumlayıcı ve yeniden yaratıcı ( reimplementation ) ve Php Runtime ın yerini yeni bir Php Runtime olarak algılamak gerek. Bunu çalışma şeklinden de anlamak mümkün, şu şekilde çalışıyor ;

Vermiş olduğunuz PHP betiğini önce C++ olarak çeviriyor sonrasında ise G++ ile compile ediliyor. Yani arada derede bir yapı ancak başarı oranına bakıldığında CPU üzerinde %50 oranında yük azalması söz konusu. Kısacası başarılı !

Hiphop Php Transformation Process

Hiphop Php Transformation Process

Son iki yıldır geliştirilmekde olan proje ilk kez bu gün geliştiricilere ve meraklılarına sunuldu.  ( HipHop for php from Facebook )

Aynı yöntemle facebook servislerinde %30’a varan hız sağlanmış ki düşünülecek olursa o yoğunlukdaki bir hizmet için oldukça verimli bir oran.

Dezavantajlarıda var elbette çok nadirde olsa kimi fonksiyonların desteklenmediğini ancak karşılığında yüksek oranda performans verildiğini görebiliyoruz, bir bölüm yazılımcının işine gelmeyecek olan en önemli fonksiyon ise ‘eval()’ fonksiyonu sanıyorum.

Hiphop for Php olarak anılan ancak daha önceleri Hyper-PHP olarak anılmış olan bu ortam şunları içermekte;

  1. Kod çevirici ( Code Transformer )
  2. Yeniden gerçeklenmiş Php Runtime ( Reimplementation of Php Runtime )
  3. Genel geçerk pek çok Php eklentisinin yeniden yazılmış yada yapılandırılmış hali ( Rewrited Php Extensions )

Kaynaklar ;