Barış Atasoy>

İki gündür evi boyuyorum; normalde bu tip mekanik işler yaparken alakasız şeyler düşünüyorsunuz (başka ne yapabiliriz ki?).

Su bazlı boyalar yaygınlaştığından beri, düşündüğüm şeylerin kalitesi de düştü(!). Zira tiner, bir yandan beyninizi yakarken bir yandan da daha neşeli(!), hatta yaratıcı olmanızı sağlıyordu (kesinlikle şikayetçi değilim).

Benim tercihim PHP; uzun süre Visual Basic kullanmış biri olarak doğal olarak ASP’yi seçmem beklenirdi. Ancak, tersine, C’ye çok fazla benzeyen PHP’yi seçtim. “Beleş” olduğu için değil; para ödemem gerekse ve ASP 1.000 dolar olsaydı, PHP’ye 3000 dolar verirdim!

ASP’ye karşı PHP’yi seçmek için sayısız neden var. Birincisi, çok daha hızlı. İkincisi, yazım şekli daha katı olduğu için, ancak bir maymunun yapabileceği kodlama hatalarını yapmıyorsunuz. Evet; biraz daha fazla zaman alabiliyor (yeniyseniz) ama debugging’e harcanan zaman radikal derecede düşüyor.

Üçüncüsü, PHP son derece modüler. Bu, çoğu Windows kullanıcısı ya da kiralık hosting kullanan web yayıncısı için Bir şey ifade etmeyecektir; ancak kendi kurduğum embedded bir sistemde, PHP’yi sadece kendi istediğim özellik setiyle derleyerek 5 küsur megabayttan 1.9 MB’a indirdim. Hız farkı ise daha radikaldi. Eğer biraz daha agresif olmak durumunda kalsaydım -ki sistemin bulunduğu 32 MB’lık Compact Flash kartın neredeyse yarısı boştu- herhalde 1 MB civarı bir executable dosya yapabilirdim. Burada tek faktör, çalıştırılabilir PHP dosyasının büyüklüğü değil. Çok yoğun bir sunucu üstünde PHP’nin küçülmesi ciddi bir performans farkı yaratacaktır.

Dördüncüsü, PHP platform bağımsız. Geçmişte zorunluluktan dolayı Linux bir sunucuya kasarak ChilliASP kurmuş ve ASP tabanlı scriptleri çalıştırmıştım; ancak ASP.NET’ten sonra durum nedir bilemiyorum; ancak pek de parlak olmasa gerek. “Mono kullan” gibi bir fikir savurmayın, neden işe yaramayacağı üzerine kitap yazabilirim…

Beşincisi, PHP çok hızlı gelişiyor ve sayısız hazır fonksiyon var. PHP’ye öyle güveniyorum ki, yapabilir miyim diye bir saniye tereddüt etmeden embedded bir cihazın kontrol panelini yazmaya giriştim ve zorlanmadım bile. C ne yapabilyorsa, PHP’de aşağı yukarı hepsini yapıyor. Hatta, PHP’de pointer olmadığını iddia eden Microserf’ci bir elemanı 30 saniyede, patronunun yanında patlıcan moru yapmıştım. Baştan beri kılçık tavırlar içinde olmasa buna yeltenecek değildim; herhalde millet olarak takım elbise ve kravata alışık olmadığımız için, onun içine girenler kendini başka bir dünyada sanıyorlar…

Bugün, özellikle Türkiye’deki çok sayıda ASP tabanlı sitenin patlak ve yavaş olması, “aman bunu kolay ve hızlı öğreniyoruz, bir de site patlatır parayı cukkalarız” anlayışından kaynaklanıyor. Her dil belli bir tecrübe gerektirir; maalesef Visual Studio dilleri ve ASP.NET gibi projeler insanlar üstünde gereksiz ve tabanı olmayan bir kendine güven hissi yaratıyor; sonuçlarını da hep beraber görüyoruz…

Ha, seçim yapabilecek kadar bilgi ve deneyiminiz yoksa, kopya çekin: Alexa’nın ilk yüzünde yer alan sitelerin neredeyse tamamı PHP ile kodlanmış…JSP (Java Server Pages) da PHP gibi bir disiplin sağlıyor; ancak sunucunun çalışma mantığı bana çok dolambaçlı geldi; ki SUN’ı el üstünde tutarım(!)

Altıncı bir neden olarak, IIS’ e hapsolma konusu var. Apache, dünyanın %70′ini elinde tutarken ve MS yıllarca önünü kesmek için dezenformasyon kampanyası yaparken, insanlar yine de Apache’yi seçtiler. Bugün ASP filan olmasa, MS’in IIS ile uğraşacağını bile sanmam.

