m.ozan.hazer

Aslında trendlere çok takılmayan, daha çok pratik bir fakat düzenli, kalıcı çözümler üretmeyi severim. O yüzden de standartları pek sevmem.

XHTML yazmam mesela, tableless design umrumda değildir, kod semantik olsun diye dert etmem. Bunların hepsi mutlaka yararları olan standartlar ama aynı zamanda vakit alan, uğraştırıcı şeyler. Ama kodun temiz ve anlaşılır, tüm tarayıcılarda düzgün çalışmasına dikkat ederim o ayrı.

O yüzden HTML validator, CSS validator türevi kodunuzun ne kadar standartlara uyduğunu kontrol eden programları da pek kullanmam, zira ota boka hata mesajı çıkartırlar.

Mesela bu programlara FotoKritik‘te fotoğraf listelediğim bir sayfayı verdiğimde (rakamları atıyorum) 187 tane hata bulundu diyor, bunlardan 170′i “IMG” tag’ına “ALT” özelliği koymamam nedeniyle…

Bilmeyenler için: ALT özelliği görme engeli olan kişiler için düşünülmüş bi komuttur ve standartlar mutlaka tüm imajlarda bu özelliğin bulunması gerektiğini söyler. Aslında gerçekten dikkat edilmesi gereken bir kural…

Allahaşkına FotoKritik bir fotoğraf sitesi, görme engelli arkadaşların yararlanmak isteyeceği belki de son kaynak. Banane ALT özelliğinden…

Allahtan sağolsun benimle benzer düşünen birileri oturmuş Firefox’a bir eklenti yazmışlar: HTML Validator. Bu eklenti sayesinde HTML kodundaki standart dışı ve hatalı kullanımları listelerken ilgili olmadığını düşündüğünüz hata mesajlarını bir daha göstertmeyebiliyorsunuz. Özellikle sayfa görüntüleme ile ilgili problemlerin keşfinde çok işe yarıyor.

Şu yazımda web geliştiricisinin olmazsa olmazı bazı araçları kısaca tanıtmıştım, bu listeye HTML Validator’ı da eklesem iyi olacak…

MySQL’in çoğu zaman gözden kaçan tablo tipi HEAP’ten bahsedesim geldi bugün. HEAP tipi tabloların özelliği MySQL’in bu tipteki tabloların verilerini doğrudan RAM’de tutması. Dolayısıyla disk I/O’suna bağlı olmadığı için çok yüksek hızda cevap verebilen bir tablo tipi.

Ancak RAM’de olması nedeniyle veritabanı sunucusunun yeniden başlatılması durumunda tüm veri haliyle kayboluyor. Ayrıca çok fazla veri kaydedilmesi durumunda sunucunun RAM’ini doldurma ihtimali de mevcut. Peki bu iki büyük engele rağmen neden böyle bir tablo tipine ihtiyaç duyulmuş?

Ben HEAP tabloları iki yerde kullanıyorum:

1. Session bilgisi
2. Kullanıcı cache

Session bilgisi dediğim PHP’nin session altyapısı değil. Session tablosunda o an online olan kullanıcıları, bağlandıkları IP adresini ve ihtiyaç duyduğum bazı birkaç kişiye özel bilgiyi ve son aksiyon zamanını tutuyorum. Böylece hatta kaç kişi online, hangi IP adresiyle bağlı takip etme imkanım oluyor. Aslında bunun bir ileri seviyesi PHP’nin session bilgisini tamamen bir HEAP tabloda tutmak.

PHP’nin session bilgisini böyle bir tabloda tutmak özellikle birden fazla web sunucusu ile yayın yaptığınızda faydalı olacaktır zira session datasını dosya sisteminde tutarsanız kullanıcı round robin ya da benzeri altyapılarla farklı sunuculara yönlendirildiğinde session bilgisi kaybolacaktır.

Cache

İkinci kullanım alanı ise kullanıcı cache’i. FotoKritik’te kullanıcıların hesap durumlarını her bir request’te kontrol ettirmem gerekiyor. Çünkü online kişiler kural dışı bir hareket yaptıkları anda hesapları moderatörler tarafından geçici ya da kalıcı olarak askıya alınabiliyor.

Ayrıca kullanıcıya yeni site içi mesaj gitmiş mi gibi bilgileri de sürekli sorguluyorum. Bu sürekli sorguları hafıza yerine disk üzerinden yapmak, az hit almayan bir sitede 15.000 devirli RAID yapılmış disklerinizi bile gereksiz bir yük altına sokabilir….

Bu iki tabloyu birleştirmek de mümkün olabilir, ben tercih etmedim ama önemli olan bu tarz sürekli yapılan ve sunucunun yeniden başlatılması durumunda kolayca tekrar yaratılabilecek bilgileri HEAP tipi tablolarda tutmanın gerçekten ciddi performans kazanımları sağlayacağıdır.

HEAP tablonun aşırı RAM tüketmesini engellemek için, tablo yaratılırken maksimum satır sayısını baştan belirleyebiliyorsunuz, ve belirlemenizi şiddetle tavsiye ederim ;)

Tamam ben de adrenalin bağımlısıyımdır ama bu maymun canına susamış :)

Nefret ediyorum trac’ten, bugzilla’dan, JotSpot’un gereksiz modüllerinden ve diğer abartılı ve kullanışsız bug takip sistemlerinden. Son favorim Basecamp idi ama bug takip sistemi değil proje yönetim sistemi olarak tasarlandığı için o da tam istediğimi yapmıyor.

Sanırım böyle düşünen tek kişi ben değilmişim ki Activereload firması Lighthouse adında güzel bir uygulama çıkarmış ortaya. Basecamp’ten esinlendiği ilk bakışta belli olan bu ürüne ilk görüşte kanım ısındı. Halen gelişmekte olan freemium bir uygulama ve Ruby on Rails ile yazılmış.

Şık tasarımı, e-posta ile ticket ekleyebilme, Basecamp’teki “milestone” ve “dashboard” kavramları ve henüz test etmediğim API imkanı ile işe yarar bir ürün gibi duruyor. İlgililere duyurulur…

Tek sorun bana göre biraz yüksek olan abonelik ücretleri.

“Dude, you can’t take something off the Internet.. that’s like trying to take pee out of a swimming pool.”

Temiz internet’le sansürü karıştıranlara duyurulur…

Web 2.0′ın bana göre en büyük farkı yaratan yanı RUI (rich user interface) ‘lerin yaratılmasında 2 şey önplana çıkıyor: firebug ve javascript framework’leri.

Prototype, ben de dahil olmak üzere birçok web geliştiricisinin hayatını kolaylaştıran süper bir javascript framework’ü. Prototype üzerine inşaa edilen script.aculo.us’un yaratılmasına neden olduğu için ayrı bir öneme sahip benim gözümde.

Bugün prototype’ın yaratıcısının blog’undan prototype ile nasıl kolayca javascript geliştirebileceği ile ilgili bir screencast‘in yayımlandığını öğrendim.

Screencast’i peepcode yayımlıyor, ama bana ilginç gelen yanı şirket bu screencast’leri satıyor. Daha da ilginç olanı sanırım satın almam :)

Başarılı olduğunu söylemem lazım, kesinlikle tavsiye edilir…