Umuyorum Cuma akşamına kadar Blogmani’nin “deneysel” sürümünün kodlaması bitecek.

Deneysel’den kastım; bunun bir Proof of Concept (“işte böyle çalışıyor” mukabili bir söz) çalışma olması. Temel fonksiyonlar çalışacak. Yani en basit haliyle. Bundan sonra, motivasyona bağlı olarak(!) projede tasarladığımız pek çok yenilik var. Motivasyon ise, elbette projenin sağlayacağı başarı ile doğru orantılı. Ne kadar çok katılım olursa, bu bizi o kadar çok motive eder. Açıkçası, ilk haliyle göreceğiniz blogmani, oldukça basit olacak. Bunun nedeni, elbette ki zaman kıtlığı. Bu tip projeler para getirmediği için, kendinizi böylesine yoğun bir çabaya tamamen adamanız mümkün değil.

Blograzzi deneyiminden en azından ben, ders aldım. Blograzzi, hergün biraz daha iyiye giden bir proje, üstelik insanları dinleyen birileri tarafından sürdürülüyor. Şu an Blograzzi’de tek yanlış bulduğum şey, puanlama algoritmasının “gizemini koruması”.

Bunu neden gizlediklerini bilmiyorum; ne de olsa ne Blograzzi’de Leibniz çalışıyor, ne de diferansiyel denklemlerin bile bilinmediği dönemlerde yaşıyoruz. Üstelik, kalıbımı basarım gayet basit bir matematiksel formülü var (diferansiyel denklem filan kullanmadıklarına yemin edebilirim!)
Bu konu daima şaibe kaynağı oldu ve açıklanmadıkça da olmaya devam edecek.

Onun için, blogmani’nin puan hesaplama sistemi şeffaf ve öyle de kalacak.

Abartıp, bunu hesaplayan PHP kodunu da sayfaya koyuyorum.

Hemen ekleyeyim; herşey doğru çalışıyor ama sistemin ne kadar adil olduğu üzerinde düşünme fırsatım olmadı. Ivır zıvırlar, zorunlu sıkıcı işler -Technorati API’si kullanmak, Alexa ve Google sayfalarını Reg Ex ile parse etmek, veritabanı işlemleri vs..- yüzünden, maalesef hesaplamalarımın ne kadar adil ve gerçeği yansıttığını zamana yayıp, bu süre içinde daha akılcı bir algoritma geliştireceğim. Bu süreçte, fikirlerinizi almak çok faydalı olacak.

Bu arada, potansiyel puanınızı test edebileceğiniz sayfa şurada:

http://blogmagazin.pozitifpc.com/puan/blogmani.html

Bir ekleme yapayım: Blogmani içinde blog girdisi yazıp, diğer girdilere yorum yapabileceksiniz. Bu da, puanlarınıza ciddi bir katkı yapacak. Burada amaç, sayısal olarak nerede olduğunuzu değil, ne kadar “yazar” olduğunuzu ölçmek. Aradaki fark, Akademi ödülleri ile Sundance gibi; biz popülariteyi değil, yazarlığınızı ölçmek niyetindeyiz.

Daha önce, Technorati verilerini, Technorati API’si kullanarak çektiğimi söylemiştim.

Aynı şeyi, Alexa için yapamadım-miktar ne olursa olsun, Alexa API’lerini kullanmak için para ödemek zorundasınız.

Bu durumda, geriye iki seçenek kalıyordu: PHP’nin CURL fonksiyonları, ya da sayfaya soket açıp, sayfa içeriğini işlemek.

CURL kullanmanızı tavsiye etmem: aslında harika çalışıyor; ancak makinaya minimal bir Apache kurduktan sonra, CURL fonksiyonlarının çalışmadığını farkettim. Standart Apache kurulumu ile gelmeyen çoğu kütüphaneyi kullanmak risklidir - sunucunuzda da o fonksiyonlar olamayabileceğinden, bilgisayarınızdaki web sunucusunda güzel güzel çalışan projeniz, hostunuz üzerinde patlayabilir.

O zaman, ben de soket açarım dedim ve fsockopen’ı bol bol kullandım!

fsockopen ile açtığınız sayfalardan spesifik bir bilgiyi alabilmek için, Regular Expressions’ın kucağına düşüyorsunuz. Eğer çok iyi düzeyde Reg Ex bilginiz yoksa -benim gibi!- ve problemi hızlı çözmek zorundaysanız, bildiğiniz kadar Reg Ex ile, sprintf (ve türevleri) ile birlikte, PHP’nin katar işleme fonksiyonlarını kombine kullanın. 15 sene önce olsa farklı konuşurdum; artık yazılım geliştirmek kolay ama zaman çok kısıtlı. Günümüzde en kıymetli kodcu, hızlı olan. Bilgisayarlarda çok hızlı olduğundan, genelde yazabileceğiniz en kötü kod bile, aletlere ter attıramıyor. (Simulatör, 3D oyun, ya da genetik alanında kullanılan tarzda karmaşık programlar yazmadığınızı varsayıyorum!)

Alexa sorununu nispeten kolay çözdüm; zira verilerin düzenli bir XML formatında geldiği bir sayfaya çengel atmayı başarabildim!

Google API’leri günde 1000 sorguya izin verdiği ve sonuçları hala parse etmeniz gerektiği için, yine API kullanmama kararı aldım.

Google ile işim, kolay görünmesine rağmen, biraz maceralı geçti. Pagerank’i alan kodu Internet’ten 10 dakika içinde çalıp(!) neredeyse aynen kullandım. Gelgelelim, arama sonuçlarını veren bir kod bulamadım. Bulduğum üç örneğin ikisi CURL’e dayandığı için, daha ilk anda çalışmadılar. Üçüncü, soket kullanan örnek ise, yazılan yanlış Reg Ex ifadeleri yüzünden çalışmıyordu.

Kolları sıvayarak 2-3 saat içinde, link sayısını veren Google kodunu yazdım. Aslında, uzamanın nedeni, yine bir Reg Ex-PHP azizliğiydi…

Benim kullandığım Apache+PHP sunucusunda, Unicode’dan (UTF-8), ISO tabanlı dil kodlamalarına çeviri yapan fonksiyonlar çalışmıyor. (Açıkcası, hala geliştirilme aşamasında ve PHP’yi ICU desteği ile derlemeniz gerek). Sorun şu; sayfadan Türkçe karakterler geliyor ve Reg Ex, Unicode anlıyor olması gerektiği halde, anlamıyor ve unicode karakterleri bulamıyor. Çözüm? Unicode harfler yerine, Reg Ex’in (.) -nokta- güzelliğini kullanmak! Böylece, katarınız içindeki unicode karakterlerini “her ne gelirse” diye geçiştiriyorsunuz. Harika bir çözüm değil ama her koşulda işe yarıyor. En azından, insanlar php.net’te ve forumlarda “reg ex ile unicode işleyemiyoruz” diye ağlaşırken, siz geminizi yürütüyorsunuz.

Sonuç olarak, Google Pagerank, link sayısı ve Alexa verileri gibi bilgileri de çekmeyi başardım. Technorati işini de dün çözdüğüm için, geriye birkaç iş kaldı.

Bunlardan biri, çektiğim verileri veritabanına yazmak. Bu, en kolay iş.

İkincisi, bu sitelere ulaşılamadığında, scriptimin neler yapacağına karar verecek ek fonksiyonları yazmak. Örneğin, Technorati’den veri gelmezse, tekrar deneme yapılacak mı? Kaç kere denenecek?

Bu tip detaylar…

Üçüncüsü, bu modülü ne zaman ve nasıl çalıştıracağıma karar vermek. Bunun içinde sunucu üzerinde bazı denemeler yapmak gerekiyor. Örneğin, bana üzerinde cron çalıştırmak için izin veriyor mu? Şayet cron iznim yoksa, scripti manuel çalıştırmak gerek.

Son olarak, iş puanlama algoritmasını çıkarmaya kalıyor. Bu iş aslında son derece basit. Tek bir zorluğu var; o da adil ama rekabetçi bir algoritma çıkarmak.

Umuyorum, bir ve iki numaralı maddeleri Pazar ve Pazartesi günü hallederim.

Regular Expressions, benim söylemeyi sevdiğim şekliyle RegEx, Türkçe’si ile “düzenli ifadeler”; eğer program yazıyorsanız ya da UNIX tabanlı sistemlerle haşır neşirseniz, kaçınılmaz olarak karşı karşıya geleceğiniz, muhtemelen de canınıza okuyacak bir konu.

PERL’in bu kadar çok sevilmesinin (kimilerince!) muhtemeldir ki, en iyi nedeni, barındırdığı güçlü RegEx desteği. Aslına bakarsanız, PHP, hem POSIX uyumlu, hem de (kısmen) PERL (PHP’de PCRE olarak geçer; Perl Compatible Regular Expressions) uyumlu RegEx desteği içeriyor. Dolayısıyla, artık Webmin gibi programların bile, PERL üzerinde diretmesinde bir anlam yok. PERL; öğrenmesi, program geliştirmesi uzun zaman alan, zahmetli bir dil. Geliştiricisinin de adını koyarken dediği gibi, “pathetically eclectic”. Eğer PERL öğrenme niyetinde iseniz, direk pas geçip PHP öğrenin derim. (Yeni programcı adayları için). Bu sayede, yazım ve çalışma biçimi hemen hemen aynı olan C ve JAVA gibi dilleri de öğrenmeniz daha kolay olacaktır.

Reg Ex konusu ise, farklı bir alan. Kaçınılmaz olarak karşınıza çıkacak. Size tavsiyem, programlama dilinden bağımsız olarak, Reg Ex’i ayrı bir “dilmiş gibi” öğrenmeye başlamanız. Çünkü, şimdiye kadar karşılaştığım en zor “dil”. Yüzde onunu bile bilmediğimi düşünüyorum (ben çok iyi bilirim diye sallayanı da gördük; bilgisayar dünyası palavra üzerinde dönüyor).

POSIX mi, PERL mi?

POSIX, daha evrensel gibi görünmesine karşın, maalesef GNU/Linux dünyası PERL’i pompalıyor gibi. POSIX standardı Reg Ex, bana daha kullanışlı, mantıksal geliyor. Aslında, PERL daha kuvvetli; ama Reg Ex’i daha da karmaşık hale getiriyor. Ben minimalizmi seviyorum; tek satırlık destan gibi Reg Ex yerine, işimi iki satırda, anlaşılır, bilgisayarın da “anlayıp”, kısa sürede işleyebileceği şekilde yapmak tercihim.

Reg Ex, Blogmani projesinde yine başıma bela oldu; öyleki, 1 saat içinde cümleyi tek satırda işleyemeyince, işi üç parçaya bölmeye karar verdim.

Reg Ex’i öğrenmek için en iyi kaynaklardan biri, GNU/Linux tabanlı bir sistemde çalışıyorsanız, bol bol SED & Gawk & vi kullanmak. Eğer Windows tabanlı bir sisteminiz varsa, EditPad Pro isimli, küçük ama herşeyi yapabilen metin editörünü tavsiye ederim.

Maalesef konuyla ilgili sistematik, iyi yazılmış belgelere, hatta kitaplara ulaşmanız pek mümkün değil. Bildiğim kadarıyla, sadece düzenli ifadeler üzerine yazılmış, Türkçe bir kitap yok.

Blogmani projemden daha önce bahsetmiştim.

İki gündür, projeyi kendi bilgisayarıma aldığım için hızlı ilerleyebiliyorum. Yaklaşık 20 gündür, sunucu üzerinde değişiklik yapıp, sonuçları bekleyerek boşu boşuna debelendim. Yarım saatlik bir emekten sonra, çok daha hızlı çalışabilmeye başladım. Her kodcunun bazı komik tembellikleri vardır; benimkisi de, çalışma hızı ve rahatlığını artıracak basit işlemlerden sürekli kaçınıyor olmak.

Şu an, basit bir komünite sistemi için “yeterli” olan bazı geliştirmeleri tamamladım. Umuyorum, gece server’a upload edeceğim. Şu haliyle site feci görünüyor ve bazı şeyler darmadağınık. Puanlama sistemini de halledince, Serhan’la birlikte tema gibi konulara da eğileceğiz ve biraz biraz kullanılabilir bir altyapı çıkacak ortaya.

Zamanımın çoğu, Wordpress’in bazı saçmalıklarıyla debelenmekle geçiyor. Bunlardan bir tanesi, usermeta isimli veritabanı tablosu. Nedense, bilinen tüm veritabanı tasarım kurallarına karşı gelerek, kullanıcı bilgilerinin tutulduğu tuhaf bir tablo hazırlamışlar. Wordpress, kullanıcı adı ve şifre gibi temel bilgileri users tablosunda tutarken, isim,soyad gibi bilgileri usersmeta isimli bir başka tabloda tutuyor. Bazı durumlarda, kullanıcı bilgilerini çekmek, deveye hendek atlatmaktan beter. Mümkün değil demiyorum; ama öylesine “çakma” çözümler geliştirmek zorundasınız ki, site büyüdüğünde (özellikle ziyaretçi sayısı arttığında) verdiğiniz yanlış kararların altında ezilmeniz işten bile değil. Bu yüzden, usersmeta’yı olduğu gibi bırakarak -çünkü bazı eklentiler ve iç fonksiyonlar onu kullanıyor ve hepsini değiştirmeye kalkmak, sistemi yeni baştan yazmaktan daha zor-, kritik alanları users tablosuna taşıdım.

Neyse ki, şu an için sorun yok. Aslında, kontrol panelinin tasarımı da ciddi zorlayıcı etkenlerden biri. Buna daha sonra geleceğim; sistem tamamlandıktan sonra, şayet kullanıcı sayısı artarsa, oraya da el atacağım.

Az önce, puanlama sistemine başladım.

Blograzzi’nin izinden gideceğim: Google, Technorati verilerini çekip, bunu başka parametrelerle birlikte kullanıp, puanlama sistemini yazacağım. Daha önce de bahsettiğim gibi, puanlama sır filan olmayacak. En sonunda algoritmayı açıklayacağım; bununla oturup kendi puanınızı kendiniz hesaplayabileceksiniz.

İlk olarak, Technorati verilerini çekmeye karar verdim…hatta çektim de. (Resmi büyütün).

Verileri çekerken izleyebileceğim birkaç metod vardı.

1.Kullanıcının sayfasını technorati içinden açıp, gelen HTML sayfayı parse ederek istediğim alanları çekmek. Bu daha önce yapmadığım iş değil. Hala birileri farkında olmasa da, PHP, RegEx (Regular Expressions – Düzenli İfadeler) konusunda neredeyse PERL kadar iyi; üstelik POSIX ya da PERL uyumlu Reg Ex kullanabiliyorsunuz.

Bunu yapmadım. Çünkü Technorati API’nin varlığından haberdarım ve daha önce bahsettiğim gibi, “uydurma” işleri sevmiyorum (mecbur değilsem, vaktim varsa)

2.Blograzzi’den verileri “çalabilirdim”. Bunu da doğal olarak yapmadım. Birincisi, özellikle veri, fikir ve bilgi hırsızlığına karşıyım. İkincisi, pragmatik bir çözüm olmasına rağmen, bu bir klon site değil. Aslında amacım bir yandan, daha önce Pozitif Linux’ta ve Pozitif PC’de yaptığım gibi, insanları teşvik etmek; birşeylerin sanıldığından çok daha kolay olduğunu göstermek.

3.Son olarak, Technorati API’yi kullanabilirdim ve bunu yaptım.

Gelgelelim, bunun bazı sakıncaları var.

Eğer para ödemezseniz, Technorati, API’si üzerinden, günde 500 query yapmanıza olanak tanıyor. Bunun anlamı şu: sonuçları günlük güncelleyeceksem, üye sayım 500′ü geçemez. Ya da para ödemem gerek, ama para kazanmadan doğal olarak Technorati’ye para verecek halim yok(!).

Birkaç API key almak da bir başka çözüm; kodda minik bir oynamaya bakar;)

Aslında API key’i limitsiz kullanabilsem, Blogmani içine çok çok daha kullanışlı bir dizi fonksiyon ilave edebilirdim. Öte yandan, buna zamanım ve isteğim de yok. Eminim, bir gün projeyi açarsam, birsürü insan bu tür siteler yapacaktır.

Technorati API’lerini kullanmak kolay olsa da, kod hamallığından kaçınmak için hazır bir kütüphane buldum. Duck Soup, bu işi hakkıyla yapıyor. Kodu inci gibi yazılmış. Gelgelelim, Technorati sunucuları pek hızlı sayılmaz; böylece Blograzzi’nin neden sonuçları anlık değilde günlük güncellediğini de keşfetmiş oldum.

Bundan sonra yapacağım şu: bir tablo açıp, Technorati’den çektiğim verileri günlük olarak buraya kaydedeceğim. Bunu da, günün “ölü saatlerinde” yapmam gerek ki, sunucum isyan etmesin. Bu arada, Linux tabanlı sunucumun Cron hakkında bana ne gibi haklar tanıdığını da öğrenmem gerek. Aslında, sunucu elimde olsa, yapacağım iş çok basit: cron.daily içine bir script atacağım; bu da PHP ile yazdığım, verileri toplayıp veritabanına giren PHP kodunu çalıştaracak (komut satırından, ya da shell script içinden, “php phpscriptim.php” şeklinde PHP kodu çalıştırabilirsiniz). Elbette, bu kadar hakkın, paylaşımlı bir sunucu içinde bana tanınmış olacağını sanmıyorum; ama birkaç saat içinde çözebileceğim, basit bir problem bu…